IT架構師該如何對應用程式實施SOA架構

        圍繞SOA的宣傳熱潮似乎是一浪高過一浪。軟體供應商和分析師樂於向媒體提供資訊，藉此大肆吹捧自己的產品和技術特點。一些供應商聲稱他們的產品為實現SOA不斷努力，另一些人儘管可能正在或多或少的使用著這些產品，但他們更願意認為SOA在更大的程度上只是一種架構模式。

　　不論市場上有什麼樣的說法，重要的是要認識到任何一個SOA基礎架構產品都是實現SOA的方法之一，是人們在實現SOA這一路走到現在的一個裡程碑，但同時，這並不意味SOA的完結，SOA本身還要繼續發展。平台軟體能夠為整個企業的服務架構，提供必要的主幹網路，但是選擇怎樣的方案只能依據企業的具體需要來定。

　　目前普遍使用的企業服務匯流排(enterprise service bus，ESB)就是這樣一類軟體。最近的一些創新產生了一些搔動和困擾。所有的ESB供應商都說使用他們的ESB產品為面向服務的技術架構提供核心組件。然而，大多數供應商仍然是努力組成一個ESB，他們的產品僅僅具有普通ESB應該具備的功能。

　　設身處地想象一下，作為IT架構師，負責對應用程式實施SOA架構。你應該作些什麼?這真的非常簡單，你只需回到業務需求一塊，只要服務調節指揮和架構模型能夠滿足業務需求即可。

　　服務調節

　　調節(Mediation)並不是一個新概念。在傳統的物件導向的文獻中,眾所周知, 調節者(mediator)是推動“松耦合”(loose coupling)的一種模式, Mediator可以用來控制和協調這些對象間的相互調用,避免他們之間的複雜調用造成混亂甚至死迴圈,同時使邏輯更加清晰,需要改變某些邏輯時也很容易實現。

　　用服務替代上一句中的對象,這樣你就可以很好地理解什麼是服務調節。然而, 在SOA中服務調節不僅可以用來控制和協調這些服務間的相互調用(儘管這種相互間的調用是一個好的開始)。在強調技術中立性的服務世界裡, 基於XML的資訊互動作用更可以使多事情都變成可能,只要你在服務生產者和服務消費者之間放置一合格的調節者。

　　傳輸協議轉化

　　通常,服務提供者基於某種傳輸協議(例如HTTP)提供服務,而服務消費者只能通過另一種不同的協議(比如MQ)通訊。 因此,也許需要在服務提供者與消費者之間建立一座非同步起動同步啟動並執行串連橋樑,超越HTTP和Java Messaging ServiceMessage Service(JMS)等協議.從技術角度講, Java Messaging ServiceMessage Service(JMS)並不是一種傳輸協議,而是一組供應商中立(vendor-neutral)的通訊APIs。正1所示,非同步Web服務實施通常表現為 “簡易物件存取通訊協定 (SOAP)(SOAP)服務在JMS之上,”而在使用傳輸協議的背後是供應商特定(vendor-specific)的,如MQ或Tibco RV。

　　這種現象在有很多遺留軟體的環境中非常普遍,這些遺留軟體的服務已被開啟,而其它應用程式卻因為傳輸協議不配不能使用這些服務。與其建立一個新的協議適配器或在執行服務提供者的基礎上實施非同步起動同步運行橋樑,還不如讓調節者來解決這些差異不同,做必要的轉換。這樣服務開發人員只需要集中精力解決服務邏輯問題,可以讓基礎結構軟體負責調節責任。

　　資料格式轉化

　　即使在同一機構中,不同部門對於業務實體的定義也會不一樣。財務部可能有特別的客戶結構,它區別於從開發帳單角度定義的客戶。這種情況下,一個開發帳單中與客戶相關的服務就不能在沒有弄清資料模型區別的情況下採用財務部的服務。

　　你可以努力使每個人都接受一個公用的定義(如使用被提議的標準資料模型),不過這種方法在大型主機構中可能並不十分有效。最好的方法就是讓斡旋組件來解決不同格式的轉化問題.甚至可以讓服務介面只處理標準資料模式,不過服務消費者則將需要配置斡旋組件來轉化其資料格式,使之成為服務提供者要求的資料格式。

　　執行服務政策

　　讓調節者來解決服務提供者與服務消費者之間的互動問題,這使得在兩者之間阻止XML傳輸變得十分簡單,需要採取必要的步驟來保證政策的執行—例如以適當審查,日誌監測和安全檢測的方式。

　　其次,以調節組件代替這些橫切關注點(cross-cutting concerns)使服務開發人員不需要一定在服務層滿足調節需求.當然,如果這是你面臨的唯一調節需求,那麼實施像面向方面編程(Aspect-oriented programming,AOP)這樣的基於技術的橫切解決方案是最划算的。

　　服務處理器傳輸途徑

　　傳輸途徑和過濾器架構模式介紹了多用途訊息預先處理程式和後置處理常式如何提高訊息處理迴圈速度。一個調節平台能夠以宣告的形式為服務呼叫構成這樣的過濾器，允許我們通過改變過濾器配置，改變這些呼叫預先處理和後置處理組件的順序。

　　這些預先處理程式包括訊息內容基礎上的服務路徑，背景或商務規則，訊息富集，訊息加密/解密，訊息複製等等(1)。在這裡，調節的核心價值不是在於能夠提供一些開發人員無論如何都要建立的處理常式，而是在於它能在宣告的形式下使任意處理常式的組合變得簡單易行。

　　服務呼叫與調度

　　還記得關於服務提供者與服務消費者之間“松耦合”(loose coupling)的部分嗎?如果服務消費者直接與服務提供者相互作用，那麼在不影響服務消費者的情況下改變服務提供者的介面(不是實施，無論如何實施獨立於介面)會是個難題。換句話說，服務消費者永遠都與服務提供者緊緊地聯絡在一起。

　　然而，如果服務消費者只與中間人調節相互作用，同時調節服務保證不改變它與服務消費者介面，那麼很顯然調節者可以為不同版本的服務派發服務呼叫，甚至是對不同服務介面。很明顯，這種情況下仍然需要調解誒(就是必要的轉化)，但是重要的是，它使服務消費者與服務提供者相對獨立。

　　服務編製

　　與服務調節不同，服務調節本質上就是配置一個中間組件作為即時中介軟體的一部分，而編製具備與服務內容和服務實施相關的功能。編製技術也是基於中介軟體，它能建立一個高度集中的架構，來管理設計商務程序的定義以及商務程序邏輯的操作執行。