數據集成與數據服務第4章SOA與數據服務基本概念2023/2/5本章目錄4.1SOA參考架構4.2SOA原理與基本體系架構4.3SOA關鍵技術4.4SOA與大數據服務4.1SOA與數據服務基本概念SOA，ServiceOrientedArchitecture面向服務的體系架構面向服務的架構以服務為中心的體系結構回顧：SOA起因：處理可伸縮性和分布的老辦法不管用了!不再能一致化系統，或維持對系統的控制。一致化和控制的前提是集中，集中則無法擴展，當前已經將集中發揮到極致。需要新的方法——一個接受異質、帶來分散的方法。SOA作用于：在大型分布式系統中，保持靈活性的唯一辦法就是支持異質、分散和容錯。SOA四大主要元素SOA：是一種幫助系統在增長的同時保持可擴展性和靈活性的方法，也有助于填平“業務/IT”鴻溝。4大主要元素：1）服務：一個服務是一項自足的、能作為一個或多個流程一部分的業務功能。服務能由任何技術、在任何平臺上實現。2）企業服務總線（ESB）：是一個基礎設施，支持服務在異質系統間進行調用，使分布式系統和服務間的高互操作性成為可能。其職責包括：數據轉化、（智能）路由、處理安全和可靠性、服務管理、檢測、日志。SOA四大主要元素4大主要元素：3）松耦合：減少系統依賴的概念。業務流程分布在多個后端系統上，最小化修改和故障的影響至關重要。目標：靈活性、可伸縮性、容錯。代價：復雜化。4）政策和過程：維護異質系統。什么是服務？服務特征：1）本質上，服務就是業務功能的IT體現。SOA的目標就是基于對業務規則和功能的抽象來構筑大型分布式系統。2）服務的自描述性（支持動態發現與延遲綁定）服務具有可發布、可發現、機器可處理的接口契約接口定義良好：包括：完整的服務行為和語義。服務契約：服務質量（QoS）及服務等級協議（SLA）。什么是服務？3）服務自治：獨立、自主、自給自足。4）抽象性：服務是種抽象，向使用者隱藏服務實現細節；有助于分離服務供應者的內部數據結構和外部接口。實現平臺透明性。5）粗粒度：支持基于業務邏輯的積木式裝配。6）連接與交互方式——松耦合式綁定，基于標準化消息進行通信。服務可具有可復用、可組合、位置透明以及可互操作等特點。BeforeSOA–AfterSOAsource:IBMSOA適用范圍1.分布式系統OASISSOA參考模型對SOA的定義指出：SOA是“組織和利用分布式能力”的范式。SOA使得需要一定分布式能力的實體能定位、使用這些能力。即：SOA方便了服務供應者和服務消費者之間的交互，使業務功能的實現成為可能。SOA適用范圍2.所有者各異OASISSOA參考模型對SOA的定義指出：這些分布式能力“可能出于不同所有權范圍控制之下”。SOA包括的某些實踐和流程基于事實：分布式系統的網絡不被某個唯一的所有者掌控。不同的組、不同部門、甚至不同公司都可能管理不同系統。則，不同平臺、進度、優先級、預算等都必須被考慮進來。SOA適用范圍2.所有者各異無論是處于一個所有者各異的環境中，還是處于一個你能控制一切的環境中，處理問題、做出調整的方式會根據需要而相應變化。（必須向他人妥協，必須接受不同的優先級，不同解決方案的存在。不能控制所有東西。）SOA適用范圍3異質（Heterogeneity）大系統缺乏一致性。用不同的平臺、不同的編程語言（及編程范式）、不同的中間件。它們是異質的。老的解決集成分布式系統的方法：試圖消除異質性。已不可行。SOA則依靠對異質性的承認和支持來處理大系統。SOA的目標僅僅是：在異質化存在的地方，用一種合適的方式處理異質化。SOA構建IT系統的特點-以業務為中心以相對于面向對象、面向構件技術，SOA更多從用戶業務出發讓業務人員參與SOA系統的規劃、設計和管理。在深刻理解業務的基礎上構建IT系統，實現IT系統與用戶業務的密切結合實施中把完成實際業務流程的一項任務封裝為服務基于業務選擇合適的技術，避免技術制約業務SOA構建IT系統的特點-靈活適應變化用戶業務實現為一系列松散耦合的服務服務可以根據用戶業務變化和發展進行按需調整、重構和重新組合提高IT系統對于業務靈活變化的適應能力SOA構建IT系統的特點-重用IT資源，提高開發效率

重用服務帶來對原有IT資源的重用度提升

大量高重用的服務資源為快速構建新的業務功能和業務系統奠定了基礎提高IT系統的開發效率，節約成本

保護用戶前期的信息化投資和IT資產積累

實現用戶信息化可持續發展服務架構的分層靈活重組

高重用性底層標準化上層定制化關注點分離不同策略ExampleLayersPresentation

&workflowComposedServicesBasicServicesUnderlying

APIaccordingto:TietoEnatorAB,KurtsBilder主要服務類型基本服務以數據和邏輯為中心的

封裝數據操作和數據模型，保證數據一致性是無狀態的(stateless)，具有高度的可重用性一般是基于遺留IT系統的API，是SOA成熟度模型中的最基本地級別服務可以被重復調用，且無需維護上下文狀態，例如天氣預報，沒有作業或者會話的概念，返回服務調用結果之后，處理就完成了，后續調用與前面的沒有任何關系。主要服務類型組合服務利用網關，適配器等技術將不一致的基礎服務組合為提供一致訪問的服務封裝了業務工作流程服務類型SOA的多層參考架構(IBM)Layer1:遺留系統客戶已經開發使用的信息系統.CRMERP應用舊的面向對象應用

商業智能應用使用面向服務的集成技術對其進行集成TheSOALayersLayer2:服務構件層-企業構件負責實現服務功能和保證服務質量-對企業級或者部門級資產進行管理和控制的集合-典型的，采用基于容器的技術（如應用服務器）來實現組件，負載管理和負載均衡，高可用性Layer3:服務層-商業業務選擇支持和公開的服務-可以通過服務發現，進行靜態綁定和調用，或者編排-為組合服務-將企業范圍、業務單元、特定項目級的特定功能，以服務描述的形式具體化了他們的接口子集-在運行時提供服務實現接口所提供的功能-這一層的接口公開為一個服務描述，服務可以獨立存在或者編排為組合服務。Component構件SOA體系架構下的應用軟件標準構造單元用以構造能為高級和更組粒度的應用軟件模塊

(Services,References,Properties)用以封裝更為低層和更細粒度的邏輯實現

(Implementation)Services:服務是被使用的功能References:實現時所要依賴于其他構件的服務Properties:實現時影響構件動作的可設置數值Implementation:支持各種實現技術（Java,C++,PHP,JavaScript,EPEL,SQL,XQuery,Composite…）相同點：Service和component，都是基于可重用的思想組件從服務提供者地角度，側重于IT實現，通過接口與實現分離，將功能分解為獨立的構造單元，可以單獨開發，打包和部署，依賴于特定的技術規范，如J2EE，.Net，Python等，與具體應用有著相同的生命周期服務則代表更高層次的抽象和演進，從服務使用者的角度，側重描述到底能提供什么，而不是如何提供，只要提供了業務所需的行為和質量，具體是不是組件實現的無關緊要，它獨立于應用的部署，可以根據業務需要，獨立重構和演進，使得大規模的重用變得更容易。服務在業務和IT技術之間提供了一個中間層，TheSOALayersLevel4:業務過程層(服務組合與協同層)-通過編制（Orchestration）或編排（Choreography）合成組合服務-用以支持業務處理和業務流程Layer5:訪問層(表現層)-將用戶接口從組件中分離出來-提供訪問服務或組合服務的方式TheSOALayersLevel6:集成(ESB)

-這一層使服務可以集成-通過一些可靠性和性能保證技術，比如智能路由，協議中介和其他轉化機制-經常被描述為ESB。Level7:服務質量(QoS)-這一層提供了監視，管理和維持諸如安全，性能和可用性等QoS的能力。-監測SOA應用程序健康的機制和工具服務質量 QoS指的是服務的一種能力，它能相應預期的請求，并能以一定的質量完成相關的任務，符合服務提供者和客戶的預期可用性：服務正常運轉的時間，修復時間（TTR）可訪問性：大量客戶同時使用服務的成功率標準性性能：吞吐量和等待時間服務質量 QoS指的是服務的一種能力，它能相應預期的請求，并能以一定的質量完成相關的任務，符合服務提供者和客戶的預期可靠性：與網絡等故障無關，能始終如一的正確運行可伸縮性：服務能力隨需求量而變化安全性：認證、授權、消息完整性、機密性本章目錄3.1SOA與數據服務基本概念3.2SOA原理與基本體系架構3.3SOA關鍵技術3.4SOA與大數據服務SOA推廣應用的挑戰以服務為導向

重用性職責分擔標準化SOA三步驟

第一個步驟是找到服務。對于一個企業（服務對象）來講有那么多種業務，怎么確定SOA架構里需要哪些服務，以及有哪些服務是需要抽象出來的？SOA三步驟

第二個步驟就是服務的描述。這些服務之間的相互關系是怎樣的，這些服務分別由哪些服務組件實現。SOA三步驟

第三個步驟就要考慮這些服務采用什么樣的技術實現，可能是租用別人提供的服務，也可以重用以前有的服務，也可以重新開發一套服務，或者我利用我們的已有系統，把已有系統的功能進行封裝成一個服務等，已達到服務實現的目的。SOA原則理念標準化服務契約StandardizedServiceContracts松散耦合LooseCoupling抽象化Abstraction可重用性Reusability自治性Autonomy無狀態Statelessness可發現性Discoverability可組合性Composability管治GovernanceSOAPrinciples-StandardizedServiceContracts“同一服務目錄下的服務按照同樣的契約設計標準設計契約服務契約表達服務的目的表達服務的能力使用正式的，標準化的服務契約Focusontheareasof功能表達數據表示策略經過服務發現階段，服務目錄基本形成，但是對于每個服務本身的屬性信息依然零散。服務規約階段的主要任務是規范性地描述服務各個方面的屬性，其中既包括輸入/輸出消息等功能性屬性，服務安全約束和響應時間等服務質量約束，以及服務在業務層面的諸多屬性，如涉及的業務規則、業務事件、時間/人員消耗等。與此同時，規范描述服務相關方面的關系也很重要，如服務間依賴關系，服務和業務組件間關系，服務和IT組件間關系和服務消息間關系等。SOAPrinciples-StandardizedServiceContracts經過服務規約階段，作為業務和IT互動的服務契約已經形成。但是服務契約和IT的現狀還是有很大差距的為了將服務契約落在實地，服務實現階段通過差距分析，并結合傳統方法學完成每個服務實現決策。這其中包括的內容甚多，其主要包括現有系統分析，確定服務分配，服務實現決策，服務基礎設施設計等方面內容。SOAPrinciples-LooseCoupling“服務對使用者來說只需低的耦合需求，并且自身也同周圍環境解耦"SOA松耦合SOA松耦合SOA松耦合SOA松耦合SOA松耦合SOA松耦合SOAPrinciples-Abstraction“服務契約僅包含最基本的信息，并且關于服務的信息限于服務契約中所發布的避免增加不必要的服務信息，元數據.盡可能的隱藏服務的底層細節.保持松散耦合關系對于服務組合的設計很重要SOAPrinciples-Reusability邏輯是高度通用的契約是通用和可擴展的可以并發訪問SOAPrinciples-Autonomy獨立與外部環境和影響的執行邏輯增加可靠性行為可預測性SOAPrinciples-Statelessness只有必要時才維護狀態信息根據每次請求消息獲得服務所需的全部信息，或者根據消息從資源信息庫中獲得完成服務的所需全部信息增加可靠性和可伸縮性有狀態的資源：一個狀態數據集，表示為XML文檔具有標識和生命周期多個服務都能夠操縱它WS-RF資源框架SOAPrinciples-Discoverability服務具有用于注冊的元數據，以便被發現和使用服務契約元數據存儲在服務注冊庫中SOAPrinciples-Composability服務可以有效組合解決更為復雜的問題無論各個成分自身有多復雜

，都可以有效進行組合有利于可重用性靈活的服務契約，以便不同種類的數據交換SOAPrinciples-ApplyingSOA-Governance針對服務所制定的管控策略和機制，涵蓋服務的整個生存周期。計劃——確定治理的重點。定義——定義治理模型啟用——實現治理模型度量——改進治理模型當服務越來越多時，服務URL配置管理變得非常困難，硬件負載均衡器的單點壓力也越來越大。當進一步發展，服務間依賴關系變得錯蹤復雜，甚至分不清哪個應用要在哪個應用之前啟動，架構師都不能完整的描述應用的架構關系。

接著，服務的調用量越來越大，服務的容量問題就暴露出來，這個服務需要多少機器支撐？什么時候該加機器？

SOAPrinciples-ApplyingSOA-Governance規模繼續擴大，應用之間不再是扁平的對應關系，開始分層，比如核心數據層，業務集成層等，就算沒有出現循環依賴，也不允許從低層向高層依賴，以免后續被逼循環依賴。

服務多了，溝通成本也開始上升，調某個服務失敗該找誰？服務的參數都有什么約定？

慢慢一些敏感數據也都服務化了，安全問題開始變得重要，誰能調該服務？如何授權？

SOAPrinciples-ApplyingSOA-Governance就算是不敏感的服務，也不是能任意調用，比如某服務突然多了一個消費者，這個消費者的請求量直接把服務給拖跨了，其它消費者跟著一起故障。

雖然有SLA約定，如果不能控制，就只是君子協定，如何確保服務質量？

SOAPrinciples-ApplyingSOA-Governance

服務上線后，需要驗證服務是否可用。

服務接口設計的經驗一直在慢慢的積累過程中，很多接口并不能一促而蹴，在修改的過程中，如何保證兼容性，怎么判斷是否兼容？另外，更深層次的，業務行為兼容嗎？

SOAPrinciples-ApplyingSOA-Governance隨著服務的不停升級，總有些意想不到的事發生，比如cache寫錯了導致內存溢出，故障不可避免，每次核心服務一掛，影響一大片，人心慌慌，如何控制故障的影響面？服務是否可以功能降級？或者資源劣化？誰能調該服務？如何授權？

SOAPrinciples-ApplyingSOA-Governance當已有很多小服務，可能就需要組合多個小服務的大服務，為此，不得不增加一個中間層，暴露一個新服務，里面分別調其它小服務，這樣的新服務業務邏輯少，卻帶來很多開發工作量。

并不是所有服務的訪問量都大，很多的服務都只有一丁點訪問量，卻需要部署兩臺提供服務的機器，進行HA互備，如何減少浪費的機器。SOAPrinciples-ApplyingSOA-Governance策略法律、規章制度、最佳實踐SOAPrinciples-ApplyingSOA-Governance服務定義（服務的范圍、接口和邊界）服務部署生命周期（各個生命周期階段）服務版本治理（包括兼容性）服務遷移（啟用和退役）服務注冊中心（依賴關系）SOAPrinciples-ApplyingSOA-Governance已計劃。已標識了新服務并正在設計中，不過尚未實現或正在實現中。測試。實現后，必須對服務進行測試（稍后將對測試進行更詳細的說明）。有些測試可能需要在生產環境中執行，此環境會將服務作為活動服務處理。活動。這是服務可供使用的階段，我們通常所談說的服務實際是處于此階段的服務。這是一個服務，處于可用狀態，在實際運行并且確實可完成相應的工作，而且尚未退役。已棄用。此階段描述仍然處于活動狀態但不會再存在很長時間的服務。這將警告使用者停止使用此服務。已退役。這是服務的最后一個階段，表示一個不再提供的服務。注冊中心可以保存有關曾經處于活動狀態但不再可用的服務的記錄。服務消息模型（規范數據模型）服務監視（進行問題確定）服務所有權（企業組織）服務測試（重復測試）服務安全（包括可接受的保護范圍）SOAPrinciples-ApplyingSOA-GovernanceApplyingSOA–

GovernanceSOA的基本體系結構樣式SOA體系結構解決什么？僅僅有松散耦合的服務還不夠，服務本身不解決接口間調用關系的拓撲問題P2P，HUB的混亂和瓶頸問題仍然存在64SOA的體系結構模式應用SOA來構造業務系統，既可以通過簡單的WebService調用，也可以通過復雜的企業服務總線(ESB)將異構系統集成為業務過程。按照SOA應用場景的復雜度，將其體系結構模式分為10種65SOA的體系結構模式按照SOA應用場景的復雜度，將其體系結構模式分為10種：硬連線(Hard-wired)點對點的服務發布與調用(P2P)服務適配器(Serviceadaptor)服務代理(Serviceproxy)遠程服務策略(Remoteservicestrategy)單點訪問(Singlepointofaccess)虛擬服務提供者(Virtualprovider)服務集成器(Serviceintegrator)企業服務總線(Enterpriseservicebus)集成化的服務生態系統(Integratedserviceecosystem)SOA基本體系結構樣式之一：發布-訪問發布(Publish)：為了使服務可訪問，需要發布服務描述以使服務使用者可以發現它。發現(Find)：服務請求者定位服務，方法是查詢服務注冊中心來找到滿足其標準的服務。調用(invoke)：在檢索到服務描述之后，服務使用者繼續根據服務描述中的信息來調用服務。服務提供者服務注冊中心服務使用者(1)發布(2)發現(3)調用一個可通過網絡尋址的實體，它接受和執行來自使用者的請求一個應用程序、一個軟件模塊或需要一個服務的另一個服務，服務使用者根據服務契約來使用服務服務發現的支持者它包含一個可用服務的存儲庫，并允許感興趣的服務使用者查找服務提供者接口WebService中該模式的實現機制WSDL：Web服務描述語言用于服務接口的描述——Whatcantheservicedo?UDDI：統一描述、發現和集成協議服務使用者通過UDDI發現相應的服務并據此將服務集成在自身的系統中——Whatkindofservicesareneeded?SOAP：簡單對象訪問協議用戶在服務客戶端與服務提供者之間傳遞信息，通過HTTP或JMS等各類基于文本的消息傳遞協議來運輸WebService提供者WebService注冊中心WebService客戶端(1)WSDL(2)UDDI(3)SOAP68基本模式：發布-訪問WSDL

WebService(J2EE,PL/SQL,

.NET,C/C++,

Legacy…)WebServiceClient(J2EE,.NET,

PL/SQL…)PointstodescriptionDescribesServiceFindsServiceInvokeswithXMLMessagesSOAPUDDI

RegistryPointstoserviceSOA基本體系結構樣式之二：適配器模式企業中存在若干遺留系統(legacysystem)；這些系統采用較傳統的技術開發，無法提供清晰的接口(interface)；但其他系統仍然需要訪問這些遺留系統的功能；——怎么辦？通過構造適配器(adaptor,wrapper)，將遺留系統中的功能進行二次包裝，從而開放出接口供其他系統使用。典型技術：Java2ConnectorWebSphereBusinessIntegrationAdaptor服務適配器Wrapper包裝器：在每個數據源上加一個Wrapper，負責封裝數據源，將該數據源的特定數據對象邏輯的轉換為一個通用的數據模型，并將對通用數據模型提出的查詢轉換為本地可執行的操作。綁定服務地址與遺留系統的功能之間的映射關系以上2種SOA模式的缺陷客戶端為了使用服務，必須在自己的程序中寫入調用服務的代碼，即通過服務的URI地址來訪問服務。這導致客戶端與服務之間的耦合度過大，系統的靈活性受到限制。例如，客戶端需要在多個候選服務之間進行靈活替換，以獲得更好的QoS。——怎么辦？將這種綁定關系從代碼中抽取出來。SOA基本體系結構樣式之三：服務代理②客戶端通過“serviceregistry”來訪問服務，當希望訪問其他服務時，只要手工修改該registry即可——相當于一個配置文件；③客戶端通過“servicebroker”來動態決定需訪問那個服務；——完全動態的服務選擇，很困難，需要用到服務語義的相關技術。①客戶端直接綁定服務接口(WSDL/URI);以上模式存在的問題上述場景都是調用單個服務如果客戶端需要同時或連續調用多個服務的功能，它必須在自己的系統中分別寫出多個調用；——非常麻煩；而且，對多個服務的調用次序也是容易發生變化的，需要頻繁的修改；——難以做到；以上模式存在的問題——怎么辦？降低耦合度將servicebroker的思想進一步發揮，客戶端不去逐一調用服務，而是首先將這些被調用的服務按邏輯關系集成起來，形成一個集成的、大粒度的服務；客戶端只需調用這一個服務即可；當該服務執行時，集成器(integrator)依靠配置信息來分別調用一個個小粒度的服務；對這些配置信息進行修改，即可方便的做到變更。SOA的基本體系結構樣式之四：服務集成器服務集成器OperationalSystemsService-OrientedBusinessProcessComponent-basedPresentationQoS,Security,Management&Monitoring(InfrastructureService)IntegrationArchitecture(EnterpriseServiceBus)Object-orientedCICS/COBOLCRM,ERPBusinessIntelligenceProcessChoreographyCompositeServicesPortlets5432167EnterpriseComponentsSOA中的Orchestration：服務編制Orchestration：指業務流程，以一種說明性的方式（而非編程方式）定義編制的服務的執行順序（如并行，邏輯條件分支等），最終合稱為組合服務。通常包括分支控制點、并行處理、人工相應步驟和許多預定義步驟(轉換、適配器、電子郵件、報警等)。SOA中的Choreography：服務編排Choreography：指業務協作，將多個零散的、分別由多方提供的服務/業務流程按照彼此之間的協同關系組織起來，支持多方的交互行為。側重于不同服務之間的消息傳遞的次序與規則，各自描述自己如何與其他服務進行消息交換，以保證期望的協同行為。Choreography&Orchestration編制（Orchestration）——面向可執行的流程：流程編制使用一個可執行的中心流程來協同內部及外部的WebService交互。通過中心流程來控制總體的目標，涉及的操作，服務調用順序。適用于域內小粒度服務組合；有中心控制點（流程引擎），層次調用。

編排（Choreography）——面向合作：更多的強調協同工作和業務合作能力，通過消息的交互序列來控制各個部分資源的交互。參與交互的資源都是對等的，沒有集中的控制。適用于域間大粒度服務協作

Orchestration的特性在于：請求者-提供者模型，通過一個中心的控制來協同流程中的各種活動（用什么服務，什么時候用，怎么用）Choreography是對等模型，高度依賴2件事情：各參與方地位平等協同工作；詳細定義的通用規則以保證協同不會導致混亂.SOA中的“集成”：服務編制(ServiceOrchestration)服務編制(ServiceOrchestration)：將多個小粒度的Web服務按照特定的業務邏輯規則構造為一個可執行的業務過程，同時又可以看作是一個大粒度的復合Web服務。側重點：如何使用已有的服務來構造新的服務。BPEL面向Web服務的過程建模語言；由IBM、Microsoft和BEA共同提出；實現基于WSDL的WebServices之間的流程編排；BPEL的一個例子Determineif

CanFulfill10:00amHandleNegativeCreditExceptionDiscountServicestartendBPELFlow?CreditServiceInventory

ServiceGetDiscountSendCreditApplicationReceiveCreditResult03:00pmSendInventoryRequestReceiveInventoryResult<process></process><switch><variable><partnerLink><partnerLink><partnerLink><faultHandlers><receive><invoke><invoke><flow></flow>BPEL是一門用于自動化業務流程的形式規約語言。用XML文檔寫入BPEL中的流程能在Web服務之間以標準化的交互方式得到精心組織。這些流程能夠在任何一個符合BPEL規范的平臺或產品上執行。所以，通過允許顧客們在各種各樣的創作工具和執行平臺之間移動這些流程，BPEL使得他們保護了他們在流程自動化上的投資。示例：Oracle的BPEL執行引擎OracleBPELProcessManager可用于集成應用程序和原有系統，使用較細粒度的服務組成粗粒度的服務，構建以流程為中心的組合應用程序，完成業務流程和工作流應用程序（包括復雜的路由和調升）自動化。WS-CDLWS-ChoreographyDefinitionLanguage(WS-CDL)isalanguagefordescribinghowpeer-to-peerparticipantscollaborate.ThelanguageusesXML,andsomeaspectsareinspiredbythepi-calculus.(未獲得廣泛認可)DifferenciesbetweenBPELandCDLCDLprovidesadefinitionoftheinformationformatsbeingexchangedbyALLparticipants,BPELprovidestheinformationformatsexchangedbyoneparticipant.(全局/局部信息交換格式)CDLprovidestheglobalmessageexchangebetweenparticipantswithoutaspecificpointofview,BPELprovidesthemessageexchangefromthepointofviewofoneparticipant(全局/局部消息傳遞)CDLprovides“reactive”rulesthatareusedbyeachparticipanttocomputethestateofthechoreographyandinferwhichmessageexchangewill/canhappennext.BPELspecifies“active”rulesthatareexecutedtoinferwhattodonext,oncetheruleiscomputed,theorchestrationrun-timeexecutesthecorrespondingactivity(ies).(被動/主動活動激活)WS-CDL(WebServiceChoreographyDefinitionLanguage)：專門的Web服務編排標準，由SUN,SAP,Oracle發起，目前由W3C發布。WS-CDL是一種描述多方契約的語言，有些類似WSDL擴展；可以看作是在已經存在的webserv