[轉]SOA、WebService、UDDI、WSDL、SOAP、MSMQ概念

轉自http://space.itpub.net/6517/viewspace-172812

SOA是什麼？因為不做程式不做java，慢慢的這些詞既不敢碰也不敢學了...

 面 向服務的體系結構（Service-Oriented Architecture，SOA）是一個元件模型，它将應用程式的不同功能單元（稱為服務）通過這些服務之間定義良好的接口和契約聯系起來。接口是采用 中立的方式進行定義的，它應該獨立于實作服務的硬體平台、作業系統和程式設計語言。這使得建構在各種這樣的系統中的服務可以一種統一和通用的方式進行互動。

這 種具有中立的接口定義（沒有強制綁定到特定的實作上）的特征稱為服務之間的松耦合。松耦合系統的好處有兩點，一點是它的靈活性，另一點是，當組成整個應用 程式的每個服務的内部結構和實作逐漸地發生改變時，它能夠繼續存在。而另一方面，緊耦合意味着應用程式的不同元件之間的接口與其功能和結構是緊密相連的， 因而當需要對部分或整個應用程式進行某種形式的更改時，它們就顯得非常脆弱。

對松耦合的系統的需要來源于業務應用程式需要根據業務的需要變 得更加靈活，以适應不斷變化的環境，比如經常改變的政策、業務級别、業務重點、合作夥伴關系、行業地位以及其他與業務有關的因素，這些因素甚至會影響業務 的性質。我們稱能夠靈活地适應環境變化的業務為按需（On demand）業務，在按需業務中，一旦需要，就可以對完成或執行任務的方式進行必要的更改。

雖 然面向服務的體系結構不是一個新鮮事物，但它卻是更傳統的面向對象的模型的替代模型，面向對象的模型是緊耦合的，已經存在二十多年了。雖然基于 SOA 的系統并不排除使用面向對象的設計來建構單個服務，但是其整體設計卻是面向服務的。由于它考慮到了系統内的對象，是以雖然 SOA 是基于對象的，但是作為一個整體，它卻不是面向對象的。不同之處在于接口本身。SOA 系統原型的一個典型例子是通用對象請求代理體系結構（Common Object Request Broker Architecture，CORBA），它已經出現很長時間了，其定義的概念與 SOA 相似。

然而，現在的 SOA 已經有所不同了，因為它依賴于一些更新的進展，這些進展是以可擴充标記語言（eXtensible Markup Language，XML）為基礎的。通過使用基于 XML 的語言（稱為 Web 服務描述語言（Web Services Definition Language，WSDL））來描述接口，服務已經轉到更動态且更靈活的接口系統中，非以前 CORBA 中的接口描述語言（Interface Definition Language，IDL）可比了。

Web 服務并不是實作 SOA 的惟一方式。前面剛講的 CORBA 是另一種方式，這樣就有了面向消息的中間件（Message-Oriented Middleware）系統，比如 IBM 的 MQseries。但是為了建立體系結構模型，您所需要的并不隻是服務描述。您需要定義整個應用程式如何在服務之間執行其工作流。您尤其需要找到業務的操 作和業務中所使用的軟體的操作之間的轉換點。是以，SOA 應該能夠将業務的商業流程與它們的技術流程聯系起來，并且映射這兩者之間的關系。例如，給供應商付款的操作是商業流程，而更新您的零件資料庫，以包括進新供應的貨物卻是技術流程。因而，工作流還可以在 SOA 的設計中扮演重要的角色。

此外，動态業務的工作流不僅可以包括部門之間的操作，甚至還可以包括與不為您控制的外部合作夥伴進行的操作。是以，為了提高效率，您需要定義應該如何得知服務之間的關系的政策，這種政策常常采用服務級協定和操作政策的形式。

最後，所有這些都必須處于一個信任和可靠的環境之中，以同預期的一樣根據約定的條款來執行流程。是以，安全、信任和可靠的消息傳遞應該在任何 SOA 中都起着重要的作用。

我可以用面向服務的體系結構做什麼？

對 SOA 的需要來源于需要使業務 IT 系統變得更加靈活，以适應業務中的改變。通過允許強定義的關系和依然靈活的特定實作，IT 系統既可以利用現有系統的功能，又可以準備在以後做一些改變來滿足它們之間互動的需要。

下 面舉一個具體的例子。一個服裝零售組織擁有 500 家國際連鎖店，它們常常需要更改設計來趕上時尚的潮流。這可能意味着不僅需要更改樣式和顔色，甚至還可能需要更換布料、制造商和可傳遞的産品。如果零售商 和制造商之間的系統不相容，那麼從一個供應商到另一個供應商的更換可能就是一個非常複雜的軟體流程。通過利用 WSDL 接口在操作方面的靈活性，每個公司都可以将它們的現有系統保持現狀，而僅僅比對 WSDL 接口并制訂新的服務級協定，這樣就不必完全重構它們的軟體系統了。這是業務的水準改變，也就是說，它們改變的是合作夥伴，而所有的業務操作基本上都保持不 變。這裡，業務接口可以作少許改變，而内部操作卻不需要改變，之是以這樣做，僅僅是為了能夠與外部合作夥伴一起工作。

另一種形式是内部改 變，在這種改變中，零售組織現在決定它還将把連鎖零售商店内的一些地方出租給專賣流行衣服的小商店，這可以看作是采用店中店（store-in- store）的業務模型。這裡，雖然公司的大多數業務操作都保持不變，但是它們現在需要新的内部軟體來處理這樣的出租安排。盡管在内部軟體系統可以承受全 面的檢修，但是它們需要在這樣做的同時不會對與現有的供應商系統的互動産生大的影響。在這種情況下，SOA 模型保持原封不動，而内部實作卻發生了變化。雖然可以将新的方面添加到 SOA 模型中來加入新的出租安排的職責，但是正常的零售管理系統繼續如往常一樣。

為 了延續内部改變的觀念，IT 經理可能會發現，軟體的新配置還可以以另外的一種方式加以使用，比如出租粘貼海報的地方以供廣告之用。這裡，新的業務提議是通過在新的設計中重用靈活的 SOA 模型得出的。這是來自 SOA 模型的新成果，并且還是一個新的機會，而這樣的新機會在以前可能是不會有的。

垂直改變也是可能的， 在這種改變中，零售商從銷售他們自己的服裝完全轉變到專門通過店中店模型出租地方。如果垂直改變完全從最底層開始的話，就會帶來 SOA 模型結構的顯著改變，與之一起改變的還可能有新的系統、軟體、流程以及關系。在這種情況下，SOA 模型的好處是它從業務操作和流程的角度考慮問題而不是從應用程式和程式的角度考慮問題，這使得業務管理可以根據業務的操作清楚地确定什麼需要添加、修改或 删除。然後可以将軟體系統構造為适合業務處理的方式，而不是在許多現有的軟體平台上常常看到的其他方式。

正如您可以看到的，在這裡，改變和 SOA 系統适應改變的能力是最重要的部分。對于開發人員來說，這樣的改變無論是在他們工作的範圍之内還是在他們工作的範圍之外都有可能發生，這取決于是否有改變 需要知道接口是如何定義的以及它們互相之間如何進行互動。與開發人員不同的是，架構師的作用就是引起對 SOA 模型大的改變。這種分工，就是讓開發人員集中精力于建立作為服務定義的功能單元，而讓架構師和模組化人員集中精力于如何将這些單元适當地組織在一起，它已經 有十多年的曆史了，通常用統一模組化語言（Universal Modeling Language，UML），并且描述成模型驅動的體系結構（Model-Driven Architecture，MDA）。

對于面向同 步和異步應用的，基于請求/響應模式的分布式計算來說，SOA是一場革命。一個應用程式的業務邏輯（business logic）或某些單獨的功能被子產品化并作為服務呈現給消費者或用戶端。這些服務的關鍵是他們的松耦合特性。例如，服務的接口和實作相獨立。應用開發人員 或者系統內建者可以通過組合一個或多個服務來建構應用，而無須了解服務的底層實作。舉例來說，一個服務可以用。NET或J2EE來實作，而使用該服務的應 用程式可以在不同的平台之上，使用的語言也可以不同。

SOA有以下特性

SOA服務具有平台獨立的自我描述XML文檔。Web服務描述語言（WSDL， Web Services Description Language）是用于描述服務的标準語言。

SOA 服務用消息進行通信，該消息通常使用XML Schema來定義（也叫做XSD， XML Schema Definition）。消費者和提供者或消費者和服務之間的通信多見于不知道提供者的環境中。服務間的通訊也可以看作企業内部處理的關鍵商業文檔。

在 一個企業内部，SOA服務通過一個扮演目錄清單（directory listing）角色的登記處（Registry）來進行維護。應用程式在登記處（Registry）尋找并調用某項服務。統一描述，定義和內建 （UDDI， Universal Description， Definition， and Integration）是服務登記的标準。

每項SOA服務都有一個與之相關的服務品質（QoS， quality of service）。QoS的一些關鍵元素有安全需求（例如認證和授權），可靠通信（譯注：可靠消息是指，確定消息“僅且僅僅”發送一次，進而過濾重複資訊。），以及誰能調用服務的政策。

為什麼選擇SOA？

不 同種類的作業系統，應用軟體，系統軟體和應用基礎結構（application infrastructure）互相交織，這便是IT企業的現狀。一些現存的應用程式被用來處理目前的業務流程（business processes），是以從頭建立一個新的基礎環境是不可能的。企業應該能對業務的變化做出快速的反應，利用對現有的應用程式和應用基礎結構 （application infrastructure）的投資來解決新的業務需求，為客戶，商業夥伴以及供應商提供新的互動管道，并呈現一個可以支援有機業務（organic business）的構架。SOA憑借其松耦合的特性，使得企業可以按照子產品化的方式來添加新服務或更新現有服務，以解決新的業務需要，提供選擇進而可以 通過不同的管道提供服務，并可以把企業現有的或已有的應用作為服務， 進而保護了現有的IT基礎建設投資。

如圖1的例子所示，一個使用SOA的企業，可以使用一組現有的應用來建立一個供應鍊複合應用（supply chain composite application），這些現有的應用通過标準接口來提供功能。

服務架構

為了實作SOA，企業需要一個服務架構，圖2顯示了一個例子：

在 圖2中， 服務消費者（service consumer）可以通過發送消息來調用服務。這些消息由一個服務總線（service bus）轉換後發送給适當的服務實作。這種服務架構可以提供一個業務規則引擎（business rules engine），該引擎容許業務規則被合并在一個服務裡或多個服務裡。這種架構也提供了一個服務管理基礎（service management infrastructure），用來管理服務，類似稽核，清單（billing），日志等功能。此外，該架構給企業提供了靈活的業務流程，更好地處理控 制請求（regulatory requirement），例如Sarbanes Oxley（SOX），并且可以在不影響其他服務的情況下更改某項服務。

SOA基礎結構

要運作，管理SOA應用程式，企業需要SOA基礎，這是SOA平台的一個部分。SOA基礎必須支援所有的相關标準，和需要的運作時容器。圖3所示的是一個典型的SOA基礎結構。

SOAP， WSDL， UDDI

WSDL，UDDI 和SOAP是SOA基礎的基礎部件。WSDL用來描述服務；UDDI用來注冊和查找服務；而SOAP，作為傳輸層，用來在消費者和服務提供者之間傳送消 息。SOAP是Web服務的預設機制，其他的技術為可以服務實作其他類型的綁定。一個消費者可以在UDDI系統資料庫（registry）查找服務，取得服務 的WSDL描述，然後通過SOAP來調用服務。

WS-I Basic Profile

WS-I Basic Profile，由Web服務互用性組織（Web Services Interoperability Organization）提供，是SOA服務測試與互用性所需要的核心構件。服務提供者可以使用Basic Profile測試程式來測試服務在不同平台和技術上的互用性。

J2EE 和 .Net

盡 管J2EE和。NET平台是開發SOA應用程式常用的平台，但SOA不僅限于此。像J2EE這類平台，不僅為開發者自然而然地參與到SOA中來提供了一個 平台，還通過他們内在的特性，将可擴充性，可靠性，可用性以及性能引入了SOA世界。新的規範，例如 JAXB（Java API for XML Binding），用于将XML文檔定位到Java類；JAXR（Java API for XML Registry）用來規範對UDDI系統資料庫（registry）的操作；XML-RPC（Java API for XML-based Remote Procedure Call）在J2EE1.4中用來調用遠端服務，這使得開發和部署可移植于标準J2EE容器的Web服務變得容易，與此同時，實作了跨平台（如。NET） 的服務互用。

服務品質

在企業中，關鍵任務系統（mission-critical system，譯注：關鍵任務系統是指如果一個系統的可靠性對于一個組織是至關重要的，那麼該系統就是該企業的關鍵任務系統。比如，電話系統對于一個電話 促銷企業來說就是關鍵任務系統，而文字處理系統就不那麼關鍵了。）用來解決進階需求，例如安全性，可靠性，事物。當一個企業開始采用服務架構作為工具來進 行開發和部署應用的時候，基本的Web服務規範，像WSDL，SOAP，以及UDDI就不能滿足這些進階需求。正如前面所提到的，這些需求也稱作服務品質 （QoS，quality of services）。與QoS相關的衆多規範已經由一些标準化組織（standards bodies）提出，像W3C（World Wide Web Consortium）和OASIS（the Organization for the Advancement of Structured Information Standards）。下面的部分将會讨論一些QoS服務和相關标準。

安全

Web 服務安全規範用來保證消息的安全性。該規範主要包括認證交換， 消息完整性和消息保密。該規範吸引人的地方在于它借助現有的安全标準，例如，SAML（as Security Assertion Markup Language）來實作web服務消息的安全。OASIS正緻力于Web服務安全規範的制定。

可靠

在典型的SOA 環境中，服務消費者和服務提供者之間會有幾種不同的文檔在進行交換。具有諸如“僅且僅僅傳送一次”（ once-and-only-once delivery），“最多傳送一次”（ at-most-once delivery），“重複消息過濾”（duplicate message elimination），“保證消息傳送”（guaranteed message delivery）等特性消息的發送和确認，在關鍵任務系統（mission-critical systems）中變得十分重要。WS-Reliability 和 WS-ReliableMessaging是兩個用來解決此類問題的标準。這些标準現在都由OASIS負責。

政策

服務提供者 有時候會要求服務消費者與某種政策通信。比如，服務提供商可能會要求消費者提供Kerberos安全标示，才能取得某項服務。這些要求被定義為政策斷言 （policy assertions）。一項政策可能會包含多個斷言。WS-Policy用來标準化服務消費者和服務提供者之間的政策通信。

控制

當 企業着手于服務架構時，服務可以用來整合資料倉庫（silos of data），應用程式，以及元件。整合應用意味着例如異步通信，并行處理，資料轉換，以及校正等程序請求必須被标準化。在SOA中，程序是使用一組離散的 服務建立的。BPEL4WS 或者 WSBPEL（Web Service Business Process Execution Language）是用來控制這些服務的語言。WSBPEL目前也由OASIS負責。

管理

随着企業服務的增長，所使用的服務 和業務程序的數量也随之增加，一個用來讓系統管理者管理所有運作在多相環境下的服務的管理系統就顯得尤為重要。WSDM（Web Services for Distributed Management）規定了任何根據WSDM實作的服務都可以由一個WSDM适應（WSDM-compliant）的管理方案來管理。

其它的qos特性，比如合作方之間的溝通和通訊，多個服務之間的事務處理，都在WS-Coordination 和 WS-Transaction 标準中描述， 這些都是OASIS 的工作。

SOA 不是Web服務

在 了解SOA和Web服務的關系上，經常發生混淆。根據2003年4月的Gartner報道，Yefim V. Natis就這個問題是這樣解釋的：“Web服務是技術規範，而SOA是設計原則。特别是Web服務中的WSDL，是一個SOA配套的接口定義标準：這是 Web服務和SOA的根本聯系。”從本質上來說，SOA是一種架構模式，而Web服務是利用一組标準實作的服務。Web服務是實作SOA的方式之一。用 Web服務來實作SOA的好處是你可以實作一個中立平台，來獲得服務，而且随着越來越多的軟體商支援越來越多的Web服務規範，你會取得更好的通用性。

SOA的優勢

SOA 的概念并非什麼新東西，SOA不同于現有的分布式技術之處在于大多數軟體商接受它并有可以實作SOA的平台或應用程式。SOA伴随着無處不在的标準，為企 業的現有資産或投資帶來了更好的重用性。SOA能夠在最新的和現有的應用之上建立應用；SOA能夠使客戶或服務消費者免予服務實作的改變所帶來的影 響；SOA能夠更新單個服務或服務消費者而無需重寫整個應用，也無需保留已經不再适用于新需求的現有系統。總而言之，SOA以借助現有的應用來組合産生新 服務的靈活方式，提供給企業更好的靈活性來建構應用程式和業務流程。