分布式計算云與大數(shù)據(jù)課件第7章web services

機械工業(yè)出版社《分布式計算、云計算與大數(shù)據(jù)》配套課件華南理工大學林偉偉主編第7章WebServices提綱WebServices概述XMLSOAPWebServicesRESTWebServicesWebServices概述WebServices背景和概念WebServices特點WebServices應用場合WebServices技術架構WebServices工作原理WebServices的開發(fā)2023/10/10DistributedComputing4WebServices的基本原理WebServices背景和概念WEB應用與傳統(tǒng)的桌面應用之間存在連接上的鴻溝，平臺的互操作性差和異構性等問題嚴重影響了WEB應用的發(fā)展。WebServices的出現(xiàn)正是為了解決跨應用系統(tǒng)、跨平臺、跨架構的互操作問題。WebService是一種跨編程語言和跨操作系統(tǒng)平臺的遠程調用技術。通過WebServices可以使運行在不同機器上的不同應用無須借助附加的、專門的第三方軟件或硬件，就可以相互交換數(shù)據(jù)或進行集成。因此，無論應用之間采用什么語言、平臺或內部協(xié)議，都可以方便地進行數(shù)據(jù)的交換。WebServices是基于一些常規(guī)的產業(yè)標準和已有的成熟技術，如XML和HTTP等開放式Web規(guī)范技術，因此，它具有很好的開放性和互操作性。此外，WebServices的協(xié)議、接口和注冊以松耦合方式協(xié)同工作，減少了應用程序接口的花費，為整個企業(yè)間業(yè)務流程集成提供了一個通用機制。WebServices特點良好的封裝性

WebServices是一種部署在Web上的對象，因此具有對象的特點，即良好的封裝性。這樣服務使用者只能看到對象提供的通用接口和功能列表，而不用關心服務的實現(xiàn)細節(jié)。松耦合

只要WebServices的調用接口不變，其內部變更對調用者來說是透明的。使用標準協(xié)議規(guī)范Web服務是基于XML的消息交換機制，其所有公共的協(xié)約都采用Internet開放標準協(xié)議進行描述、傳輸和交換。相比一般對象而言，其調用更加規(guī)范化，便于機器理解。高度可集成性

由于WebServices采取簡單的、易于理解的標準協(xié)議作為組件描述，因此完全屏蔽了不同軟件、平臺的差異，使它們之間可以通過WebServices來實現(xiàn)互操作。易于構建

要構建WebServices，開發(fā)人員可以使用任何常用的編寫語言（如Java、C#、C/C++或Perl等）及其現(xiàn)有的應用程序組件。WebServices應用場合跨防火墻的通信把應用程序的中間層換成WebServices，可以從客戶端直接調用服務，而不需要建立額外的ASP頁面。同時作為中間層的WebServices完全可以在應用程序集成場合下重用。這樣不僅減少了開發(fā)周期和代碼復雜度，還能夠增強應用程序的重用性和可維護性。應用程序集成通過WebServices把應用之間需要“暴露”給對方的功能和數(shù)據(jù)，以服務接口的形式提供給調用者，而不用去在意各應用程序之間異構性，因為WebServices是采用開放的、標準的、跨平臺的協(xié)約來執(zhí)行的。B2B的集成WebServices是實現(xiàn)B2B應用程序高效集成的重要技術之一，電子商務公司可以根據(jù)業(yè)務需求將應用的接口“暴露”給指定的客戶或供應商，以方便客戶和供應商高效地完成電子業(yè)務。軟件和數(shù)據(jù)重用組件提供商可以把組件變成WebServices，并把相應的服務接口提供給服務使用者。這樣，服務使用者無需將服務組件下載到本地并安裝，而是直接在應用中調用服務，獲取所需的數(shù)據(jù)。WebServices技術架構三種主流的Web服務實現(xiàn)方案：RESTSOAPXML-RPCREST表述性狀態(tài)轉移（RepresentationalStateTransfer）采用Web服務使用標準的HTTP方法(GET/PUT/POST/DELETE)將所有Web系統(tǒng)的服務抽象為資源，REST從資源的角度來觀察整個網(wǎng)絡，分布在各處的資源由URI確定，而客戶端的應用通過URI來獲取資源的表述（representation）。REST是一種軟件架構風格而非協(xié)議也非規(guī)范，是一種針對網(wǎng)絡應用的開發(fā)方式，可以降低開發(fā)的復雜性，提高系統(tǒng)的可伸縮性。SOAP簡單對象訪問協(xié)議（SimpleObjectAccessProtocol）一種標準化的通訊規(guī)范，主要用于Web服務（webservice）中。用一個簡單的例子來說明SOAP使用過程，一個SOAP消息可以發(fā)送到一個具有WebService功能的Web站點，例如，一個含有房價信息的數(shù)據(jù)庫，消息的參數(shù)中標明這是一個查詢消息，此站點將返回一個XML格式的信息，其中包含了查詢結果（價格，位置，特點，或者其他信息）。由于數(shù)據(jù)是用一種標準化的可分析的結構來傳遞的，所以可以直接被第三方站點所利用。XML-RPC遠程過程調用（RemoteProcedureCall，RPC)通過XML將調用函數(shù)封裝，并使用HTTP協(xié)議作為傳送機制。后來在新的功能不斷被引入下，這個標準慢慢演變成為今日的SOAP協(xié)定。XML-RPC協(xié)定是已登記的專利項目。XML-RPC透過向裝置了這個協(xié)定的服務器發(fā)出HTTP請求。發(fā)出請求的用戶端一般都是需要向遠端系統(tǒng)要求呼叫的軟件。三種方案的比較XML-RPC已慢慢的被SOAP所取代，現(xiàn)在很少采用了，但它還是有版權的；SOAP在成熟度上優(yōu)于REST；在效率和易用性上，REST更勝一籌；在安全性上，SOAP安全性高于REST，因為REST更關注的是效率和性能問題。SOAP是WebServices的核心技術，且現(xiàn)在大多數(shù)WebServices都是基于SOAP的，其應用開發(fā)也相對成熟。REST是一項新技術，它不是協(xié)議、不是架構，嚴格來說也不屬于WebServices；它只是一種抽象的軟件設計觀念，要求從資源的角度來考慮問題。因此，WebServices的核心架構其實就是SOAP技術，而REST是理念。SOAP基于SOAP的WebServices主要包括SOAP、WSDL、UDDI等技術，其協(xié)議棧如圖WebServices工作原理一般WebServices角色包括服務提供者、服務注冊中心和服務使用者：服務提供者注冊和發(fā)布自己的服務在服務注冊中心中，并對服務請求進行響應；服務注冊中心擔任中介的作用，一邊接收服務提供者發(fā)來的服務，一邊供服務提供者在其統(tǒng)一目錄中查找合適的服務；服務使用者是根據(jù)具體的應用需求調用服務的。在典型情況下，服務提供者托管可通過網(wǎng)絡訪問特定的軟件模塊，定義WebServices的服務描述并將服務發(fā)布到服務注冊中心統(tǒng)一目錄中；服務請求者使用查找操作從注冊中心中檢索特定的服務，然后使用服務描述與服務提供者進行綁定并調用相應的服務。WebServices的開發(fā)WebServices的開發(fā)周期包括服務的構建、部署、運行和管理。在Web服務的實踐開發(fā)中，有以下四種模式：零起點開發(fā)模式自底向上開發(fā)模式自頂向下開發(fā)模式中間相遇開發(fā)模式零起點開發(fā)模式開發(fā)者不僅要創(chuàng)建Web服務，還要創(chuàng)建與Web服務相集成的應用程序（服務功能代碼），然后才能部署和發(fā)布整套Web服務。通常，我們先創(chuàng)建服務功能代碼，然后使用Axis創(chuàng)建WSDL服務描述和部署描述，這樣便可以部署和發(fā)布整個Web服務了。自底向上開發(fā)模式不需要創(chuàng)建與Web服務相集成的應用程序，而是使用現(xiàn)有的、或遺留的應用程序代碼作為服務功能代碼。然后使用工具從這些服務功能代碼導出相應的WSDL服務描述，再部署和發(fā)布即可。自頂向下開發(fā)模式相當于Web服務的WSDL服務描述已經(jīng)存在了，此時WSDL相當于一種規(guī)范，我們只要按著這種規(guī)范創(chuàng)建相應的服務功能代碼（如Java類），然后將服務功能代碼和WSDL相關聯(lián)，并部署和發(fā)布即可。中間相遇開發(fā)模式是自底向上和自頂向下兩種開發(fā)方案的組合，此時不僅存在Web服務的接口，也存在服務功能性代碼，但它們可能并不滿足既定需求，而需要做適當?shù)男拚?。因此，只要對二者進行修整，再結合起來，部署并發(fā)布服務即可。提綱WebServices概述XMLSOAPWebServicesRESTWebServicesXMLXML概述XML語法和文檔命名空間XMLSchemaXML概述XML是ExtendedMarkupLanguage的縮寫，即可擴展標記語言。它是一種廣泛應用于互聯(lián)網(wǎng)分布式計算中的、簡單的、跨平臺的結構化數(shù)據(jù)或數(shù)據(jù)結構標記語言。同時，XML是一種元語言，即用戶可以根據(jù)實際需求設計自定義的標記來描述數(shù)據(jù)，XML中使用文檔類型定義（DTD）或者模式（Schema）來描述數(shù)據(jù)。XML具有其跨平臺、與軟硬件無關的優(yōu)點，以XML為基石不斷催生著各種新技術的到來，如SOAP、WSDL和XSL等，它們?yōu)閃eb技術的發(fā)展提供了不竭動力。XML具有以下特點：可擴展性自描述性簡潔性數(shù)據(jù)的描述與顯示相分離易于數(shù)據(jù)的交換和共享易于充分利用數(shù)據(jù)可用于創(chuàng)造新的語言XML語法和文檔所有的數(shù)據(jù)都是在文檔中進行描述的。而XML文檔具有不同的類型，XML的組成部分和結構形式地定義了文檔的類型。XML文檔由命名容器和命名容器的相關參數(shù)值組成，這些命名容器包括聲明、元素和屬性。其中聲明確定了當前XML文檔所使用的XML標準規(guī)范的版本；元素就是XML文檔中的一對標記及標記之間的內容，它是文檔最基本的組成單元，XML正是通過這些命名的標簽對來描述結構化數(shù)據(jù)的；屬性用于對元素的特性進行描述，以便XML文檔處理器能按照特定的屬性來處理文檔。命名空間用于指定變量、函數(shù)、數(shù)據(jù)對象等標示符所處的有效范圍。通過命名空間可以避免名稱沖突，使系統(tǒng)更加模塊化。例如，在C++語言中，使用關鍵字namespace來聲明命名空間，并使用“{}”來界定命名空間的作用域。例如，聲明命名空間MyNamespace，并在其中定義兩個int型變量。XML命名空間的聲明方法為：xmlns:prefix-name=”URI”。其中，xmlns是XML中專門用于聲明命名空間的關鍵字。prefix-name是命名空間的名稱，一般以字母或下劃線（_）開頭，不包含空白字符和冒號（:），且不能使用XML保留字（如：xml、xsl等）做命名空間名稱。命名空間的值是一個URI（UniformResourceIdentifier，統(tǒng)一資源標示符）。因為，在Web中匯集了各種各樣的資源，為了唯一地標識這些資源，W3C提出了URI的概念。一個URI中包含了能夠唯一標識一個資源的字符串，通過URI可以方便地實現(xiàn)對資源的表示、描述、訪問和共享。任何命名空間只能夠在其作用域內進行使用，且同一個命名空間中所有元素名和屬性名必須是唯一的。如圖清單為含有命名空間的XML文檔。以上清單描述了一家名為GZSoftware的軟件公司的基本信息，其中元素company、company-info、name、fdate都是定義在命名空間ns中的，ns的URI為，因此這些元素的名稱前綴都是ns（如pany）。而元素division、name（為division的name）、employee是定義在命名空間nsd中的，nsd的URI為，其元素名前綴都是nsd?？梢姡@樣避免了name重名沖突問題，因為它們在不同的命名空間。在XML中，命名空間可以劃分為三類，即目標命名空間、標準命名空間和源命名空間。如下清單是一個XMLSchema文檔，展示了這三種命名空間的用法。目標命名空間（targetNamespace）為“”，文檔中定義的元素名稱（Schema、import、element）、類型名稱（string、float）、屬性名稱（name、type）和屬性組名稱的作用范圍就是此目標命名空間。標準命名空間（XMLns），即文檔中的“”，其中定義了XMLSchema語法標準中規(guī)定的一些名字（Schema、import、element等）。注意，“XMLns:INFO”是對命名空間的一種簡化處理，這樣“XMLns:INFO”就代表了命名空間“”。源命名空間表示使用外部名稱所在的命名空間，如上述清單中“importnamespace”導入的外部命名空間“”，并用“XML:proAera”簡化。XMLSchemaXMLShema，即XML模式。在XML中模式用來描述文檔類型，即把特定的XML文檔當做一種規(guī)范來描述，XMLSchema定義了一類XML文檔。XML是WebServices的基石，以SOAP為例，SOAP消息就是以XML文檔形式存在的，而消息中包含有待交互的數(shù)據(jù)，通過網(wǎng)絡傳輸即可與服務進行交互。但服務接收者會接收到各種各樣的SOAP消息，要識別出哪些SOAP消息格式是滿足要求的，必須通過一定的機制，那就是XMLSchema。通過XMLSchema可以檢測一個SOAP消息是否滿足預定義模式要求，再決定是否接受消息。清單8.7為一個描述智能手機基本信息的XML文檔，而清單8.8為此文檔的Schema。XMLSchema的語法規(guī)范：（1）ElementType元素——用于定義XML文件中元素的名稱、格式、數(shù)據(jù)類型等特性。 ElementType元素的基本格式：（2）AttributeType元素——在模式中，AttributeType用于定義元素屬性的類型，其基本格式如下：（3）description元素——專門用于XMLSchema中的注釋，用于注解說明Schema的內容：（4）group元素——在XMLSchema中有一種機制可以將多個元素按一定順序組織起來，即group元素，它的基本格式如下：基本格式中各部分的含義如下：maxOccurs——表示該group最多能夠被調用的次數(shù)，1表示只能調用一次，*表示可以調用任意次。minOccurs——表示該group最少能夠被調用的次數(shù)，0表示對調用次數(shù)無要求，1表示至少調用一次。order——表示該group中element元素的排列順序，one表示只允許元素內容按一種方式排列，seq表示元素內容按指定的方式排列，many表示按任意方式排列。提綱WebServices概述XMLSOAPWebServicesRESTWebServicesSOAPWebServicesSOAP概述SOAP消息結構SOAP消息交換模型SOAP應用模式WSDLUDDI使用MyEclipse開發(fā)SOAPWebServicesSOAP概述SOAP(SimpleObjectAccessProtocol，簡單對象訪問協(xié)議）是一種基于XML的、輕量級的、跨平臺的數(shù)據(jù)交換協(xié)議。SOAP不僅描述了數(shù)據(jù)類型的消息格式及一整套串行化規(guī)則，包括結構化類型和數(shù)組，還描述了如何使用HTTP來傳輸消息。SOAP提供了應用程序之間的交互能力。SOAP主要包括以下四個部分：SOAPEnvelope——用于定義一個描述消息中的內容、發(fā)送者、接收者、處理者及如何處理的整體表示框架。SOAP編碼規(guī)則——定義了一套編碼機制用于交換應用程序定義的數(shù)據(jù)類型的實例。SOAPRPC——表示遠程過程調用和應答的協(xié)定。SOAP綁定 ——定義了一種使用底層傳輸協(xié)議來完成節(jié)點間交換SOAP消息的約定。SOAP消息結構SOAP是基于XML的消息式數(shù)據(jù)交換協(xié)議，為了準確地實現(xiàn)應用與服務間數(shù)據(jù)的互操作，SOAP消息的提供者與請求者都必須訪問相同的XML模式。SOAP就是一個含有Envelope、Header、Body等元素的XMLSchema。其中，Envelope元素是SOAP規(guī)范中專用的，用于封裝整個SOAP消息的數(shù)據(jù)，是必須要有的。子元素Header是可選的，Header主要用于傳輸那些不是有效載荷的控制信息或上下文信息，例如路由與傳送設置、認證或授權聲明、事務上下文等。而Body元素是必須要有的，它是SOAP消息的有效載荷信息。SOAPEnvelopeSOAPEnvelope，即SOAP信封，是每一個SOAP消息唯一的根，是必須要有的。SOAP信封中所有的元素都是使用W3CXMLSchema規(guī)范進行定義的。命名空間是XMLSchema中關鍵的技術，它不僅避免了元素重名的困擾，還使得模式文檔更具可擴展性。因此，通過引用不同的命名空間，SOAP消息可以擴展其語義范圍。在SOAP中同樣適用xmlns來聲明命名空間，例如上面清單上中命名空間soap的值為。在此命名空間中，不僅定義了<Envelope>元素，還定義了<Header>和<Body>元素。SOAP規(guī)范允許在信封標簽中定義任意數(shù)量的附加的、自定義的屬性，但每一個自定義的屬性都必須有合適的命名空間。SOAPHeaderHeader元素是SOAPEnvelope中的第一個直接子元素，Header并不是Envelope中必須要含有的，且一個SOAPEnvelope中只能有一個Header元素。Header提供了一種對擴展功能進行封裝的機制，且擴展功能無須與有效載荷發(fā)生關聯(lián)，也不需要修改SOAP基本結構，因此可以在不違反規(guī)范的前提下不斷為SOAP消息添加新的特性或功能，例如安全性、對象引用、計費、數(shù)字簽名、QoS等。Header中的所有直接子元素都稱為Header條目，每個Header條目都由一個命名空間和局部名組成的完整修飾元素來標識，不允許出現(xiàn)沒有命名空間修飾的Header條目。SOAPHeader示例：SOAPBodyBody元素是Envelope中必須要有的，它提供了一種SOAP消息與中消息接收者交換信息的機制，例如RPC調用和錯誤報告。Body應該作為Envelpoe元素的一個直接子元素，若Envelope中包含Header元素，則Body元素必須緊跟在Header后，作為Header元素的直接的下一個兄弟。在Body元素中所有的直接子元素都稱為Body條目，每一個條目必須是一個獨立的元素，且每一個完整的條目由一個命名空間URI和名稱組成。Body條目自身可以包含下級子元素，但這些元素也不是Body的條目，而是Body條目的內容。此外，在Body中可以使用Fault元素來指示調用錯誤的信息。請求響應SOAP示例清單8.16表示一個請求鉛筆價格的SOAP消息，它不含Header元素，且在Body元素中定義了條目m:GetPrice，用m:Item表示請求價格的商品。注意m:GetPrice和m:Item并不是SOAP標準的一部分，而是應用程序專用的元素。清單8.17中是對清單8.16中SOAP消息的響應，其Body元素中定義了m：GetPriceResponse條目返回商品的價格信息。SOAPFaultSOAPFault元素用于在SOAP消息中傳輸錯誤及狀態(tài)信息。Fault元并不是必須的，若出現(xiàn)了Fault，則它必須位于Body元素中，作為Body的一個條目，且在Body元素中至多出現(xiàn)一次。如下表格給出了SOAPFault的子元素。Fault子元素faultcode的值有下面四種：關于SOAPFault的請求/響應示例，如清單8.18和清單8.19所示：清單8.18中定義了Herder條目Extension1和Extension2，它們分別位于命名空間exp和stu中，且屬性mustUnderstand的值都為true。此消息作為SOAP請求發(fā)送至接收方。清單8.19是接收方響應請求的SOAP消息，響應SOAP的Header中定義了Misunderstood條目，且qname的命名空間就是Extension1和Extension2的命名空間，表示SOAP請求消息不能被按照規(guī)范來處理。同時，在Body元素中使用了Fault條目來報告產生錯誤的信息，F(xiàn)ault中使用了faultcode表明錯誤類別，并使用faultstring來指示錯誤信息說明。SOAP消息交換模型SOAP消息交換是從發(fā)送方到接收方的一種傳輸方法。從本質上說，SOAP是一種無狀態(tài)的協(xié)議，它提供符合的單向消息交換框架，以便在稱為SOAP節(jié)點的SOAP應用程序之間傳輸XML文檔。SOAP節(jié)點既可以是SOAP消息的發(fā)送者，也可以是SOAP消息的接收者，或者是SOAP消息的發(fā)送者和接收者放入中介。由于SOAP并不提供路由機制，因此SOAP需要識別發(fā)送者發(fā)送的SOAP消息應當通過哪些SOAP中介才能到達接收者處。此外，接收到SOAP消息的節(jié)點必須能夠實時處理被產生必要的SOAP錯誤和SOAP響應，如果合適，還應當根據(jù)SOAP規(guī)范的后續(xù)描述生成額外的SOAP消息。SOAPHeader中actor屬性可以用來標識SOAP的角色，SOAP角色是SOAP節(jié)點在處理SOAP消息時的身份。actor屬性的值是一個URI，例如：。當SOAP節(jié)點在處理一個SOAP消息時，其SOAP角色在整個處理過程中是不變的，因為SOAP是無狀態(tài)的。含actor屬性的SOAPHeader匹配了一個SOAP節(jié)點，或者此SOAPHeader沒有actor屬性，而采用匿名角色，則我們稱SOAPHeader指向了一個SOAP節(jié)點。下圖展示了SOAP消息交換的流程圖。SOAP應用模式按照SOAP應用環(huán)境的不同，將SOAP分為五類：請求/響應模式fire-and-forget模式高級消息模式增量解析和處理模式緩存模式請求/響應模式請求/響應方式的SOAP服務，即服務請求者將請求發(fā)送給服務接收者，服務接收者接收到發(fā)送者的請求后，再獲取并處理其中的數(shù)據(jù)，最后將處理結果信息以SOAP消息方式回送給服務請求者。如果請求消息沒有被接收到，或沒有被期望的業(yè)務應用所處理，那么保障通信的傳輸層會產生相應的狀態(tài)信息，并報告給SOAP發(fā)送者。請求/響應模式的示例如清單8.20和清單8.21所示，它們分別表示請求和響應文檔。fire-and-forget模式fire-and-forget一詞源于軍事中，比喻當某種武器當被發(fā)射出后，便不用人們再去控制，而可以自行尋找攻擊目標。把它用在SOAP中時，表示SOAP消息一經(jīng)發(fā)出，便不用發(fā)送者關心，SOAP消息自己會尋找相應的接收者。按照SOAP消息接收者的多少，可以將fire-and-forget分為兩類，一種是面向單個接收者的，另一種是面向多個接收者的。面向單個接收者指發(fā)送者要求該SOAP消息只被一個接收者接受，且不要求予以回復發(fā)送報告，比如是否發(fā)送完成、是否已被接收等報告。面向多個接收者指的是發(fā)送者要求該SOAP消息被發(fā)送給一組接收者，也不要求回復發(fā)送報告。高級消息模式會話消息模式——基于會話的消息模式，雙方會長時間維持一個會話進程，其中包含了雙方多次的消息交互。異步消息模式——此種模式下，發(fā)送者發(fā)送SOAP消息后，并不期望接收者接收并處理后立即予以響應，而允許接收者在一定的時間段內給予回復。異步方式更加適合于實際應用。事件通知模式——此種模式類似于“訂閱”。應用程序向一個事件源訂閱了一些特定的事件通知，當事件發(fā)生時，事件源便按照訂閱者的要求將通知發(fā)送給原訂閱者，或其他指定的用戶。增量解析和處理模式當SOAP消息過于龐大，給傳輸帶來困難時，往往想到的是分組來發(fā)送，類似于計算機網(wǎng)絡中IP數(shù)據(jù)報的分組。按照一定機制將冗長的SOAP消息分割后，由多個SOAP消息來發(fā)送，待接收者收到這些分片的消息后，再對分片進行重組和處理。這種模式縮短了消息傳輸延時，降低了通信阻塞，使SOAP服務效率得以提高。但此模式要求發(fā)送者和接收者都具備增量解析和處理消息的能力。緩存模式在SOAP消息中，為了縮短響應時延、占用更小的帶寬，可以將一些常用的消息存儲在緩存中，供相關應用或SOAP節(jié)點使用。WSDLWSDL（WebServicesDescriptionLanguage，Web服務描述語言）是一種基于XML的、專門用于描述WebServices的語言。通過WSDL可以對服務的功能信息、功能參數(shù)的消息類型、協(xié)議綁定信息和特定服務的地址信息進行描述。WSDL文檔將服務訪問點、消息的抽象定義與具體服務部署、數(shù)據(jù)格式的綁定分離開來，因此可以對抽象定義進行重用。在WSDL中，消息指對數(shù)據(jù)的抽象描述，端口類型指的是操作的抽象幾何，端口類型使用的具體協(xié)議和數(shù)據(jù)格式規(guī)范構成了一個綁定，將Web訪問地址與可再次使用的綁定相關聯(lián)來以定義一個端口，而端口的集合則稱為服務。在WSDL文檔中常常用到以下8種元素來描述SOAPWebServices：definitions——該元素用于定義WSDL文檔的名稱，引入必要的命名空間。types——數(shù)據(jù)類型定義容器，提供了用于描述交換信息的數(shù)據(jù)類型定義，它使用某種類型系統(tǒng)（如XMLSchema中的類型，即XSD）。 message——消息結構的抽象類型化定義，消息包括多個邏輯部分，每一部分與某種類型系統(tǒng)中的一個定義相關。消息使用types所定義的類型來定義整個消息的數(shù)據(jù)結構。

operation——描述了一個訪問入口的請求/響應消息對，是對服務中所支持的操作的抽象描述。portType——portType是服務訪問入口點類型所支持的操作的抽象集合，這些操作可以由一個或多個服務訪問點來支持，每個操作指向一個輸入消息和多個輸出消息。

binding——binding元素用于將特定的具體協(xié)議和數(shù)據(jù)格式規(guī)范的綁定，它是由端口類型定義的操作和消息指定具體的協(xié)議和數(shù)據(jù)格式規(guī)范的結合。因此，binding元素可以用來具體化portType元素，其中定義了portType元素中的操作和消息的格式與協(xié)議等。port——協(xié)議/數(shù)據(jù)格式與具體Web訪問地址組合的單個服務訪問點，它指出了用于綁定的地址，因此定義了單個通信終端。

service——service元素指定了WebService的位置，一個service元素可以包含多個port元素，端口的集合構成了service。WSDL的文檔結構模型：在實際的應用中很少直接去硬編碼WSDL，而是采用一些軟件工具自動化生成WSDL文檔，幾種自動化生成WSDL文檔的工具：IBMWSTK——即IBMWebServices工具包