小朱® 的技術隨手寫

早期企業在打造應用程式時，除了少數較宏觀的主導者以外，多數都是按照當下的需求以及業務條件來發展的，很少會有考量到軟體特性（例如Scalability、Extensibility、Maintainability等）的規劃。隨著時代的進步，物件導向程式設計與系統分析的發展，讓資訊產業開始重視軟體元件（Software Component）的概念，軟體元件的可重覆使用性愈高，則軟體元件的效益就會愈高，同時也代表該軟體的價值也愈高。但只要是在資訊產業涉足一段時間的人，通常都會知道資訊產業的主流總是掌握在幾個大廠商或是領導社群中，企業需要在不同的廠商標準間將內部所有的系統整併以維持或強化企業的資訊體質，系統整合（System Integration）在這段期間成為顯學，但如果要在不同組織所開發的系統間交流，除非是在同一個基礎，否則基本上是不太可能，這也是後來大廠間開始合作要發展統一標準的原因。隨著HTTP以及架構在其上的SOAP協定的發展，讓Web Service成為一個新的共通的系統資料交換的平台，也讓許多大廠可以在通訊協定統一的情況下，坐下來談整合的未來發展，並且進一步的訂定許多共用的資訊交換標準。這點對於大型企業應用程式來說十分重要，像是跨國型的ERP/SCM以及CRM或是EI等企業內或企業間交流的系統，由於與開發和營運成本有很大的關係，有了較開放的通訊方式以及服務的標準以後，開發人員通常不用再花太多時間與心力在整合不同的異質平台上。

基於這樣的基礎，某些大廠開始提出了服務可重覆使用性（Service Reusability）的概念，他們認為服務應該可以像軟體元件一樣，視用戶端的不同需求而取用，在通訊協定統一的情況下，這個想法是可以實現的，將系統置於統一管理的機房中，然後將必要的服務顯露給用戶端使用，且用戶端與伺服器端不需要關心彼此的平台是哪一種，這樣的作法可以讓系統的可服務範圍加大，與異質性的用戶端平台也更能相容。這個概念日後更進一步的演化成企業服務匯流排（Enterprise Service Bus; ESB）。而服務導向架構（Service Oriented Architecture）則更進一步的提供企業應用程式開發的概念方向，將軟體或應用程式以服務的方式顯露，由用戶端決定要存取哪一種服務，同時雙方不必關心各自的平台種類即可處理資料的交換與共享等。

當企業應用程式發展到以企業服務匯流排組成的架構時，應用程式就可以利用服務匯流排在不同的應用程式間進行資料的流動以及工作的處理，在這個時候，應用程式就需要提供兩個關鍵的應用程式支援：

• 存取控制（Access Control）：由於各式的服務是在服務匯流排上開放，且是在獨立伺服器上執行的，為了要確保應用程式存取是經過授權（authorized）的，需要有一個獨立的驗證與授權管理單元，類似在內部區域網路中Active Directory的角色一樣的集中帳戶管理以及授權服務提供者（Authentication and Authorization Provider），如此在服務匯流排上的所有驗證功能都由它來集中管理。同時這個集中的驗證與授權管理員也必須要能與其他驗證的協定相容，像是Open ID或OAuth（Open Authorization Protocol）這樣的開放式驗證與授權協定。
• 服務匯流排基礎服務（Service Bus Foundation）：為了要將各種類型的服務應用程式掛上匯流排，必須要有一個基礎服務，由應用程式模組實作，並開放一個供應用程式存取的入口（Entry Point），所有的應用程式都利用這個入口存取服務，這個入口的通訊協定視服務應用程式的位置決定開放的類型，例如TCP或是HTTP通道，同時這些通訊的方式必須要可以跨越防火牆，以利與其他企業的服務匯流排溝通。

 

Windows Azure AppFabric是實作在Windows Azure Platform之上，可建構服務導向架構之企業級應用程式的核心服務，讓應用程式開發人員得以利用 Windows Azure Platform實作出可支援雲端或本地端應用程式顯露出服務的服務匯流排，並且藉由存取控制功能來管制應用程式的存取權限。而在AppFabric的持續發展之下，微軟已將AppFabric視為新一代的應用程式伺服器（application server）平台，並持續發展相關的工具，日前已推出與memcached類似的中間層快取服務AppFabric Caching Service。AppFabric基本上是WCF的各式通訊服務雲端化的一個產品，WCF也是整個AppFabric平台最好的載具，因為WCF本身就支援合約（Contract）的概念，合約在服務應用程式中是很重要的資料結構定義概念，通訊的雙方都必須要遵守合約的規範，才可以進行合作（通訊），只要是資料結構相同，那麼服務匯流排只需要將相同的資料結構以不同的載具（協定）裝載並送到用戶端或服務進行處理即可，在AppFabric中所提供的Service Bus服務功能就是針對ESB的需求所設計的，它可以利用在雲端的優勢，作為企業應用程式服務的匯流排功能，用戶端與服務只需要處理來自AppFabric轉送的訊息，並且將回應送到AppFabric中即可，其他的轉送機制由AppFabric以及其上的匯流排應用程式（Service Bus Application）處理。

Windows Azure AppFabric Access Control Service（以下稱AC Service）是一個中間層的身份認證與授權的服務，它可以作為企業應用程式的單一簽入（SSO）

服務，在v1.0版時，AC Service允許企業直接以它作為帳戶資料庫，並透過不同應用程式的授權規則給予token，以作為登入認證的依據，而到了v2.0時，AC Service更允許透過Open ID和OAuth整合大型社群網路的供應商的帳戶進行SSO，一樣可以享有使用AC Service授權規則的優點，但不用再到AC Service中建立帳戶。

Windows Azure AppFabric Service Bus（以下稱為SB Service）則是作為企業服務匯流排應用程式的基礎，服務應用程式在SB Service中註冊一個端點，用戶端程式向SB Service搜尋得到端點後，透過經由SB Service的方式與服務進行連線與溝通，這個方式稱為Service Relay（服務轉送），它可以在不受防火牆的限制下串接用戶端與服務，亦可視用戶端與服務的網路狀態決定是否使用直接連線（Direct Communication），SB Service目前可實作下列訊息的通訊方式：

在SB Service 2.0中，又新增了一個類似Storage Service的Queue Storage的佇列服務，同樣是以穩定的佇列訊息為主打，但不論是哪一種訊息，服務和用戶端都要以WCF為標準來實作，這也就是說開發人員需要熟悉WCF，才可以利用Windows Azure AppFabric SDK中的Microsoft.ServiceBus.dll內建的通訊格式開發服務應用程式，面對WCF高學習曲線，開發人員可能要花更多的心力。

Windows Azure AppFabric Caching Service（以下簡稱Caching Service）是一個類似memcached的中間層分散式快取服務，作為雲端應用程式前端和資料庫之間的資料暫存區，善用它可以加速前端應用程式的回應時間，也可以降低資料存取的負擔。Caching Service可以作為ASP.NET應用程式的Session存放區，也可以作為全域快取（Global Data Cache）的資料存放區，在Windows Azure AppFabric SDK中也包含了Cache APIs以及可供ASP.NET直接使用的Cache Provider，以加速應用程式與Caching Service的整合。

最後，筆者認為會使用到Windows Azure AppFabric的多半是中大型應用程式，小型應用程式用到的機會不多（Caching Service也許會多一點），所以筆者不打算介紹細部的東西，如果對它有興趣的話，不妨參考MSDN邊做邊學的相關文章或書籍，也可以下載Windows Azure Training Kit，裡面有AppFabric的教學課程與Hands-on Lab可供實作練習。

Reference:

http://msdn.microsoft.com/en-us/library/ee922714.aspx

http://msdn.microsoft.com/zh-tw/windowsazure/gg722839

http://msdn.microsoft.com/en-us/wazplatformtrainingcourse_appfabric_unit