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 Service消息服務(JMS)等協議.從技術角度講, Java Messaging Service消息服務(JMS)并不是一種傳輸協議,而是一組供應商中立(vendor-neutral)的通信APIs。正如圖1所示,異步Web服務實施通常表現為 “簡單對象訪問協議(SOAP)服務在JMS之上,”而在使用傳輸協議的背后是供應商特定(vendor-specific)的,如MQ或Tibco RV。

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

　　數據格式轉化

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

 

原文轉自：http://www.kjueaiud.com