14.1 Web Services和面向服務(wù)的軟件架構(gòu)（Service Oriented Architecture，簡稱SOA）概述：

在最新Java開發(fā)世界里，我們經(jīng)常會遇到這樣一個名詞：Web Services（Web服務(wù)）。同時還會發(fā)現(xiàn)，與這個名詞同時出現(xiàn)的多是各大主流技術(shù)供應(yīng)商，各大技術(shù)供應(yīng)商無一不在關(guān)注這一領(lǐng)域的發(fā)展。從Microsoft的.NET架構(gòu)，到SUN的SUN ONE，以及IBM的Web Services，都體現(xiàn)了這些重量級的技術(shù)提供者對Web Services的推崇與重視。

電子商務(wù)的發(fā)展促進(jìn)了Web Services的發(fā)展。Web服務(wù)可以使公司降低進(jìn)行電子商務(wù)的成本，更快地部署解決方案以及開拓更多的新機(jī)遇。Web服務(wù)使應(yīng)用程序的集成比以前更快、更容易而且更便宜。它更注重服務(wù)語義而不那么注重網(wǎng)絡(luò)協(xié)議語義的消息，從而實現(xiàn)了業(yè)務(wù)功能的松散耦合。這些特性對于在企業(yè)之間和企業(yè)內(nèi)部通過web連接業(yè)務(wù)功能是非常理想的。它提供了一致化（Uniform）的編程模型，從而在企業(yè)內(nèi)外都可以利用通用的基礎(chǔ)設(shè)施并以一種通用的方法進(jìn)行應(yīng)用程序集成。

要理解Web Services, 首先需要認(rèn)識面向服務(wù)的軟件架構(gòu)（Service Oriented Architecture，簡稱SOA），Web Services是SOA架構(gòu)系統(tǒng)的一個實例。

14.1.1面向服務(wù)的軟件架構(gòu)（SOA）

1. 面向服務(wù)中的基本概念

在面向服務(wù)的架構(gòu)中包含一些基本的概念，透過這些基本概念可以進(jìn)一步了解面向服務(wù)的架構(gòu)。

(1) 服務(wù)的概念

在SOA中的服務(wù)是指能夠處理一些任務(wù)過程的動作的抽象概念，這些服務(wù)可以被描述，可以被發(fā)現(xiàn)，可以由服務(wù)代理負(fù)責(zé)向請求者提供服務(wù)并給出結(jié)果。代理是指請求或者提供服務(wù)的人所使用的軟件工具，人通過代理進(jìn)行交互操作。

(2) 消息的概念

服務(wù)代理之間需要通過消息的傳遞進(jìn)行交互操作，消息的內(nèi)容含有一定的語義和數(shù)據(jù)，消息傳輸需要與某個通信協(xié)議相綁定才能夠?qū)崿F(xiàn)。

(3) 服務(wù)的描述和發(fā)現(xiàn)

眾多的服務(wù)組成一個開放系統(tǒng)，除了需要提供信息交互方式以外，還需要提供相互了解的機(jī)制，這就需要提供描述和發(fā)現(xiàn)的方式。代理可以通過服務(wù)的描述來了解一個服務(wù)的內(nèi)容，包括使用這個服務(wù)的技術(shù)信息、訪問這個服務(wù)的地址信息等內(nèi)容。當(dāng)新的服務(wù)被投入到系統(tǒng)之中后，它需要被注冊，并且要能夠被發(fā)現(xiàn)，使它可以被利用起來。

2.為什么需要面向服務(wù)的軟件

由于軟件需求的擴(kuò)大，軟件系統(tǒng)變得越來越復(fù)雜。面對復(fù)雜的系統(tǒng)資源，我們需要一種更加合理的方式將不同類型、不同位置的子系統(tǒng)有力地結(jié)合起來，這種整合并不是將它們之間綁定得更加緊密，而是利用更加松散的方式來建立這個系統(tǒng)。

SOA通過松散的方式將分布式的軟件模塊結(jié)合起來，與舊有系統(tǒng)集成相比有著明顯的優(yōu)勢。對于服務(wù)的使用者來說，可以簡單地通過服務(wù)的描述來獲取服務(wù)，系統(tǒng)各部分之間不必為了某一部分的升級而改變，在服務(wù)的過程中不同的軟件模塊可以充當(dāng)不同的角色，從而構(gòu)成整個系統(tǒng)的工作體系。

在SOA當(dāng)中，一個服務(wù)代表的是一個由服務(wù)提供者向服務(wù)請求者發(fā)布的一些處理過程，這個過程在被調(diào)用之后，獲得服務(wù)請求者所需要的一個結(jié)果。在這個過程中，服務(wù)請求者可以向任何能夠提供此項服務(wù)的服務(wù)提供者來請求服務(wù)，服務(wù)實現(xiàn)的過程對于服務(wù)請求者來說是透明的。

隨著系統(tǒng)分布式和多種結(jié)構(gòu)復(fù)合程度的提高，SOA的巨大優(yōu)勢將進(jìn)一步被挖掘。

(1) 建立松散耦合的系統(tǒng)

松散耦合系統(tǒng)的優(yōu)點已經(jīng)被業(yè)內(nèi)充分地認(rèn)可，SOA作為一種分布式的系統(tǒng)，它實現(xiàn)了一種服務(wù)和描述等概念相結(jié)合的架構(gòu)。

SOA中的服務(wù)在SOA架構(gòu)中被標(biāo)準(zhǔn)的描述語言所描述，并通過與某種傳輸協(xié)議的綁定來實現(xiàn)相互之間的交互。這種基于服務(wù)的架構(gòu)使整個系統(tǒng)成為一個松散耦合的結(jié)構(gòu)，利用與通信協(xié)議的綁定將分布式系統(tǒng)中的所有部分連接起來，利用語義和服務(wù)的描述，在代理之間進(jìn)行交互。

(2) 提高軟件的重用性

面向服務(wù)的架構(gòu)還提高了對軟件的重用性。與組件方式相比，SOA系統(tǒng)中的單個服務(wù)的改變不會對其他部分造成嚴(yán)重的影響，同時利用服務(wù)的描述使同一服務(wù)可以充分地被其他系統(tǒng)所調(diào)用，各個系統(tǒng)之間形成了高度的重用性。

現(xiàn)在正在被廣泛使用的一些服務(wù)，正在不斷地被各個系統(tǒng)所重用，重用的條件十分簡單，只要了解服務(wù)的描述，或者可以訪問到服務(wù)的描述地址即可。與組件重用相比，服務(wù)的重用還具有與實現(xiàn)語言無關(guān)的特點，重用服務(wù)的客戶端程序不需要使用與服務(wù)實現(xiàn)部分同樣的開發(fā)語言，一切交互的過程都是利用與實現(xiàn)無關(guān)的方式進(jìn)行的。

(3) 提供按需服務(wù)的代碼

面向服務(wù)的架構(gòu)也使得系統(tǒng)的實現(xiàn)虛擬化，在SOA架構(gòu)中的請求和提供之間交互或相互代理的過程中，可計算的代碼資源分布在松散結(jié)構(gòu)中的各個部分上，當(dāng)請求發(fā)生時才被調(diào)用和服務(wù)，所有計算過程都是按照請求者的需求進(jìn)行的。服務(wù)的對象分為有狀態(tài)和無狀態(tài)兩種方式提供服務(wù)，按照需求提供服務(wù)，也可以利用緩沖機(jī)制優(yōu)化系統(tǒng)的系統(tǒng)。

總之，SOA使代碼的開發(fā)變得更有服務(wù)的目的性，使開發(fā)更加有效和合理。

14.1.2 SOA與 Web 2.0

另外，我們補充一下SOA與目前同樣熱門的Web 2.0的關(guān)系。

實際上Web 2.0 和SOA的概念在很大程度上是相同的，只是被粉飾成為軟件的不同部分（如果的確存在不同的話），也就是說SOA和Web 2.0有很多重疊的東西，例如都是基于調(diào)用（invoke）的服務(wù)，都能存在于網(wǎng)絡(luò)的任何位置等等。

SOA和Web 2.0的共性遠(yuǎn)大于它們之間的區(qū)別，而且Web 2.0在推廣SOA方面起到了一定作用。到現(xiàn)在為止，SOA和Web 2.0擁有不同的支持者- SOA更多涉及企業(yè)結(jié)構(gòu)和商務(wù)開拓，而Web 2.0更關(guān)注用戶。這種差別隨著更多企業(yè)接納Web 2.0而在變化，但是這兩項技術(shù)有著不同的重心: Web 2.0告訴我們數(shù)據(jù)是軟件應(yīng)用中最重要的部分，而SOA告訴我們服務(wù)才是中心。SOA中傳輸數(shù)據(jù)的服務(wù)也非常重要，但是傳統(tǒng)SOA更關(guān)注IT系統(tǒng)的接合處而不是那些能使接合處更具價值的東西。也就是說，SOA也許是通暢的管道，但并不是系統(tǒng)中通過的水的價值。許多行業(yè)領(lǐng)導(dǎo)者說企業(yè)同時需要SOA類方法的結(jié)構(gòu)和Web 2.0方法的創(chuàng)業(yè)能力。

SOA和Web 2.0之間有許多共有的要素：

l 軟件重組

l 管理

l 軟件就是服務(wù)

l 應(yīng)用就是平臺

l 無意識的使用

l 開放

l AJAX

l 互操作性

l 貨幣化

l 安全

l 網(wǎng)絡(luò)導(dǎo)向架構(gòu)

特別要說的是，最后一條網(wǎng)絡(luò)導(dǎo)向架構(gòu)或者Web Oriented Architecture（WOA）是關(guān)鍵的內(nèi)容，最終有可能會將SOA和Web 2.0合為一體。

了解了SOA后， 我們來介紹什么是Web Services。Web Services是SOA架構(gòu)系統(tǒng)的一個實例。從技術(shù)角度來講，Web Services是一種新的技術(shù)架構(gòu)、新的軟件應(yīng)用環(huán)境。它的系統(tǒng)架構(gòu)和實現(xiàn)技術(shù)完全繼承已有的技術(shù)，可以認(rèn)為Web Services是Internet的一種延伸，是現(xiàn)有的Internet面向更好的互操作能力的一個延伸。

14.2． Web Services的概念

Web Services，從字面上理解就是通過Web提供的服務(wù)。我們可以理解Web Services是自包含的、模塊化的應(yīng)用程序，它可以在網(wǎng)絡(luò)(通常為Web)中被描述、發(fā)布、查找以及調(diào)用；也可以理解Web Services是基于網(wǎng)絡(luò)的、分布式的模塊化組件，它執(zhí)行特定的任務(wù)，遵守具體的技術(shù)規(guī)范，這些規(guī)范使得Web Sevices能與其他兼容的組件進(jìn)行互操作；也可以這樣理解，所謂Web服務(wù)，它是指由企業(yè)發(fā)布的完成其特別商務(wù)需求的在線應(yīng)用服務(wù)，其他公司或應(yīng)用軟件能夠通過Internet來訪問并使用這項應(yīng)用服務(wù)

對于Web Services，很多人會與Web Service混為一談，認(rèn)為二者指的是同一個事物。其實不然，前者指的是用于建構(gòu)Web Service的技術(shù)框架，后者指的是使用Web Services技術(shù)而創(chuàng)建的應(yīng)用實例。Web Services是描述了一些操作的接口，基于標(biāo)準(zhǔn)化的XML消息傳輸機(jī)制，我們可以通過網(wǎng)絡(luò)訪問這些操作。Web Services使用規(guī)范的、基于XML的WSDL(Web Services Description Language)語言描述的，這稱為Web Services的服務(wù)描述。這一描述囊括了與服務(wù)交互所需要的全部細(xì)節(jié)，包括消息格式（詳細(xì)描述操作的輸入輸出消息格式）、傳輸協(xié)議和位置。該接口隱藏了服務(wù)實現(xiàn)的細(xì)節(jié)，允許通過獨立與服務(wù)實現(xiàn)、獨立于軟硬件平臺、獨立于編寫服務(wù)所用的編程語言的方式使用該服務(wù)。這使得基于Web Services的應(yīng)用程序具有松散耦合、面向組件和跨技術(shù)實現(xiàn)的特點。Web Services都履行一定的特定業(yè)務(wù)或任務(wù)，可以實現(xiàn)同其他Web Services一起用于實現(xiàn)復(fù)雜的商業(yè)交易。

從外部使用者角度而言，Web Services是一種部署在Web上的對象和組件，具備以下特征：

.完好的封裝性：

Web服務(wù)既然是一種部署在web上的對象，自然具備對象的良好封裝性，對于使用者而言，他能且僅能看到該對象提供的功能列表。

.松散耦合

這一特征也是源于對象／組件技術(shù)，當(dāng)一個Web服務(wù)的實現(xiàn)發(fā)生變更的時候，調(diào)用者是不會感到這一點的，對于調(diào)用者來說，只要Web服務(wù)的調(diào)用界面不變，Web服務(wù)實現(xiàn)的任何變更對他們來說都是透明的，甚至是當(dāng)Web服務(wù)的實現(xiàn)平臺從J2EE遷移到了．NET或者是相反的遷移流程，用戶都可以對此一無所知。對于松散耦合而言，尤其是在Internet環(huán)境下的Web服務(wù)而言，需要有一種適合Internet環(huán)境的消息交換協(xié)議，而XML／SOAP正是目前最為適合的消息交換協(xié)議。

.使用協(xié)議的規(guī)范性

這一特征從對象而來，但相比一般對象，它更加規(guī)范化和易于理解。首先，作為Web服務(wù)，對象界面所提供的功能應(yīng)當(dāng)使用標(biāo)準(zhǔn)的描述語言來描述(比如WSDL)；其次，由標(biāo)準(zhǔn)描述語言描述的服務(wù)界面應(yīng)當(dāng)是能夠被發(fā)現(xiàn)的，因此這一描述文檔需要被存儲在私有的或公共的注冊庫里面。同時，使用標(biāo)準(zhǔn)描述語言描述的使用協(xié)約將不僅僅是服務(wù)界面，它將被延伸到Web服務(wù)的聚合、跨Web服務(wù)的事務(wù)、工作流等，而這些又都需要服務(wù)質(zhì)量(QoS)的保障。其次，我們知道安全機(jī)制對于松散耦合的對象環(huán)境的重要性，因此我們需要對諸如授權(quán)認(rèn)證、數(shù)據(jù)完整性(比如簽名機(jī)制)、消息源認(rèn)證以及事務(wù)的不可否認(rèn)性等運用規(guī)范的方法來描述、傳輸和交換。最后，在所有層次的處理都應(yīng)當(dāng)是可管理的，因此需要對管理協(xié)約運用同樣的機(jī)制。

.高度可集成能力

由于Web服務(wù)采取簡單的、易理解的標(biāo)準(zhǔn)，Web協(xié)議作為組件界面描述和協(xié)同描述規(guī)范，完全屏蔽了不同軟件平臺的差異，無論是CORBA、DCOM還是EJB，都可以通過這一種標(biāo)準(zhǔn)的協(xié)議進(jìn)行互操作，實現(xiàn)了在當(dāng)前環(huán)境下最高的可集成性。

14.2.1 Web Services的核心技術(shù)

Web Services 是一種基于組件的軟件平臺,是面向服務(wù)的Internet 應(yīng)用。Web Services 是應(yīng)用于Internet 的,而不是限于局域網(wǎng)或試驗環(huán)境，這就要求Web Services 框架必須適用于現(xiàn)有的Internet 軟件和硬件環(huán)境,即服務(wù)的提供者所提供的服務(wù)必須具有跨平臺、跨語言的特性。其次,Web Services 所提供的服務(wù)不但是面向人,而且需服務(wù)于其它應(yīng)用系統(tǒng)。現(xiàn)有的Web網(wǎng)站也可以認(rèn)為是面向服務(wù)的,但這種服務(wù)僅僅可以提供給人使用(只有人類才可以讀懂瀏覽器下載的頁面) 。而新一代的Web Services 所提供的服務(wù)應(yīng)能被機(jī)器所讀懂,例如其它應(yīng)用程序及移動設(shè)備中的軟件系統(tǒng)。這樣,我們可以看出,Web Services 的發(fā)展方向?qū)嶋H上是構(gòu)造一個基于現(xiàn)有Internet 技術(shù)之上的分布計算系統(tǒng)。

Web Services 框架的核心技術(shù)包括SOAP(Simple Object Access Protocol,簡單對象訪問協(xié)議) ,WSDL(Web Services Description Lanuage,Web服務(wù)描述語言) 和UDDI（Universal Description，Discovery and Integration，通用描述，發(fā)現(xiàn)，集成) ,它們都是以標(biāo)準(zhǔn)的XML 文檔的形式表述的。

XML是Web Services技術(shù)體系中最基礎(chǔ)的標(biāo)準(zhǔn)，Web Services的一切都建立在XML技術(shù)的基礎(chǔ)之上，包括Web Services的消息、描述和服務(wù)實現(xiàn)的各個環(huán)節(jié)。利用XML，Web Services的服務(wù)提供者和請求者可以利用不同的開發(fā)語言來協(xié)作完成服務(wù)調(diào)用的過程。XML是Web Services技術(shù)體系中的很多標(biāo)準(zhǔn)得以建立的基礎(chǔ)，在Web Services系統(tǒng)中無處不在。

SOAP 是Web services 的通信協(xié)議。SOAP是一種簡單的、輕量級的基于XML 的機(jī)制，用于在網(wǎng)絡(luò)應(yīng)用程序之間進(jìn)行結(jié)構(gòu)化數(shù)據(jù)交換。SOAP包括三部分:一個定義描述消息內(nèi)容的框架的信封，一組表示應(yīng)用程序定義的數(shù)據(jù)類型實例的編碼規(guī)則，以及表示遠(yuǎn)程過程調(diào)用和響應(yīng)的約定。

WSDL表示W(wǎng)EB服務(wù)說明語言。WSDL文件是一個XML 文檔，用于說明一組SOAP消息以及如何交換這些消息，通過WSDL可以描述一個服務(wù)的信息。這些信息使不了解這個服務(wù)的開發(fā)者可以建立調(diào)用這個服務(wù)的客戶端代碼，或者通過WSDL幫助生成實現(xiàn)它的基本代碼結(jié)構(gòu)。WSDL在Web Services的實際開發(fā)過程中起著重要的作用。

　　Web Services是基于互聯(lián)網(wǎng)的應(yīng)用程序模塊，用于在互聯(lián)網(wǎng)上運行，它采用開放的UDDI（Universal Description，Discovery and Integration，通用描述，發(fā)現(xiàn)，集成）標(biāo)準(zhǔn)。UDDI標(biāo)準(zhǔn)先由IBM、微軟、Ariba制訂，到目前為止獲得了130多家公司的支持。UDDI 提供一種發(fā)布和查找服務(wù)描述的方法。UDDI 數(shù)據(jù)實體提供對定義業(yè)務(wù)和服務(wù)信息的支持。WSDL 中定義的服務(wù)描述信息是UDDI注冊中心信息的補充。UDDI提供了一個開放，平臺獨立的技術(shù)框架，來使企業(yè)之間能在互聯(lián)網(wǎng)上找到對方的服務(wù)，定義它們在互聯(lián)網(wǎng)上的交互活動，以及這些信息的共享方式。

Web 服務(wù)體系結(jié)構(gòu)基于三種角色（服務(wù)提供者、服務(wù)注冊中心和服務(wù)請求者）之間的交互。

服務(wù)提供者。從企業(yè)的角度看，這是服務(wù)的所有者。從體系結(jié)構(gòu)的角度看，這是托管訪問服務(wù)的平臺。 
服務(wù)請求者（用戶）。從企業(yè)的角度看，這是要求滿足特定功能的企業(yè)。從體系結(jié)構(gòu)的角度看，這是尋找并調(diào)用服務(wù)，或啟動與服務(wù)的交互的應(yīng)用程序。服務(wù)請求者角色可以由瀏覽器來擔(dān)當(dāng)，由人或無用戶界面的程序（例如，另外一個 Web 服務(wù)）來控制它。 
服務(wù)注冊中心。這是可搜索的服務(wù)描述注冊中心，服務(wù)提供者在此發(fā)布他們的服務(wù)描述。在靜態(tài)綁定開發(fā)或動態(tài)綁定執(zhí)行期間，服務(wù)請求者查找服務(wù)并獲得服務(wù)的綁定信息（在服務(wù)描述中）。對于靜態(tài)綁定的服務(wù)請求者，服務(wù)注冊中心是體系結(jié)構(gòu)中的可選角色，因為服務(wù)提供者可以把描述直接發(fā)送給服務(wù)請求者。同樣，服務(wù)請求者可以從服務(wù)注冊中心以外的其它來源得到服務(wù)描述，例如本地文件、FTP 站點、Web 站點、廣告和服務(wù)發(fā)現(xiàn)（Advertisement and Discovery of Services，ADS）或發(fā)現(xiàn) Web 服務(wù)（Discovery of Web Services，DISCO）。 

　　Web Services 的體系架構(gòu)如圖1 所示

Web Services 服務(wù)提供方通過WSDL(Web Services Description Language) 描述所提供的服務(wù),并將這一描述告知Web Services 注冊服務(wù)器。注冊服務(wù)器依據(jù)WSDL 的描述,依照UDDI (Universal Description Discovery and Integration) 的協(xié)定更新服務(wù)目錄并在Internet 上發(fā)布。用戶在使用Web Services 前先向注冊服務(wù)器發(fā)出請求,獲得Web Services 提供者的地址和服務(wù)接口信息,之后使用SOAP 協(xié)議(Simple Object Access Protocol) 與Web Services 提供者建立連接,進(jìn)行通信。Web Services 的技術(shù)主要建立在XML 的規(guī)范之上,這保證了這一體系結(jié)構(gòu)的平臺無關(guān)性、語言無關(guān)性和人機(jī)交互性能。

14.2.2 Web 服務(wù)開發(fā)生命周期

Web 服務(wù)開發(fā)生命周期包括了設(shè)計和部署以及在運行時對服務(wù)注冊中心、服務(wù)提供者和服務(wù)請求者每一個角色的要求。每個角色對開發(fā)生命周期的每一元素都有特定要求。

Web 服務(wù)開發(fā)生命周期有以下四個階段：

1. 構(gòu)建 
生命周期的構(gòu)建階段包括開發(fā)和測試 Web 服務(wù)實現(xiàn)、定義服務(wù)接口描述和定義服務(wù)實現(xiàn)描述。我們可以通過創(chuàng)建新的 Web 服務(wù)、把現(xiàn)有的應(yīng)用程序變成 Web 服務(wù)和由其它 Web 服務(wù)和應(yīng)用程序組成新的 Web 服務(wù)來提供 Web 服務(wù)的實現(xiàn)。

2. 部署 
部署階段包括向服務(wù)請求者或服務(wù)注冊中心發(fā)布服務(wù)接口和服務(wù)實現(xiàn)的定義，以及把 Web 服務(wù)的可執(zhí)行文件部署到執(zhí)行環(huán)境（典型情況下，Web 應(yīng)用程序服務(wù)器）中。

3. 運行 
在運行階段，可以調(diào)用 Web 服務(wù)。在此，Web 服務(wù)完成部署，成為可操作的服務(wù)。服務(wù)請求者可以進(jìn)行查找和綁定操作。

4. 管理 
管理階段包括持續(xù)的管理和經(jīng)營 Web 服務(wù)應(yīng)用程序。安全性、可用性、性能、服務(wù)質(zhì)量和業(yè)務(wù)流程問題都必須被解決。

接下來我們具體展開Web Services原理。

14.3．Web Services原理

首先，我們將看看 Web 服務(wù)的一個概念性協(xié)議棧以及這個協(xié)議棧的細(xì)節(jié)。然后我們將討論選擇網(wǎng)絡(luò)協(xié)議的標(biāo)準(zhǔn)。我們還將回顧一下基本的基于 XML 的消息傳遞分布式計算。我們將用服務(wù)描述擴(kuò)展基本的 XML 消息傳遞，而服務(wù)描述是根據(jù)它的協(xié)議棧來解釋的。接下來，我們將討論服務(wù)描述在 Web 服務(wù)體系結(jié)構(gòu)中的角色，說明支持靜態(tài)和動態(tài) Web 服務(wù)應(yīng)用程序的服務(wù)發(fā)布技術(shù)的范圍。我們還將圍繞服務(wù)發(fā)布討論服務(wù)發(fā)現(xiàn)的角色。最后，我們將描述基本 Web 服務(wù)體系結(jié)構(gòu)的擴(kuò)展，電子商務(wù)需要這些擴(kuò)展才能使用 Web 服務(wù)。

14.3.1 Web 服務(wù)協(xié)議棧

要以一種可交互操作的方式執(zhí)行發(fā)布、發(fā)現(xiàn)和綁定這三個操作，必須有一個包含每一層標(biāo)準(zhǔn)的 Web 服務(wù)協(xié)議棧。圖 2 展示了一個概念性 Web 服務(wù)協(xié)議棧。上面的幾層建立在下面幾層提供的功能之上。垂直的條表示在協(xié)議棧中每一層必須滿足的需求。

圖2. Web 服務(wù)概念性協(xié)議棧

Web 服務(wù)協(xié)議棧的基礎(chǔ)是網(wǎng)絡(luò)層。Web 服務(wù)要被服務(wù)請求者調(diào)用，就必須是可以通過網(wǎng)絡(luò)訪問的?；ヂ?lián)網(wǎng)上可以公用的 Web 服務(wù)使用普遍適用的網(wǎng)絡(luò)協(xié)議。HTTP 憑借其普遍性，成為了互聯(lián)網(wǎng)可用的 Web 服務(wù)真正的標(biāo)準(zhǔn)網(wǎng)絡(luò)協(xié)議。Web 服務(wù)還可以支持其它互聯(lián)網(wǎng)協(xié)議，包括 SMTP 和 FTP。內(nèi)部網(wǎng)域可以使用可靠消息傳遞和調(diào)用基礎(chǔ)結(jié)構(gòu)，如 MQSeries 和 CORBA 等等。

下一層是基于 XML 的消息傳遞，它表示使用 XML 作為消息傳遞協(xié)議的基礎(chǔ)。選擇 SOAP 作為 XML 消息傳遞協(xié)議有很多原因：

它是使用 XML 傳送以文檔為中心的消息以及遠(yuǎn)程過程調(diào)用的標(biāo)準(zhǔn)化封裝機(jī)制。 
SOAP 很簡單；它基本上是一個用 XML 信封作為有效負(fù)載的 HTTP POST。 
SOAP 比對 XML 簡單的 HTTP POST 更受青睞，因為它定義了一個標(biāo)準(zhǔn)機(jī)制，這個機(jī)制將正交擴(kuò)展（orthogonal extension）合并為使用 SOAP 報頭和對操作或函數(shù)進(jìn)行標(biāo)準(zhǔn)編碼的消息。 
SOAP 消息支持 Web 服務(wù)體系結(jié)構(gòu)中的發(fā)布、查找和綁定操作。 
服務(wù)描述層實際上是描述文檔的一個協(xié)議棧。首先，WSDL 是基于 XML 的服務(wù)描述的真正標(biāo)準(zhǔn)。這是支持可交互操作的 Web 服務(wù)所需的最小標(biāo)準(zhǔn)服務(wù)描述。WSDL 定義了服務(wù)交互的接口和結(jié)構(gòu)。要指定業(yè)務(wù)環(huán)境、服務(wù)質(zhì)量和服務(wù)之間的關(guān)系，我們還需要另外的描述。WSDL 文檔可以由其它服務(wù)描述文檔來補充，從而描述 Web 服務(wù)的這些更高級的方面。例如，描述業(yè)務(wù)環(huán)境除了使用 WSDL 文檔，還要使用 UDDI 數(shù)據(jù)結(jié)構(gòu)。Web 服務(wù)流程語言（Web Services Flow Language，WSFL）文檔中則描述了服務(wù)組成和流程。

因為 Web 服務(wù)被定義為可以通過 SOAP 從網(wǎng)絡(luò)進(jìn)行訪問，并由服務(wù)描述表示，所以該協(xié)議棧中的前三層需要提供或使用 Web 服務(wù)。最簡單的協(xié)議棧將包括網(wǎng)絡(luò)層的 HTTP、XML 消息傳遞層的 SOAP 協(xié)議以及服務(wù)描述層的 WSDL。所有企業(yè)間或公用 Web 服務(wù)都應(yīng)該支持這種可交互操作的基礎(chǔ)協(xié)議棧。Web 服務(wù)，特別是企業(yè)內(nèi)部或?qū)Ｓ?Web 服務(wù)，能夠支持其它的網(wǎng)絡(luò)協(xié)議和分布式計算技術(shù)。該協(xié)議棧提供了互操作性，它使 Web 服務(wù)能夠利用現(xiàn)有的互聯(lián)網(wǎng)基礎(chǔ)結(jié)構(gòu)。這將使進(jìn)入普遍存在的環(huán)境的成本非常低。另外，靈活性并不會因為互操作性需求而有所降低，因為我們可以為選擇性和增值的技術(shù)提供另外的支持。例如，我們必須支持 HTTP 上的 SOAP，但也可以同時支持 MQ 上的 SOAP。

協(xié)議棧的最下面三層確立了保證一致性和互操作性的技術(shù)，而它們上面的兩層，即服務(wù)發(fā)布和服務(wù)發(fā)現(xiàn)，可以用多種解決方案來實現(xiàn)。

任何能夠讓服務(wù)請求者使用 WSDL 文檔的操作，不管它處于服務(wù)請求者生命周期的哪個階段，都符合服務(wù)發(fā)布的標(biāo)準(zhǔn)。該層中最簡單、最靜態(tài)的實例就是服務(wù)提供者直接向服務(wù)請求者發(fā)送 WSDL 文檔。這被稱為直接發(fā)布。電子郵件是直接發(fā)布的載體之一。直接發(fā)布對靜態(tài)綁定的應(yīng)用程序來說很有用。另外，服務(wù)提供者還可以將描述服務(wù)的文檔發(fā)布到主機(jī)本地 WSDL 注冊中心、專用 UDDI 注冊中心或 UDDI 運營商節(jié)點。

Web 服務(wù)如果沒有被發(fā)布就不能被發(fā)現(xiàn)，所以說服務(wù)發(fā)現(xiàn)依賴于服務(wù)發(fā)布。該層的各種發(fā)現(xiàn)機(jī)制和一組發(fā)布機(jī)制互相平行。任何允許服務(wù)請求者獲得對服務(wù)描述的訪問權(quán)，并在運行時使應(yīng)用程序能夠使用該服務(wù)描述的機(jī)制都必須符合服務(wù)發(fā)現(xiàn)的標(biāo)準(zhǔn)。最簡單、最靜態(tài)的發(fā)現(xiàn)的實例是靜態(tài)發(fā)現(xiàn)，其中服務(wù)請求者從本地文件獲取 WSDL 文檔。這通常都是通過直接發(fā)布獲取的 WSDL 文檔，或者前面查找操作的結(jié)果。另外，也可以通過使用本地 WSDL 注冊中心、專用 UDDI 注冊中心或 UDDI 運營商節(jié)點在設(shè)計時或運行時發(fā)現(xiàn)服務(wù)。因為 Web 服務(wù)實現(xiàn)是一種軟件模塊，所以通過組建 Web 服務(wù)來產(chǎn)生 Web 服務(wù)是很自然的。Web 服務(wù)的組合可以扮演很多角色之一。企業(yè)內(nèi)部的 Web 服務(wù)可能會相互合作，從而對外顯示出一個單獨的 Web 服務(wù)接口，或者，來自不同企業(yè)的 Web 服務(wù)可以相互合作，從而執(zhí)行機(jī)器到機(jī)器、企業(yè)到企業(yè)的事務(wù)。另外，工作流程管理者還可以在參與業(yè)務(wù)流程的時侯調(diào)用每個 Web 服務(wù)。最上面一層，即服務(wù)流程，描述了如何執(zhí)行服務(wù)到服務(wù)的通訊、合作以及流程。WSFL 用于描述這些交互。要使 Web 服務(wù)應(yīng)用程序滿足當(dāng)今電子商務(wù)的迫切需求，就必須提供企業(yè)級基礎(chǔ)結(jié)構(gòu)，包括安全性、管理和服務(wù)質(zhì)量。這幾個垂直條在協(xié)議棧的每一層都必須得到解決。每一層的解決方案可以彼此獨立。隨著 Web 服務(wù)范例的采用和發(fā)展，將會出現(xiàn)更多此類垂直條。

該協(xié)議棧的最下面幾層表示基礎(chǔ) Web 服務(wù)協(xié)議棧，它們相對于協(xié)議棧中上面幾層來說更成熟，也更標(biāo)準(zhǔn)。Web 服務(wù)的成熟和采用將會帶動協(xié)議棧中上面幾層和垂直條的開發(fā)和標(biāo)準(zhǔn)化。

網(wǎng)絡(luò)層

Web 服務(wù)協(xié)議棧的最底層是網(wǎng)絡(luò)層。該層可表示任意多個網(wǎng)絡(luò)協(xié)議：HTTP、FTP、SMTP、消息排隊（Message Queuing）、互聯(lián)網(wǎng) ORB 間協(xié)議（Internet Inter ORB Protocol，IIOP）上的遠(yuǎn)程方法調(diào)用（Remote Method Invocation，RMI）、電子郵件等等。在任何給定的情況下使用的網(wǎng)絡(luò)協(xié)議都依賴于應(yīng)用程序需求。

對于可以從互聯(lián)網(wǎng)訪問的 Web 服務(wù)，人們選擇網(wǎng)絡(luò)技術(shù)的時侯通常會傾向于選擇普遍部署的協(xié)議，如 HTTP。對于內(nèi)部網(wǎng)中提供和使用的 Web 服務(wù)，使用另外的網(wǎng)絡(luò)技術(shù)也會被認(rèn)同。我們可以根據(jù)其它需求選擇網(wǎng)絡(luò)技術(shù)，包括安全性、可用性、性能以及可靠性。這使得 Web 服務(wù)可以利用已有的功能更高級的聯(lián)網(wǎng)基礎(chǔ)結(jié)構(gòu)和面向消息的中間件，如 MQSeries。在有多種網(wǎng)絡(luò)基礎(chǔ)結(jié)構(gòu)的企業(yè)中，HTTP 可以用來在這些基礎(chǔ)結(jié)構(gòu)之間搭建橋梁。

Web 服務(wù)的好處之一在于，它為專用內(nèi)部網(wǎng)和公用互聯(lián)網(wǎng)服務(wù)的開發(fā)和使用提供了統(tǒng)一的編程模型。所以，網(wǎng)絡(luò)技術(shù)的選擇對服務(wù)開發(fā)者來說是透明的。

基于 XML 消息傳遞的分布式計算

Web 服務(wù)體系結(jié)構(gòu)最基礎(chǔ)的支柱是 XML 消息傳遞。當(dāng)前 XML 消息傳遞的行業(yè)標(biāo)準(zhǔn)是 SOAP。IBM、Microsoft 以及其它企業(yè)都向 W3C 建議 SOAP 作為 XML 協(xié)議工作組（XML Protocol Working Group）的基礎(chǔ)。XML 協(xié)議將代替 SOAP 作為行業(yè)標(biāo)準(zhǔn) XML 消息傳遞協(xié)議的位置。當(dāng) W3C 發(fā)布 XML 協(xié)議的草案標(biāo)準(zhǔn)時，Web 服務(wù)體系結(jié)構(gòu)就會從 SOAP 遷移到 XML 協(xié)議。

SOAP 是一種簡單的、輕量級的基于 XML 的機(jī)制，用于在網(wǎng)絡(luò)應(yīng)用程序之間進(jìn)行結(jié)構(gòu)化數(shù)據(jù)交換。SOAP 包括三部分：一個定義描述消息內(nèi)容的框架的信封、一組表示應(yīng)用程序定義的數(shù)據(jù)類型實例的編碼規(guī)則，以及表示遠(yuǎn)程過程調(diào)用（remote procedure calls，RPC）和響應(yīng)的約定。SOAP 可以和各種網(wǎng)絡(luò)協(xié)議（如 HTTP、SMTP、FTP 和 IIOP 或 MQ 上的 RMI）相結(jié)合使用，或者用這些協(xié)議重新封裝后使用。

雖然理解這個基礎(chǔ)很重要，但多數(shù) Web 服務(wù)開發(fā)者不必直接處理這個基礎(chǔ)結(jié)構(gòu)。大多數(shù) Web 服務(wù)都會使用從 WSDL 生成的經(jīng)過優(yōu)化的特定于編程語言的綁定。當(dāng)服務(wù)提供者和服務(wù)請求者都在類似的環(huán)境中執(zhí)行時，這種優(yōu)化可能尤為重要。

圖 4 展示了 XML 消息傳遞（即 SOAP）和網(wǎng)絡(luò)協(xié)議如何組成Web 服務(wù)體系結(jié)構(gòu)的基礎(chǔ)。

圖 4. 使用 SOAP 的 XML 消息傳遞

網(wǎng)絡(luò)節(jié)點在基于 XML 消息傳遞的分布式計算中扮演提供者和請求者角色的基本要求是構(gòu)建、解析 SOAP 消息的能力（或兩者兼而有之），以及在網(wǎng)絡(luò)上通信的能力（接收、發(fā)送消息，或兩者）。

通常，在 Web 應(yīng)用程序服務(wù)器中運行的 SOAP 服務(wù)器將執(zhí)行這些功能。另外，我們也可以使用在 API 中封裝這些功能的特定于編程語言的運行庫。應(yīng)用程序與 SOAP 的集成可以通過使用四個基本步驟來實現(xiàn)：

在圖 4 中，服務(wù)提供者的應(yīng)用程序在（1）創(chuàng)建一條 SOAP 消息。這條 SOAP 消息是調(diào)用由服務(wù)提供者提供的 Web 服務(wù)操作的請求。消息主體中的 XML 文檔可以是一個 SOAP RPC 請求，也可以是一個服務(wù)描述中所描述的以文檔為中心的消息。服務(wù)請求者將此信息和服務(wù)提供者的網(wǎng)址一起提供給 SOAP 基礎(chǔ)結(jié)構(gòu)（例如一個 SOAP 客戶機(jī)運行時）。SOAP 客戶機(jī)運行時與一個底層網(wǎng)絡(luò)協(xié)議（例如 HTTP）交互，然后在網(wǎng)絡(luò)上將 SOAP 消息發(fā)送出去。 
網(wǎng)絡(luò)基礎(chǔ)結(jié)構(gòu)在（2）將消息傳送到服務(wù)提供者的 SOAP 運行時（例如一個 SOAP 服務(wù)器）。SOAP 服務(wù)器將請求消息路由到服務(wù)提供者的 Web 服務(wù)。如果應(yīng)用程序需要，SOAP 運行時負(fù)責(zé)將 XML 消息轉(zhuǎn)換為特定于編程語言的對象。這個轉(zhuǎn)換由消息中可以找到的編碼模式所控制。 
Web 服務(wù)負(fù)責(zé)處理請求信息并生成一個響應(yīng)。該響應(yīng)也是一條 SOAP 消息。響應(yīng)的 SOAP 消息在（3）被提供給 SOAP 運行時，其目的地是服務(wù)請求者。在 HTTP 上的同步請求／響應(yīng)的情況中，聯(lián)網(wǎng)協(xié)議的底層請求／響應(yīng)本質(zhì)用于實現(xiàn)消息傳遞的請求／響應(yīng)本質(zhì)。SOAP 運行時將 SOAP 消息響應(yīng)發(fā)送到網(wǎng)絡(luò)上的服務(wù)請求者。 
響應(yīng)消息在（4）由服務(wù)請求者節(jié)點上的聯(lián)網(wǎng)基礎(chǔ)結(jié)構(gòu)接收。消息會經(jīng)過整個 SOAP 基礎(chǔ)結(jié)構(gòu)；可能會將 XML 消息轉(zhuǎn)換為目標(biāo)編程語言中的對象。然后，響應(yīng)消息被提供給應(yīng)用程序。 
本示例使用了請求／響應(yīng)傳送基本原理，這種原理在大多數(shù)分布式計算環(huán)境中都很常見。請求／響應(yīng)交換可以是同步的，也可以是異步的。其它傳送基本原理，如單向消息傳遞（無響應(yīng)），通知（推動式響應(yīng)）以及發(fā)布／訂閱，也可能用到 SOAP。

那么，服務(wù)請求者如何知道請求消息應(yīng)該使用什么格式呢？這個問題在下面會得到回答。

服務(wù)描述：從 XML 消息傳遞到 Web 服務(wù)

服務(wù)提供者是通過服務(wù)描述將所有用于調(diào)用 Web 服務(wù)的規(guī)范傳送給服務(wù)請求者的。要實現(xiàn) Web 服務(wù)體系結(jié)構(gòu)的松散耦合，并減少服務(wù)提供者和服務(wù)請求者之間所需的共識的程度和定制編程與集成的程度，服務(wù)描述就是關(guān)鍵。例如，不管是請求者還是提供者，都不必了解對方的底層平臺、編程語言或分布式對象模型（如果有的話）。服務(wù)描述與底層 SOAP 基礎(chǔ)結(jié)構(gòu)相結(jié)合，足以封裝服務(wù)請求者的應(yīng)用程序和服務(wù)提供者的 Web 服務(wù)之間的這個細(xì)節(jié)。

基本服務(wù)描述

Web 服務(wù)體系結(jié)構(gòu)使用 WSDL 作為基本服務(wù)描述。WSDL 已經(jīng)被提交到 W3C 作為標(biāo)準(zhǔn)。WSDL 是一種 XML 文檔，它將 Web 服務(wù)描述為一組端點，這些端點會處理包含面向文檔或面向過程的（RPC）消息的消息。操作和消息都是被抽象描述的，然后它們會被綁定到一個具體的網(wǎng)絡(luò)協(xié)議和消息格式，用來定義端點。相關(guān)的具體端點被合并到抽象的端點或服務(wù)中。WSDL 可以擴(kuò)展為允許端點和其消息的描述，不管使用哪種消息格式或網(wǎng)絡(luò)協(xié)議進(jìn)行通訊都可以。然而，目前經(jīng)過描述的綁定只能用于 SOAP 1.1、HTTP POST 以及多用途互聯(lián)網(wǎng)郵件擴(kuò)展（Multipurpose Internet Mail Extensions，MIME）。

Web 服務(wù)體系結(jié)構(gòu)中對 WSDL 的使用按照常規(guī)將基本的服務(wù)描述分成了兩部分：服務(wù)接口和服務(wù)實現(xiàn)。這使每個部分都可以被分開獨立定義，并可以由另一部分重新使用。

服務(wù)接口定義是一種抽象或可重用的服務(wù)定義，它可以被多個服務(wù)實現(xiàn)定義實例化和引用。我們可以將服務(wù)接口定義想象成接口定義語言（Interface Definition Language，IDL）、Java 接口或 Web 服務(wù)類型。這使常見的行業(yè)標(biāo)準(zhǔn)服務(wù)類型可以被多個服務(wù)實現(xiàn)者定義和實現(xiàn)。這類似于在編程語言中定義抽象接口然后得到多個具體實現(xiàn)。服務(wù)接口可以由行業(yè)標(biāo)準(zhǔn)組織定義。

服務(wù)接口包含 WSDL 元素，它們組成了服務(wù)描述中的可重用部分，這些元素有：WSDL: binding、WSDL: portType、WSDL: message 和 WSDL: type 元素，如圖 5 中所描述。WSDL: portType 元素中定義了 Web 服務(wù)的操作。操作定義了輸入和輸出數(shù)據(jù)流中可以出現(xiàn)的 XML 消息。您可以將操作想象成編程語言中的方法說明。WSDL: message 元素指定哪些 XML 數(shù)據(jù)類型組成消息的各個部分。WSDL: message 元素用于定義操作的輸入和輸出參數(shù)。WSDL: types 元素中描述消息中復(fù)雜數(shù)據(jù)類型的使用。WSDL: binding 元素描述特定服務(wù)接口（WSDL: portType）的協(xié)議、數(shù)據(jù)格式、安全性和其它屬性。

服務(wù)實現(xiàn)定義是一個描述給定服務(wù)提供者如何實現(xiàn)特定服務(wù)接口的 WSDL 文檔。Web 服務(wù)被建模成 WSDL: service 元素。服務(wù)元素包含一組（通常是一個）WSDL: port 元素。端口將端點（例如網(wǎng)址位置或 URL）與來自服務(wù)接口定義的 WSDL: binding 元素關(guān)聯(lián)起來。

為了說明職責(zé)的安排，開放應(yīng)用程序組（Open Applications Group，OAG）為開放應(yīng)用程序組集成規(guī)范（Open Applications Group Integration Specification，OAGIS）購買標(biāo)準(zhǔn)定義了一個服務(wù)接口定義。這個服務(wù)接口定義會定義 WSDL: type、WSDL: message、WSDL: portType 和 WSDL: binding。

服務(wù)提供者可以選擇開發(fā)實現(xiàn) OAGIS 購買訂單服務(wù)接口的 Web 服務(wù)。服務(wù)提供者會開發(fā)一個服務(wù)實現(xiàn)定義文檔，描述 WSDL 設(shè)備、端口和地址位置元素，這些元素描述提供者的 Web 服務(wù)的網(wǎng)址及其它特定于實現(xiàn)的細(xì)節(jié)。

服務(wù)接口定義和服務(wù)實現(xiàn)定義結(jié)合在一起，組成了服務(wù)完整的 WSDL 定義。這兩個定義包含為服務(wù)請求者描述如何調(diào)用以及與 Web 服務(wù)交互的足夠信息。服務(wù)請求者可以要求獲得其它關(guān)于服務(wù)提供者端口的信息。此信息由服務(wù)完整的 Web 服務(wù)描述提供。

完整的 Web 服務(wù)描述

完整的 Web 服務(wù)描述建立在服務(wù)基本的 WSDL 定義之上。完整的 Web 服務(wù)描述可以解決這樣的問題：什么企業(yè)在托管這個服務(wù)？它是何種類型的企業(yè)？與服務(wù)相關(guān)聯(lián)的產(chǎn)品有哪些？各種公司和產(chǎn)品類別中與該企業(yè)或其 Web 服務(wù)相關(guān)聯(lián)的分類有哪些？有沒有服務(wù)的其它方面（如服務(wù)質(zhì)量）會影響到請求者是否選擇調(diào)用服務(wù)？為了使查找該服務(wù)更容易，可以提供哪些關(guān)鍵字？

圖 6 中描述了一個完整的 Web 服務(wù)描述。

圖 6. 完整的 Web 服務(wù)描述協(xié)議棧

UDDI 提供了一個保存 Web 服務(wù)描述的機(jī)制。雖然 UDDI 通常會被認(rèn)為是一種目錄機(jī)制，但是它也定義了一個用 XML 表示服務(wù)描述信息的數(shù)據(jù)結(jié)構(gòu)標(biāo)準(zhǔn)。UDDI 條目中有四種基本數(shù)據(jù)結(jié)構(gòu)，如圖 7 中所示。

圖 7. 基本 UDDI 數(shù)據(jù)結(jié)構(gòu)

UDDI 條目由 businessEntity 開始。businessEntity 元素對關(guān)于企業(yè)的信息進(jìn)行建模，包括基本的企業(yè)信息（例如企業(yè)名稱和聯(lián)系方式信息是什么？）、分類信息（例如這是何種類型的企業(yè)？）以及標(biāo)識信息（即 Dunn and Bradstreet 編號是什么？）。businessEntity 包含一組 businessService 元素，每個元素對應(yīng)于企業(yè)希望發(fā)布的每個 Web 服務(wù)。每個 businessService 元素都包含和 businessEntity 元素的 Web 服務(wù)有關(guān)的技術(shù)性和描述性信息。businessService 包含一組 bindingTemplate 元素。bindingTemplate 描述訪問信息（例如端點地址），還描述 businessService 如何使用各種不同的技術(shù)規(guī)范。技術(shù)規(guī)范在這里的模型是 tModel。tModel 可以為很多不同概念建模，如：一種服務(wù)、一個諸如 HTTPS 之類的平臺技術(shù)或一個類別。與 businessService 相關(guān)聯(lián)的那一組 bindingTemplate 元素代表了 businessService 所使用的技術(shù)的印記。

在Web 服務(wù)體系結(jié)構(gòu)中，完整的 Web 服務(wù)描述包括用于端點描述的一層，這個端點描述使用 UDDI 條目向服務(wù)描述添加企業(yè)和實現(xiàn)環(huán)境。

端點描述遵循結(jié)合 WSDL 使用 UDDI 的約定。端點描述使用 UDDI 提供企業(yè)信息和類別的標(biāo)準(zhǔn)表示。這個 UDDI-WSDL 約定規(guī)定了如何從和 Web 服務(wù)相關(guān)聯(lián)的 UDDI 條目中得出服務(wù)接口定義和服務(wù)實現(xiàn)定義的 WSDL 描述。這個約定對于在Web 服務(wù)體系結(jié)構(gòu)中使用 UDDI 作為基于 WSDL 的服務(wù)的服務(wù)注冊中心來說至關(guān)重要。

端點描述向應(yīng)用到服務(wù)的特定實現(xiàn)的服務(wù)描述添加了另外的語義。安全屬性可以定義對 Web 服務(wù)的訪問進(jìn)行控制的策略。服務(wù)質(zhì)量屬性指定面向性能的能力，例如服務(wù)在一定時間內(nèi)作出響應(yīng)的能力，或所支持的可靠消息傳遞的級別。服務(wù)開銷屬性描述服務(wù)的資源需求。還可以定義支持哪些對話語義。

服務(wù)描述協(xié)議棧中的最后一層是協(xié)議描述。協(xié)議描述反映兩個企業(yè)伙伴之間為了完成一個多步企業(yè)交互而進(jìn)行的 Web 服務(wù)調(diào)用的一個簡單的編排。例如，“協(xié)議定義”定義了購買協(xié)議中諸如購買者和出售者之類的角色。協(xié)議定義規(guī)定了每個角色必須達(dá)到的要求。例如，出售者必須有接受報價請求（request for quote，RFQ）消息、購買訂單（purchase order，PO）消息和付款消息的 Web 服務(wù)。購買者的角色必須有接受報價（RFQ 響應(yīng)信息）、發(fā)票消息和帳戶摘要信息的 Web 服務(wù)。這個簡單的 Web 服務(wù)到企業(yè)角色的編排對于在企業(yè)伙伴之間建立多步的、面向服務(wù)的交互來說至關(guān)重要。在很多不同的企業(yè)協(xié)議標(biāo)準(zhǔn)下，一個給定的服務(wù)請求者或服務(wù)提供者也許能夠扮演購買者或出售者的角色。通過顯式地建立企業(yè)協(xié)議和每個節(jié)點在企業(yè)協(xié)議中扮演各種角色的能力，請求者可以選擇在面對各種提供者企業(yè)伙伴時加入哪種企業(yè)協(xié)議。

這個領(lǐng)域充滿了創(chuàng)新。對于企業(yè)協(xié)議定義來說，目前還沒有一個單獨的標(biāo)準(zhǔn)。ebXML 協(xié)作-協(xié)議概要和協(xié)定規(guī)范（ebXML Collaboration-Protocol Profile and Agreement Specification）描述了這些概念，但不是根據(jù)作為該體系結(jié)構(gòu)的一部分描述的 Web 服務(wù)技術(shù)而描述的。Web 服務(wù)流程描述和 Web 服務(wù)端點描述這兩層正處于開發(fā)中，它們可以提供這個級別的服務(wù)描述。

服務(wù)描述的發(fā)布和發(fā)現(xiàn)

服務(wù)發(fā)布

Web 服務(wù)的發(fā)布包括服務(wù)描述的生成和之后的發(fā)布。發(fā)布可以使用各種不同機(jī)制。

生成服務(wù)描述 
我們可以生成、手工編碼服務(wù)描述，也可以根據(jù)已有的服務(wù)接口定義組成服務(wù)描述。開發(fā)者可以手工編碼整個服務(wù)描述，包括 UDDI 條目。有些工具可以從編程模型和可執(zhí)行 Web 服務(wù)的部署生成 WSDL，還有可能生成來自元數(shù)據(jù)構(gòu)件的部分 UDDI 條目。部分服務(wù)描述可能已經(jīng)存在（例如，Web 服務(wù)可以基于一個行業(yè)標(biāo)準(zhǔn)服務(wù)接口定義），這樣就只須進(jìn)一步生成一小部分就可以了。

發(fā)布服務(wù)描述 
服務(wù)描述可以使用各種不同機(jī)制來發(fā)布。根據(jù)應(yīng)用程序?qū)⑹褂梅?wù)的動態(tài)程度，這些不同的機(jī)制提供不同的能力。服務(wù)描述可以使用多種不同機(jī)制發(fā)布到多個服務(wù)注冊中心。

最簡單的情況是直接發(fā)布。直接發(fā)布意味著服務(wù)提供者直接將服務(wù)發(fā)布給服務(wù)請求者。這可以通過使用電子郵件附件、FTP 站點甚至光盤分發(fā)來實現(xiàn)。直接發(fā)布可以在企業(yè)伙伴雙方就在 Web 上使用電子商務(wù)的條款達(dá)成一致后進(jìn)行，或在請求訪問服務(wù)的服務(wù)請求者支付了費用之后進(jìn)行。在這種情況下，服務(wù)請求者可以保留服務(wù)描述的一份本地副本。

稍微更動態(tài)一點的發(fā)布使用 DISCO 或 ADS。DISCO 和 ADS 兩者都定義了一個從給定 URL 獲取 Web 服務(wù)描述的簡單的 HTTP GET 機(jī)制。增強(qiáng)的服務(wù)描述資源庫會提供服務(wù)描述的一個本地高速緩存，不過還提供了附加的搜索能力。對于在企業(yè)內(nèi)部跨越主機(jī)的服務(wù)描述資源庫來說，服務(wù)提供者會向?qū)Ｓ玫?UDDI 節(jié)點發(fā)布。我們可以根據(jù)發(fā)布到節(jié)點的 Web 服務(wù)的域的范圍，使用幾種專用的 UDDI 節(jié)點。

內(nèi)部企業(yè)應(yīng)用程序 UDDI 節(jié)點（Internal Enterprise Application UDDI node）節(jié)點：公司內(nèi)部為了進(jìn)行內(nèi)部企業(yè)應(yīng)用程序集成而使用的 Web 服務(wù)應(yīng)該被發(fā)布到這一類 UDDI 節(jié)點。此類 UDDI 節(jié)點的范圍可以是部門的或公司的單獨的應(yīng)用程序。這些 UDDI 位于防火墻之后，允許服務(wù)發(fā)布者對他們的服務(wù)注冊中心和它的訪問權(quán)、可用性以及發(fā)布要求有更多的控制。 
門戶網(wǎng)站 UDDI 節(jié)點（Portal UDDI node）節(jié)點：由公司發(fā)布以供外部伙伴查找和使用的 Web 服務(wù)可以使用門戶網(wǎng)站 UDDI 節(jié)點。門戶網(wǎng)站節(jié)點運行在服務(wù)提供者的防火墻之外或之間。這種專用 UDDI 節(jié)點只包含公司希望向來自外部伙伴的請求者提供的那些服務(wù)描述。這允許公司保留對他們服務(wù)描述的控制、UDDI 節(jié)點的訪問以及 UDDI 節(jié)點的服務(wù)質(zhì)量。此外，通過使用門戶網(wǎng)站中固有的基于角色的可見性，企業(yè)將服務(wù)描述的可見性局限在允許看到它們存在的伙伴中。 
伙伴目錄 UDDI 節(jié)點（Partner Catalog UDDI node）節(jié)點：由特定公司使用的 Web 服務(wù)可以被發(fā)布到伙伴目錄 UDDI 節(jié)點?；锇槟夸?UDDI 節(jié)點位于防火墻之后。此類專用 UDDI 節(jié)點只包含來自合法企業(yè)伙伴的經(jīng)過允許的、測試過的、有效的 Web 服務(wù)。此類 Web 服務(wù)的業(yè)務(wù)環(huán)境和元數(shù)據(jù)可以被定位到特定的請求者。 
電子市場 UDDI 節(jié)點（E-Marketplace UDDI node）節(jié)點：對于服務(wù)提供者打算用來與其它 Web 服務(wù)競爭請求者的業(yè)務(wù)的 Web 服務(wù)來說，服務(wù)描述應(yīng)該被發(fā)布到電子市場 UDDI 節(jié)點或 UDDI 運營商節(jié)點。電子市場 UDDI 節(jié)點由一個行業(yè)標(biāo)準(zhǔn)組織或社團(tuán)托管，包含特定行業(yè)中的企業(yè)的服務(wù)描述。我們可以要求這些服務(wù)支持特定的標(biāo)準(zhǔn)、可搜索元數(shù)據(jù)、接口或數(shù)據(jù)類型。電子市場 UDDI 節(jié)點一般會過濾掉某些非法的條目，并提供有保證的服務(wù)質(zhì)量。 
UDDI 運營商節(jié)點：如果您希望 Web 服務(wù)可以被潛在的新的企業(yè)伙伴或服務(wù)用戶發(fā)現(xiàn)，還可以將其發(fā)布到 UDDI 運營商節(jié)點。IBM、Microsoft 和 Ariba 都支持、復(fù)制和托管 UDDI 運營商節(jié)點。在發(fā)布 UDDI 運營商節(jié)點的時侯，如果要讓潛在的服務(wù)請求者發(fā)現(xiàn)服務(wù)的話，完整的業(yè)務(wù)環(huán)境和經(jīng)過深思熟慮的分類法是很必要的。

圖 8. 服務(wù)發(fā)現(xiàn)連續(xù)體

圖 8 展示了從發(fā)布和發(fā)現(xiàn)中最靜態(tài)、最簡單的技術(shù)到最動態(tài)、更復(fù)雜的技術(shù)的連續(xù)體。Web 服務(wù)的用戶或?qū)崿F(xiàn)者不必嚴(yán)格遵循這個發(fā)展順序。

服務(wù)發(fā)現(xiàn)

Web 服務(wù)的發(fā)現(xiàn)包括獲取服務(wù)描述和使用描述。獲取過程可以使用各種不同機(jī)制。

獲取服務(wù)描述

和發(fā)布 Web 服務(wù)描述一樣，根據(jù)服務(wù)描述如何被發(fā)布以及 Web 服務(wù)應(yīng)用程序可能達(dá)到的動態(tài)程度，獲取 Web 服務(wù)描述也會有所不同。服務(wù)請求者將在應(yīng)用程序生命周期的兩個不同階段，即設(shè)計時和運行時查找 Web 服務(wù)。在設(shè)計時，服務(wù)請求者按照他們支持的接口類型搜索 Web 服務(wù)描述。在運行時，服務(wù)請求者根據(jù)他們通訊的方式或公告的服務(wù)質(zhì)量搜索 Web 服務(wù)。

使用直接發(fā)布方法時，服務(wù)請求者在設(shè)計時對服務(wù)描述進(jìn)行高速緩存，以在運行時使用它。服務(wù)描述可以被靜態(tài)地用程序邏輯表示，并存儲在文件或簡單的本地服務(wù)描述資源庫中。

服務(wù)請求者可以在設(shè)計時或運行時在服務(wù)描述資源庫（簡單的服務(wù)注冊中心或 UDDI 節(jié)點）中檢索一條服務(wù)描述。查找機(jī)制需要支持一種查詢機(jī)制，它提供按接口類型（基于 WSDL 模板）、綁定信息（即協(xié)議）、屬性（如 QoS 參數(shù)）、所需的中介類型、服務(wù)分類法、企業(yè)信息等等的查找。

不同類型的 UDDI 節(jié)點會顯示可以選擇的運行時綁定 Web 服務(wù)的數(shù)目、多選一的策略，或者調(diào)用服務(wù)之前必須由請求者作出預(yù)選的量。

內(nèi)部企業(yè)應(yīng)用程序 UDDI 節(jié)點和伙伴目錄 UDDI 節(jié)點將不需要預(yù)選來建立對服務(wù)的信任。服務(wù)選擇可以建立在綁定支持、歷史性能、服務(wù)質(zhì)量分類、相似性或負(fù)載平衡的基礎(chǔ)之上。

電子市場 UDDI 節(jié)點將有更多的運行時服務(wù)可以選擇。必須執(zhí)行某種預(yù)選以保證 Web 服務(wù)提供者是有價值的伙伴。我們可以根據(jù)價格承諾、開銷、經(jīng)過允許的伙伴列表的出席情況，同樣還有綁定支持、歷史性能、服務(wù)質(zhì)量分類和相似性來選擇服務(wù)。

如果服務(wù)請求者從 UDDI 運營商節(jié)點查詢 Web 服務(wù)提供者，他們在預(yù)選可能的服務(wù)提供者時就必須盡可能謹(jǐn)慎和認(rèn)真。應(yīng)該有一個有效和準(zhǔn)確的機(jī)制就位，過濾掉無用的服務(wù)描述和沒有價值的服務(wù)提供者。

使用服務(wù)描述 
在獲取了服務(wù)描述之后，服務(wù)請求者需要處理它以調(diào)用服務(wù)。服務(wù)請求者使用服務(wù)描述生成對 Web 服務(wù)的 SOAP 請求或特定于編程語言的代理。該生成可以在設(shè)計時或運行時進(jìn)行，從而對 Web 服務(wù)的調(diào)用進(jìn)行格式化。我們在設(shè)計時和運行時可以使用各種工具從 WSDL 文檔生成編程語言綁定。這些綁定表示應(yīng)用程序的 API，并封裝了來自應(yīng)用程序的 XML 消息傳遞的細(xì)節(jié)。

在下一部分，我們將描述基本 Web 服務(wù)體系結(jié)構(gòu)的擴(kuò)展，電子商務(wù)需要這些擴(kuò)展才能使用 Web 服務(wù)。

在下一部分，我們將描述基本 Web 服務(wù)體系結(jié)構(gòu)的擴(kuò)展，電子商務(wù)需要這些擴(kuò)展才能使用 Web 服務(wù)。

14.3.2 真正的電子商務(wù)的 Web 服務(wù)

雖然對于可互操作的 XML 消息傳遞來說 SOAP 和 HTTP 就足夠了，而且 WSDL 也足可以傳達(dá)服務(wù)請求者和服務(wù)提供者之間需要什么樣的消息，但是要覆蓋電子商務(wù)的全部需求還需要更多的技術(shù)。為了完全支持電子商務(wù)，安全性、可靠的消息傳遞、服務(wù)質(zhì)量、Web 服務(wù)協(xié)議棧的每一層的管理都需要擴(kuò)展。

安全性

真的需要 Web 服務(wù)安全層嗎？對于基于消息的體系結(jié)構(gòu)，業(yè)界已經(jīng)有一套現(xiàn)成的而且廣泛接受的傳輸層安全機(jī)制，比如，安全套接字層（Secure Sockets Layer，SSL）和網(wǎng)際協(xié)議安全（Internet Protocol Security，IPSec），為什么還要再加別的呢？為了回答這個問題，我們不僅要研究要求，還將探討一些只依靠現(xiàn)有的幾類傳輸層安全機(jī)制并不能在 Web 服務(wù)模型內(nèi)提供足夠的安全性的情況。

通常，Web 服務(wù)安全層必須提供以下四個基本的安全性要求：

機(jī)密性（Confidentiality）是指信息對沒有經(jīng)過授權(quán)的個人、實體或進(jìn)程的不可用性或不公開性，并保證消息內(nèi)容不對沒有經(jīng)過授權(quán)的個人公開。 
授權(quán)（Authorization）是指權(quán)限的授予，包括根據(jù)訪問權(quán)限授予訪問權(quán)和保證發(fā)送方被授權(quán)發(fā)送消息。 
數(shù)據(jù)完整性（Data integrity）是指數(shù)據(jù)沒有以未經(jīng)授權(quán)的方式或被未經(jīng)授權(quán)的用戶不可察覺的改變或者破壞的性質(zhì)，從而確保消息在傳送的過程中不會被偶然或故意修改。 
原始性證明（Proof of origin）是對消息或數(shù)據(jù)的發(fā)送者進(jìn)行標(biāo)識的證據(jù)。斷言消息由正確標(biāo)識的發(fā)送者傳送，并且不會重新發(fā)送以前傳送過的消息。這一要求隱含了數(shù)據(jù)完整性的要求。 
由于需要在基于 XML 消息和工作流的動態(tài) Web 服務(wù)世界中管理不同風(fēng)格的資源訪問，所以必須重新評估策略、信任和風(fēng)險評估這三者相互之間的關(guān)系。現(xiàn)有的基于個人身份的訪問控制模型正在發(fā)展成為基于角色的信任域關(guān)系，在該種關(guān)系中，可信任的權(quán)威機(jī)構(gòu)將執(zhí)行某項任務(wù)的權(quán)限授予個人，其行為受該權(quán)限限制。Web 服務(wù)體系結(jié)構(gòu)定義了需要信息的代理（服務(wù)請求者）、提供信息的代理（服務(wù)提供者），有時還有提供關(guān)于信息的信息的代理（服務(wù)中介者、元信息提供者或服務(wù)注冊中心）。服務(wù)中介者經(jīng)常會收到大量信息請求，這樣就需要它能夠決定誰想要哪些信息以及請求者是不是已經(jīng)被授予訪問權(quán)?；A(chǔ)設(shè)施和關(guān)系變化迅速，因此有關(guān)的策略需要能靈活的允許或拒絕訪問。

此外，盡管 XML 發(fā)誓要為這樣的服務(wù)提供通用接口，但 XML 不會提供實現(xiàn)這一夢想所需要的整個基礎(chǔ)設(shè)施。而且，XML 可能不適合構(gòu)建整個 Web 服務(wù)安全層。目標(biāo)是要確定在哪些場合用 XML 格式提供信息以顧及通用數(shù)據(jù)交換較為重要，以及在哪些場合利用目前已存在于平臺之上的現(xiàn)有安全性機(jī)制較為重要。

SOAP 信封是用 XML 定義的，從而使您可以向消息添加種類眾多的元信息，比如事務(wù) ID、消息路由信息和消息安全性。SOAP 信封由兩個部分組成：頭和主體。頭是把功能添加到 SOAP 消息中的通用機(jī)制。SOAP 頭元素下一級的所有子元素都叫做頭條目。主體是為最終的消息接收方想要的應(yīng)用數(shù)據(jù)（如 RPC）準(zhǔn)備的容器。因此，可以把 SOAP 看作是在傳輸層（例如 HTTP）和應(yīng)用層（例如，業(yè)務(wù)數(shù)據(jù)）之間引入的另外一層，在此可以方便的傳送消息元信息。SOAP 頭提供可擴(kuò)展機(jī)制以擴(kuò)展 SOAP 消息使其可以適用于多種用途。雖然 SOAP 頭是向消息添加安全性功能最合理的地方，但是 SOAP 規(guī)范本身并沒有指定這樣的頭元素。

讓我們仔細(xì)的分析一下在 Web 服務(wù)模型中現(xiàn)有的各種各樣的傳輸層安全機(jī)制為什么不夠，又為什么會需要 Web 服務(wù)安全層，以及這個安全層最初是怎樣的。

端對端的消息傳遞。安全傳輸協(xié)議，如 SSL 和 IPSec，可以在傳輸過程中提供消息完整性和機(jī)密性，但只有在點對點的情況下，它們才會這樣做。但是，因為 SOAP 消息是由中介體接收并處理的，所以即便兩兩之間的通信鏈路（communication link）是可信任的，只要在所有的中介體間沒有信任關(guān)聯(lián)（trust association），那么安全的端對端通信就是不可能的。如果有一條通信鏈路不安全，那么端對端安全性也會被削弱。就 Web 服務(wù)拓?fù)鋪砜?，安全的傳輸對?SOAP 消息的端對端安全性是不夠的。

中間件的獨立性。最終，唯一能提供端對端安全性的方式就在于應(yīng)用層或中間件層。如果消息在通信方之間的某點是純文本，那么就有可能在這點受到攻擊。但是，既要在新的或現(xiàn)有的應(yīng)用中集成加密功能，又不能引入額外的安全性弱點或增加風(fēng)險，這是一項不容易又不受歡迎的任務(wù)。因此，在大多數(shù)情況下，人們希望安全性功能盡可能靠近應(yīng)用，但不在應(yīng)用本身中構(gòu)建。

傳輸?shù)莫毩⑿?。SOAP 中介體的原意是用來把信息轉(zhuǎn)發(fā)到不同的網(wǎng)絡(luò)上去，通常使用的傳輸協(xié)議也會有所不同。雖然所有的通信鏈路都是安全的，中介體也是值得信賴的，但是，安全信息（如消息發(fā)送者的身份驗證）需要被轉(zhuǎn)移到消息路徑上的下一個傳輸協(xié)議安全性域，這個過程冗長而且復(fù)雜，還可能會導(dǎo)致完整性方面的缺陷。

異步多階消息傳遞。傳輸層安全性保證數(shù)據(jù)在通信鏈路上傳輸時的安全。它與存儲在任何中介體上的數(shù)據(jù)都無關(guān)。在一次傳輸被接收并解密后，傳輸層安全性對保護(hù)數(shù)據(jù)免受沒有經(jīng)過授權(quán)的訪問和可能的改變就不是很有幫助了。在先存儲消息然后轉(zhuǎn)發(fā)的情況下（持久的消息隊列），消息層保護(hù)是有必要的。

因為我們已經(jīng)看到安全的傳輸機(jī)制不足以滿足 Web 服務(wù)開發(fā)方法和使用場景的要求，所以我們的任務(wù)就是要創(chuàng)建一個概念性 Web 安全層，包括下列幾個組件：

對于網(wǎng)絡(luò)安全性： 
支持如 SSL 和 HTTPS 等提供機(jī)密性和完整性的安全傳輸機(jī)制。 
對于 XML 消息： 
如果通信沒有中間節(jié)點，那么發(fā)送方可以依靠 SSL 或 HTTPS 來保證用戶標(biāo)識和密碼的機(jī)密性。 
W3C 正在標(biāo)準(zhǔn)化 XML 數(shù)字簽名工作的支持。它定義了生成消息摘要與利用發(fā)送方的私鑰來簽發(fā)消息的標(biāo)準(zhǔn) SOAP 頭和算法。因此，接收方就可以證明消息發(fā)送方的身份。 
對網(wǎng)絡(luò)內(nèi)部的、可信任的第三方驗證服務(wù)（例如 Kerberos）的支持。 
概念性 XML 消息傳遞模型還必須支持端對端保護(hù)消息及其子元素。為了全面的支持，過程和流能力需要被擴(kuò)展到包括消息交換的安全性特征。應(yīng)該有一種方式可以定義多段消息和用預(yù)期接收方的公鑰來保護(hù)消息段。需要探討的一些論題有：

端點負(fù)責(zé)實現(xiàn)驗證及授權(quán)。應(yīng)該支持在企業(yè)之間交換信息的合同的任何描述中都要定義哪些雇員可以使用哪些服務(wù)。中介體負(fù)責(zé)審計和服務(wù)原始性證明。中介體還可能需要執(zhí)行驗證、授權(quán)和數(shù)字簽名驗證以及有效性檢查。 
在服務(wù)端點的服務(wù)描述層中需要定義支持上文論述的安全性問題的面向安全性元數(shù)據(jù)。這些安全性描述將根據(jù)主體或角色定義 Web 服務(wù)層訪問控制。服務(wù)描述將會描述是否支持?jǐn)?shù)字簽名、加密、驗證和授權(quán)以及如何支持它們。 
請求者將使用服務(wù)描述的安全性元素來查找服務(wù)端點，該端點應(yīng)符合政策要求及其安全性方法。 
標(biāo)準(zhǔn)組正在調(diào)查如下主題和技術(shù)。隨著這些標(biāo)準(zhǔn)固定下來，它們將會被并入 Web 服務(wù)安全性體系結(jié)構(gòu)。

W3C 有一個 XML 加密工作組，幫助提供數(shù)據(jù)元素的機(jī)密性，這樣驗證交換成為可能。 
W3C 已發(fā)布了一個 XML 密鑰管理服務(wù)（XML Key Management Services，XKMS）的備忘錄，來幫助分發(fā)及管理在端點之間進(jìn)行安全的通信所需的密鑰。 
OASIS 已經(jīng)成立了一個技術(shù)委員會來定義授權(quán)和驗證斷言（Authorization and Authentication assertions，SAML）。這將幫助端點接受和決斷訪問控制權(quán)。 
OASIS 已經(jīng)成立了一個技術(shù)委員會來標(biāo)準(zhǔn)化訪問控制權(quán)的表達(dá)（XACML）。這將幫助端點能夠以一致的方式解析 SAML 斷言。 
隨著我們不斷的研究 Web 服務(wù)模型中遇到的所有威脅和對策，Web 服務(wù)安全性體系結(jié)構(gòu)也在不斷發(fā)展著。

服務(wù)質(zhì)量（QoS）和可靠的消息傳遞

服務(wù)質(zhì)量垂直塔提供與 Web 服務(wù)概念棧每一層有關(guān)的信息的規(guī)范。對于網(wǎng)絡(luò)層，這將會暗示能使用各種級別的服務(wù)質(zhì)量的網(wǎng)絡(luò)。

由于需要通過網(wǎng)絡(luò)進(jìn)行可靠的消息傳遞，所以得根據(jù)在這一領(lǐng)域內(nèi)發(fā)送高質(zhì)量服務(wù)的能力來選擇網(wǎng)絡(luò)技術(shù)。可靠的消息傳遞指基礎(chǔ)設(shè)施把消息一次發(fā)送（只發(fā)送一次）到預(yù)定目標(biāo)或提供確定的事件（如果發(fā)送沒能完成，也許會重新發(fā)送到源）的能力。結(jié)合網(wǎng)絡(luò)層與 XML 消息傳遞將需要支持四個等級的消息傳遞服務(wù)質(zhì)量：

1. 最佳努力：服務(wù)請求者發(fā)送消息，服務(wù)請求者和基礎(chǔ)設(shè)施不嘗試重發(fā)。

2. 至少一次：服務(wù)請求者提出請求，并一直重試直到它接收到確認(rèn)為止。服務(wù)提供者重復(fù)消息處理不是問題，例如簡單的查詢處理。實現(xiàn)這可能意味著每個消息包含唯一的標(biāo)識。服務(wù)請求者以自己確定的時間間隔重發(fā)沒有得到確認(rèn)的消息。服務(wù)提供者發(fā)出確認(rèn)消息，為 RPC 響應(yīng)消息，如果不能處理的話，就發(fā)送不能處理的消息異常。

3. 至多一次：這建立在最少一次情況的基礎(chǔ)之上。服務(wù)請求者試著請求直到它得到回應(yīng)。象現(xiàn)有的全局唯一標(biāo)識符（universal unique identifier，UUID）這樣的機(jī)制允許服務(wù)提供者抑制重復(fù)多次的請求，以確保請求不會被多次執(zhí)行。例如，請求根據(jù)庫存目錄中的一個號碼拿一件東西。

4. 剛好一次：服務(wù)請求者提出請求，請求已經(jīng)執(zhí)行的回應(yīng)使其得到保證。剛好一次交換模式排除了重傳請求的需要并且適應(yīng)失效的情況。

可靠的消息傳遞通常是通過標(biāo)準(zhǔn)設(shè)計模式傳送的，在該模式中，一件基礎(chǔ)設(shè)施，有時叫做端點管理器，將會被用來在通信的每一端協(xié)調(diào)消息發(fā)送。在這種模式中，發(fā)送方通過同步請求把消息發(fā)給端點管理器。一旦發(fā)送到，發(fā)送方就可以得到保證，一定會把消息發(fā)送出去或引發(fā)確定的事件（例如超時）。端點管理器與其它資源管理器參與本地事務(wù)，在一次事務(wù)中不僅可以由端點管理器對消息進(jìn)行排隊，還有可能在數(shù)據(jù)庫中記錄業(yè)務(wù)過程步驟。應(yīng)用程序應(yīng)該指派端點管理器來負(fù)責(zé)發(fā)送消息或者檢測發(fā)送失敗的原因，它在網(wǎng)絡(luò)傳輸層或 XML 消息傳遞層都可以起作用。

可靠的一次性消息發(fā)送的技術(shù)和目的都不會引起爭議。但是，圍繞如何在 SOAP 和 XML 的上下文中支持這項技術(shù)已經(jīng)提出了重要的質(zhì)疑。關(guān)鍵問題是：應(yīng)不應(yīng)該在 XML 消息層上定義必要的協(xié)議和消息格式，從而允許可靠的消息發(fā)送成為兩端應(yīng)用程序的責(zé)任，或者能不能在較低的層（如傳輸層上）定義協(xié)議和消息格式？

在沒有支持可靠的消息傳遞的傳輸方式的情況下（即互聯(lián)網(wǎng)），XML 消息傳遞層將需要在不可靠的基礎(chǔ)設(shè)施之上支持這些服務(wù)質(zhì)量。端點管理器將需要修改消息，而不是修改消息的傳輸信封，這樣才能成功扮演其角色。應(yīng)用程序和業(yè)務(wù)過程的定義將必須考慮所有可能的結(jié)果，如拒收消息或在可接受的時間長度內(nèi)發(fā)送不出去。但是，這些定義還需要考慮在發(fā)送過程中發(fā)生的中間狀態(tài)。向業(yè)務(wù)過程公開這些狀態(tài)可能會大大增加其定義的復(fù)雜程度，但對于定義過程的業(yè)務(wù)分析師而言并無太大意義。在一些情況下，使用 XML 消息傳遞來發(fā)送可靠的消息傳遞格式可能會導(dǎo)致使用現(xiàn)有的這些傳輸毫無效率。最好能開發(fā)一種在互聯(lián)網(wǎng)上使用的可靠的 HTTP 標(biāo)準(zhǔn)。

在有支持可靠的消息傳遞的傳輸方式的情況下（即在企業(yè)內(nèi)部），它可以用于發(fā)送可靠的消息，而不是 XML 消息傳遞層（可能缺省為空實現(xiàn)）。端點管理器將會只修改傳輸信封，而不會修改 XML 消息。使用可靠的傳輸使應(yīng)用程序和業(yè)務(wù)過程定義不需要知道或處理消息發(fā)送的中間狀態(tài)。

需要在將來進(jìn)行的幾點補充：

互聯(lián)網(wǎng)的 HTTP 需要加以改進(jìn)才能提供可以在企業(yè)間使用的簡單可靠的消息傳遞。這會帶來額外的好處：不止 SOAP，許多種消息類型都可以采用可靠的消息傳遞。需要 XML 消息傳遞層處理可靠的消息傳遞的情況就會隨之減少，促進(jìn)不依賴于網(wǎng)絡(luò)選擇的應(yīng)用程序開發(fā)。 
HTTP 上的 XML 消息傳遞層也需要處理發(fā)布和訂閱、消息排序、發(fā)送時間限制、優(yōu)先級和多點傳送等等問題。 
服務(wù)提供者對可靠的消息傳遞的質(zhì)量和實現(xiàn)的支持情況將會在服務(wù)描述的綁定信息中定義。

服務(wù)實現(xiàn)層（例如，通過事務(wù)的或安全的 SOAP 綁定）的服務(wù)描述以及接口層（例如，從請求者開始等待來自提供者的響應(yīng)之后最長經(jīng)過多久）的其它服務(wù)描述中都會關(guān)系到服務(wù)質(zhì)量（Quality of Service）信息。人們期待著開發(fā)出 WSDL 擴(kuò)展或新的服務(wù)描述層來允許指定其它服務(wù)質(zhì)量和功能的規(guī)范。

Web 服務(wù)層上的服務(wù)質(zhì)量可以在服務(wù)合成和服務(wù)流中使用。在為流選擇服務(wù)或提示流管理器該開始恢復(fù)或其它的流時，預(yù)期的執(zhí)行時間、超時值、歷史平均執(zhí)行時間值都可以作為輸入。服務(wù)描述棧的端點描述層和工作流描述層必須提供這一信息。

Web 服務(wù)的服務(wù)質(zhì)量問題和解決方案仍然很緊迫。

系統(tǒng)和應(yīng)用程序管理(Management)

隨著 Web 服務(wù)成為商業(yè)運作的重要因素，就需要對其進(jìn)行管理。在這種情況下，所謂管理是指專為應(yīng)用程序定制的或從廠商那里買來的管理應(yīng)用程序可以發(fā)現(xiàn) Web 服務(wù)的基礎(chǔ)設(shè)施、Web 服務(wù)、服務(wù)注冊中心和 Web 服務(wù)應(yīng)用程序存在性、可用性以及健康度。最令人滿意的結(jié)果是管理系統(tǒng)還應(yīng)當(dāng)能夠控制和配置基礎(chǔ)設(shè)施及組件。

管理概念性 Web 服務(wù)棧各層的 Web 服務(wù)和 Web 服務(wù)模型組件必定是有可能的。對管理的需求可以分成兩個集中的領(lǐng)域。第一個領(lǐng)域是用于實現(xiàn) Web 服務(wù)的基礎(chǔ)設(shè)施的可管理性。主要的考慮應(yīng)當(dāng)是確?？捎眯院吞峁┓?wù)描述、消息傳遞和網(wǎng)絡(luò)的關(guān)鍵元素的性能。Web 服務(wù)基礎(chǔ)設(shè)施提供者應(yīng)當(dāng)提供這一層上的系統(tǒng)管理。

企業(yè)對其自己的基礎(chǔ)設(shè)施及管理擁有完全的自主權(quán)。但是，當(dāng)企業(yè)在對等基礎(chǔ)上相互作用時，就應(yīng)當(dāng)提供對網(wǎng)絡(luò)層、XML 消息傳遞層、服務(wù)注冊中心和 Web 服務(wù)實現(xiàn)的基本報告和恢復(fù)辦法。此外，企業(yè)向其合伙人提供的管理接口應(yīng)當(dāng)是在服務(wù)層上操作的，而不是在相對低級的基礎(chǔ)設(shè)施層上。合伙人應(yīng)該能夠訪問到報告操作和請求處理的狀態(tài)和健康度的接口，但不一定要理解企業(yè)如何管理其請求的細(xì)節(jié)。

對于網(wǎng)絡(luò)層，現(xiàn)有的網(wǎng)絡(luò)管理產(chǎn)品幾乎支持目前所有的網(wǎng)絡(luò)基礎(chǔ)設(shè)施。這些產(chǎn)品應(yīng)當(dāng)用于管理企業(yè)內(nèi)部的 Web 服務(wù)的網(wǎng)絡(luò)基礎(chǔ)設(shè)施。當(dāng)企業(yè)相互作用時，就應(yīng)該向其合伙人提供有關(guān) Web 服務(wù)基礎(chǔ)設(shè)施可用性的基本報告。影響 Web 服務(wù)基礎(chǔ)設(shè)施可用性的網(wǎng)絡(luò)可用性應(yīng)作為因素之一寫入報告。

在 XML 消息傳遞層，協(xié)議應(yīng)該在企業(yè)內(nèi)部由現(xiàn)有的基礎(chǔ)設(shè)施管理工具來管理。在企業(yè)相互作用的情況下，每個站點都有必要提供協(xié)議的基本報告和恢復(fù)辦法。例如，如果站點 A 支持會話，就該向站點 B 提供可用于查詢活躍的 IBM Software Group Architecture Overview Web Services Conceptual Architecture 28 會話以及強(qiáng)行回滾的接口。協(xié)議層需要正常的頻道與協(xié)議和類似對等的控制接口。

管理的第二個方面是 Web 服務(wù)本身的可管理性。一些主要的考慮是性能、可用性、事件和使用量度，因為它們將為服務(wù)提供者市場收取所提供的服務(wù)使用費提供必要信息。

服務(wù)描述可以用于宣傳可管理性特征和管理需求。這方面的約定正在開發(fā)之中。

服務(wù)注冊中心的任何實現(xiàn)，不管是用于私人消費還是公共消費，都要求基礎(chǔ)設(shè)施是可用的、發(fā)送承諾的服務(wù)質(zhì)量并能夠報告使用情況。這些系統(tǒng)管理元素對于成功采用 UDDI 是十分重要的。

對于 Web 服務(wù)應(yīng)用程序組件來說，支持管理環(huán)境可能會大大增加應(yīng)用程序的復(fù)雜性。由于 Web 服務(wù)必須易于開發(fā)，所以必須盡可能向開發(fā)者隱藏這樣的復(fù)雜性。Web 服務(wù)的管理方式要使基礎(chǔ)設(shè)施能自動提供量度、審計日志、啟動和停止處理過程、事件通知和作為 Web 服務(wù)運行時的一部分（也就是說，起碼是 SOAP 服務(wù)器）的其它管理功能。因為基礎(chǔ)設(shè)施通過觀察它所托管的組件的行為不可能收集到所有的信息，所以 Web 服務(wù)實現(xiàn)也許會需要向托管它的服務(wù)器提供基本的健康度和監(jiān)督信息。

Web 服務(wù)基礎(chǔ)設(shè)施應(yīng)該為服務(wù)提供一種簡單的方式以參與管理和利用管理基礎(chǔ)設(shè)施。可管理的服務(wù)的 WSDL 文檔的定義應(yīng)當(dāng)是 Web 服務(wù)能實現(xiàn)提供通過管理系統(tǒng)訪問 Web 服務(wù)的管理信息的功能。這一接口可能包括的能力是獲得配置和量度數(shù)據(jù)、更新配置及接收來自可管理的 Web 服務(wù)的事件。

Web 服務(wù)體系結(jié)構(gòu)的平臺獨立性使它不適合套用任何一條 Web 服務(wù)管理標(biāo)準(zhǔn)。因此，需要有一種基于 Web 服務(wù)而且允許 Web 服務(wù)與管理系統(tǒng)通信的方法。為了達(dá)到這一目的，還應(yīng)當(dāng)定義由 WSDL 文檔描述的、可接收來自可管理 Web 服務(wù)的事件以及量度更新的管理服務(wù)，并使其可用。管理服務(wù)的實現(xiàn)技術(shù)與 Web 服務(wù)無關(guān)。但是，對于基于 Java 技術(shù)的環(huán)境，Java 管理擴(kuò)展（Java Management Extension，JMX）應(yīng)該是合乎邏輯的而且廠商不可知的選擇。通過使用 JMX 這樣的開放標(biāo)準(zhǔn)，對現(xiàn)有的系統(tǒng)管理提供者來說，要把其目前所提供的產(chǎn)品擴(kuò)展為包括 Web 服務(wù)關(guān)鍵元素的管理應(yīng)該是很容易的。Web 服務(wù)的管理體系結(jié)構(gòu)仍在向前發(fā)展。

14.4 Web Services 項目實戰(zhàn)

14．4．1 Web Services實現(xiàn)

本書是重點講解EJB 3.0的。在理解了Web Services原理之后， 接下來我們講解如何使用J2EE和EJB3.0來實現(xiàn)Web Services

Web 服務(wù)遵循 Java 2 平臺，企業(yè)版（Java 2 Platform，Enterprise Edition，J2EE）、通用對象請求代理體系結(jié)構(gòu)（Common Object Request Broker Architecture，CORBA）以及其它針對與耦合較緊的分布式或非分布式應(yīng)用程序集成的標(biāo)準(zhǔn)。Web 服務(wù)是部署并提供通過 Web 訪問業(yè)務(wù)功能的技術(shù)；J2EE、CORBA 和其它標(biāo)準(zhǔn)是實現(xiàn) Web 服務(wù)的技術(shù)。

J2EE 1.4為使用常規(guī)Java類或企業(yè)級Java Beans來創(chuàng)建和部署web services提供了一個全面的平臺。以下表格給出了J2EE 1.4中包括的web service APIs的細(xì)節(jié)。 

定義在Java Community Process的JSR 101之下的JAX-RPC，提供了創(chuàng)建和訪問web services的Java API,因此它是使用J2EE平臺創(chuàng)建和部署web services的“心臟和靈魂”。通過向應(yīng)用程序開發(fā)者隱藏XML類型和Java類型映射的復(fù)雜性，以及處理XML和SOAP消息的底層細(xì)節(jié)，它提供了一個簡單的，健壯的創(chuàng)建web services應(yīng)用的平臺。為了引入一個方法調(diào)用范式，它提供了兩種編程模式:服務(wù)器端模式，使用Java類或無狀態(tài)EJB開發(fā)web service 端點，和客戶端模式，創(chuàng)建作為本地對象訪問web services的Java客戶端。JAX-RPC 1.1要求使用SOAP 1.1，并且實現(xiàn)與使用其他技術(shù)創(chuàng)建的web services之間的互操作性，比如微軟的.NET。實現(xiàn)了J2EE1.4規(guī)范的應(yīng)用服務(wù)器，比如OC4J 10.1.3和SUN的Java System Application Sever,提供了對于JAX-RPC的支持。

JAX-RPC的叫法有點用詞不當(dāng)，因為它既支持RPC類型的web services，也支持文檔類型的web services。

Web Services部署模型

在J2EE 1.4之前，所有J2EE商家都使用他們私有的部署模型支持web services。J2EE 1.4為Java Web Services定義了部署模型。它為J2EE平臺上的web services制定了開發(fā)，部署以及服務(wù)發(fā)布和使用的標(biāo)準(zhǔn)。

有了J2EE 1.4對web services的支持，讓我們學(xué)習(xí)使用J2EE平臺來建造web service的方法。

使用J2EE創(chuàng)建一個Web Service

把web service創(chuàng)建成一個輕便的和可互操作的分布式組件不是一項瑣碎的任務(wù)。如之前討論的，你既可以把常規(guī)Java類，也可以把無狀態(tài)EJB部署成web services。常規(guī)Java類被打包在一個web模塊中，而EJB web services被打包在標(biāo)準(zhǔn)的ejb-jar模塊中。

在這兩種部署選擇中，你會使用哪一個呢?

Java 類對無狀態(tài)EJB:永無止境的爭論

你會選擇常規(guī)Java類還是EJB作為你創(chuàng)建web service的技術(shù)可能是一個長期的爭論。Java類比EJB更容易開發(fā)，它是純的Java對象，并且它不具有EJB帶來的“額外輜重”。但是，EJB提供了幾個很好的特點，比如被聲明的事務(wù)和安全性，因此它使開發(fā)者將精力集中于建立商業(yè)邏輯，而不需要擔(dān)心基礎(chǔ)服務(wù)架構(gòu)。EJB 3.0大大簡化了設(shè)計模型，在它的規(guī)范中，EJB看起來就像常規(guī)Java類。

使用J2EE 5.0簡化SOA的開發(fā)

　　使用J2EE創(chuàng)建面向服務(wù)的應(yīng)用程序確實很困難，因此通過使用由JSR 181定義的Web Services 元數(shù)據(jù)注解，J2EE 5.0將使開發(fā)更簡單。EJB 3.0和Web Services元數(shù)據(jù)具有相似的目標(biāo)，就是向開發(fā)者提供親和力。

　　為了在J2EE 1.4中開發(fā)一個簡單的Java web service，你需要幾個web service定義文件:WSDL，映射文件和幾個冗長的標(biāo)準(zhǔn)以及私有的web services部署描述符。Web Services元數(shù)據(jù)規(guī)范使用一種類似于EJB 3.0的缺省配置方法來使開發(fā)更簡便。Web Services元數(shù)據(jù)注解處理器(或web services 裝配工具)會為你生成這些文件，因此你只需要關(guān)心類的實現(xiàn)。

　　當(dāng)你使用Web Services元數(shù)據(jù)開發(fā)時，這是一個看起來如此簡單的Java web service:

package com.ascenttech.ejb30.ws.demo; 
import javax.jws.WebMethod; 
import javax.jws.WebService; 
@WebService(name = "HelloWorldService", 
targetNamespace = "http://hello/targetNamespace" ) 
public class HelloWorldService { 
@WebMethod public String sayhello(String name ) { 
return "Hello” +name+ “ from jws";
} 
}

　　正如我之前提到的，EJB 3.0使用常規(guī)Java類簡化了EJB的開發(fā)。通過利用EJB 3.0和Web Services元數(shù)據(jù)，開發(fā)基于EJB的web services將會變得越來越簡單。當(dāng)使用EJB 3.0和web services元數(shù)據(jù)時，這是一個看起來如此簡單的HelloWorld EJB web service。你不必?fù)?dān)心創(chuàng)建WSDL，部署描述符等等，應(yīng)用服務(wù)器會在部署過程中生成這些定義文件。

package com.ascenttech.ejb30.ws;
import javax.ejb.Remote;
import javax.jws.WebService;
@WebService 
public interface HelloServiceInf extends java.rmi.Remote{
@WebMethod java.lang.String sayHello(java.lang.String name) 
throws java.rmi.RemoteException;
}

　　如下是EJB 3.0中 HelloWorld EJB的實現(xiàn)類:

package com.ascenttech.ejb30.ws;
import java.rmi.RemoteException;
import javax.ejb.Stateless;
@Stateless(name="HelloServiceEJB")
public class HelloServiceBean implements HelloServiceInf {
public String sayHello(String name) {
return("Hello "+name +" from first EJB3.0 Web Service");
}
}

　　以上例子清楚的表明了通過使用web services元數(shù)據(jù)和EJB 3.0，服務(wù)開發(fā)正在變得越來越簡單?，F(xiàn)在，你可以在實現(xiàn)了J2EE規(guī)范的應(yīng)用服務(wù)中，比如JBoss Application Server等，開始創(chuàng)建和部署你的web services了。

14.4．2 Web Services 項目實戰(zhàn)

14.4.2.1 Web Services的實現(xiàn)
本節(jié)使用EJB 3.0 實現(xiàn)一個web Services登錄的例子。下面我們創(chuàng)建一個工程叫：EmployeeManager。加入用到的EJB 3.0的jar包。

我們先創(chuàng)建服務(wù)器端的實體Bean，這和創(chuàng)建普通的Ejb3.0實體bean是一樣的：

package com.ascent.ejb.po;

import java.io.Serializable;

import javax.ejb.Remote;

import javax.ejb.Stateless;

import javax.persistence.Column;

import javax.persistence.Entity;

import javax.persistence.GeneratedValue;

import javax.persistence.Id;

import javax.persistence.Table;

@SuppressWarnings("serial")

@Entity

@Table(name = "usr")

public class User implements Serializable

{

private Integer id;

private String name;

private String password;

private String description;

@Id

@GeneratedValue

public Integer getId()

{

return id;

}

public void setId(Integer id)

{

this.id = id;

}

@Column(name = "name", nullable = false)

public String getName()

{

return name;

}

public void setName(String name)

{

this.name = name;

}

@Column(name = "password", nullable = false)

public String getPassword()

{

return password;

}

public void setPassword(String password)

{

this.password = password;

}

@Column(name = "description", nullable = true, length = 100)

public String getDescription()

{

return description;

}

public void setDescription(String description)

{

this.description = description;

}

}

接著創(chuàng)建遠(yuǎn)程接口：

package com.ascent.webservice.bean;

import java.rmi.Remote;

import javax.jws.WebMethod;

import javax.jws.WebService;

import javax.jws.soap.SOAPBinding;

import javax.jws.soap.SOAPBinding.Style;

@WebService

@SOAPBinding(style=Style.RPC)

public interface LoginDao extends Remote {

@WebMethod

public boolean isLogin(String name, String password);

}

在LoginDao類中要注意的是Remote接口是要實現(xiàn)的，@SOAPBinding(style=Style.RPC)，Soap的綁定方式也是需要的，不然在客戶端是找不到LoginDao 。

下面創(chuàng)建會話bean：

package com.ascent.webservice.bean;

import java.util.List;

import javax.ejb.Stateful;

import javax.ejb.Stateless;

import javax.jws.WebService;

import javax.persistence.EntityManager;

import javax.persistence.PersistenceContext;

import javax.persistence.Query;

@Stateless

@WebService(endpointInterface = "com.ascent.webservice.bean.LoginDao")

public class LoginDaoBean

{

@PersistenceContext

protected EntityManager em;// the manager of entity

public boolean isLogin(String name, String password)

{

// define query sentence

StringBuffer hql = new StringBuffer();

hql.append("from User u where u.name='" + name + "'");

hql.append(" and u.password='" + password + "'");

// create the query

Query query = em.createQuery(hql.toString());

List queryList = query.getResultList();

// if the result is null

if (queryList.size() == 0)

{

return false;

}

// if the user's length greater 1

if (queryList.size() > 1)

{

return false;

}

// return single user

return true;

}

}

至此服務(wù)器端的類是建好了，這里又兩個問題，需要說明一下

A． 兩個類的方法中都沒有拋出異常，可不可以拋出呢? 可以。但到實現(xiàn)SOA的時候會有一些問題，就是異常在經(jīng)axis 通過WSDL2Java 生成后，在程序運行時有可能會出現(xiàn)找不到的情形。所以本文為了讓大家在仿照這個例子時都能成功，所以也就拋棄了異常的拋出。

B． 兩個類的方法的返回值是基本類型，而不是自定義類型，為什么會這樣呢，自定義類型可以不可以呢，可以。

現(xiàn)在我們的webservice的服務(wù)器端就已經(jīng)創(chuàng)建好了，我們把服務(wù)器端的三個類和persistence.xml文件一起打包部署到j(luò)boss服務(wù)器里。包名是：empdEjb。

下面我們來創(chuàng)建客戶端：

package com.ascent.webservice.client;

import java.net.URL;

import javax.xml.namespace.QName;

import javax.xml.rpc.Service;

import javax.xml.rpc.ServiceFactory;

import com.ascent.webservice.bean.LoginDao;

public class LoginClient

{

public static void main(String[] args) throws Exception

{

String userName ="lxl";

String password = "lxl";

URL url = new URL("http://localhost:8080/empdEjb/LoginDaoBean?wsdl");

QName qname =

new QName("http://bean.webservice.ascent.com/jaws","LoginDaoService");

ServiceFactory factory = ServiceFactory.newInstance();

Service service = factory.createService(url, qname);

LoginDao loginDao = (LoginDao) service.getPort(LoginDao.class);

boolean isExists = loginDao.isLogin(userName, password);

if(isExists)

{

System.out.println("hello " + userName);

}

else

{

System.out.println("sorry " + userName + ", you are not user in the system!");

}

}

}

把服務(wù)器端發(fā)布出去以后，服務(wù)器端會自動發(fā)布一個webService，并且生成并發(fā)布一個WSDL文件，通過訪問http://localhost:8080/empdEjb/LoginDaoBean?wsdl這個網(wǎng)址是可以找到的。http://bean.webservice.ascent.com/jaws 和 LoginDaoService 字符串，在客戶端程序當(dāng)中出現(xiàn)了上面兩個字符串，它們在你生成的wsdl 文件中有詳細(xì)的描述。在地址欄里輸入http://localhost:8080/empdEjb/LoginDaoBean?wsdl，就可以看到wsdl文件了。這里你所需要做的是按照你自己的情況編寫你自己的客戶端程序。啟動服務(wù)器后，在機(jī)子上運行客戶端程序就可以了。當(dāng)然你也可以去編寫自己的jsp客戶端去調(diào)用它。wsdl文件的內(nèi)容如下：

<definitions name="LoginDaoService"

targetNamespace="http://bean.webservice.ascent.com/jaws">

<types/>

<message name="LoginDao_isLogin">

<part name="String_1" type="xsd:string"/>

<part name="String_2" type="xsd:string"/>

</message>

-

<message name="LoginDao_isLoginResponse">

<part name="result" type="xsd:boolean"/>

</message>

-

<portType name="LoginDao">

-

<operation name="isLogin" parameterOrder="String_1 String_2">

<input message="tns:LoginDao_isLogin"/>

<output message="tns:LoginDao_isLoginResponse"/>

</operation>

</portType>

-

<binding name="LoginDaoBinding" type="tns:LoginDao">

<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>

-

<operation name="isLogin">

<soap:operation soapAction=""/>

-

<input>

<soap:body namespace="http://bean.webservice.ascent.com/jaws" use="literal"/>

</input>

-

<output>

<soap:body namespace="http://bean.webservice.ascent.com/jaws" use="literal"/>

</output>

</operation>

</binding>

-

<service name="LoginDaoService">

-

<port binding="tns:LoginDaoBinding" name="LoginDaoPort">

<soap:address location="http://lixinli:8080/empdEjb/LoginDaoBean"/>

</port>

</service>

</definitions>

這樣一個WebService+Ejb 3.0的例子就實現(xiàn)了。

14.4.2.2 SOA的實現(xiàn)
本例還是基于前兩個例子的基礎(chǔ)上的，要保證上面的例子是能正常運行的。

1.WSDL2Java
從名字上可以看出，是把wsdl 轉(zhuǎn)化為java的.在上面的例子中我們在服務(wù)器端生成了一個wsdl文件，現(xiàn)在要做的就是你把那個wsdl文件給別人或者別的公司，讓他們根據(jù)wsdl中所描述的你所提供的服務(wù)，去開發(fā)一個應(yīng)用，來訪問你所提供的接口。拿到這個WSDL文件后要做什么呢，to java。我們來看看怎么to java。

這里，在原來的EmployeeManager工程下面建一個wsdl文件夾，將它放在下面，然后所要做的準(zhǔn)備工作是，把包括axis在內(nèi)的幾個jar包找到，設(shè)置在你的classpath里面。然后在命令行下運行WSDL2Java。

哪幾個jar包？

C:\axis-1_4\lib\axis.jar;C:\axis-1_4\lib\axis-ant.jar;C:\axis-1_4\lib\commons-discovery-0.2.jar;C:\axis-1_4\lib\commons-logging-1.0.4.jar;C:\axis-1_4\lib\jaxrpc.jar;C:\axis-1_4\lib\log4j-1.2.8.jar;C:\axis-1_4\lib\saaj.jar;C:\axis-1_4\lib\wsdl4j-1.5.1.jar;E:\jboss-4.0.5\server\default\lib\activation.jar;E:\jboss-4.0.5\server\default\lib\mail.jar

這是我classpath 里面所設(shè)置的幾個jar包，后面兩個可以不需要，第二個也可以不需要，后倆個只是保證運行的時候沒有警告。

1． 將LoginDaoBean.wsdl 放在wsdl文件夾下面。E:\workspace\EmployeeManager\wsdl

2． 在命令行下進(jìn)入E:\workspace\EmployeeManager\wsdl

3． 執(zhí)行 java org.apache.axis.wsdl.WSDL2Java LoginDaoBean.wsdl

這個時候，你會發(fā)現(xiàn)在wsdl文件夾下面生成了一個目錄，它里面包含了幾個java類。

LoginDao.java，LoginDaoBindingStub.java，LoginDaoService.java，LoginDaoServiceLocator.java

2 SOA的實現(xiàn)
本節(jié)是一個以SOA+struts實現(xiàn)登錄的例子。新建一個web工程，EmployeeWebService，然后將上面生成的幾個類放入你的src目錄下面，是放整個目錄，別只放幾個類進(jìn)去. 構(gòu)建struts資源。創(chuàng)建struts的過程就不在這里細(xì)說了。創(chuàng)建的action內(nèi)容如下：

package com.ascent.webservice.struts.action;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;

import javax.servlet.http.HttpSession;

import org.apache.commons.logging.Log;

import org.apache.commons.logging.LogFactory;

import org.apache.struts.action.Action;

import org.apache.struts.action.ActionForm;

import org.apache.struts.action.ActionForward;

import org.apache.struts.action.ActionMapping;

import org.apache.struts.action.ActionMessage;

import org.apache.struts.action.ActionMessages;

import com.ascent.webservice.struts.form.LoginForm;

import com.ascent.webservice.bean.jaws.LoginDao;

import com.ascent.webservice.bean.jaws.LoginDaoServiceLocator;

public class LoginAction extends Action

{

public ActionForward execute(ActionMapping mapping, ActionForm form,

HttpServletRequest request, HttpServletResponse response)

throws Exception {

LoginForm loginForm = (LoginForm) form;

String userName = loginForm.getLoginName();

String password = loginForm.getPassword();

LoginDaoServiceLocator loginDaoServiceLocator = new LoginDaoServiceLocator();

LoginDao loginDao=

loginDaoServiceLocator.getLoginDaoPort();

boolean isExists = loginDao.isLogin(userName, password);

if(isExists)

{

System.out.println("hello " + userName);

HttpSession session = request.getSession();

session.setAttribute("loginName", loginForm.getLoginName());

return mapping.findForward("success");

}

else

{

System.out.println("sorry " + userName + ", you are not user in the system!");

ActionMessages messages = new ActionMessages();

messages.add("login",new ActionMessage("error.login.jsp.loginName.exists"));

this.saveErrors(request, messages);

return mapping.getInputForward();

}

}

}

這里用到的LoginDaoServiceLocator類和getLoginDaoPort()方法就是使用WSDL2Java命令把wsdl文件生成的類?，F(xiàn)在就可以打包成叫employee的war文件，運行它。至此，你便可以在瀏覽器中輸入http://localhost:8080/employee/login.jsp，運行你這個SOA的應(yīng)用了。如果是把服務(wù)器端部署到別的機(jī)器上，只要把localhost改為相應(yīng)的ip就可以了。

小結(jié)
本章首先介紹了目前一個前沿技術(shù)：Web Services和面向服務(wù)的軟件架構(gòu)（Service Oriented Architecture，簡稱SOA）。在理解了Web Services原理之后， 接下來我們講解了如何使用J2EE和EJB3.0來實現(xiàn)Web Services。