服務計算概論

第一章緒論§1.面向效勞計算概述1.1效勞計算起因和概念隨著經濟全球化和電子商務的普及，當代企業(yè)必須要面對不斷變化的市場條件、劇烈的競爭壓力、新出臺的法規(guī)以及新的競爭威脅，從而企業(yè)要獲得競爭優(yōu)勢就要不斷調整其業(yè)務模式和需求。因此，企業(yè)應用要能需要根據(jù)業(yè)務的需要變得更加靈活，能夠對業(yè)務模式和業(yè)務需求的變化迅速做出反響，具有“隨需而變”的敏捷性。這種敏捷性表達在新的業(yè)務可以通過組合現(xiàn)有的效勞快速構造出來，業(yè)務的調整也可以通過調整效勞之間的關系迅速改變。這種應用集成既包括企業(yè)內的各種應用系統(tǒng)之間的集成，也包括集團企業(yè)總部與下屬企業(yè)、企業(yè)與上下游伙伴之間的業(yè)務協(xié)同。但是，構建“隨需而變”的應用。面對怎么樣的環(huán)境呢？隨需應變的軟件應用需要考慮三個因素：重用、標準化封裝和松耦合組裝。重用不僅可以被其它效勞或使用者調用，而且可以與其它效勞一起組合成新的效勞；標準化封裝通過提供統(tǒng)一的描述標準，消除軟件對語言、平臺和廠家的依賴；松耦合組裝利用松耦合的組件構造靈活可變的企業(yè)應用。但是，假設實現(xiàn)企業(yè)應用的快速調整和構造，傳統(tǒng)的分布式計算技術存在兩大難題：一是應用程序客戶端和效勞端之間的緊密耦合問題，以微軟的DCOM為例，客戶端和效勞器端都要求遵循同樣的API，一旦一個COM對象代碼有改變，那么訪問該對象的客戶端代碼也需要相應的更改。二是不同應用程序之間的異構問題。由于企業(yè)應用嚴重依賴計算環(huán)境，從而使得同一企業(yè)不同應用之間，不同企業(yè)應用之間還不能有效地相互集成?？傊?，傳統(tǒng)架構存在的最大缺陷就是對變化的適應性差，難以適應企業(yè)不斷變化的業(yè)務需求。構造靈活可變的企業(yè)應用系統(tǒng)必須通過建立松耦合的計算環(huán)境來實現(xiàn)。計算環(huán)境包含一組計算機、軟件平臺、協(xié)議和相互連通的網絡。在該計算環(huán)境中，計算機之間、軟件平臺之間可以通過網絡按照協(xié)議實現(xiàn)數(shù)據(jù)交換和信息處理。采用標準化的效勞描述將企業(yè)應用進行封裝，通過以編程方式實現(xiàn)的自描述接口，提供效勞的核心功能，屏蔽了應用的實現(xiàn)細節(jié)，這樣可以通過效勞描述訪問效勞構造企業(yè)應用。形象地說就是將軟件封裝成類似于硬件模塊帶接口的構件，在接口匹配的情況下可以隨時“插入”特定的軟件應用完成相應的功能，使效勞之間〔企業(yè)內或跨企業(yè)〕以松散耦合的形式互聯(lián)、互操作完成特定的業(yè)務需求?；谛诟拍畹馁Y源封裝和抽象逐漸成為資源發(fā)布、共享和應用協(xié)同的重要技術根底。這樣，剝離了客戶端和效勞器端之間的語言/平臺依賴，消除了不同應用之間由于采用的不同系統(tǒng)、不同平臺和不同語言所造成的異構。在接口描述不變的情況下，效勞實現(xiàn)的任意變更都不會對應用產生影響。這樣，一方面可以將遺留系統(tǒng)封裝為效勞進行重用，一方面可以直接調用企業(yè)外效勞提供商提供的效勞，從而可使開發(fā)者更快速、敏捷地根據(jù)企業(yè)業(yè)務的變化，構造企業(yè)應用。面向效勞計算(SOC)是一種新的計算范式,它利用效勞為根本構建塊,支持異構環(huán)境下分布式應用的快速、低本錢、便捷的組合。這種方法的根本思想是通過重用已有的網絡效勞而不是重新開發(fā)來構造企業(yè)應用。重用和組裝是這個方法的核心，松散耦合是這個方法的本質。重用就是使應用系統(tǒng)具有較強的獨立性，以便其作為一個“零部件”能隨時被單獨使用；組裝就是高效而靈活地將跨組織、跨平臺的應用無縫地進行組合來構造滿足企業(yè)需求的應用。松散耦合的目標是使應用系統(tǒng)之間的依賴到達最小，任何應用系統(tǒng)的更改和錯誤對其他的應用系統(tǒng)沒有影響。效勞是自治的，與平臺無關的計算實體。效勞是可描述，可發(fā)布、可發(fā)現(xiàn)的、可以動態(tài)組裝成分布式的、可交互的、可擴展的系統(tǒng)，效勞可以包括從執(zhí)行簡單的請求到復雜的業(yè)務流程，該流程要求不同多種層的效勞消費者和供給商之間點對點之間的關系。部署在一個系統(tǒng)中的任何一段代碼和任何應用組件都可以重用，并且可以轉化為網絡效勞。實現(xiàn)這一思想的關鍵是面向效勞架構，SOA是一種符合邏輯的設計軟件系統(tǒng)的方式，通過已發(fā)布的或可發(fā)現(xiàn)的接口將效勞提供給終端用戶或者分布在網絡上的效勞。一個結構良好、基于標準SOA通過以效勞的形式提供獨立的、可重用的應用功能和更加健壯的根底，可以賦予企業(yè)更加靈活的根底設施和處理環(huán)境。Web效勞是當今最有前途的面向效勞計算技術，Web效勞利用互聯(lián)網作為傳輸媒介、利用開放的基于因特網的標準，如簡單對象訪問協(xié)議SOAP作為傳輸數(shù)據(jù)、Web效勞描述語言WSDL用于效勞定義、業(yè)務流程執(zhí)行語言BPEL編排效勞。Web效勞解決了以往分布式計算平臺的兩大難題：一個是平臺之間的互操作問題；另一個是客戶端和效勞端之間的緊密耦合問題。它提供一個與操作系統(tǒng)無關、與程序設計語言無關、與機器類型無關、與運行環(huán)境無關的平臺，實現(xiàn)網絡上應用的共享。效勞技術是由作為一個整體的現(xiàn)代社會而形成的，特別是動態(tài)業(yè)務、醫(yī)療、教育和政府效勞等關鍵領域，同時也將不斷推動作為一個整體的社會的形成。通過封裝和重用業(yè)務的核心功能、增強靈活性、提高技術遷移的適應性、改善操作效率，應用效勞技術降低了復雜性和本錢。由于這些原因，面向效勞的范型可望得到迅速地應用，由于它解決昂貴的、難以解決的業(yè)務和技術問題，將比以往的任何應用技術更具有前途。Servicestechnologiesarebeingshapedby,andincreasinglywillhelpshape,modernsocietyasawhole,especiallyinvitalareassuchasdynamicbusiness,health,educationandgovernmentservices.Applyingservicestechnologiesleadstoreducedcomplexityandcosts,exposingandreusingcorebusinessfunctionality,increasedflexibility,resiliencetotechnologyshiftsandimprovingoperationalefficiency.Forallthesereasons,itisexpectedthattheServiceOrientedComputingparadigmwillexhibitasteeperadoptioncurve,asitsolvesexpensiveandintractablebusinessandtechnologyproblems,andwillinfiltratemoreoftheapplicationsportfolio,thanpreviousapplicationtechnologies.SOC包括效勞根本原理、效勞組合、效勞管理和監(jiān)控以及面向效勞的工程?！?.效勞計算產生的背景效勞計算給軟件體系架構以及軟件開發(fā)方法帶了革命性的變化，軟件體系架構從早期集中式的整體軟件體系結構逐步開展成為一種松散、靈活、易擴展的分布式軟件架構模式，效勞表達了面向效勞的編程方法，這種方法改變了傳統(tǒng)的重新開發(fā)的軟件設計理念和方法，通過重用已有的網絡效勞構造應用的設計思想。不難看出，效勞計算是軟件體系架構和軟件開發(fā)方法不斷演化的產物，也是進一步提高和加快軟件產業(yè)開展的必然結果。2.1軟件體系架構的開展歷程軟件體系架構是指構成軟件系統(tǒng)的軟件元素、軟件元素外部可見的屬性以及這些軟件元素之間的關系。為便于說明問題，首先介紹軟件系統(tǒng)的分層邏輯結構。一般而言，構造軟件時都會遇到三類問題：⑴如何將軟件功能以圖形或字符人機界面的形式呈現(xiàn)給用戶；⑵如何編寫實際的應用邏輯實現(xiàn)軟件功能；⑶如果利用已有資源如數(shù)據(jù)庫、文件系統(tǒng)等完成對資源的管理和操作?；谝陨戏治觯浖w系架構從邏輯上可以分為三層，即表示層、應用邏輯層和資源管理層1．主機計算環(huán)境。其軟件體系架構的特點是，軟件的所有功能集中由主機完成，而分布的是僅僅具有輸入輸出功能的啞終端或多人分時使用一臺計算機。其優(yōu)點是其所有功能都在一致的系統(tǒng)環(huán)境下實現(xiàn)，因此可方便地對系統(tǒng)進行調試。其缺點是組成系統(tǒng)的表示層、應用邏輯層和資源管理層之間彼此緊密耦合、很難維護和擴展；各個主機之間的數(shù)據(jù)、功能很難共享和相互調用。2．客戶/效勞器計算環(huán)境。通過局域網相互連接的計算設備構成客戶/效勞器計算環(huán)境，這種體系架構將表示層從集中式的效勞器中剝離出來轉移給客戶端，客戶和效勞器通過網絡協(xié)議、遠程調用或消息等方式來相互協(xié)作，完成計算。其主要優(yōu)點是將表示層和其他兩層功能別離，降低了對效勞器的性能要求，支持跨平臺系統(tǒng)開發(fā)，還可以根據(jù)需要個性化地設計和實現(xiàn)表示層的樣式。主要缺點是客戶端和效勞器端之間緊密耦合，一般一個特定的客戶端只能連接到一臺效勞器，容易造成“信息孤島”；另外維護代價高，一旦應用環(huán)境發(fā)生變化需要改變業(yè)務邏輯時，每個客戶端程序都要進行更新。3．多層分布式計算環(huán)境。為了滿足更高的可伸縮性需求，C/S計算環(huán)境派生出多層軟件架構，在C/S架構根底上進一步將效勞器端的應用邏輯層和資源管理層別離，把應用邏輯交給單獨應用效勞器處理。其中，表示層被一分為二，通用功能由標準應用軟件承當、而非通用功能由特定的分布式計算平臺實現(xiàn)，瀏覽器和應用效勞器上的表示層之間通過標準文檔形式的標準HTML對話；應用邏輯層和資源管理層之間通過標準數(shù)據(jù)訪問協(xié)議〔JDBC/ODBC〕對話。其主要優(yōu)點是瀏覽器和應用效勞器之間、應用效勞器和資源管理器之間是松耦合關系。但是，表示層和應用邏輯層之間是緊耦合的，兩者之間在技術平臺上耦合緊密。當表示層想訪問不同平臺如J2EE和DCOM上的應用邏輯時，不得不參加額外的接口適配器代碼。4、面向效勞的計算環(huán)境。也就是基于標準、開放的互聯(lián)網技術，以效勞為中心的計算環(huán)境。這是一個以效勞為根本單位和抽象手段的世界。隨著互聯(lián)網〔Internet〕的開展，開放和標準的網絡協(xié)議被普遍支持，所有底層計算平臺都開始支持這些標準和協(xié)議，這導致一個計算環(huán)境內部和各個計算環(huán)境之間交互的藩籬被打破。其軟件架構的特點是將應用邏輯層封裝為Web效勞，這樣表示層就可以通過XML/SOAP協(xié)議與其實現(xiàn)松耦合交互，從而解決表示層和應用邏輯層緊密耦合的問題，保證了通用性和最大的交互能力，這使得計算環(huán)境開展到一個全新的階段—基于標準、開放的互聯(lián)網技術的計算環(huán)境。在這樣的計算環(huán)境中，各個局部可以采用異構的底層技術，它們使用XML來描述和表示自己的數(shù)據(jù)和功能，采用開放的網絡協(xié)議〔如〕來握手，在此之上，基于Web效勞來互操作和交換數(shù)據(jù)。在這里，一個很重要的新概念是"效勞"，它是一個自包含的功能，使用者通過明確定義的接口〔契約〕來與一個效勞交互，這個接口的描述基于WSDL〔WebServiceDescriptionLanguage〕這樣的開放標準。Web效勞是實現(xiàn)效勞的技術手段，就如同各種編程語言中的對象是實現(xiàn)對象的技術手段，J2EE中的EJB是實現(xiàn)組件的技術手段一樣。2.2軟件編程范型的演變過程軟件系統(tǒng)的規(guī)模越大，復雜程度也就越高，驅動軟件技術不斷向前開展的核心動因之一是復雜性控制。復用是控制軟件復雜度的有效機制，下面從軟件復用角度闡述闡述每種編程范型的特點。編程范型經歷四個階段，即面向過程的編程、面向對象的編程、面向組件的編程以及標準化的Web效勞的編程。簡言之，范型就是某一學科在一定時期內開展研究活動共有的根底和準那么。編程范型是指導和制約編程活動的范型。1.面向過程的編程。是指用程序狀態(tài)和改變程序狀態(tài)的語句描述計算的編程范型。面向過程的語言提供一種通過過程抽象控制復雜性的方法，從而支持更大規(guī)模軟件的開發(fā)，同時過程也提供一種根本的代碼復用機制。但是該范型的主要缺點是：這種復用范圍是一個可執(zhí)行程序內復用，靜態(tài)開發(fā)期復用，如果修改了過程，意味著所有調用這個過程的系統(tǒng)必須重新編譯、測試和發(fā)布。2.面向對象的編程。是指用封裝了數(shù)據(jù)和對數(shù)據(jù)操作的對象以及對象之間的消息傳遞描述計算的編程范型。面向對象的認識論是將系統(tǒng)看成由多個對象組成，通過對象之間的通信形成了系統(tǒng)面向對象系統(tǒng)中功能。其主要特征是:(1)封裝性(2)繼承性,(3)多態(tài)性。復用的兩種最常用技術是封裝性和類繼承，封裝機制實現(xiàn)了數(shù)據(jù)抽象和信息隱蔽，通過生成實例后通過對象組合組裝成系統(tǒng)；繼承機制提供了代碼的復用。但是這兩種復用機制都存在缺點：繼承機制導致子類和父類之間的緊耦合關系，同時對象很難共享，更談不上分布式計算環(huán)境下復用。其根本原因在于認知體系上的不完整，對象的理解不同,難以形成統(tǒng)一的標準和開發(fā)標準，由此基于面向對象的構件軟件應運而生。3.面向組件的編程。面向組件的編程是指以構件的創(chuàng)立、構件的管理以及復用已有的構件組裝形成應用為根本活動的編程范型。構件是模塊化、可部署、可替換的軟件系統(tǒng)組成局部，它封裝了內部的具體實現(xiàn)并對外提供一組接口。比方Spring框架中，就采用了面向組件的思路，將系統(tǒng)看作一個個的組件，通過定義組件之間的協(xié)作關系〔通過效勞〕來完成系統(tǒng)的構建。這樣做的好處是能夠隔離變化，合理的劃分系統(tǒng)。而框架的意義就在于定義一個組織組件的方式?；跇嫾幊谭缎偷奶攸c是：基于構件范型涉及三類根本活動:構件生產、構件的管理和應用組裝〔基于構件的應用開發(fā)〕。構件生產者采用領域工程方法通過對領域的分析和設計總結形成可復用的領域構件。構件管理者根據(jù)一定的分類指標和特征管理構件，以方便構件的發(fā)布和發(fā)現(xiàn)。構件復用者負責進行基于構件的軟件開發(fā)、包括構件的查詢、構件理解、構件組裝以及系統(tǒng)演化等。分布式組件技術屏蔽了網絡硬件平臺的差異性和操作系統(tǒng)與網絡協(xié)議的異構性，實現(xiàn)企業(yè)網絡內復用，不同系統(tǒng)之間復用。但是，分布式組件也是嚴重依賴其計算環(huán)境，各種分布式組件技術在構件實現(xiàn)和運行支撐技術缺乏統(tǒng)一標準，在組件描述、發(fā)布、發(fā)現(xiàn)、調用、互操作協(xié)議及數(shù)據(jù)傳輸?shù)确矫娉尸F(xiàn)出異構性，從而導致不同技術設計和實現(xiàn)的構件之間無法直接組裝式復用如J2EE和DCOM無法互相調用。J2EE(EJB)、CORBA和DCOM是比較典型的三種分布式組件。基于構件編程范型的優(yōu)點是解決分布式網絡計算環(huán)境之間的組件復用，通過遠程對象代理，來實現(xiàn)企業(yè)網絡內復用，不同系統(tǒng)之間復用。4.面向效勞的編程。前已經敘及，不同組件技術沒有統(tǒng)一的標準，不同廠家之間的組件很難實現(xiàn)互操作，最終導致了跨企業(yè)/部門的業(yè)務集成和重組難以靈活快速的進行。為徹底解決互操作問題，通過標準化的封裝技術如Web效勞,SCA/SDO等，來實現(xiàn)更高層次的復用和互操作。效勞是通過標準封裝，效勞組件之間的組裝、編排和重組來實現(xiàn)效勞的復用。而且這種復用，可以在不同企業(yè)之間，全球復用，到達復用的最高級別，并且是動態(tài)可配置的復用。面向效勞的編程是指以效勞的創(chuàng)立、效勞的管理以及復用已有的效勞組裝形成應用為根本活動的編程范型。效勞是自治、開放、自描述、與實現(xiàn)無關的網絡構件。面向效勞的編程范型采用標準化的傳輸協(xié)議SOAP、描述協(xié)議WSDL，使軟件構件的復用擴大到整個互聯(lián)網，可使不同分布式平臺技術〔不同廠商〕實現(xiàn)的Web效勞之間可以相互調用。如J2EE所提供的Web效勞可以被.NET來調用。反過來，.NET也可以調用J2EE所提供的Web效勞。Web效勞的SOAP傳輸協(xié)議盡管是一種標準的傳輸協(xié)議，但是它畢竟還是一種特殊的傳輸協(xié)議，一種特定的技術。Web效勞并不支持其他的傳輸協(xié)議，如RMI等。所以說效勞還是和特定的SOAP技術綁定在一起的。面向效勞編程范型的根本活動和基于組件編程范型根本上是一致的，不同是編程的根本組件變成了效勞。從技術實現(xiàn)和運行模式角度，Web應用效勞器分為腳本模式、面向對象模式和對象模式。腳本模式應用效勞器通過腳本以超文本方式描述動態(tài)頁面的內容和處理邏輯，當接受到客戶請求時，應用效勞器首先搜索相應的源文件，然后在效勞器端解釋該源文件中的腳本，最后將腳本解釋器產生的結果匯編后返回給Web應用效勞器〔是否是客戶端？〕腳本模式Web應用效勞器一般都通過擴展接口〔如CGI和ISAIP〕或效勞器端腳本語言〔如果JSP、ASP和PHP〕動態(tài)地生成響應頁面，但是這種模式的應用效勞器可擴展性、高可用性差，可重用性低。此外，該種模式缺乏集成歷史遺留系統(tǒng)以及事物處理的支持能力。面向對象模式介于腳本模式和對象模式之間，其主要特點是使用面向對象編寫腳本。例如，在JSP和Servlets中使用Java語言進行編碼。與純腳本模式相比，該模式可重用性較好，但是沒有相應的標準，不提供統(tǒng)一的接口標準，其使用范圍和移植性受到了限制。對象模式應用效勞器支持分布對象模型，能將應用劃分為多層，易于維護，在開發(fā)和部署過程中支持組件重用，模塊化程度高，業(yè)務邏輯的變化只需修改相關組件即可。與面向對象模式相比，對象模式應用效勞器遵循相應的標準和標準，其中較突出的兩大類：J2EE(Java2platformenterpriseedition)和微軟的.Net。J2EE由SUN公司在3年前提出，目前至少有40多種實現(xiàn)J2EE標準的效勞器。J2EE為事務性Web應用的開發(fā)、部署、運行和管理提供一系列的標準和標準，主要包括JavaServlets，JSP,EJB，JTA，JTS，JMS，JAXP，JMX，RMI-IIOP，JNDI，JCA，JavaMail和JAF標準。這些J2EE標準為應用效勞器的實現(xiàn)提供了一個完整的底層框架和一套標準的標準，在不同的J2EE應用效勞器之上的應用操作也可以互操作，移植的風險和代價小。而微軟那么在其操作系統(tǒng)之上附加一系列具備中間件功能的軟件包來提供給用效勞器的相應功能。微軟.Net構建在WindowsDNA技術〔如MicrosoftTransactionServer,COM+,MSMQ,SQLServer數(shù)據(jù)庫等〕根底上，在.Net中提供了一系列企業(yè)級應用效勞，為部署、管理和建立基于XML和Web的應用構筑了.Ｎet效勞器結構，包括ApplicationCenter，BizTalkServer,ExchangeServer等，它們結合了Windows平臺上的一系列開發(fā)工具和技術〔如VisualStudio,CommerceServer,ExchangeServer等〕，提供了強有力的應用效勞器解決方案。雖然目前J2EE和.Net勢均力敵，但是J2EE作為一種標準，具有Net無法比較的跨平臺、企業(yè)應用集成能力以及可擴展性和開放性，得到許多廠商的支持，已經逐步被廣闊研發(fā)人員和企業(yè)所接受，有良好的前景，逐步成為Web應用效勞器研究和開發(fā)的一個方向?！?.企業(yè)應用集成〔喻堅、韓燕波書〕3.1企業(yè)內應用集成技術3.2企業(yè)間應用集成技術3.3面向效勞的應用集成技術§4.效勞計算學科涵蓋內容2.1效勞資源層主要為數(shù)據(jù)資源和軟件資源的效勞化過程提供根底標準、技術和方法支持。該層主要解決兩大問題：①效勞本質的認識問題，即效勞模型包含哪些方面，應用何種語言進行效勞描述，效勞具有哪些根本特征；②效勞的實現(xiàn)問題，即如何開發(fā)、封裝、測試、部署、運行和發(fā)布效勞等。2.2效勞會聚層效勞資源層實現(xiàn)了各類異質異構數(shù)據(jù)和軟件資源的效勞標準化，而效勞會聚層是在效勞資源層根底上進一步實現(xiàn)細粒度效勞到大粒度效勞的標準化，即為不同效勞之間的協(xié)同以及由多個效勞構成的效勞流程的管理提供一系列標準、技術和方法。它涵蓋了效勞集成與協(xié)作、效勞編排與效勞編舞、效勞流程管理等。2.3效勞應用層經過效勞資源層和效勞會聚層，各類異質異構數(shù)據(jù)和軟件資源或資源集合被整合成不同粒度的標準化效勞，這為方便、快捷、透明地應用效勞提供了可能。效勞應用層主要為效勞在使用過程中提供根本的技術和方法支持，包括效勞調用、效勞發(fā)現(xiàn)、效勞匹配、效勞組合、效勞驗證、效勞適配、效勞監(jiān)控等技術，這些技術是當前效勞計算研究與開發(fā)中最活潑的局部。2.4效勞系統(tǒng)層是在效勞應用層技術根底上，為指導效勞計算環(huán)境下設計、開發(fā)、運行和管理面向效勞的軟件系統(tǒng)而提供的一組標準、技術和方法，包含了面向效勞的體系架構、企業(yè)效勞總線以及效勞系統(tǒng)工程等?！?.效勞計算開展現(xiàn)狀以及應用效勞計算是企業(yè)界和學術界共同努力的結果。企業(yè)界致力于制定效勞計算相關技術標準、開發(fā)各種支撐工具軟件和系統(tǒng)平臺；學術界致力于效勞計算學科建設、理論創(chuàng)新和方法研究。3.1企業(yè)界企業(yè)界是推動效勞計算產生和開展的源動力。企業(yè)界對“隨需應變”的軟件系統(tǒng)的強烈需求催生了Web效勞技術、面向效勞的體系架構等效勞計算技術體系最為重要的支撐技術。W3C致力于創(chuàng)立Web相關技術標準并催生Web技術開展。該組織針對效勞計算根底技術，特別是Web效勞技術成立了多個工作組，涵蓋了Web效勞架構、Web效勞策略、Web效勞編舞、Web效勞語義標準等工作內容。OASIS致力于推進電子商務標準的開展、整合、推廣和應用，制定了當前大局部效勞計算技術標準。它為效勞計算技術專門成立了多個技術委員會，涵蓋了效勞平安、可靠、效勞質量、事務、信任以及效勞流程等方面，制定了一系列重要標準。第二章面向效勞體系架構SOA(Software-OrientedArchitecture)，即面向效勞架構。軟件架構〔SoftwareArchitecture，或軟件體系結構〕，描述了軟件系統(tǒng)的藍圖，即，構成一個程序或系統(tǒng)的構件的結構，構件間的互連，以及管理構件的設計和演化的原那么和指導。從技術上看，SOA代表了一種開放的、可擴展的、可聯(lián)邦的、可組合的設計范型，是軟件構件技術在分布計算環(huán)境的自然延伸。SOA的根底設施是已有中間件平臺的演化和開展，保存了傳統(tǒng)架構的成功特征?！仓饕妹嫦蛐诩軜嫷谌聝热荨场?.什么是SOASOA的理念最初由全球最具權威的IT研究與參謀咨詢公司Gartner于1996年提出，但是由于當時的技術水平和市場環(huán)境尚不具備真正實施SOA的條件，因此SOA并未引起人們的廣泛關注。進入21世紀之后，Internet風起云涌，越來越多的企業(yè)將業(yè)務轉移到互聯(lián)網領域，帶動了電子商務的蓬勃開展。為了能夠將公司業(yè)務打包成獨立的、具有強大伸縮性的可跨越Internet訪問的效勞，人們提出了Web效勞的概念，這是SOA實踐的真正發(fā)端。到現(xiàn)在為止，還沒有一個權威的SOA標準定義，因為從不同角度，不同廠商和學術團隊會有不同的答案。爭論定義本身，不是目的?！馩ASIS〔一個SOA標準組織〕給出的SOA定義“SOA是一個范式，用于組織和利用可能處于不同所有權范圍控制下的分布式系統(tǒng)?！薄窬S基百科給出的SOA定義“面向效勞的體系結構〔Service-orientedarchitecture〕是構造分布式系統(tǒng)的應用程序的方法。它將應用程序功能作為效勞發(fā)送給最終用戶或者其他效勞。它采用開放標準、與軟件資源進行交互并采用表示的標準方式?！?。這些定義本身，一般人員要準確理解是非常困難的，既便是專業(yè)人士，未必能夠深刻理解其內涵。如何更加形象理解SOA？怎么通俗化解析SOA的核心含義？事實上，SOA的思想我國很早就有了，印刷術的開展過程其思想就完整表達了SOA的核心含義。印刷的內容-文字，在秦始皇統(tǒng)一六國之前，各國的文字是不統(tǒng)一的，據(jù)說許多常用的文字有十幾種寫法和讀音，阻礙了各國之間的文化交流，就象SOA之前，各種軟件平臺、各種開發(fā)工具和各種接口的組件之間，沒有統(tǒng)一的標準，對軟件系統(tǒng)之間的整合造成巨大的困難。因此，偉大的始皇帝統(tǒng)一了六國文字，“書同文、車同軌”就是通過標準解決“復用”和“互操作”等問題。這也為大規(guī)模的印刷和文明開展提供了一個良好的根底，這種“統(tǒng)一封裝”的文字，對文化交流起到了一個“互操作”的標準作用。在沒有印刷術之前，書籍要依賴于手工抄寫，這樣效率當然是非常低下，而且質量也不能獲得一致性的保證，也就是書籍還無法“復用”。中國人首先創(chuàng)造了刻版印刷術，就是將書籍刻成一塊一塊的凸字版，然后就可以大規(guī)模進行印刷了，當印刷出來的書籍脫銷時，下次還可以繼續(xù)使用，大大提高了效率，這就是“復用”，軟件通過組件的封裝，也可以到達重復和在不同場合屢次使用的“復用”效果?？贪嬗∷⑿g有個很大的問題就是文字之間是緊耦合的，同樣一個字，在另一部書之中是不能“復用”的，必須重新雕刻，也就是說刻版印刷是沒有“編排”特性的。就如軟件技術中微軟VB開發(fā)的Com+組件就只能在Windows環(huán)境之中使用，它不能與Java開發(fā)的EJB組件進行復用和編排，因為他們與開發(fā)環(huán)境和運行環(huán)境是緊耦合的，要在UNIX環(huán)境下使用，必須重新開發(fā)〔相當于重新“刻版”〕?；钭钟∷⒕褪峭ㄟ^文字與版面之間的松耦合，通過“排版”來實現(xiàn)一部書的印刷版面的，這種松耦合就大大提高了文字的字模之間的復用和編排效率。我們標準封裝的“效勞”就類似一個一個的字模，通過效勞編排〔“排版”〕來實現(xiàn)業(yè)務流程。統(tǒng)一文字和活字印刷促進了人類文明進步，而SOA促進全球IT架構和應用的革命。要準確全面理解SOA，首先必須理解SOA的核心要素：SOA的目標就是通過重用現(xiàn)有的軟件應用、以組裝的方式實現(xiàn)靈活可變的IT系統(tǒng)。因此，重用、標準化封裝和松耦合可編排是SOA技術本質特征。其中，標準化的封裝實現(xiàn)各個軟件應用之間的松散耦合最為關鍵的因素。§2SOA實現(xiàn)技術的本質特征2.1.1松耦合的依賴關系過去分布式技術沒能解決軟件應用對語言、平臺和廠商的依賴性，不同技術開發(fā)的應用之間不能交互。SOA當前主流實現(xiàn)技術即Web效勞解決了不同應用之間的互聯(lián)互通。效勞是通過效勞描述消除了應用對語言、平臺和廠商的依賴，如圖2-1所示，效勞消費者完全依賴效勞描述。效勞描述是效勞消費者和效勞之間的“合同”，效勞描述包括效勞消費者為實現(xiàn)和效勞交互需要的所有信息，如接口定義、效勞使用策略、效勞級別約定等。效勞描述按照開放標準以文本方式聲明，具有實現(xiàn)無關性。因此效勞描述屏蔽了效勞的實現(xiàn)細節(jié)，剝離了傳統(tǒng)構件所具有的與語言、平臺和廠商的相關性。效勞效勞描述效勞效勞描述效勞消費者-消除組件語言的依賴，CORBA、DCOM分別采用IDL、ODL接口描述語言描述構件。每種實現(xiàn)技術只能實現(xiàn)同類產品之間的交互，不能實現(xiàn)不同類產品的交互。除了消除了上述關鍵性的依賴因素外，SOA還借助其他策略消除了更多的依賴因素，具體包括時間、訪問地址和訪問協(xié)議等。-消除時間依賴對基于遠程過程調用的分布式系統(tǒng)，客戶端需要同步等待請求的返回，在SOA中，我們可以集合事情驅動的原理通過單向消息實現(xiàn)客戶端和效勞的異步交互，從而消除時間依賴。-消除訪問地址依賴SOA通過間接尋址策略消除訪問地址依賴，間接尋址有兩種方式：一種是將訪問地址放到效勞注冊中心，消費者通過查詢注冊中心發(fā)現(xiàn)訪問地址實現(xiàn)間接尋址；另一種是通過單獨的配置文件規(guī)定效勞訪問地址，這樣當效勞地址改變的時候，只需要改變配置文件即可。-消除訪問協(xié)議的依賴，如JAVA使用RMI，CORBA使用IIOP等。效勞描述包括消息傳輸協(xié)議如SOAP和網絡傳輸協(xié)議如的定義，而SOA通過標準的、支持Internet、與操作系統(tǒng)無關的SOAP協(xié)議實現(xiàn)了連接互操作。2.1.2效勞資源的間接尋址間接尋址是SOA松耦合的重要表達之一，通過間接尋址可以消除效勞的訪問地址依賴。圖是被廣泛引用的效勞交互模型，效勞注冊中心是SOA間接尋址的表達。效勞效勞注冊中心效勞提供者效勞請求者發(fā)現(xiàn)發(fā)布交互效勞交互模型包含三類角色：效勞提供者、效勞消費者和效勞注冊中心。效勞交互必須發(fā)生的三種行為：發(fā)布、發(fā)現(xiàn)和綁定或調用。交互作用的對象是效勞和效勞描述。效勞提供者是一個接受并執(zhí)行效勞請求的通過網絡可訪問的實體，效勞提供者將接口約定發(fā)布到效勞注冊中心，以便效勞請求者發(fā)現(xiàn)并訪問。效勞請求者是一個應用、一個軟件模塊或發(fā)出效勞請求的另一個效勞。效勞請求者可以通過效勞注冊中心間接獲得效勞描述，或者從效勞提供者處直接獲得描述，然后遵從效勞描述的接口約定實現(xiàn)和效勞提供者所提供效勞的交互。效勞注冊中心是用于發(fā)現(xiàn)和定位效勞的中介，包括一組供效勞請求者查詢的效勞描述。效勞注冊中心的作用是剝離了效勞提供者和效勞請求者之間的直接地址依賴，使效勞的地址在發(fā)生變更的時候不會影響效勞請求者。另外，效勞注冊中心可以使效勞消費者實現(xiàn)一種更加靈活的效勞定位：在運行的時候通過約束條件在多個效勞中選擇條件最匹配的效勞。一些面向效勞的應用在構造時候僅僅想利用SOA的語言/平臺無關的松散耦合特點，而不需要SOA的間接尋址能力。我們將這種體系結構稱為SBA，即基于效勞的體系架構。§3SOA的作用正如前邊討論過的，企業(yè)業(yè)務正在處理兩個根本問題：快速變化的能力和降低本錢的需要。為了保持競爭優(yōu)勢，企業(yè)必須快速適應內部因素如兼并和重組和外部因素如競爭壓力和顧客需求。業(yè)務需要經濟的、靈活的IT根底設施其業(yè)務需要。SOA具有如下優(yōu)點，有助于組織在今天的動態(tài)業(yè)務環(huán)境下獲得優(yōu)勢?！?〕利用已有資源使企業(yè)通過將現(xiàn)有的資源封裝為效勞來保護IT的投資，這樣企業(yè)可以持續(xù)地利用這些資源，而無需重新開發(fā)。從而表達“構造”而不是重新開發(fā)的先進設計理念?！?〕更容易集成和控制復雜性SOA集成的觀點是效勞標準，而不是實現(xiàn)。提供了實現(xiàn)透明，當根底設施和實現(xiàn)發(fā)生變化的時候，可以將影響降到最低。通過為別離系統(tǒng)中的資源提供效勞標準，集成變得可管理?！?〕更加敏捷、快速地適應市場變化SOA利用現(xiàn)有資源構造新的效勞的機制，可以靈活地反響業(yè)務需求。利用現(xiàn)有的資源構造效勞可以減少軟件開發(fā)周期，這樣可以盡快地開發(fā)出新的業(yè)務，使企業(yè)更快地適應市場變化?！?〕降低本錢，增減重用由于核心業(yè)務效勞是松散耦合，這樣可以根據(jù)業(yè)務需求更加方便地使用和組合。這意味著盡量防止資源的重復開發(fā)、最大程度地利用現(xiàn)有資源、從而降低開發(fā)本錢?！?〕提前開發(fā)，以備之需業(yè)務功能可以預先開發(fā)，以備未來之需。由于業(yè)務流程是由一系列業(yè)務效勞組成的，這樣可以更加容易地創(chuàng)立、調整和管理業(yè)務流程，可以更快地搶占市場先機。SOA提供的這種靈活和敏捷是企業(yè)生存和開展的關鍵。構成效勞5構成效勞5效勞1效勞4效勞3效勞2效勞1效勞4效勞3效勞2效勞層效勞層應用層應用層應用3(Legacy)應用2應用3(Legacy)應用2〔.NET〕應用1〔J2EE〕§4SOA參考模型SOA的核心主體是效勞。所謂“效勞〔Service〕”，從業(yè)務角度而言，效勞是一個可重復的經過標準封裝的任務，例如:檢查帳號余額;開新帳戶等等…。SOA的目標是通過效勞的流程化來實現(xiàn)業(yè)務的靈活性，所謂流程〔Process〕是由一系列相互關聯(lián)的任務所組成，實現(xiàn)一個具體的業(yè)務功能。一個流程可以由一系列效勞來實現(xiàn)。效勞就像一堆“元器件”，這些元器件通過封裝形成標準效勞，他們有相同的接口和語義表達規(guī)那么。但效勞要組裝成一個流程和應用，還需要有效的“管理”，包括如何注冊效勞、如何發(fā)現(xiàn)效勞、如何包裝效勞的平安性和可靠性，這些就是SOA治理。SOA治理乃是將SOA這一堆元器件，進行有效組裝，形成一個“產品”的關鍵，否那么它永遠是一堆器件，而無法形成一個有機整體。SOA治理的方法和體系，就是區(qū)別于一般組件開發(fā)的技術的重要區(qū)別和特征。一個正確的框架，是指導我們開發(fā)和實施SOA架構的根底。由IBM提案，國際開放群組(TheOpenGroup)提出了一個SOA架構的參考模型，這個架構框架目前是產業(yè)界最權威和嚴謹?shù)腟OA架構標準。TheOpenGroup是一個非營利標準化組織，是一個廠商中立和技術中立的機構，致力于提出各種技術框架和理論結構，致力于促進全球市場的業(yè)務效率。TheOpenGroup已有超過20年的標準制定與推廣歷史。在1996年，由X/Open與OpenSoftwareFoundation合并組成。TheOpenGroup最有名是作為UNIX商標的認證機構。在過去，協(xié)會最知名的是其出版的SingleUNIXSpecification，它擴充了POSIX標準而且是UNIX的官方定義，其成員包括IT用戶、供給商以及政府機構。TheOpenGroup在中國的創(chuàng)始會員為金蝶集團，金蝶集團負責成立了中國分會。TOG在1993年提出的TheOpenGroupArchitectureFramework(TOGAF)架構框架，是一套行之有效的企業(yè)架構。歷經15年9個版本開展，支持開放、標準的SOA參考架構，已被80％的福布斯(Forbes)全球排名前50的公司使用。這個SOA參考模型為：根據(jù)這個模型，完整的SOA架構由五大局部組成，分別是：根底設施效勞、企業(yè)效勞總線、關鍵效勞組件、開發(fā)工具、管理工具等。SOA根底實施是為整個SOA組件和框架提供一個可靠的運行環(huán)境，以及效勞組件容器，它的核心組件是應用效勞器等根底軟件支撐設施，提供運行期完整、可靠的軟件支撐。企業(yè)效勞總線〔ESB〕是指由中間件根底設施產品技術實現(xiàn)的、通過事件驅動和基于XML消息引擎，為SOA提供的軟件架構的構造物。企業(yè)效勞總線ESB提供可靠消息傳輸、效勞接入、協(xié)議轉換、數(shù)據(jù)格式轉換、基于內容的路由等功能，屏蔽了效勞的物理位置，協(xié)議和數(shù)據(jù)格式。在SOA根底實現(xiàn)的方案上，應用的業(yè)務功能能夠被發(fā)布、封裝和提升〔Promote〕成為業(yè)務效勞〔BusinessService〕；業(yè)務效勞的序列可以編排成為BPM的流程，而流程也可以被發(fā)布和提升為復合效勞〔CompositedService〕，業(yè)務效勞還可以被外部的SOA系統(tǒng)再次編排和組合。ESB是實現(xiàn)SOA治理的重要支撐平臺，是SOA解決方案的核心，從某種意義上說，如果沒有ESB，就不能算作嚴格意義上的SOA。關鍵效勞實現(xiàn)，是SOA在各種業(yè)務效勞組件的分類。一般來說，一個企業(yè)級的SOA架構通常包括：交互效勞、流程效勞、信息效勞、伙伴效勞、企業(yè)應用效勞和接入效勞。這些效勞可能是一些效勞組件，也可能是企業(yè)應用系統(tǒng)〔如ERP〕所暴露的效勞接口等等。這些效勞都可以接入ESB，進行集中統(tǒng)一管理。開發(fā)工具和管理工具：提供完善的、可視化的效勞開發(fā)和流程編排工具，涵蓋效勞的設計、開發(fā)、配置、部署、監(jiān)控、重構等完整的SOA工程開發(fā)生命周期。按照這個模型，許多SOA解決方案是只提供局部實現(xiàn)。這個行業(yè)中，許多國內的企業(yè)為了搭上SOA的便車，經常以偏概全，混繞概念。應該說真正按照SOA的思想和模型來構建整個企業(yè)的IT架構的案例是非常之少的。許多國外廠商的宣傳案例，根本上是停留在部署應用效勞器，開發(fā)了局部WebService組件，可以實現(xiàn)局部數(shù)據(jù)集成，這個層次而已，而這些WebService是部署在ESB平臺之上的，就已經很不錯了。實現(xiàn)了效勞流程重組，實現(xiàn)SOA治理的案例就更是很少見到了。國內有許多軟件企業(yè)開發(fā)的系統(tǒng)，宣傳是SOA架構的。根本上有幾種情況，其一，有些開發(fā)組件和開發(fā)平臺廠商，他們也自稱中間件企業(yè)，根本上是提供一個工作流平臺，許多還不支持BPEL的業(yè)務流程管理，只是傳統(tǒng)的XPDL/WfMC工作流平臺〔Workflow不同于支持效勞流程的BusinessProcess〕，最常見的案例是OA辦公審批，或者效勞組件開發(fā)工具，而所謂的ESB產品大局部都是EAI的升級，可以與Webservice進行接口而已，就宣稱這是ESB產品了，根本的效勞注冊、效勞編排和平安管理都不具備。這些解決方案只是提供了許多WebService開發(fā)的組件，而不提供SOA治理的核心架構，相當于造了許多元器件，但還不能提供整機產品。其二，許多宣稱SOA架構的應用軟件，根本上可以說是“支持”SOA，而不能稱為“基于SOA”架構。因為支持SOA一般是指可以將其某些功能，封裝為效勞〔WebService〕，可以在SOA架構之中進行管理，這比較容易到達。而“基于SOA”是指應用系統(tǒng)的業(yè)務功能都是封裝為效勞，通過ESB進行集中管理，業(yè)務實現(xiàn)是通過BPEL業(yè)務流程管理進行編排，用戶交互是通過交互效勞〔如門戶〕進行管理，整個解決方案可以到達標準效勞封裝、效勞復用、松耦合、效勞編排與重組，并且根本符合TOG-SOA的架構模型。

按照這個標準，IT用戶就可以了解到真正的SOA架構的框架模型，就可以識別是否是企業(yè)所需要的架構。講到這里，我們已經很清楚了，對于SOA的理解，有些學者或者咨詢公司強調SOA不是一種技術，也不是軟件，而是一種思想，一種架構風格。我認為這也是不完全準確的，這種觀點認為SOA僅僅是思想和方法，將使得SOA成為一種不可知論，飄在空中，很難落地。§5基于SOA的應用系統(tǒng)基于SOA的應用系統(tǒng)構建方法與傳統(tǒng)軟件架構方法有所不同。首先基于SOA的應用系統(tǒng)建模和管理的組件層次是效勞：基于效勞的應用系統(tǒng)的本質特征是松耦合，以根本業(yè)務功能〔效勞封裝〕為系統(tǒng)的根本實現(xiàn)單元，然后通過效勞編排〔流程管理〕來“組裝”業(yè)務應用系統(tǒng)。相對于以往的應用系統(tǒng)，是面向技術組件，由系統(tǒng)程序實現(xiàn)業(yè)務流程，在復用、耦合方面都存在靈活性問題。

效勞建模是第一步，也就是效勞識別和顆粒度確定。效勞識別是方法論的第一步，效勞識別的主要任務，是確定在一定范圍內〔通常是企業(yè)范圍，或假設干業(yè)務場景范圍內〕可能成為效勞的候選者列表，并確定效勞的顆粒度，以及標識效勞的接口。效勞建模也就確定了應用系統(tǒng)架構的耦合程度。

效勞封裝階段的主要任務是對效勞進行標準性的描述，其中包括輸入/輸出消息等功能性屬性，以及效勞在業(yè)務層面的諸多屬性。并決定效勞以何種形式向外提供效勞。效勞可能是新開發(fā)的業(yè)務功能和業(yè)務對象的封裝，也可能是遺留系統(tǒng)的效勞封裝，將遺留系統(tǒng)的軟件資產以效勞的形式進行封裝，在新的架構上利用已有的資產。

效勞治理就是將已經封裝好的效勞進行集中統(tǒng)一有效的管理。通過ESB根底設施，提供效勞注冊、存儲、平安控制和版本管理等。效勞注冊階段的主要任務是將效勞注冊到效勞庫。此時需要決定效勞的命名、平安、性能、時間特性。

效勞編排就是根據(jù)業(yè)務流程的需求，對效勞進行組合和組裝。效勞組裝是以實現(xiàn)業(yè)務流程為目的，通過對業(yè)務效勞的組合和組裝，實現(xiàn)更粗粒度的業(yè)務效勞，實現(xiàn)最終的業(yè)務需求。

應用交付階段主要任務是完成業(yè)務系統(tǒng)效勞化組裝和效勞部署，實現(xiàn)業(yè)務按需交付?；赟OA的應用系統(tǒng)是SOA架構的重要組成局部，也是SOA落地的地基?！舱越鸬虚g件總經理奉繼承博士原文：://blog.vsharing/fengjicheng/A1059842.html〕第三章SOA主流實現(xiàn)技術〔Web效勞〕簡單地說，Web

效勞是部署在Web上的軟件構件。Web效勞互操作性拓展了Web的能力，使其從原來的單純面向人類的信息和功能提供平臺開展成為分布式計算平臺。如圖1.1所示，人通過瀏覽器軟件與Web應用交互，此時瀏覽器與Web應用是通過HTML語言互相傳遞消息；Web

效勞提供了一種可以在Web上共享的功能，應用通過標準Web和Internet協(xié)議可以直接使用Web效勞提供的功能，此時兩者之間是通過XML/SOAP語言互相對話的。其中，XML是一種與平臺/編程語言無關、具有可擴展類型系統(tǒng)的數(shù)據(jù)表示語言，適合在各種平臺/編程語言的應用之間交換信息；SOAP那么提供了一種應用之間互相傳遞基于XML數(shù)據(jù)的消息通信協(xié)議。2.1Web效勞的定義效勞是面向效勞架構中核心概念，不理解效勞的概念，那么無法理解面向效勞的架構。目前不同組織對效勞尚無統(tǒng)一的定義。?國際標準化組織W3C：Web效勞是一個通過URL識別的軟件應用程序，其界面及綁定能用XML文檔來定義、描述和發(fā)現(xiàn)，使用基于Internet協(xié)議上的消息傳遞方式與其他應用程序進行直接交互。?Microsoft：Web效勞是為其它應用提供數(shù)據(jù)和效勞的應用邏輯單元，應用程序通過標準的Web協(xié)議和數(shù)據(jù)格式獲得Web效勞，如、XML和SOAP等，每個Web效勞的實現(xiàn)是完全獨立的。Web效勞具有基于組件的開發(fā)和Web開發(fā)兩者的優(yōu)點，是Microsoft的.Net程序設計模式的核心。?IBM認為，Web效勞是一種自包含、自解釋、模塊化的應用程序，能夠被發(fā)布、定位、并且從Web上的任何位置進行調用。Web效勞可以執(zhí)行從簡單的請求到錯綜復雜的商業(yè)處理過程的任何功能。理論上來講，一旦對Web效勞進行了部署，其它Web效勞應用程序就可以發(fā)現(xiàn)并調用已部署的效勞。?市場研究公司Forrester以一種更加開放的方法將Web效勞定義為人、系統(tǒng)和應用之間的自動連接，這種連接能夠實現(xiàn)將業(yè)務功能元素轉變?yōu)檐浖?，并且?chuàng)造新的業(yè)務價值。Web效勞是基于網絡的、分布式的模塊化組件，它執(zhí)行特定的任務，遵守具體的技術標準，這些標準使得Web效勞能與其他兼容的組件進行互操作。?Gartner將Web效勞定義為：松散耦合的軟件組件，這些組件動態(tài)地通過標準的網絡技術與另一個組件進行交互。Web效勞可以從多個角度來描述〔理解〕。從技術方面講，一個Web效勞是可以被URI識別的應用軟件，其接口和綁定由XML描述和發(fā)現(xiàn)，并可與其他基于XML消息的應用程序交互；從功能角度講，Web效勞是一種新型的Web應用程序，具有自包含、自描述以及模塊化的特點，可以通過Web發(fā)布、查找和調用實現(xiàn)網絡調用。從應用的層面來說，Web效勞是用于集成應用的，將原有的面向對象、面向組件的軟件系統(tǒng)改造為基于消息面向效勞的松散耦合系統(tǒng)或者構建新的松散耦合系統(tǒng)的一種協(xié)作設施。從組成框架及實現(xiàn)目標的角度講，Web效勞作為一種網絡操作，能夠利用標準的Web協(xié)議及接口進行應用間的交互。從網格計算(gridcomputing)的角度看，Web效勞能用于Web上的資源發(fā)現(xiàn)、數(shù)據(jù)管理及網格計算平臺上異構系統(tǒng)的協(xié)同設計，提出了網格效勞的新概念?！?.2Web效勞根底標準1999年，W3C和相關的企業(yè)開始討論設計基于XML的通信協(xié)議，2000年，W3C發(fā)布SOAP〔Simple

Object

Access

Protocol〕協(xié)議的1.1版。人們把利用SOAP協(xié)議傳遞XML信息的分布式應用模型稱為Web

效勞。2001年，W3C發(fā)布了WSDL〔Web

Services

DescriptionLanguage〕協(xié)議的1.1版。SOAP協(xié)議和WSDL協(xié)議共同構成了Web

Service的根底如下圖。隨后，J2EE和.NET這兩大企業(yè)級開發(fā)平臺先后實現(xiàn)了Web

Service，并將其視為平臺的一項核心功能。

〔點擊查看大圖〕圖9-2圖2.Web效勞根底協(xié)議棧Web效勞平臺需要一套協(xié)議來實現(xiàn)分布式應用程序的創(chuàng)立。任何平臺都有它的數(shù)據(jù)表示方法和類型系統(tǒng)。要實現(xiàn)互操作性，Web效勞平臺必須提供一套標準的類型系統(tǒng)，用于溝通不同平臺、編程語言和組件模型中的不同類型系統(tǒng)。在傳統(tǒng)的分布式系統(tǒng)中，基于界面(interface)的平臺提供了一些方法來描述界面、方法和參數(shù)〔譯注：如COM和COBAR中的IDL語言〕。同樣的，Web效勞平臺也必須提供一種標準來描述Web效勞，讓客戶可以得到足夠的信息來調用這個Web效勞。最后，我們還必須有一種方法來對這個Web效勞進行遠程調用。這種方法實際是一種遠程過程調用協(xié)議(RPC)。為了到達互操作性，這種RPC協(xié)議還必須與平臺和編程語言無關。下面幾個小節(jié)就簡要介紹了組成Webservice平臺的這三個技術。傳輸協(xié)議傳輸層是用來將效勞請求從效勞請求者傳輸給效勞提供者，或者將效勞響應從效勞提供者傳輸給效勞響應者的機制。目前有多種Web效勞傳輸標準如、SMTP和FTP，其中最流行的是標準是。Web效勞XML和XSD可擴展的標記語言(XML)是Web效勞平臺中表示數(shù)據(jù)的根本格式。除了易于建立和易于分析外，XML主要的優(yōu)點在于它既是平臺無關的，又是廠商無關的。XML解決了數(shù)據(jù)表示的問題，但它沒有定義一套標準的數(shù)據(jù)類型，更沒有說怎么去擴展這套數(shù)據(jù)類型。例如，整形數(shù)到底代表什么？16位，32位，還是64位？這些細節(jié)對實現(xiàn)互操作性都是很重要的。W3C制定的XMLSchema(XSD)就是專門解決這個問題的一套標準。它定義了一套標準的數(shù)據(jù)類型，并給出了一種語言來擴展這套數(shù)據(jù)類型。Web效勞平臺就是用XSD來作為其數(shù)據(jù)類型系統(tǒng)的。當采用某種語言(如C#)來構造一個Web效勞時，為了符合Web效勞標準，所使用的所有數(shù)據(jù)類型都必須被轉換為XSD類型。Web效勞SOAPWeb效勞建好以后，就需要去調用它。簡單對象訪問協(xié)議(SOAP)提供了標準的RPC方法來調用Web效勞。實際上，SOAP在這里有點用詞不當：它意味著下面的Web效勞是以對象的方式表示的，但事實并不一定如此，Web效勞寫成被一系列的C函數(shù)，并仍然使用SOAP進行調用。SOAP標準定義了SOAP消息的格式，以及怎樣通過協(xié)議來使用SOAP。SOAP也是基于XML和XSD的，XML是SOAP的數(shù)據(jù)編碼方式。如果將傳輸層看成是兩個端點之間的通路，那么效勞通信協(xié)議那么是通路上行駛的機動車。效勞通信協(xié)議描述和定義用來提供交互的效勞之間的傳輸機制的技術和標準。Web效勞WSDL你會怎樣向別人介紹你的Web效勞有什么功能，以及每個函數(shù)調用時的參數(shù)呢？你可能會自己寫一套文檔，你甚至可能會口頭上告訴需要使用你的Web效勞的人。這些非正式的方法至少都有一個嚴重的問題：當程序員坐到電腦前，想要使用你的Web效勞的時候，他們的工具(如VisualStudio)無法給他們提供任何幫助，因為這些工具根本就不了解你的Web效勞。解決方法是：用機器能閱讀的方式提供一個正式的描述文檔。Web效勞描述語言(WSDL)就是這樣一個基于XML的語言，用于描述Web效勞及其函數(shù)、參數(shù)和返回值。因為是基于XML的，所以WSDL既是機器可閱讀的，又是人可閱讀的，這將是一個很大的好處。一些最新的開發(fā)工具既能根據(jù)你的Web效勞生成WSDL文檔，又能導入WSDL文檔，生成調用相應Web效勞的代碼。WEB效勞的描述與參考資料Web效勞是一種新的重要的應用程序。Web效勞是一段可以用XML發(fā)現(xiàn)、描述和訪問的代碼。在這一領域有許多活動，但有三種主要的用于Web效勞的XML標準：SOAP：最初是簡單對象訪問協(xié)議〔SimpleObjectAccessProtocol〕，SOAP定義一個XML文檔格式，該格式描述如何調用一段遠程代碼的方法。我的應用程序創(chuàng)立一個描述我希望調用的方法的XML文檔，并傳遞給它所有必需的參數(shù)，然后應用程序通過網絡將該XML文檔發(fā)送給那段代碼。代碼接收XML文檔、解釋它、調用我請求的方法，然后發(fā)回一個描述結果的XML文檔。SOAP標準版本1.1位于/TR/SOAP/。請訪問/TR/以了解W3C中SOAP相關的所有活動。WSDL：Web效勞描述語言〔WebServicesDescriptionLanguage〕是一個描述Web效勞的XML詞匯表。編寫一段接收WSDL文檔然后調用其以前從未用過的Web效勞的代碼，這是可能的。WSDL文件中的信息定義Web效勞的名稱、它的方法的名稱、這些方法的參數(shù)和其它詳細信息。您可以在/TR/wsdl〔結尾沒有斜杠符號〕找到最新的WSDL標準。UDDI：統(tǒng)一描述、發(fā)現(xiàn)和集成〔UniversalDescription,Discovery,andIntegration〕協(xié)議向Web效勞注冊中心定義SOAP接口。如果您有一段代碼希望作為Web效勞部署，UDDI標準定義如何將您的效勞描述添加至注冊中心。如果您在尋找一段提供某種功能的代碼，UDDI標準定義如何查詢注冊中心以找到您想要的信息。有關UDDI的所有資料來源都可以在找到。Web效勞的優(yōu)點：適應性：可以使用任何編程語言、計算平臺和軟件體系結構開發(fā)Web效勞。應用性：Web效勞允許作為組件開發(fā)的軟件被其他軟件部件或被可以被輸入到Web瀏覽器的URI重用?；ゲ僮餍裕旱浆F(xiàn)在為止Web效勞最大的好處是它們支持不同計算平臺之間的通信。平臺之間的通信不再要求它們必須具有相同的硬件和軟件組件。Web效勞支持使用Java、C++、.NET、JavaScript、Perl和其他編程語言開發(fā)的多種平臺之間的交互操作性。因為Web效勞建于Web標準(比方XML)之上，所以業(yè)務組件之間的通信基于行業(yè)標準而非專門的協(xié)議。為啥要創(chuàng)立WEB效勞1.Webservice平臺是一套標準，它定義了應用程序如何在Web上實現(xiàn)互操作性。你可以用任何你喜歡的語言，在任何你喜歡的平臺上寫Webservice，只要我們可以通過Webservice標準對這些效勞進行查詢和訪問2..任何運行Web瀏覽器的機器都在使用協(xié)議。同時，當前許多防火墻也配置為只允許連接-SOA標準體系是實現(xiàn)SOA應用系統(tǒng)所涉及的國際標準、業(yè)界主流技術標準、行業(yè)標準的有機整體，涵蓋業(yè)務分析、建模、設計、開發(fā)、組裝、部署、測試、管理〔治理〕等各個環(huán)節(jié)。SOA標準體系基于中國的行業(yè)應用需求及標準化現(xiàn)狀，以現(xiàn)有國際標準組織〔W3C、OASIS、WS-I、OMG、IETF等〕所發(fā)布的相關技術標準為核心，從根底、架構、應用三個層次提供了支撐SOA系統(tǒng)實現(xiàn)的參考標準集，為基于SOA的測試、評估及質量保證提供依據(jù)。SOA標準體系圖如下：

下面依據(jù)SOA標準體系圖，介紹SOA標準體系的組成局部以及各局部之間的關系。

1、根底層：

(1)XML及相關標準

XML及其相關標準是SOA的基石。其規(guī)定了效勞之間以及效勞內部數(shù)據(jù)交換的格式和結構、保障消息數(shù)據(jù)的完整性和有效性、提供不同數(shù)據(jù)表達之間互相通信的格式，同時提供在XML文檔和信息內嵌的加密數(shù)據(jù)和數(shù)字簽名格式、為所有Web效勞平安技術建立的提供根底。

(2)網絡傳輸標準

數(shù)據(jù)傳輸是SOA系統(tǒng)最根本的需求之一。SOA系統(tǒng)是分布式系統(tǒng)，需要傳輸大量數(shù)據(jù)，數(shù)據(jù)傳輸就是其生命線。網絡傳輸標準解決了如何連接，如何驗證，如何發(fā)送、接收數(shù)據(jù)以及如何報告錯誤等問題。

2、架構層：

(1)消息傳遞標準

基于SOA構建的系統(tǒng)，系統(tǒng)內部各組成局部間需要不斷的相互交換消息，以到達協(xié)調完成業(yè)務任務的目標。消息傳遞標準提供了在分布式環(huán)境中交換信息的框架，定義了消息格式、消息交換模式，保證SOA系統(tǒng)能可靠、及時的傳遞消息。

(2)效勞描述和發(fā)現(xiàn)標準

對松散耦合的SOA系統(tǒng)來講，效勞標準化的描述、發(fā)布和發(fā)現(xiàn)是至關重要的。描述和發(fā)現(xiàn)標準和標準定義一組效勞，用于支持Web效勞提供者、Web效勞消費者以及可以用于訪問這些效勞的技術接口的描述和發(fā)現(xiàn)。

(3)可靠性標準

可靠性是指穩(wěn)定、魯棒等效勞質量因素，可靠消息傳遞允許在出現(xiàn)軟件組件、系統(tǒng)或網絡故障時可靠的在分布式應用程序間交付消息?？煽啃允鞘褂肳eb效勞的必要條件。

(4)事務性標準

SOA系統(tǒng)是分布式系統(tǒng)，在分布式計算領域，事務是構造可靠分布式應用程序的關鍵。Web效勞事務性標準利用傳統(tǒng)事務機制提供的協(xié)調行為來控制應用程序的操作和輸出。

(5)平安性標準

平安性是SOA系統(tǒng)的重要方面，是大多數(shù)用戶優(yōu)先考慮的問題。使用Web效勞技術構建SOA系統(tǒng)，需要保護Web效勞，確保只被那些準許的邏輯訪問。為了保持Web效勞的開放性并支持多種類型的客戶端，就必須解決Web效勞的平安性問題。Web效勞平安性標準為Web效勞框架提供平安通信的方法。

(6)互操作標準

SOA和Web效勞技術的標準眾多，不同的標準可能來自不同的標準化組織，存在著不能完全互聯(lián)互通的問題，如何用這些標準來開發(fā)可互操作的Web效勞，是一個亟待解決的問題。因此，SOA需要互操作標準來確保SOA系統(tǒng)的互操作性。

(7)表示層標準

標準Web效勞或面向數(shù)據(jù)的Web效勞包括業(yè)務邏輯，但缺少表示邏輯。相同的業(yè)務流程和業(yè)務數(shù)據(jù)在不同平臺不同終端上往往要求以不同的表現(xiàn)形式展現(xiàn)給用戶。表示層標準將下層的內容以多樣化的形態(tài)提供給上層的終端用戶。

(8)業(yè)務流程標準

構建基于SOA的系統(tǒng)以業(yè)務為中心，業(yè)務邏輯的實現(xiàn)及優(yōu)化通過效勞組合、效勞編排來完成。業(yè)務效勞通?？缍鄠€組織和機構，需要將效勞進行有效的組織才能滿足業(yè)務邏輯的需求。業(yè)務流程方面的標準由此而催生。

(9)集成開發(fā)標準

SOA產品及系統(tǒng)的具體實現(xiàn)需要開發(fā)標準作為指導，包括根底效勞的實現(xiàn)、效勞組裝的實現(xiàn)等。同時SOA工程往往需要整合各種已有資源，作為一項系統(tǒng)性的工作，集成過程需要全局的標準化的效勞組件以及協(xié)議接口作為支撐。

(10)效勞管理標準

管理效勞用于發(fā)現(xiàn)它們存在的問題、了解效勞的狀況、性能，并對效勞進行控制和配置。用效勞構建SOA系統(tǒng)時，業(yè)務操作全部都是由效勞來完成，效勞管理標準提供對效勞合理有效管理的方法，滿足業(yè)務操作需要。

(11)質量保證標準

效勞質量及水平是判定一個SOA系統(tǒng)是否成功的重要因素。SOA系統(tǒng)的質量重點是貫穿于效勞生命周期的質量維護，包括可用性、穩(wěn)定性、可維護性等多方面因素。SOA系統(tǒng)需要質量保證標準來確保系統(tǒng)的效勞質量。

3、應用層—應用標準

SOA工程最終效勞于具體的行業(yè)或領域用戶，如電子政務、電子商務、企業(yè)信息化、社區(qū)信息化等等。不同用戶有各自不同的特點，SOA工程的規(guī)劃及設計必須首先遵從行業(yè)標準、企業(yè)的業(yè)務戰(zhàn)略及規(guī)那么，實施中效勞設計及實現(xiàn)需要相關的應用標準來指導，SOA的治理也需要和企業(yè)IT策略一致。

4、組成局部關系分析

XML及相關標準是支撐SOA技術及標準開展的重要根底，在SOA熱潮之前已在傳統(tǒng)的萬維網及Web技術中得到了廣泛應用。XML作為目前數(shù)據(jù)交換的唯一公共語言，是架構層所有SOA標準的根底，提供了不同平臺及應用軟件通過網絡可進行交互的數(shù)據(jù)內容和結構描述格式。相關的XMLSchema、XSLT、XMLSignature、XMLEncryption為SOA架構層中的關鍵消息傳遞、Web效勞平安等標準提供了直接構建和引用根底。根底層中以為代表的網絡傳輸標準，廣泛應用于傳統(tǒng)Web應用，是SOA消息傳遞標準的根底。架構層的SOA技術標準以WS-*核心。消息傳遞標準構筑在傳輸標準之上，它以傳輸標準作為載體進行工作，消息傳遞標準之上是效勞描述和發(fā)現(xiàn)相關標準，標準體系的這三個局部搭建起了SOA的根本框架；可靠、平安、事務三個局部標準需要與效勞描述、發(fā)現(xiàn)相關標準結合起來工作，它們一定程度上是對根本的效勞描寫、發(fā)現(xiàn)標準的補充，用以滿足SOA實際應用的要求。

標準出自不同的標準組織，同一標準不同的廠商實現(xiàn)也可能不是完全一樣，互操作標準將SOA標準中的二義性進行重新定義，在語義上確保交互的一致性，以實現(xiàn)不同實現(xiàn)平臺的互操作。互操作性標準可以看作SOA標準體系的根底組成局部，利用它們即可以支撐構建出較完善的SOA系統(tǒng)。架構層業(yè)務流程標準建立起業(yè)務與效勞的橋梁，開發(fā)標準指導SOA系統(tǒng)的實施，它需要SOA標準體系中其它各類標準的支持。集成標準標準化基于不同技術構筑的系統(tǒng)的協(xié)作，管理標準方便SOA系統(tǒng)資源和效勞的管理，這幾個標準都以構筑在標準體系根底組成局部之上的效勞為對象，因此它們需要根底組成局部標準對它們的支持。架構層質量保證標準是SOA構建后重要評估手段，需要從不同等級〔單個效勞、局部集成、整個系統(tǒng)〕來確保效勞質量，其內容涉及到架構層其他各類標準SOA系統(tǒng)。應用層標準是針對各行業(yè)制定的指南性標準，基于應用行業(yè)及企業(yè)的具體要求及規(guī)那么、對應各類SOA相關標準的具體應用。三Web效勞介紹Web效勞包含3種類型的角色：效勞請求者、效勞提供程序和效勞發(fā)現(xiàn)代理。請求者(requestor)--客戶端--是需要數(shù)據(jù)或已執(zhí)行效勞的商業(yè)軟件，所以它發(fā)出執(zhí)行某個Web效勞的請求。效勞提供程序(serviceprovider)響應Web效勞請求。請求者使用提供者提供的效勞。發(fā)現(xiàn)代理(discoveryagency)用作所有已發(fā)布的Web效勞的存儲庫。這種代理可能支持向其發(fā)送描述，或者可能輪詢公共提供者以獲得描述。計算平臺可以承當這些角色中的一個或多個，例如同時作為請求者和提供程序，或者同時作為請求者、提供程序和效勞發(fā)現(xiàn)代理。一個或多個Web效勞可以被結合起來以執(zhí)行一個完整的業(yè)務事務。圖9-1說明了分別承當一個角色的計算平臺之間的交互。

〔點擊查看大圖〕圖9-1在執(zhí)行這些角色的平臺間可以發(fā)生3種類型的操作：獲取、發(fā)布和綁定。效勞提供程序實現(xiàn)軟件組件，把描述直接發(fā)布給請求者或效勞發(fā)現(xiàn)代理。效勞請求者嘗試從本地或效勞發(fā)現(xiàn)代理定位/找到/獲取效勞描述(這種獲取操作可以在軟件開發(fā)期間或請求者軟件的執(zhí)行期間發(fā)生)。平臺間的通信以XML(eXtensibleMarkupLanguage，可擴展標記語言)形式的消息進行。這些消息的方向可以是單向、雙向、播送或大量的消息。可以同步或異步發(fā)送消息。9.3

Web效勞體系結構Web效勞運行在一個通信根底設施之上，這個通信根底設施由由幾層廣泛使用的公共可用協(xié)議組成。Web效勞協(xié)議棧不存在標準定義，所以對這些協(xié)議的體系結構說明根據(jù)供給商或標準組織的不同而不同。盡管如此，圖9-2給出了一個根底的協(xié)議棧圖。UDDI、WSDL和SOAP都是得到批準的協(xié)議。

〔點擊查看大圖〕圖9-29.3.1

網絡層在商業(yè)組織內可能存在許多運行不同協(xié)議(如IBMMQSeries或CORBA)的私有內部網。與此相反，Web效勞使用行業(yè)內普遍接受的Web網絡協(xié)議進行通信。因此，Web效勞可以用作各種專用內部網之間進行通信的媒介。雖然IT部門取締和阻止了許多其他的網絡協(xié)議(比方telnet、ftp等)，并把它們看做潛在的平安漏洞，但是卻被用來支持Web瀏覽器的連續(xù)操作。這保證了以為根底的應用程序協(xié)議的較長生命期。在Web效勞中，Web效勞的消息通過這個網絡層傳遞。9.3.2

XMLXML是一種格式，通過它文本可以以獨立于平臺的方式代表數(shù)據(jù)。處理XML的工具有很多。XML數(shù)據(jù)的格式和內容在XML模式中描述。XML模式使用XML語法描述XML文檔中的元素、屬性和實體之間的關系。XML模式的用途是定義一類必須符合特定的結構規(guī)那么和數(shù)據(jù)約束的集合的XML文檔。這種XML數(shù)據(jù)要想有用，必須把XML傳輸給業(yè)務應用程序使用的編程語言所支持的應用程序數(shù)據(jù)結構。用于轉換XML和數(shù)據(jù)結構的機制的技術術語稱為數(shù)據(jù)綁定。對于根底數(shù)據(jù)類型(比方Java根本數(shù)據(jù)類型)已經存在執(zhí)行這種轉換的軟件。然而，對于較為復雜的數(shù)據(jù)結構而言，可能需要開發(fā)自定義的代碼。9.3.3

SOAPSOAP現(xiàn)在是XML消息的行業(yè)標準，這是一個圍繞通過網絡層傳遞的XML應用程序有效負載的瘦層(thinlayer)。SOAP獨立于網絡層的類型，它可以與許多協(xié)議一起使用，比方、JMS或FTP。交換SOAP最常用的方法是通過。通過它的消息頭可以對它進行擴展，而業(yè)務應用程序可以對它的消息頭進行填充或處理。SOAP消息提供了如下內容。通過Web對數(shù)據(jù)和效勞的訪問通過Web在客戶端和效勞之間傳輸數(shù)據(jù)對象的能力正是通過這兩種能力業(yè)務才能與其他的業(yè)務或客戶通信。SOAP消息可能包含3種不同類型的元素，而且它必須是結構良好的XML文檔。這3種不同類型的元素分別如下。信封(必要)：這是SOAP消息的容器，所以它可以包含消息主體和任何消息頭。它包含一個用于唯一身份標識的名稱空間聲明。消息頭(可選)：這個可選元素用作容器，包含可用于擴展SOAP消息以支持身份驗證或路由能力的額外信息。事實上，整個的WS-*功能集都使用消息頭來實現(xiàn)擴展。消息主體(必要)：消息主體包含XML格式的有效負載，還可能包含SOAPRPC請求或以文檔為中心的消息。在較早的RPC風格的Web效勞(稱為rpc/end)中，效勞請求者使用必要的參數(shù)發(fā)送調用方法的名稱，任何計算結果都將被返回。雖然這種風格有助于更簡單地開發(fā)軟件，但是它會帶來互操作性上的問題，尤其在發(fā)送和接收復雜數(shù)據(jù)結構時更是這樣。使用這種風格時，其內容的特殊性質使通信系統(tǒng)具有緊密地耦合性。這種風格代表了通信的一種同步形式。由于互操作性的問題，現(xiàn)在Web效勞互操作性組織的根本配置文件(WebServicesInteroperabilityOrganization'sbasicprofile，WS-IBP)不推薦這種風格。與之相反，得到推薦的是XML以文檔為中心的風格--doc/lit風格。這是一種面向文檔的風格，在其中效勞請求者發(fā)送完整的XML文檔。效勞提供者可以也可以不返回消息。這種風格使用W3CXML模式定義來指定XML數(shù)據(jù)格式。9.3.4

WSDLWSDL就是對Web效勞軟件的描述。具體來說，它描述所有公共可用的方法、交換方法、消息類型以及用在網絡層的傳輸協(xié)議和Web效勞的地址?？蛻舳藨贸绦蚩梢詾槭褂玫奶囟▊鬏攨f(xié)議找到Web效勞，以及調用任何公共方法。根本上，WSDL可以看作是效勞提供者和效勞請求者之間的契約。WSDL是XML格式的，所以它也具有平臺無關性。WSDL和Java類似，因為它支持抽象和具體概念、以及接口。類似于Java，WSDL也支持抽象的接口。在WSDL下是一個效勞，這個效勞被描述為一個接受消息的終端的集合。再往下是一些根底的WSDL術語，圖9-3顯示了這些概念之間的關系。消息：消息由類型化的數(shù)據(jù)局部組成操作：效勞請求者和效勞提供者之間的一組消息portType：操作集合端口：portType的實現(xiàn)serviceType：portType的集合效勞：端口集合，這是serviceType的實現(xiàn)1.WSDL文檔WSDL1.2文檔由4個信息的根本元素組成，它們被稱為Infoset，描述Web效勞。Infoset就是WSDL文檔中使用的XML元素和屬性。另外，WSDL支持一個組件模型，這個組件模型鏡像Infoset并提供另一個抽象層。下面的列表定義了WSDL2中XMLInfoset的元素。

〔點擊查看大圖〕圖9-3描述：這是第一個元素，它用作其他WSDL元素的容器。接口：這個元素定義了效勞具有的抽象行為。接口有名稱，可以擴展其他的接口。接口可以包含操作以及錯誤。綁定：這個元素定義了訪問效勞的方式。綁定有名稱，是一個具體元素，它指定了消息的內容以及每個接口的傳輸協(xié)議。接口中存在的所有操作和錯誤都在這個元素中定義。效勞：這個元素定義了訪問效勞的地方，它包含效勞的名稱和一個或多個終端。終端：這是引出消息的目的地。2.WSDL綁定WSDL1.2是可以擴展的。通過使用一個稱為擴展(extension)--或者具體來說是綁定擴展(bindingextension)--的機制，可以添加新的消息格式以及傳輸協(xié)議。擴展在WSDL的頂部為每個綁定擴展提供一個名稱空間聲明前綴。之后在WSDL中綁定擴展的前綴就可以用于元素和屬性了。WSDL1.2包含支持SOAP1.2和SOAP1.1的綁定擴展。這些擴展允許定制SOAP消息，比方使用的版本、綁定、協(xié)議和SOAP消息頭。擴展有一個默認值的集合，可以用在接口或操作級上。當使用作為傳輸協(xié)議時，綁定應該指出是否使用GET或POST。WSDL2.0也支持綁定擴展，以便在使用時不使用SOAP。9.3.5

UDDIUDDI是一個標準，它定義了與Web效勞相關的信息的發(fā)布、發(fā)現(xiàn)和管理。UDDI以2000年的1.0版本開始，現(xiàn)在UDDI的標準已經是3.0版本，它向后兼容以前的版本。該標準中存在3種類型的組件。第一種類型(節(jié)點)是UDDI效勞器，它確切地屬于一個UDDI注冊庫。節(jié)點在UDDI數(shù)據(jù)上執(zhí)行操作。對于API，標準區(qū)分了兩種不同類型的節(jié)點：UDDI效勞器和UDDI客戶端。組件的第二種類型，注冊庫，包含一個或多個節(jié)點。節(jié)點有3種類型：公有、附屬和私有。公有注冊庫中的數(shù)據(jù)可以在其他注冊庫中共享。私有注冊庫中的數(shù)據(jù)不可以共享，并且也不允許對注冊庫和管理功能的訪問。第三種組件，附屬注冊庫，由通過使用策略在彼此間共享信息的注冊庫組成。UDDI3.0中的注冊庫可以被配置為分層次結構的、基于對等實體的、或受委托的配置。受管理的客戶端對這些注冊庫有有限的訪問權。標準有一個信息模型，它包括以下內容。業(yè)務實體：關于效勞發(fā)布者的信息。業(yè)務實體包含業(yè)務效勞。業(yè)務效勞：關于特定技術效勞組的信息。業(yè)務效勞包含綁定模板。綁定模板：關于如何與效勞交互的信息。綁定模板可以引用tModels。UDDI用作描述Web效勞的數(shù)據(jù)和元數(shù)據(jù)的存儲庫。9.4Web效勞交互9.4

Web效勞交互Web效勞的應用場合如下。(1)效勞請求者創(chuàng)立一個包含必要的效勞有效負載的SOAP消息。通常效勞請求者在運行時使用SOAP客戶端，這有助于把輸入和輸出對象轉換為XML消息。(2)在網絡層的另一端，SOAP效勞器運行庫接收到效勞請求，并把該XML消息轉換為提供程序平臺(Java、C#等)使用的編程語言所支持的數(shù)據(jù)結構。然后效勞提供程序說明響應并把它交給SOAP效勞器運行庫以通過網絡