Web Service
體系結(jié)構(gòu)描述
概念
定義一：
Web Services是自包含的、模塊化的應(yīng)用程序，它可以在網(wǎng)絡(luò)（通常為Web）中被描述、發(fā)布、查找以及調(diào)用。
定義二：
Web Services是基于網(wǎng)絡(luò)的、分布式的模塊化組件，它執(zhí)行特定的任務(wù)，遵守具體的技術(shù)規(guī)范，這些規(guī)范使得Web Service能與其他兼容的組件進行互操作。
定義三：
所謂Web服務(wù)，它是指由企業(yè)發(fā)布的完成其特別商務(wù)需求的在線應(yīng)用服務(wù)，其他公司或應(yīng)用軟件能夠通過Internet來訪問并使用這項應(yīng)用服務(wù)。（UDDI規(guī)范2.0）
體系結(jié)構(gòu)
Web 服務(wù)的一個主要思想，就是未來的應(yīng)用將由一組應(yīng)用了網(wǎng)絡(luò)的服務(wù)組合而成。只要兩個等同的服務(wù)使用統(tǒng)一標(biāo)準(zhǔn)和中性的方法在網(wǎng)絡(luò)上宣傳自己，那么從理論上說，一個應(yīng)用程序就可以根據(jù)價格或者性能的標(biāo)準(zhǔn)，從兩個彼此競爭的服務(wù)之中選出一個。除此之外，一些服務(wù)允許在機器之間復(fù)制，因而可以通過把有用的服務(wù)復(fù)制到本地儲存庫，來提高允許運行在特定的計算機（群）上的應(yīng)用程序的性能。
Web Services體系結(jié)構(gòu)是面向?qū)ο蠓治雠c設(shè)計（OOAD）的一種合理發(fā)展（logical evolution），同時也是電子商務(wù)解決方案中，面向體系結(jié)構(gòu)、設(shè)計、實現(xiàn)與部署而采用的組件化的合理發(fā)展（logical evolution of components geared towards the architecture, design, implementation, and deployment of e-business solutions）。這兩種方式在復(fù)雜的大型系統(tǒng)中經(jīng)受住了考驗。和面向?qū)ο笙到y(tǒng)一樣，封裝、消息傳遞、動態(tài)綁定、服務(wù)描述和查詢也是Web Services中的基本概念，而且，Web Services另外一個基本概念就是：所有東西都是服務(wù)，這些服務(wù)發(fā)布一個API供網(wǎng)絡(luò)中的其他服務(wù)使用，并且封裝了實現(xiàn)細節(jié)。
下面我們就來看一下Web Services的體系結(jié)構(gòu)--面向服務(wù)的體系結(jié)構(gòu)（SOA）。
圖1：面向服務(wù)的體系結(jié)構(gòu)（SOA）?
從圖1可以看出，SOA結(jié)構(gòu)中共有三種角色：
?、?Service provider：發(fā)布自己的服務(wù)，并且對使用自身服務(wù)的請求進行響應(yīng)
?、?Service broker：注冊已經(jīng)發(fā)布的Service provider，對其進行分類，并提供搜索服務(wù)
?、?Service requester：利用Service broker查找所需的服務(wù)，然后使用該服務(wù)
SOA體系結(jié)構(gòu)中的組件必須具有上述一種或多種角色。
在這些角色之間使用了三種操作：
?、?publish操作：使Service provider可以向Service broker注冊自己的功能及訪問接口
?、?find操作：使Service requester可以通過Service broker查找特定種類的服務(wù)
?、?bind操作：使Service requester能夠真正使用Service provider
為支持結(jié)構(gòu)中的三種操作（publish、find和bind），SOA需要對服務(wù)進行一定的描述，這種服務(wù)描述（Service Description）應(yīng)具有下面幾個重要特點：首先，它要聲明Service provider的語義特征。Service broker使用語義特征將Service provider進行分類，以幫助具體服務(wù)的查找。Service requester根據(jù)語義特征來匹配那些滿足要求的Service provider。（因此，語義特征中重要的一點就是對Service provider的分類。）其次，服務(wù)描述應(yīng)該聲明接口特征，以訪問特定的服務(wù)。最后，服務(wù)描述還應(yīng)聲明各種非功能特征，如安全要求，事務(wù)要求，使用Service provider的費用等等。接口特征和非功能特征也可以用來幫助Service requester對Service provider的查找。
注意，服務(wù)描述和服務(wù)實現(xiàn)是分離的，這使得Service requester可以在Service provider的一個具體實現(xiàn)（implementation）正處于開發(fā)階段、部署階段或完成（execution）階段時，對其（具體實現(xiàn)）進行綁定。
另外，SOA中的組件相互之間必須能夠進行交互，才能進行上述三種操作。所以Web Services體系結(jié)構(gòu)的另一個基本原則就是使用標(biāo)準(zhǔn)的技術(shù)，包括服務(wù)描述、通訊協(xié)議以及數(shù)據(jù)格式等。這樣一來，開發(fā)者就可以開發(fā)出平臺獨立、編程語言獨立的Web Services，從而能夠充分利用現(xiàn)有的軟硬件資源和人力資源。
最后，SOA體系結(jié)構(gòu)沒有對Web Service的粒度進行限制，因此一個Web Service即可以是一個組件（小粒度），該組件必須和其他組件結(jié)合才能進行完整的業(yè)務(wù)處理；Web Service也可以是一個應(yīng)用程序（大粒度）。
相關(guān)技術(shù)規(guī)范
協(xié)議及消息傳遞（Protocol and Messaging）
SOAP
即簡單對象訪問協(xié)議（Simple Object Access Protocol），它是用于交換XML編碼信息的輕量級協(xié)議。它有三個主要方面：XML-envelope為描述信息內(nèi)容和如何處理內(nèi)容定義了框架；將程序?qū)ο缶幋a成為XML對象的規(guī)則；執(zhí)行遠程過程調(diào)用（RPC）的約定。
SOAP 可以運行在任何其它傳輸協(xié)議上。例如，您可以使用 SMTP，即因特網(wǎng)電子郵件協(xié)議來傳遞SOAP消息。在傳輸層之間的頭是不同的，但XML有效負載保持相同。
性能：
SOAP 用 XML 將消息編碼，因此在調(diào)用過程的任何一步都極易處理消息。另外，調(diào)試 SOAP 消息的方便性使各種 SOAP 執(zhí)行能快速聚合在一起，這點很重要因為 SOAP 就是要達到大范圍的協(xié)同工作。（CORBA、DCOM 和 RMI 對參數(shù)和返回值使用二進制編碼。除此之外，他們假設(shè)發(fā)送端和接收端充分了解消息的前后關(guān)系，因此對諸如參數(shù)名稱或類型的任何元信息都不編碼。這種方法產(chǎn)生了良好的性能，但使中介很難處理消息。因為每個系統(tǒng)使用不同的二進制編碼，所以建立互操作的系統(tǒng)很難）。
表面看來，基于 XML 的模式本應(yīng)比基于二進制的慢，但它并不像表面那么簡單。首先，當(dāng)SOAP被用于通過因特網(wǎng)發(fā)送消息時，在每個端點給消息編碼／解碼的時間與在端點間傳輸字節(jié)的時間相比較是微不足道的，所以這種情況下使用 XML 沒太大問題。
其次，當(dāng)SOAP用于封閉環(huán)境下的點對點間的消息傳送，如在同一公司部門間的傳送時，各端點可能將運行相同的SOAP執(zhí)行。這樣，這個特定執(zhí)行就擁有專門的優(yōu)化機會。例如，一個SOAP客戶端可添加一個 HTTP header 標(biāo)記到 SOAP 請求上，這個請求說明它支持一個特定的優(yōu)化。如果SOAP服務(wù)器也支持那個優(yōu)化，它會在第一個SOAP響應(yīng)中返回一個 HTTP header 標(biāo)記，告訴客戶端可以在下面的通信中使用這種優(yōu)化。接下來，客戶端和服務(wù)器可以開始使用這種優(yōu)化了。
接口描述（Interface Description）
1. WSDL
WSDL是用來描述網(wǎng)絡(luò)（network）服務(wù)或終端（endpoint）的一種XML語言，它用于定義Web Services以及如何調(diào)用它們（描述Web服務(wù)的屬性，例如它做什么，它位于哪里和怎樣調(diào)用它）。WSDL文檔可用于動態(tài)發(fā)布Web Services、查找已發(fā)布的Web Services以及綁定Web Services。
在WSDL中包含了使用SOAP的服務(wù)描述的綁定，也包含了使用簡單HTTP GET和POST請求的服務(wù)描述的綁定。
WSDL將Web服務(wù)定義成一系列的端口（port），每個端口用來表示從抽象端口類型（port type）到用于調(diào)用Web服務(wù)的具體通信協(xié)議的一個映射。端口類型由一組與Service provider交換信息的操作組成，它支持對包含消息的數(shù)據(jù)類型的定義。（可參考具體的WSDL文檔定義http://www-900.ibm.com/developerWorks/webservices/ws-peer4/listing1.html）
一個完整的 WSDL 服務(wù)描述是由一個服務(wù)接口和一個服務(wù)實現(xiàn)文檔組成的。 由于服務(wù)接口表示服務(wù)的可重用定義，它在 UDDI 注冊中心被作為 tModel 發(fā)布。服務(wù)實現(xiàn)描述服務(wù)的實例。每個實例都是使用一個 WSDL service 元素定義的。服務(wù)實現(xiàn)文檔中的每個 service 元素都被用于發(fā)布 UDDI businessService。
因為 WSDL 包含了對服務(wù)接口的完整描述，所以我們可以使用它來創(chuàng)建能簡化服務(wù)訪問的存根，該存根為一段Java代碼（假設(shè)使用Java），它自動生成了訪問Web服務(wù)的類。如果我們需要訪問Web服務(wù)，只需調(diào)用該類中對應(yīng)的方法即可，而不用在客戶端程序中再寫入那些令人頭疼的配置信息了。通過IBM提供的工具包可以輕松創(chuàng)建WSDL文檔對應(yīng)的存根。（由此看出，不用WSDL也可以訪問Web服務(wù)）
WSDL取代了IBM的NASSL（Network-Accessible Service Specification Language）和Microsoft的SCL（SOAP Contract Language）。
2. UDDI
即Universal Description, Discovery and Integration。它提供了在Web上描述并發(fā)現(xiàn)商業(yè)服務(wù)的框架。UDDI通過服務(wù)注冊，以及使用SOAP訪問這些注冊信息的約定來實現(xiàn)上述目標(biāo)。
UDDI計劃的核心組件是UDDI商業(yè)注冊，它使用一個XML文檔來描述企業(yè)及其提供的Web服務(wù)。從概念上來說，UDDI商業(yè)注冊所提供的信息包含三個部分："白頁(White Page)" 包括了地址，聯(lián)系方法，和已知的企業(yè)標(biāo)識；"黃頁(Yellow page)"包括了基于標(biāo)準(zhǔn)分類法的行業(yè)類別；"綠頁(Green Page)"則包括了關(guān)于該企業(yè)所提供的Web服務(wù)的技術(shù)信息，其形式可能是一些指向文件或是URL的指針，而這些文件或URL是為服務(wù)發(fā)現(xiàn)機制服務(wù)的。所有的UDDI商業(yè)注冊信息存儲在UDDI商業(yè)注冊中心中。
借助XML 和SOAP ，集成和交互的問題將從層次上被簡化。XML 提供了跨平臺的數(shù)據(jù)編碼和組織方法，而SOAP 建立在XML 之上，定義了一種跨系統(tǒng)平臺的信息交換的簡單包裝方法。綁定于HTTP之上的SOAP協(xié)議，可以跨語言、跨操作系統(tǒng)進行遠程過程調(diào)用(RPC)，實現(xiàn)了編程語言和系統(tǒng)平臺的無關(guān)性。而以前的調(diào)用方式則和復(fù)雜的分布式對象標(biāo)準(zhǔn)或是中間件有密切的關(guān)系，從長期的眼光來看，這些都不是高效的解決方案。XML 和SOAP 這樣的跨語言、跨平臺的解決方案大大簡化了不同企業(yè)系統(tǒng)之間的交互問題。
但如果僅僅是XML和SOAP的話，對于公司間的交流仍存在著巨大的鴻溝。UDDI 規(guī)范在XML 和SOAP 的基礎(chǔ)之上定義了新的一層，在這一層次，不同企業(yè)可以用相同的方法描述自己所能提供的，并能查詢對方所能提供的服務(wù)。
互操作
協(xié)議棧? 統(tǒng)一服務(wù)互操作協(xié)議
（這些協(xié)議尚未定義）?
統(tǒng)一描述、發(fā)現(xiàn)和集成協(xié)議 (UDDI)
簡單對象訪問協(xié)議 (SOAP)
擴展標(biāo)注語言 (XML)
通用Internet協(xié)議 (HTTP, TCP/IP)
以下圖表描述了這些協(xié)議的層次關(guān)系：
UDDI 注冊使用的核心信息模型由XML Schema 定義。使用XML 是因為它提供了平臺無關(guān)的數(shù)據(jù)描述并很自然的描述了數(shù)據(jù)的層次關(guān)系。而選擇XML Schema 是因為它支持豐富的數(shù)據(jù)類型，便捷的描述方式及其按信息模型對數(shù)據(jù)進行驗證的能力。
UDDI XML Schema 定義了四種主要信息類型，它們是技術(shù)人員在需要使用合作伙伴所提供的Web 服務(wù)時必須了解的技術(shù)信息。它們是：商業(yè)實體信息、服務(wù)信息、綁定信息和服務(wù)調(diào)用規(guī)范的說明信息。
UDDI程序員API規(guī)范分為兩個邏輯部分：查詢API 和發(fā)布API 。查詢API 又分為兩個部分:一部分被用來構(gòu)造搜索和瀏覽UDDI 注冊信息的程序，另一部分在Web服務(wù)出現(xiàn)錯誤時使用。程序員可以利用發(fā)布API創(chuàng)建各種類型的工具，以直接與UDDI注冊中心進行交互，便于企業(yè)技術(shù)人員管理businessEntity 或tModel 結(jié)構(gòu)的發(fā)布信息。
UDDI調(diào)用模型
每一個獨立發(fā)布的Web服務(wù)都是使用一個bindingTemplate結(jié)構(gòu)來建模的。對這個Web服務(wù)的調(diào)用通常通過緩存bindingTemplate 數(shù)據(jù)來實現(xiàn)。注意到這一點后，在你準(zhǔn)備編寫調(diào)用某種Web 服務(wù)的程序時，該如何使用UDDI 就很清楚了。下面列出了基本步驟：
1．編寫調(diào)用遠程Web 服務(wù)的程序時，程序員使用UDDI 商業(yè)注冊中心(通過使用Web界面或其它基于查詢API 的工具)來定位businessEntity 信息，這些信息是由(或為)提供該Web 服務(wù)的企業(yè)注冊的。
2．程序員可以進一步獲得更詳細的businessService信息，或是得到一個完整的businessEntity結(jié)構(gòu)。因為businessEntity結(jié)構(gòu)包含了有關(guān)已發(fā)布的Web服務(wù)的所有信息，因此程序員只需簡單地選擇一個bindingTemplate 并保存留待以后使用。
3．基于Web服務(wù)在bindingTemplate的tModel中提供的調(diào)用規(guī)范的相關(guān)信息，程序員可以按照該Web服務(wù)的調(diào)用規(guī)范編寫程序。
4．在運行時，程序可以按需要使用已保存下來的 bindingTemplate的信息來調(diào)用Web服務(wù)。
一般說來，只要遠程Web 服務(wù)和調(diào)用它的程序都準(zhǔn)確的實現(xiàn)了必要的接口(按照在tModel 中所引用的調(diào)用規(guī)范)，對遠程服務(wù)的調(diào)用就一定會成功。
服務(wù)發(fā)現(xiàn)（Service Discovery）
1． UDDI（同上）
2． ADS
即Advertisement and Discovery of Services。這是由IBM提出的建議，它使服務(wù)提供者（service provider）能夠?qū)λ麄兊姆?wù)進行廣告宣傳。它允許將這些服務(wù)的信息集中到大家熟悉的地方，而且還提供了連接內(nèi)容及服務(wù)的方式。
由于ADS提供了可選擇的、分散的服務(wù)公告機制，因而補充了基于注冊的訪問方案。這遵循了Microsoft的DISCO（Discovery of Web Services）思想，但更為先進。
總結(jié)
以上是生活随笔為你收集整理的Web Service的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： xp系统中的隐藏文件不能显示 解决方案
- 下一篇： IBM开发单原子存储技术 iPod能存上