SOA 比 Web Services 涵义更广.docVIP

SOA 比 Web Services 涵義更廣時間：2004-08-31作者：Steve Wilkes 下面是相當常見的狀況，在街上問一個略懂技術的人有關服務導向架構（SOA）概念，首先浮現他腦海的將是Web Services，這一點都不讓人驚訝，儘管SOA已經存在一段時間了，但在Web Services的助力之下，已使得SOA這個詞彙的名聲大幅上升。為了使我們有所共識，定義本文SOA如下：“SOA是一種設計和實作企業應用程式的方法，應用程式處理那些透過定義良好、平台獨立的介面約定（interface contracts）來擷取鬆散耦合、粗粒度（業務層級）、可重覆使用元件（服務）的互通問題。”很清楚的是該定義不包含用來呼叫服務的通訊協定或者線路格式。不同於其他服務為基礎的方式，真正的SOA鼓勵透過不同方法存取服務而不只是HTTP之上的SOAP。本文的目的是以此點為基礎展開的。本文提供其它選擇的服務呼叫模式並且解釋為什麼SOA要比Web Services涵義更廣。背景服務基礎的概念在Web Services之前就有很長並且成功的歷史了。常見的物件請求代理體系結構（Common Object Request Broker Architecture ，CORBA）已經存在多年並且提供許多至今仍被稱許的SOA優點。根據我們的定義，很明顯CORBA不是一個真正的SOA實作。儘管CORBA有一個透過IDL（介面定義語言）定義的平台獨立的服務約定和一個支援不同語言和平台的實作，但是它需要一個稱為IIOP（Internet Inter-ORB Protocol）的特定通訊協定和標準化的線路格式。此外，編譯IDL以產生存根（stub）和骨架(skeleton)的需求表示產生的應用程式是緊密耦合的。如果我們將SOA的範圍縮小為只是Web Services，我們將有一個相似的故事。WSDL代替了IDL，並且服務透過一個特定的（雖然成本較低但更流行）具有標準線路格式（SOAP）的協定（HTTP）來呼叫。使用現在的開發環境，可以從WSDL產生存根和骨架，並且產生更具緊密耦合性的服務。當我們放寬這些限制並且使得服務可以透過不同協定呼叫的時候，真正SOA的威力就顯現出來了。協定的問題問你自己這樣的問題“我的組織內部使用了多少種不同的協定處理內部通訊？”根據公司規模的不同，你可能使用了HTTP、HTTPS、訊息代理（JMS、MQ、MSMQ等）、CORBA和SMTP。你可能也意識到了，EJB的遠端呼叫或者遠端物件上一個方法的簡單執行都將利用諸如JRMP這樣的協定。你將意識到的其他事情是，為一個特定情況選擇協定經常並非以真正的使用案例分析為基礎，而是建立在當前的實作上，選擇的依據通常是現有基礎設施或者選擇最快的和最容易的路由來整合。該問題的另一個方面是整合機制可能透過轉接器、打包器或者委託機制使用現有的原始碼並且沒有嘗試去確定通訊顆粒度的正確水準。在一個真正的SOA中，上面提到的所有協定都可以為服務提供一個擷取點。原則上，一個服務可以透過服務介面被定義一次，但可以利用不同擷取協定產生許多實作。這一點是目前用來描述服務語言WSDL中最明顯的一點。WSDL去掉W儘管WSDL的名字是Web Services描述語言，實際上它並沒有描述Web Services。它有一個獨立於通訊協定或資料格式的核心服務定義框架，該核心框架描述了組成一個服務的操作和每次請求和回應中傳送的資料，處於該層之上的是綑綁延伸，它將一個特定的協定或格式附加到一個訊息、操作或者擷取點上。一般的理解認為WSDL描述了Web Services，而SOA是關於Web Services的，這種理解來自於延伸到SOAP、HTTP和MIME綑綁的核心框架的混淆方式就包含在最初的WSDL規範中。以這些綑綁為例子包含在規範中是為了讓使用方法更清楚，但是正如規範中聲明的：“不排除在WSDL中使用其他綑綁延伸。”根據上面的說明，我們可以明白WSDL規範的作者希望用它從總體上來描述服務，將這些綑綁範例與解決特定使用案例的現有技術結合，增加此規範的相關性。WSDL的完全形式鼓勵將服務綑綁到多個協定；關鍵是決定哪個協定最適合特定場合。最佳實務產生完美的產品任何單一服務都有很多呼叫服務的方法。假設服務已經綑綁到很多協定，一個IT架構師如何決定在一個特定範例中使用哪種方法呢？下表總述普遍的協定屬性和資料格式：傳輸協定同步性資料格式描述HTTP同步或非同步表單（Get / Post）、XML、SOAP遠端、無安全性、平台獨立、組織內部或外部服務擷取HTTPS同步或非同步表單（Get / Post）、XML、SOAP遠端、安全性、平台獨立、組織內部或外部服務擷取JMS非同步XML、SOAP、Java物件在通訊Java環境中點對點或者發佈訊息SMTP非同步基於情境的、XML、SOAP組織內部或外部遠端訊息傳輸Proprietary Message Broker非同步XML、SOAP專利在專有環境中點到點或發佈訊息CORBA同步CORBA物件在潛在異質環境中直接遠端物件呼叫Native Distributed Objects同步COM+、EJB /RMI、.NET遠程在本機環境中直接遠端物件呼叫Native Object同步本機資料類型在本機環境中本機物件擷取應該了解的是，對於分散式和本機物件技術，服務導向方法的應用程式不代表執行很多高顆粒度的方法呼叫。如果我們應用最佳實務，應該假設這些物件包含了可以接收複雜資料結構的商業層級的方法。藉由舉例的方法，想像一個管理採購訂單的本機物件並使用企業資源達將它們永久保存，該物件可能有方法能夠建立訂單、添加項目、設定客戶資訊等。在本機層級呼叫這些方法不會引起任何問題，但是如果我們使用遠端或者非同步協定，由很多遠端呼叫引起的效能問題就很明顯了，解決方案是提供一個單一方法接收包含整個訂單全部資料結構的物件以添加一個訂單。該方法可以透過服務介面來描述，並且透過分層技術可以經由多種協定來擷取。不用更改服務簽名，要改的只是通信協定和資料有線格式。下圖解釋了如何實作分層。既然這樣一個服務可以透過很多協定擷取，接下來就由服務使用者決定哪一種協定與特定範例和技術集彼此間最相符。當考慮資料線路格式時，就引起另外一個複雜問題，如同前面表中所示，每一種協定都支援多種格式的資料，上圖中也意含會在不同資料格式需求之間轉換資料。為了討論方便我們假設本機物件提供的方法接受通過所有層次傳播的XML。下表再次列出這些協定並且解釋什麼時候應該使用何種協定擷取由打包的本機物件所提供之相同服務。傳輸協定推薦使用方法HTTP服務可能位於組織外部的遠端機器上，提供服務的平台與客戶平台不同。可能需要同步擷取服務使能夠立即傳達回應給客戶；在回傳或者輪詢結果時則需要非同步操作；而可靠擷取該服務沒問題，安全性則不必要HTTPS除了需要一個安全驗證連結之外，其他與HTTP相同JMS服務和客戶都位於可以擷取JMS提供者的Java平台上，服務不需要立即給予回應，服務請求傳送確認是必要的，傳送或接收訊息是一個交易的一部分，安全性如驗證和授權等是選擇性的SMTP服務和客戶都可以擷取SMTP引擎，但是在直接通訊中或者是位於不同平台上都不是必要的。服務不需要立即給予回應，不需要交易支援，確認傳輸也不是必須的，沒有安全性需求Proprietary Message Broker服務和客戶都可以擷取訊息代理，但是可以在不同的平台上。不需要服務立即給予回應，服務請求傳輸確認是必要的，傳送和接收訊息是一個交易的一部分，安全性是選擇性的CORBA服務和客戶都可以擷取物件請求代理（ORB）並且可以經由IIOP通訊。為了能夠立即傳達回應給客戶，同步擷取該項服務是必要的。服務請求是一個交易的一部分。安全性是選擇性的Native Distributed Objects儘管不需要位於相同的實體機器上，但服務和客戶必須位於相同的本機平台並且使用直接通訊。為了能夠立即傳達回應給客戶，同步擷取該項服務是必要的。服務請求是一個交易的一部分。安全性如驗證和授權等是選擇性的Native Objects服務和客戶都位於相同的本機平台並且位於相同的實體機器上。為了能夠立即傳達回應給客戶，同步擷取該項服務是必要的。不需要交易支援。安全性則不必要要為一個特定範例選擇適當的協定，那麼就需要考慮服務使用的情境和整體系統的可靠性、效能和安全性需求。SOA使得事情變得容易提供多種方法呼叫相同服務的明顯副作用在於開發中所提供必要的分層技術費用。在本機物件上執行一個方法可能只需要一行原始碼；建立一個JMS並將它放在一個佇列中或尋找它並縮小遠端分散式物件需要多得多的工作。要在這樣的環境中達到高生產率，所有這些事情應該變得同樣容易。實際上，呼叫服務應該使用相同的機制，獨立於底層的實作。在WebLogic平台中，控制項正好扮演這樣的角色。服務的建立者可以建立接受XML的Java控制項並執行比如說建立一個購物訂單的所有工作。這是由本機物件實作的（在此場景後面，Java控制項可能使用了Java流程，能依次執行其他服務，但是這在另一篇文章中討論）。一個附加的步驟可以由此控制項建立一個Java Web Services（JWS）（現在根據需要而支援HTTP或HTTPS），也可以建立一個使用此Java控制金的Java頁面流，使可以直接由Web擷取到該服務（也是一種HTTP或者HTTPS格式）。如果需要遠端物件擷取，可以建立一個有Session Bean（本機分散式物件）的EJB專案，透過一個流程代理將其委派給一個Java流程。另外，EJB控制項提供介面使能透過HTTP或JMS提供現有的EJB，EJB編譯選項允許透過CORBA擷取EJB並使EJB產生IDL和Stub。可以透過兩種方式添加JMS支援。首先，JWS可以透過jws：協定標籤直接綑綁到JMS，或者在WSDL中透過JMS綑綁到以服務為基礎的JAXRPC。另外，可以建立一個Java流程來監聽JMS佇列並且在接收到訊息的時候委託Java控制項處理訊息中包含的XML。透過訂閱一個Email頻道，可以使用類似的流程提供SMTP支援。用同樣的方法可以支援其他訊息代理。下表對這些內容做了一下總結：傳輸協定WebLogic 平台元件HTTPJWS、JAX-RPC Web Services或者頁面流動作HTTPSJWS、JAX-RPC Web Services或者頁面流動作JMSJWS或者具有JMS綑綁的JAX-RPC Web Services、具有JMS訂閱的JPDSMTP具有Email訂閱的JPDProprietary Message Broker具有訊息代理訂閱的JPDCORBAEJB編譯選項允許產生IDL和CORBA的存根Native Distributed Objects具有Session Bean的EJB專案Native ObjectJava控制項（JCS）服務的客戶同樣很容易使用服務。在Workshop中，可以使用各種內建的控制項輕鬆地擷取Web Services、EJB、JMS佇列、訊息代