服務導向架構擴充Web服務的前景

服務導向架構擴充Web服務的前景

撰文/ Mark Colan

公元前221年，秦始皇將連年征戰的幾個國家統一為一個新國家，我們現在稱之為中國。中國作為一個國家存在下來的一個可能原因就是秦朝引入了標準，標準鞏固了文化，促進了貿易：標準的輪距使得馬車可以有效地行使在任何的道路，共同的書面語言使得每個人都可以交換資訊（即使他們說的並不是相同的語言），而堅固的工事（比如中國的長城）使得人們可以防禦外敵入侵。您甚至可以說，他們為標準化傳輸、訊息交換和防火牆開發了一些模型。
同樣地，現代的業務整合同樣也受益於標準，它使異構的電腦系統能夠有效地互操作。這些技術合在一起稱作Web服務。Web服務的出現是以 SOAP 1.1 的引入作為標誌的，SOAP 1.1 定義了將 XML 內容用於分布式系統，而同時隱藏實現的細節。四年後的今天，許多公司正在使用 Web 服務，並且可以毫無疑問地說，業界正處在 Web 服務主流時代的開端。
IBM 將服務導向架構（Service-Oriented Architecture，SOA）視為它的隨需應變（On Demand）業務前景的互通性和靈活性的關鍵。服務導向架構（SOA）支援跨企業和業務夥伴之間的端到端（End to End）整合。這就提供了一種靈活的商務程序模型，使得客戶可以迅速地響應新的顧客需求、新的業務機會以及競爭的威脅。

什麼是服務導向架構（SOA）？
服務導向架構（SOA）表示您可以如何使用 Web服務的大圖景。Web服務規範定義了實現服務以及與它們的互動所需要的細節。然而，服務導向架構（SOA）是一種用於構建分布式系統的方法，採用SOA這種方法構建的分布式應用程式可以將功能作為服務交付給終端使用者，也可以構建其他的服務。服務導向架構（SOA）可以基於Web服務，但是它可能改為使用其他的技術來代替。在使用服務導向架構（SOA）設計分布式應用程式時，您可以將 Web 服務的使用從簡單的用戶端-伺服器模型擴充成任意複雜的系統。
因而，單個的軟體資產成為開發其他應用程式的基本構件。您可以通過與新的代碼和遺留代碼一起使用的共同互動方式來減少系統的複雜性（CBDi的 Lawrence Wilkes開玩笑說，服務導向架構（SOA）可以代表“節省我們的資產（Save Our Assets）”）。有一種標準的方法可以用於表示這些軟體資產和與它們互動；現在人們關注的重點已經轉移到基於這些構件的應用程式裝配上來了。
雖然在這裡討論的是用於商務應用程式的服務導向架構（SOA），但是服務導向架構（SOA）同樣也可以用於其他的分布式系統，比如格線運算和進階 Web 服務規範（例如，Web 服務分布式管理（WS-DistributedManagement）、Web 服務信任（WS-Trust）以及 UDDI）。

什麼是服務？
在服務導向架構（SOA）中，服務（Service）是封裝成用於商務程序的可重用組件的應用程式函數。它提供資訊或簡化業務資料從一個有效、一致的狀態向另一個狀態的轉變。用於實現特定服務的流程並不重要，只要它響應您的命令並為您的請求提供高品質的服務就可以了。
通過定義的通訊協定，可以調用服務來強調互通性和位置透明性。一個服務表現為一個軟體組件，因為從服務要求者的角度來看，它看起來就像是一個自包含的函數。然而，實際上，服務的實現可能包括在一個企業內部的不同電腦上或者許多業務夥伴擁有的電腦上執行的很多步驟。就封裝的軟體而言，服務可能是一個組件，也可能不是一個組件。如同類對象，要求者應用程式能夠將服務看作是一個整體。
Web 服務是以使用 SOAP 訊息（它是用像 HTTP 這樣的標準協議上的 WSDL 來描述的）的調用為基礎的。使用 Web 服務的最佳實務就是與外部的業務夥伴通訊。

松耦合
服務要求者到服務提供者的綁定與服務之間應該是松耦合的。這就意味著，服務要求者不知道提供者實現的技術細節，比如程式設計語言、部署平台，等等。服務要求者往往通過訊息叫用作業——請求訊息和響應——而不是通過使用 API 和檔案格式。
這個松耦合使會話一端的軟體可以在不影響另一端的情況下發生改變，前提是訊息模式保持不變。在一個極端的情況下，服務提供者可以將以前基於遺留代碼（例如，COBOL）的實現完全用基於 Java 語言的新代碼取代，同時又不對服務要求者造成任何影響。這種情況是可實現的，只要新代碼支援相同的訊息模式。

明確定義的介面
服務互動必須是明確定義的。Web 服務描述語言（Web Services Description Language，WSDL）是受到廣泛支援的方法，用於描述服務要求者所要求的綁定到服務提供者的細節。服務描述的重點在於與下面幾部分互動所用的操作：
l 服務
l 叫用作業的訊息
l 構造這種訊息的細節
l 關於向何處發送用於構造這種訊息的處理細節的訊息的資訊
WSDL 不包括服務實現的任何技術細節。服務要求者不知道也不關心服務究竟是由 Java 代碼、C#、COBOL，還是由某種其他的程式設計語言編寫的。它可以描述使用 HTTP 的 SOAP 調用。由於它的擴充機制，它也可以定義其他類型的互動，比如通過 JMS 提交的 XML 內容、直接方法調用、由管理遺留代碼的適配器處理的調用（CICS），等等。
WSDL 的通用定義允許開發工具建立各種各樣類型的互動的通過介面，同時隱藏它是如何由應用程式代碼調用服務的細節。例如，如果服務是以多種互動類型公開的，Web 服務調用架構（Web Services Invocation Framework，WSIF）通過允許運行時決定調用高品質服務的最優方法來使用這種能力。

無狀態的服務設計
服務應該是獨立的、自包含的請求，在實現時它不需要從一個請求到另一個請求的資訊或狀態。服務不應該依賴於其他服務的上下文和狀態。當需要依賴時，它們最好定義成通用商務程序、函數和資料模型，而不是實現構件（比如工作階段金鑰）。當然，要求者應用程式需要服務調用之間的持久狀態，但是這不應該與服務提供者分開。
這裡有一個定義會話的錯誤方法的樣本：

Requester: “What is Bruce’s checking account balance??Provider:  “$x?Requester: “And what is his credit limit??Provider:   “$y?
提供者被要求記住請求之間 Bruce 的帳號，這就在服務實現中引入了複雜性。無狀態的服務設計將重新定義會話，如下所示：

Requester: “What is Bruce’s checking account balance??Provider:  “$x?Requester: “What is Bruce’s credit limit?"
Provider: “$y?  

服務粒度
操作的粒度是一項重要的設計要點。對於外部的消耗推薦使用粗粒度的介面，而細粒度的介面可用於企業內部。粗粒度介面可能是特定服務的完整處理，例如 SubmitPurchaseOrder，在這裡訊息包括定義訂購單所需的所有商務資訊。細粒度介面可能具有用於以下方法的不同操作：CreateNewPurchaseOrder、SetShipping-Address、AddItem，等等。
雖然細粒度的介面為要求者應用程式提供了更多的靈活性，它同樣也意味著互動的模式可能隨著不同的服務要求者而不同。這可能使對於服務提供者的支援更加困難。粗粒度介面保證服務要求者將以一致的方式使用服務。服務導向架構（SOA）不要求使用粗粒度介面，但是推薦使用它們作為外部整合的最佳實務。服務編排可以用來建立運行由細粒度操作組成的商務程序的粗粒度介面。

服務品質需要考慮的問題
服務導向架構（SOA）設計將跨越電腦系統，並且還可能跨越企業邊界。您不得不考慮在使用 Internet時安全性功能和需求以及如何連結夥伴的安全域。Internet協議並不是為可靠性（有保證的提交和提交的順序）而設計，但是您不得不確保訊息被提交並被處理一次。當這不可能時，要求者必須知道請求並沒有被處理。
例如，您可能需要考慮您所部署服務的度量、可靠性以及回應時間，以便確保它們在承諾的範圍之內。當您設計使用來自其他業務夥伴的服務的系統時，您就不得不考慮面向服務的管理來以協作方式管理夥伴之間的服務。

服務工作角色
同 Web 服務一樣，物件導向的體繫結構（SOA）中有兩個關鍵角色：服務要求者和服務提供者。一個或多個提供者應用程式通過發送請求訊息並處理響應訊息來提供服務，要求者應用程式調用這些服務。
一些服務提供者同時也是服務要求者：它們聚集其他服務提供者的功能來構造複合的更進階別的服務。通過使用Java、C#或者象商務程序執行語言（BPEL）那樣的特殊編排語言來完成這種組合。
一些像UDDI和WS-Trust的SOA技術提出了第三種角色，叫做服務代理（Service Broker）。 服務代理是服務提供者和服務要求者之間的中介——服務本地化，代理程式管理方案等等。
使用這三種角色建模的實體使用服務調用（Service Invocation，例如SOAP訊息）來通訊。

服務調用
W3C SOAP1.2規範在服務要求者和服務提供者之間定義使用XML格式的訊息進行通訊。將應用程式請求（封裝在XML中）放入SOAP信封中（也是XML），並從要求者到提供者發送應用程式請求，提供者發回的響應也採用相同的形式。市場上的大部分產品支援早期的 SOAP1.1規範，但是在未來產品發布中將支援 SOAP1.2。由於已經有許多關於SOAP的內容，進一步內容請參閱相關的的出版物。
因為SOAP是平台無關和廠商無關的標準，因此在帶有單獨IT基礎架構的夥伴之間的松耦合互操作中，SOAP是支援服務調用的最好方法。然而，SOA不需要使用SOAP。
例如，在SOAP之前，一些公司使用IBM WebSphere MQ來給其它的電腦發送XML文檔，其他電腦依據這些文檔執行應用程式操作。使用 HTTPS介面的eBey XML以相似的方式來傳遞用於拍賣的物品條目。雖然由於沒有使用SOAP而不能調用Web服務，但是仍然可以在SOA中調用服務。當然，目前WebSphere MQ也對 SOAP訊息提供了直接支援。
只要所有的實體是用Java語言編寫，那麼就可以僅僅使用J2EE中的可用功能來建立SOA。然而，這種方法不能為非Java應用程式的互通性提供令人滿意的解決方案。
在企業內部需要為IT系統控制碼的地方，可以考慮使用SOAP之外的服務調用方法，這些方法可能沒有構建並解析XML內容。這就會有更好的效能，並且可以避免圍繞現有功能編寫SOAP封裝代碼。出於對簡單性的需求，能夠使用其他協議調用服務的單一調用API樣式是一個很好的實踐。

多重協議服務調用
JAX-RPC規範（也叫 JSR-101）定義了一個 Java API，使從 Java 程式中調用 Web 服務變得簡單。JAX-RPC實現至少必須支援使用HTTP的 SOAP1.1。然而，為了服務調用它可能還支援其他的協議。 多重協議服務調用能夠使用相同的API指定不同的協議，例如改變URL。
WebSphere Application Server目前的版本中的 JAX-RPC實現是 JSR-101-compliant，但允許簡單的通過將URL修改為對JMS伺服器（比如 WebSphere MQ）定址的形式來使用JMS上的SOAP調用。在不久的將來，這種多重協議樣式將允許使用IIOP上的RMI 進行服務調用，以使EJB服務實現有效互操作。
簡單性的關鍵是不考慮協議而使用相同的API。讓這成為可能的是在WSDL中描述協議的能力，這些協議不同於HTTP上的SOAP。

服務描述
Web服務描述語言（WSDL）規範定義了一個 XML詞彙表，該詞彙表依照請求和響應訊息，在服務要求者和服務提供者之間定義了一種契約。你能夠將 Web服務定義為軟體，這個軟體通過描述SOAP訊息介面的WSDL文檔來提供可重用的應用程式功能，並使用標準的傳輸協議來進行傳遞。
WSDL描述包含必要的細節以便服務要求者能夠使用特定服務：
l 請求訊息格式
l 響應訊息格式
l 向何處發送訊息
WSDL是基於XML的，因此WSDL文檔是電腦可讀的（Machine-Readable）。這樣開發環境使用WSDL 將整合服務的流程自動處理到要求者應用程式。例如 WebSphere Studio產生一個 Java 的代理對象，它能夠像本機物件一樣實現服務，但是實際上代理對象僅僅處理請求的建立和響應訊息的解析。不管服務是否用 Java，C#或者其他的語言實現，產生的Java代理對象都能夠從 WSDL 描述中調用任何的 Web 服務。實際上，WSDL不能像程式設計語言那樣描述實現細節。
WSDL使用它的擴充功能並通過與HTTP上的 SOAP不同的協議來支援服務定義。依據SOA，你能夠將任何可以用WSDL描述介面的應用程式功能稱為服務。當SOA不特別的需要WSDL時—你可以使用其他服務描述語言—目前大部分廠商和產品都支援 WSDL。

資訊交換模式
在流行的要求-回應（Request-Response）交換模式中，服務要求者向服務提供者（或端點）發送請求訊息，處理完請求之後，提供者將響應訊息發送給要求者。服務互操作可以是會話式的，由若干對要求-回應構成。然而，為了效能、設計的簡單性和從松耦合中獲得好處，設計粗粒度介面是一個好辦法，它能夠將事務需要的交換數量最小化。
除了要求-回應模式之外，WSDL還定義了以下內容：
l 將單向（One-way）訊息發送到端點—例如，不需要響應的請求：
l 從端點發送的單向訊息，叫做通知：
l 要求-響應（Solicit-Response） 模型，端點通過它發送訊息和接收響應：
目前SOA實現通常使用HTTP，導致了同步通訊 —在處理之前要求者等待響應。同步交換用於預期完成時間相對較短（幾秒或幾分鐘）的服務。
也可能有非同步服務互操作，在非同步服務互操作中服務要求者不等待響應，而是期望以後交付響應。這適合於長時間啟動並執行事務。例如調用一個商務程序來請求指定的客機報價，流程包括許多夥伴或人的互操作，這要花幾天或是幾周來完成。使用非同步交換能夠避免失去串連（因為伺服器維護等等）以及因此而失去響應的風險。
Web服務定址（WS-Addressing）規範將Reply-to地址作為SOAP信封前序元素的擴充。服務要求者將請求排隊放入WSDL文檔中指定的連接埠，但是不需要等待。相反，在響應到達之前，它做其他的工作。當服務提供者準備發送響應時，使用SOAP中的Reply-to地址：請求訊息的前序。
使用像WebSphere MQ這樣的訊息佇列產品時，可以使用JMS來實現同步訊息。要求者可以選擇為請求排隊但是不等待處理的完成。當執行其他工作時，要定時檢查響應隊列中的響應。
你可以應用同步訊息的方法來建立其他的交換模式，比如接收多重通知請求（例如在股票報價變更的通知）。
服務發現
儘管服務調用和服務描述通常被認為是SOA的需求，但服務發現也是它的可選功能。UDDI（通用描述、探索與整合協議）為發布服務的可用性和發現所需服務定義了一個標準介面（基於SOAP訊息）。UDDI實現將發布和探索服務的SOAP請求解釋為用於基本資料存放區的資料管理功能調用。
為了發布和發現其他Web服務，UDDI通過定義標準的SOAP訊息來實現服務註冊（Service Registry）。註冊是一種服務代理，它是在UDDI上需要探索服務的要求者和發布服務的提供者之間的中介。一旦要求者決定使用特定的服務，開發人員通常藉助於開發工具（例如IBM WebSphere Studio 或者Microsoft Visual Studio .NET）並通過建立以發送請求並處理響應的方式訪問服務的代碼來綁定服務。
發現用於構建SOA應用程式的服務，其結果就象電子黃頁一樣。你可以使用工具（比如WebSphere中的UDDI Browser）在應用系統設計期間尋找合適的服務。SOA不需要使用UDDI，但由於UDDI是建立在 SOA上來完成自身工作的，所以UDDI是服務發現的一個好的解決方案。
正如在Steve Graham的文章“Six Species of UDDI”中提到的，你能夠用多種不同的方法使用UDDI。本文特別指出了在IT組織內 UDDI 的使用，主要是為了管理內部服務以提高可重用性以及進一步促進端點無關性。例如，應用程式中可能會緩衝所需服務的位置。如果服務重新部署到不同的伺服器當中，服務要求者能夠使用UDDI發現新的位置並將它緩衝以備將來使用。當內部部署UDDI時，使用 UDDI服務要求者應用程式將自動適應於服務部署的變更（例如，為維護Server Load Balancer而做的變更）。
隨著UDDI的發展，它將廣泛的用於發現由市場模型中其他組織所提供的公用可用的（Publicly-A協議vailable）商務服務。正如我們將在關於服務編排的文章中所討論的，UDDI在運行時對服務的UDDI動態選擇方面很有用的。

結束語
本文重點講解的是，在服務導向架構（SOA）中擴大軟體資產價值的同時控制分布式應用程式中的複雜性所帶來的好處。它也定義了服務的性質並分析了它們的特徵、以及一些最佳實務。同時本文討論了SOA的基本元素以及它們相互發現和互操作的方法。你通過開發服務類別目錄（內部的或夥伴的）來建立基於SOA的IT體繫結構，並編寫代碼使用這些服務來開發出新的應用程式。由於服務提供者能夠通過請求其他服務來完成自己的工作，在設計上就可以使用服務的分層結構。雖然簡單的要求-回應訊息模型最為流行，但是你可以使用其他的訊息模型靈活的設計系統。WSDL 文檔告訴你如何整合服務，UDDI協助你找到所需的服務。