引言
SaaS 現在算得上 SOA 之外的另一個熱門名詞，SaaS 是 Software-as-a-Service（軟件即服務）的簡稱，是隨著互聯網技術的發展和應用軟件的成熟，而在 21 世紀開始興起的一種完全創新的軟件應用模式。
它是一種通過 Internet 提供軟件的模式，廠商將應用軟件統一部署在自己的服務器上，客戶可以根據自己實際需求，通過互聯網向廠商定購所需的應用軟件服務，按定購的服務多少和時間長短向廠商支付費用，並通過互聯網獲得廠商提供的服務。用戶不用再購買軟件，而改用向提供商租用基於 Web 的軟件，來管理企業經營活動，且無需對軟件進行維護，服務提供商會全權管理和維護軟件，軟件廠商在向客戶提供互聯網應用的同時，也提供軟件的離線操作和本地數據存儲，讓用戶隨時隨地都可以使用其定購的軟件和服務。對於許多小型企業來說，SaaS 是采用先進技術的最好途徑，它消除了企業購買、構建和維護基礎設施和應用程序的需要。
在這種模式下，客戶不再象傳統模式那樣花費大量投資用於硬件、軟件、人員，而只需要支出一定的租賃服務費用，通過互聯網便可以享受到相應的硬件、軟件和維護服務，享有軟件使用權和不斷升級，這是網絡應用最具效益的營運模式。
SaaS 重要術語簡術語簡介
多重租賃 (Multi-tenancy)
SaaS 的“多重租賃”概念就是，多個公司將其數據和業務流程托管存放在 SaaS 服務商的同一服務器組上，相當於服務商將一套在線軟件同時出租給多個公司，每個公司只能看到自己的數據，由服務商來維護這些數據和軟件。也就是說，多個公司登錄到同一網站，但登錄後看到的界面和數據，每個公司都不相同。
跨界混搭 (mash-up)
“跨界混搭”這個術語起源於流行音樂，編曲者把兩張唱片混編以後重新制作出一首新歌。這個概念應用在 SaaS 上，就是指把多個不同的在線應用軟件服務搭建成為一種新型的整合服務。用戶通常只需要登錄一次就可以使用集成好的組合應用軟件。
解決方案擴展 (Solution extension)
SaaS 解決方案具有的擴展性讓用戶能夠在已存在的軟件結構上，按需增加額外的工具或功能。還有一些擴展性例如可以擴展數據模型，提供個性化的用戶界面以及其他更多自定制的擴展服務。
垂直應用 (Vertical applications)
“垂直應用”不是 SaaS 的專用術語，它也應用於其他領域，通常是指為某一個領域（例如銀行，醫藥等）建立一個專門的平台。雖然它已經在傳統行業應用很多年了，但是相對來講應用在 SaaS 中還是一個比較新的概念。
參數應用 (Parametric applications)
在傳統軟件模式下，如果軟件的服務功能需要改變，那麼相應的代碼也需要重新編寫。但是在 SaaS 模式下，用戶可以通過輸入新的參數變量，或者制定一些數據關聯規則來開啟一種新的應用。這種新式服務模式也被稱為“參數應用”，“宏”或“自定制對象”，主要是因為這種應用程序可以讓用戶自己定制新的應用，而不需要懂軟件編程。
模塊化 (Modular)
SaaS 中模塊的功能主要用於關閉或開啟服務。在聚集了豐富功能的強大應用平台中，IT 經理可以像選擇菜單那樣任意地選擇功能，關閉某些不需要用到的功能，也可以根據需求增加新的功能。 SaaS 服務商基於網絡架構建立了自己的應用平台，模塊的靈活性使得他們可以根據客戶的不同需求，將功能復雜繁多的系統配置成適合客戶的系統。
SaaS 應用特點
與傳統軟件模式相比，SaaS 具有低建設成本、低維護成本、低投入風險和低應用門檻等四大特點。
SaaS 給軟件開發商打開了一個新的市場領域，就是軟件應用可以像電信運營商提供給客戶電信服務一樣提供相應地企業管理軟件服務；軟件開發商可以成為軟件運營服務提供商，而軟件運營服務具有以下三個特點：
軟件的功能為多個組織所重用和共享。在傳統的軟件中，一個軟件的功能為單個個人或組織所擁有，每個軟件實例只管理這個個人或組織內用戶的數據。在軟件服務的模式下，同一個軟件的功能為多個組織所重用和共享，同一個軟件實例同時管理多個用戶或組織的數據。如何將不同用戶和組織的數據進行有效管理將是一個具有挑戰性的課題。
所有軟件活動統一管理。傳統的軟件維護困難的主要原因之一是軟件活動分散於用戶端，軟件版本不統一，軟件維護工作需要根據不同的版本進行不同的操作。軟件服務的模式把分散的軟件集中起來統一管理，這樣既提高了工作效率，同時也降低了成本。
基於互聯網訪問和管理應用軟件。在當今時代，把軟件轉變成服務的一個有利且必備的條件是互聯網技術。通過網絡來配置管理提供給用戶的服務，軟件服務提供商能夠把這種服務提供給全球范圍內的任何用戶；分散在各地的用戶都可以享受同一種優質的服務，而不受時間和地域的限制。毫不誇張地說，互聯網的發展促成了軟件服務這種軟件發布的模式，大大改變了人們的生活和工作方式。
SaaS 應用面臨的挑戰
SaaS 應用還面臨著很多挑戰，這其中包括技術上存在的難點、缺乏殺手級的應用、商業模式的不清晰以及對於傳統營銷模式的顛覆。我們在這裡主要闡述的是 SaaS 應用所面臨技術上的挑戰。
系統性能的挑戰
當一個應用系統在初期運行階段的時候，由於用戶少、數據量少；所以應用系統能夠提供非常好的服務質量（如響應速度相當快），給用戶的感覺就是應用系統很快。當隨著用戶數的上升、數據量的增大，應用系統的性能急劇下降，具體的反應就是應用系統很慢並且老是出錯、甚至系統經常沒有響應。而對於面對互聯網的應用系統 Saas 應用出現這樣的情況將更加的頻繁，然而出現這個問題的症結在哪呢？我們怎麼樣來避免它呢？
一個現代的應用系統基本上都是建立在 B/S 架構的基礎上，通過具體的層次來劃分看基本上分為以下幾層：
界面展現層
AJax 技術在這方面帶來了創新，通過 JavaScript+Html+XML( 或者 JSON)，在浏覽器裡實現了與桌面應用等同的界面效果 , 帶來了極好地交互體驗，以及很容易與後台的業務邏輯層模塊進行交互；並且很容易避免由於采用 J2EE 架構中的 JSP 技術而給後台的應用服務器帶來多余的壓力等問題，讓應用服務器專注於處理業務邏輯而不關心產生具體的頁面；以及避免了界面交互性不友好的弊病。
業務邏輯層
在 J2EE 架構中，我們一般采用 Servlet 或者 EJB 來操作具體的企業信息系統（如數據庫）或者消息系統（如 JMS）來實現具體的業務邏輯。由於 EJB 的缺陷以及 Spring 技術的興起 , 業務邏輯層基本上都采用 Servlet+Spring 來實現。
數據層
比如說是關系型數據庫。有些架構中可能會是指相應訪問數據庫的邏輯封裝層（如采用 Hibernate/ibitas 技術來訪問數據庫封裝層）。
從上面三層就能很容易演化出下圖所示的軟件系統架構：
圖 1. 軟件系統架構圖
由於界面表現層的代碼運行在用戶端機器上的浏覽器中，並且通過這個軟件系統架構圖我們可以看到要使一個 SaaS 應用成為一個能夠承載高並發、高數據量的應用系統，關鍵就是使 SaaS 應用所依賴的底層系統具有非常高的性能和伸縮性，即需要有高性能、高伸縮性的數據庫系統，高性能、高伸縮性的中間件 ( 如 J2EE 應用服務器 )。我們如何去解決這個問題呢？請詳細參考：如何實現高性能、高伸縮性的架構
系統安全性的挑戰
SaaS 用戶很多都是中小企業，他們采用 SaaS 應用後對於安全的最擔心的地方可以分成以下幾個部分：
數據傳輸的安全性
由於用戶采用浏覽器並且通過互聯網訪問部署在軟件運營商端的 SaaS 應用，用戶需要 SaaS 應用的軟件提供商保證在互聯網上傳輸的數據的是安全的、是可靠的，因為這些傳輸數據（如客戶資料、財務資料等）對他們來說非常的重要。
眾所周知，我們可以采用 CA 證書以及 SSL v3 技術來保障這一點，並且在 HTTP SERVER 以及 J2EE 應用服務器都支持 HTTP SSL 功能，從而可以保障客戶的數據傳輸安全性。但是通過 HTTP SERVER 來實現 SSL 功能的效率太低，如果我們采用組建 VPN 網絡的話對運營商來說成本太高，我們需要采取什麼樣的措施來解決這個問題呢？請詳細參考：如何實現高性能、高伸縮性的架構
數據存儲的安全性
在軟件運營商端的 SaaS 應用是給不同客戶來使用的，也就是說是給不同的企業來使用的。對用戶來說他就非常擔心其它企業是否可以看到他們企業的數據。
並且這裡還存在一個非常大的挑戰就是，由於數據是存放在軟件運營商端的數據庫系統中，在數據庫系統中都存在一個超級用戶，而這個數據庫超級用戶都是軟件運營商的所擁有，由於數據對用戶來說非常重要，用戶對此就會產生這樣的一個需求，就是不希望軟件運營商的數據庫管理員也能夠查看和訪問他們的數據。我們需要采取什麼樣的措施來解決這個問題呢？詳細請見：DB2 V9.5 的安全控制功能
系統是否很容易被攻擊？
請詳細參考：如何實現高性能、高伸縮性的架構
系統可靠性的挑戰
由於非常大量的用戶都會使用軟件運營商提供的 SaaS 應用，用戶就會有以下幾個擔心：
軟件運營商提供的 SaaS 應用是否經常很容易崩潰以及無法提供服務？
軟件運營商提供的 SaaS 應用的崩潰以及無法提供服務的主要原因是以下幾個：
一是應用代碼有問題；
二是數據庫服務器在高並發用戶的情況經常崩潰；
三是應用服務器經常崩潰或者一個應用服務器無法承受如此大的壓力。
我們需要采取什麼樣的措施來解決這個問題呢？請詳細參考：如何實現高性能、高伸縮性的架構
數據是否能夠可靠的存儲？
由於數據是保存在數據庫系統中，數據庫系統是否能夠提供一個很好的數據備份 / 恢復、數據卸載 / 掛接的功能。我們需要采取什麼樣的措施來解決這個問題呢？請詳見參考資料中 DB2 的表分區以及備份 / 恢復功能的相應文檔。
系統如何提供不同的服務質量？
就像中國移動公司它劃分了三個品牌全球通、神州行、動感地帶，這三個品牌提供了不同的服務質量。而對於提供 SaaS 應用的軟件提供商來說它也面臨這樣一個問題，就是不同的客戶需要不同的服務質量從而付出不同的資費，如不同的客戶需要不同的響應時間，形象一點來說就好比有這樣的一個場景，有 5 個用戶同時發起 5 個請求到數據庫端，而這個 5 個用戶具有不同的服務等級，對於數據庫端來說它就應該以更多的資源服務服務等級最高的用戶，以較少的資源服務服務等級較低的客戶，從而使不同服務等級的客戶具有不同的服務質量。這樣能夠使軟件運營商的 SaaS 應用更具有適應性、更具有競爭力、更能創造價值。我們需要采取什麼樣的措施來解決這個問題呢？詳細的解決方式請見：DB2 V9.5 的工作負載管理功能的闡述。
DB2 V9.5 的工作負載管理功能
對於 系統如何提供不同的服務質量 的相應的需求，可以概述成以下的敘述：一個 SaaS 應用程序可能由三個不同用戶使用。一個用戶可能希望響應時間平均值小於 2 秒，而其他兩個用戶可能對 5 秒的響應時間就感到滿意了。並且對於達到響應時間平均值小於 2 秒的用戶收取較多的資費，而對於達到 5 秒的響應時間的用戶收取較低的資費。
並且由於 SaaS 應用的特點（如高並發），導致它所依賴的數據庫活動量非常大，系統資源（如 CPU、I/O 和內存）的爭用情況非常的普遍，如果要達到上面所述的服務質量將非常的困難，為了實現上面所述按需提供 SaaS 用戶所需要的服務質量功能，我們將需要利用 DB2 V9.5 中提供的工作負載管理引擎。通過利用 DB2 V9.5 中的工作負載管理引擎將輕松的達到我們所需要的功能即針對不同等級的用戶按需提供不同的服務質量。
DB2 V9.5 的工作負載管理引擎概述
DB2 V9.5 的工作負載管理功能使您可以更深入地洞察系統的運行情況並更好地控制資源和性能。DB2 V9.5 的這項功能執行以下任務：
通過使用工作負載定義自動標識工作、將工作負載分配給服務類並將資源分配到每個服務類，可以將工作劃分為易管理的邏輯組。您可以捕獲詳細的工作負載概要文件和性能信息，以幫助優化您的工作負載定義和服務類定義。
您可以通過成本、時間和並行性阈值來控制執行情況，這使您可以控制流氓查詢並有助於達到服務級別協議（SLA）目標。通過使用阈值，系統可以自動對不良情況作出反應或在它發生前進行預測。當您控制了長時間運行且復雜的查詢的影響後，您就可以使事務保持平穩運行。
您可以跟蹤處理的每個階段，以便可以為用戶提供最新的狀態信息。
下圖顯示如何評估發送至數據服務器的多個請求、如何將它們分配到特定的工作負載以及如何在適用的服務類中執行這些請求。不能與您定義的工作負載匹配的請求將分配到缺省工作負載，然後在缺省服務類中執行此工作負載。
圖 2. 服務類和工作負載
工作負載管理引擎具體實現概述
SLA 是組之間的一個正式協議，它定義組之間的期望值並包含服務、優先級和職責等各項的目標。SLA 目標通常使用響應時間目標來表示。例如，特定的“人力資源”報表可能需要在平均 5 分鐘內運行完成。
增強的 DB2 工作負載管理功能可以幫助您標識一組已定義的數據庫活動並將它們隔離在自己的執行環境中，您可以對這些活動分配達到您的目標所需要的適當資源。在環境或服務類中，您可以顯式管理系統資源，以便較重要的資源可供較高優先級的工作使用，並可以控制或消除與較低優先級工作的爭用情況。
您通過對每種不同類型的客戶使用服務類來隔離數據服務器上的活動。例如，您可以按組來設置工作負載，然後對該組分配一個具有較少資源的不同服務類。在您設置服務類後，您可以輕松地收集並監視聚集活動統計信息，以確保滿足每個客戶的 SLA 目標。從而使您可以根據接收到的服務級別對每個客戶進行收費。
示例如下：我們假設一個 SaaS 應用程序可能由三個不同用戶使用。用戶 1 可能希望響應時間平均值小於 2 秒，而用戶 2 和用戶 3 可能希望 5 秒之內的平均響應時間；從這可以看出這裡有兩個服務等級，服務等級 1 需要的服務質量是使服務的響應時間在 2 秒之內，服務等級 2 需要的服務質量是使服務的響應時間在 5 秒之內。於是我們在 DB2 V9.5 中定義兩個服務類：
ServiceClass1（這個服務類具有更多的系統資源）和ServiceClass2（這個服務類具有較少的系統資源）；然後把 ServiceClass1 賦給用戶 1，ServiceClass2 賦給用戶 2 和用戶 3。通過這樣的配置，我們就能夠實現所需要的功能。
DB2 V9.5 的安全控制功能
在現今最常見的采用 J2EE 架構的三層架構應用系統中，我們經常會運用 J2EE 應用服務器提供的安全控制功能，來控制不同用戶具有訪問不同業務邏輯模塊（如用戶 1 只能訪問某個 Servlet、用戶 2 只能訪問某個 EJB 或者某個 EJB 提供的方法），從而實現了相應的權限控制；然後在訪問數據庫的時候，我們通常會利用 Spring 框架或者 J2EE 應用服務器提供的連接池來訪問數據庫，從而可以實現連接的復用而降低了經常建立物理連接的開銷。相應的架構圖如下圖所示：
圖 3. 常見的安全控制的 J2EE 應用系統架構圖
但是在使用系統提供的連接池功能的時候我們都是使用數據庫系統提供的某個用戶名、密碼來訪問數據庫，這樣就失去了在數據庫系統這一級提供的豐富的安全控制功能；如在數據庫系統中我們建立了 DBUSER1 具有相應的特權，而 DBUSER2 具有其它相應的特權；然而采用上圖所示的架構功能，這樣對數據庫系統來說僅僅只有一個 DBUSER1 這個用戶來訪問自己；然而對於整個系統來說有 USER1 、USER2、 USER3 這三個用戶需要在數據庫系統這一級進行詳細的安全控制。這樣的架構就導致整個系統失去了強大的數據庫安全能力來控制對數據的訪問。
很多軟件開發商為了避免這樣的問題，一般都會在數據庫系統中建立相應的表結構來控制相應的訪問權限或者通過 J2EE 應用服務器提供的一些功能來進行用戶上下文的切換，但是這樣的方法帶來的代價就是性能的開銷以及控制的粒度不夠，特別是無法實現對表中數據訪問進行行一級的控制，如用戶 1 只能查看表 A 中的某些行，而用戶 2 只能查看表 A 中其它的一些行。
特別針對 SaaS 應用來說，它是給不同客戶來使用的，也就是說是給不同的企業來使用的。就必須實現針對行一級訪問的安全控制，即客戶 A 和客戶 B 運行同樣的一條 SQL 語句，然後數據庫系統必須返回符合相應的權限的數據給不同的客戶即客戶 A 和客戶 B 看到的數據是不一樣；並且 SaaS 應用必須還要實現 SaaS 應用的軟件運營商的數據庫管理員也不能夠查看數據庫系統中的數據，這樣才能夠讓用戶放心，讓用戶感受到只有它自己才能夠查看到專屬它自己的數據而其它任何人是看不到的即使是軟件運營商的數據庫管理員。
為了實現這樣的兩個主要功能，以及避免圖3 所示架構的系統所帶來的缺陷，我們需要利用 DB2 V9.5 中提供的基於標號的訪問控制 (LBAC) 和可信上下文增強這兩個功能來實現相應的解決方案 . 通過利用 DB2 V9.5 提供的這兩個功能我們稍微修改下架構就可以解決 SaaS 應用以及其它應用所面臨的問題。如下圖所示：
圖 4. 改進後的安全控制的 J2EE 應用系統架構圖
改進後的架構圖與原有的架構圖的區別僅僅就是在數據庫系統采用了 DB2 V9.5，並且啟用了 DB2 V9.5 的 LBAC 和可信上下文功能；然後簡單的修改在 J2EE 應用服務器上相應的代碼就可以實現充分利用 DB2 V9.5 提供的完整的安全控制功能。當利用了 DB2 V9.5 這兩個功能後，相應的流程就改變成這樣：
我們在 DB2 V9.5 中，針對企業 1、企業 2、企業 3 建立相應的用戶名 DBUSER1、DBUSER2、DBUSER3。並針對這些用戶建立相應的 LBAC 控制信息，從而可以實現這些用戶能夠應用同一條 SQL 就能訪問出符合不同用戶權限的不同的數據。
我們確定在 J2EE 應用服務器連接池中連接 DB2 V9.5 的用戶名 (user) 和密碼 (passWord)，並在 DB2 V9.5 建立此用戶名和密碼。並且利用 DB2 V9.5 提供的 TRUSTED CONTEXT 語句建立相應的可信上下文。
在 J2EE 應用服務器配置相應的用戶名 (DBUSER1、DBUSER2、DBUSER3)，並且在 J2EE 應用服務器上實現這三個用戶的認證來自於 DB2 V9.5 的對應的 DBUSER1、DBUSER2、DBUSER3 這三個用戶。
對 J2EE 應用服務器的 DBUSER1、DBUSER2、DBUSER3 這三個用戶在應用服務器中的不同權限，如依照 J2EE 安全標准實現這三個用戶具有訪問不同 SERVLET 或者 EJB 的權限機制。
