SOA特徵簡介與Web擴充服務的前景展望

web

什麼是服務導向架構（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）是受到廣泛支援的方法，用於描述服務要求者所要求的綁定到服務提供者的細節。服務描述的重點在於與下面幾部分互動所用的操作：

  服務
叫用作業的訊息
構造這種訊息的細節
關於向何處發送用於構造這種訊息的處理細節的訊息的資訊
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、SetShippingAddress、AddItem，等等。

  雖然細粒度的介面為要求者應用程式提供了更多的靈活性，它同樣也意味著互動的模式可能隨著不同的服務要求者而不同。這可能使對於服務提供者的支援更加困難。粗粒度介面保證服務要求者將以一致的方式使用服務。服務導向架構（SOA）不要求使用粗粒度介面，但是推薦使用它們作為外部整合的最佳實務。服務編排可以用來建立運行由細粒度操作組成的商務程序的粗粒度介面。

  服務品質需要考慮的問題

  服務導向架構（SOA）設計將跨越電腦系統，並且還可能跨越企業邊界。您不得不考慮在使用 Internet 時安全性功能和需求以及如何連結夥伴的安全域。網際網路通訊協定 (IP)並不是為可靠性（有保證的提交和提交的順序）而設計，但是您不得不確保訊息被提交並被處理一次。當這不可能時，要求者必須知道請求並沒有被處理。

  例如，您可能需要考慮您所部署服務的度量、可靠性以及回應時間，以便確保它們在承諾的範圍之內。當您設計使用來自其他業務夥伴的服務的系統時，您就不得不考慮面向服務的管理來以協作方式管理夥伴之間的服務。