posts - 1, comments - 25, trackbacks - 0

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

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

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

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

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

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

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

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

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

(2) 消息的概念

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

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

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

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

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

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

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

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

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

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

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

(2) 提高軟件的重用性

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

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

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

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

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

14.1.2 SOA與 Web 2.0

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

實(shí)際上Web 2.0 和SOA的概念在很大程度上是相同的，只是被粉飾成為軟件的不同部分（如果的確存在不同的話），也就是說(shuō)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ù)開(kāi)拓，而Web 2.0更關(guān)注用戶。這種差別隨著更多企業(yè)接納Web 2.0而在變化，但是這兩項(xiàng)技術(shù)有著不同的重心: Web 2.0告訴我們數(shù)據(jù)是軟件應(yīng)用中最重要的部分，而SOA告訴我們服務(wù)才是中心。SOA中傳輸數(shù)據(jù)的服務(wù)也非常重要，但是傳統(tǒng)SOA更關(guān)注IT系統(tǒng)的接合處而不是那些能使接合處更具價(jià)值的東西。也就是說(shuō)，SOA也許是通暢的管道，但并不是系統(tǒng)中通過(guò)的水的價(jià)值。許多行業(yè)領(lǐng)導(dǎo)者說(shuō)企業(yè)同時(shí)需要SOA類方法的結(jié)構(gòu)和Web 2.0方法的創(chuàng)業(yè)能力。

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

l 軟件重組

l 管理

l 軟件就是服務(wù)

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

l 無(wú)意識(shí)的使用

l 開(kāi)放

l AJAX

l 互操作性

l 貨幣化

l 安全

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

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

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

14.2． Web Services的概念

Web Services，從字面上理解就是通過(guò)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)用軟件能夠通過(guò)Internet來(lái)訪問(wèn)并使用這項(xiàng)應(yīng)用服務(wù)

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

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

.完好的封裝性：

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

.松散耦合

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

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

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

.高度可集成能力

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

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

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

Web Services 框架的核心技術(shù)包括SOAP(Simple Object Access Protocol,簡(jiǎn)單對(duì)象訪問(wèn)協(xié)議) ,WSDL(Web Services Description Lanuage,Web服務(wù)描述語(yǔ)言) 和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ù)實(shí)現(xiàn)的各個(gè)環(huán)節(jié)。利用XML，Web Services的服務(wù)提供者和請(qǐng)求者可以利用不同的開(kāi)發(fā)語(yǔ)言來(lái)協(xié)作完成服務(wù)調(diào)用的過(guò)程。XML是Web Services技術(shù)體系中的很多標(biāo)準(zhǔn)得以建立的基礎(chǔ)，在Web Services系統(tǒng)中無(wú)處不在。

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

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

　　Web Services是基于互聯(lián)網(wǎng)的應(yīng)用程序模塊，用于在互聯(lián)網(wǎng)上運(yùn)行，它采用開(kāi)放的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ù)實(shí)體提供對(duì)定義業(yè)務(wù)和服務(wù)信息的支持。WSDL 中定義的服務(wù)描述信息是UDDI注冊(cè)中心信息的補(bǔ)充。UDDI提供了一個(gè)開(kāi)放，平臺(tái)獨(dú)立的技術(shù)框架，來(lái)使企業(yè)之間能在互聯(lián)網(wǎng)上找到對(duì)方的服務(wù)，定義它們?cè)诨ヂ?lián)網(wǎng)上的交互活動(dòng)，以及這些信息的共享方式。

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

服務(wù)提供者。從企業(yè)的角度看，這是服務(wù)的所有者。從體系結(jié)構(gòu)的角度看，這是托管訪問(wèn)服務(wù)的平臺(tái)。
服務(wù)請(qǐng)求者（用戶）。從企業(yè)的角度看，這是要求滿足特定功能的企業(yè)。從體系結(jié)構(gòu)的角度看，這是尋找并調(diào)用服務(wù)，或啟動(dòng)與服務(wù)的交互的應(yīng)用程序。服務(wù)請(qǐng)求者角色可以由瀏覽器來(lái)?yè)?dān)當(dāng)，由人或無(wú)用戶界面的程序（例如，另外一個(gè) Web 服務(wù)）來(lái)控制它。
服務(wù)注冊(cè)中心。這是可搜索的服務(wù)描述注冊(cè)中心，服務(wù)提供者在此發(fā)布他們的服務(wù)描述。在靜態(tài)綁定開(kāi)發(fā)或動(dòng)態(tài)綁定執(zhí)行期間，服務(wù)請(qǐng)求者查找服務(wù)并獲得服務(wù)的綁定信息（在服務(wù)描述中）。對(duì)于靜態(tài)綁定的服務(wù)請(qǐng)求者，服務(wù)注冊(cè)中心是體系結(jié)構(gòu)中的可選角色，因?yàn)榉?wù)提供者可以把描述直接發(fā)送給服務(wù)請(qǐng)求者。同樣，服務(wù)請(qǐng)求者可以從服務(wù)注冊(cè)中心以外的其它來(lái)源得到服務(wù)描述，例如本地文件、FTP 站點(diǎn)、Web 站點(diǎn)、廣告和服務(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ù)提供方通過(guò)WSDL(Web Services Description Language) 描述所提供的服務(wù),并將這一描述告知Web Services 注冊(cè)服務(wù)器。注冊(cè)服務(wù)器依據(jù)WSDL 的描述,依照UDDI (Universal Description Discovery and Integration) 的協(xié)定更新服務(wù)目錄并在Internet 上發(fā)布。用戶在使用Web Services 前先向注冊(cè)服務(wù)器發(fā)出請(qǐng)求,獲得Web Services 提供者的地址和服務(wù)接口信息,之后使用SOAP 協(xié)議(Simple Object Access Protocol) 與Web Services 提供者建立連接,進(jìn)行通信。Web Services 的技術(shù)主要建立在XML 的規(guī)范之上,這保證了這一體系結(jié)構(gòu)的平臺(tái)無(wú)關(guān)性、語(yǔ)言無(wú)關(guān)性和人機(jī)交互性能。

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

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

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

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

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

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

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

接下來(lái)我們具體展開(kāi)Web Services原理。

14.3．Web Services原理

首先，我們將看看 Web 服務(wù)的一個(gè)概念性協(xié)議棧以及這個(gè)協(xié)議棧的細(xì)節(jié)。然后我們將討論選擇網(wǎng)絡(luò)協(xié)議的標(biāo)準(zhǔn)。我們還將回顧一下基本的基于 XML 的消息傳遞分布式計(jì)算。我們將用服務(wù)描述擴(kuò)展基本的 XML 消息傳遞，而服務(wù)描述是根據(jù)它的協(xié)議棧來(lái)解釋的。接下來(lái)，我們將討論服務(wù)描述在 Web 服務(wù)體系結(jié)構(gòu)中的角色，說(shuō)明支持靜態(tài)和動(dòng)態(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)和綁定這三個(gè)操作，必須有一個(gè)包含每一層標(biāo)準(zhǔn)的 Web 服務(wù)協(xié)議棧。圖 2 展示了一個(gè)概念性 Web 服務(wù)協(xié)議棧。上面的幾層建立在下面幾層提供的功能之上。垂直的條表示在協(xié)議棧中每一層必須滿足的需求。

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

Web 服務(wù)協(xié)議棧的基礎(chǔ)是網(wǎng)絡(luò)層。Web 服務(wù)要被服務(wù)請(qǐng)求者調(diào)用，就必須是可以通過(guò)網(wǎng)絡(luò)訪問(wèn)的。互聯(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)程過(guò)程調(diào)用的標(biāo)準(zhǔn)化封裝機(jī)制。
SOAP 很簡(jiǎn)單；它基本上是一個(gè)用 XML 信封作為有效負(fù)載的 HTTP POST。
SOAP 比對(duì) XML 簡(jiǎn)單的 HTTP POST 更受青睞，因?yàn)樗x了一個(gè)標(biāo)準(zhǔn)機(jī)制，這個(gè)機(jī)制將正交擴(kuò)展（orthogonal extension）合并為使用 SOAP 報(bào)頭和對(duì)操作或函數(shù)進(jìn)行標(biāo)準(zhǔn)編碼的消息。
SOAP 消息支持 Web 服務(wù)體系結(jié)構(gòu)中的發(fā)布、查找和綁定操作。
服務(wù)描述層實(shí)際上是描述文檔的一個(gè)協(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ù)描述文檔來(lái)補(bǔ)充，從而描述 Web 服務(wù)的這些更高級(jí)的方面。例如，描述業(yè)務(wù)環(huán)境除了使用 WSDL 文檔，還要使用 UDDI 數(shù)據(jù)結(jié)構(gòu)。Web 服務(wù)流程語(yǔ)言（Web Services Flow Language，WSFL）文檔中則描述了服務(wù)組成和流程。

因?yàn)?Web 服務(wù)被定義為可以通過(guò) SOAP 從網(wǎng)絡(luò)進(jìn)行訪問(wèn)，并由服務(wù)描述表示，所以該協(xié)議棧中的前三層需要提供或使用 Web 服務(wù)。最簡(jiǎn)單的協(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é)議和分布式計(jì)算技術(shù)。該協(xié)議棧提供了互操作性，它使 Web 服務(wù)能夠利用現(xiàn)有的互聯(lián)網(wǎng)基礎(chǔ)結(jié)構(gòu)。這將使進(jìn)入普遍存在的環(huán)境的成本非常低。另外，靈活性并不會(huì)因?yàn)榛ゲ僮餍孕枨蠖兴档停驗(yàn)槲覀兛梢詾檫x擇性和增值的技術(shù)提供另外的支持。例如，我們必須支持 HTTP 上的 SOAP，但也可以同時(shí)支持 MQ 上的 SOAP。

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

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

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

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

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

Web 服務(wù)協(xié)議棧的最底層是網(wǎng)絡(luò)層。該層可表示任意多個(gè)網(wǎng)絡(luò)協(xié)議：HTTP、FTP、SMTP、消息排隊(duì)（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)用程序需求。

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

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

基于 XML 消息傳遞的分布式計(jì)算

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)時(shí)，Web 服務(wù)體系結(jié)構(gòu)就會(huì)從 SOAP 遷移到 XML 協(xié)議。

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

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

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

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

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

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

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

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

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

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

基本服務(wù)描述

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

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

服務(wù)接口定義是一種抽象或可重用的服務(wù)定義，它可以被多個(gè)服務(wù)實(shí)現(xiàn)定義實(shí)例化和引用。我們可以將服務(wù)接口定義想象成接口定義語(yǔ)言（Interface Definition Language，IDL）、Java 接口或 Web 服務(wù)類型。這使常見(jiàn)的行業(yè)標(biāo)準(zhǔn)服務(wù)類型可以被多個(gè)服務(wù)實(shí)現(xiàn)者定義和實(shí)現(xiàn)。這類似于在編程語(yǔ)言中定義抽象接口然后得到多個(gè)具體實(shí)現(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 消息。您可以將操作想象成編程語(yǔ)言中的方法說(shuō)明。WSDL: message 元素指定哪些 XML 數(shù)據(jù)類型組成消息的各個(gè)部分。WSDL: message 元素用于定義操作的輸入和輸出參數(shù)。WSDL: types 元素中描述消息中復(fù)雜數(shù)據(jù)類型的使用。WSDL: binding 元素描述特定服務(wù)接口（WSDL: portType）的協(xié)議、數(shù)據(jù)格式、安全性和其它屬性。

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

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

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

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

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

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

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

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

UDDI 提供了一個(gè)保存 Web 服務(wù)描述的機(jī)制。雖然 UDDI 通常會(huì)被認(rèn)為是一種目錄機(jī)制，但是它也定義了一個(gè)用 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 開(kāi)始。businessEntity 元素對(duì)關(guān)于企業(yè)的信息進(jìn)行建模，包括基本的企業(yè)信息（例如企業(yè)名稱和聯(lián)系方式信息是什么？）、分類信息（例如這是何種類型的企業(yè)？）以及標(biāo)識(shí)信息（即 Dunn and Bradstreet 編號(hào)是什么？）。businessEntity 包含一組 businessService 元素，每個(gè)元素對(duì)應(yīng)于企業(yè)希望發(fā)布的每個(gè) Web 服務(wù)。每個(gè) businessService 元素都包含和 businessEntity 元素的 Web 服務(wù)有關(guān)的技術(shù)性和描述性信息。businessService 包含一組 bindingTemplate 元素。bindingTemplate 描述訪問(wèn)信息（例如端點(diǎn)地址），還描述 businessService 如何使用各種不同的技術(shù)規(guī)范。技術(shù)規(guī)范在這里的模型是 tModel。tModel 可以為很多不同概念建模，如：一種服務(wù)、一個(gè)諸如 HTTPS 之類的平臺(tái)技術(shù)或一個(gè)類別。與 businessService 相關(guān)聯(lián)的那一組 bindingTemplate 元素代表了 businessService 所使用的技術(shù)的印記。

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

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

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

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

這個(gè)領(lǐng)域充滿了創(chuàng)新。對(duì)于企業(yè)協(xié)議定義來(lái)說(shuō)，目前還沒(méi)有一個(gè)單獨(dú)的標(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ù)端點(diǎn)描述這兩層正處于開(kāi)發(fā)中，它們可以提供這個(gè)級(jí)別的服務(wù)描述。

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

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

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

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

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

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

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

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

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

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

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

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

獲取服務(wù)描述

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

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

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

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

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

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

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

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

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

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

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

安全性

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

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

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

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

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

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

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

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

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

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

因?yàn)槲覀円呀?jīng)看到安全的傳輸機(jī)制不足以滿足 Web 服務(wù)開(kāi)發(fā)方法和使用場(chǎng)景的要求，所以我們的任務(wù)就是要?jiǎng)?chuàng)建一個(gè)概念性 Web 安全層，包括下列幾個(gè)組件：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

需要在將來(lái)進(jìn)行的幾點(diǎn)補(bǔ)充：

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

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

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

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

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

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

管理概念性 Web 服務(wù)棧各層的 Web 服務(wù)和 Web 服務(wù)模型組件必定是有可能的。對(duì)管理的需求可以分成兩個(gè)集中的領(lǐng)域。第一個(gè)領(lǐng)域是用于實(shí)現(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è)對(duì)其自己的基礎(chǔ)設(shè)施及管理?yè)碛型耆淖灾鳈?quán)。但是，當(dāng)企業(yè)在對(duì)等基礎(chǔ)上相互作用時(shí)，就應(yīng)當(dāng)提供對(duì)網(wǎng)絡(luò)層、XML 消息傳遞層、服務(wù)注冊(cè)中心和 Web 服務(wù)實(shí)現(xiàn)的基本報(bào)告和恢復(fù)辦法。此外，企業(yè)向其合伙人提供的管理接口應(yīng)當(dāng)是在服務(wù)層上操作的，而不是在相對(duì)低級(jí)的基礎(chǔ)設(shè)施層上。合伙人應(yīng)該能夠訪問(wèn)到報(bào)告操作和請(qǐng)求處理的狀態(tài)和健康度的接口，但不一定要理解企業(yè)如何管理其請(qǐng)求的細(xì)節(jié)。

對(duì)于網(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è)相互作用時(shí)，就應(yīng)該向其合伙人提供有關(guān) Web 服務(wù)基礎(chǔ)設(shè)施可用性的基本報(bào)告。影響 Web 服務(wù)基礎(chǔ)設(shè)施可用性的網(wǎng)絡(luò)可用性應(yīng)作為因素之一寫(xiě)入報(bào)告。

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

管理的第二個(gè)方面是 Web 服務(wù)本身的可管理性。一些主要的考慮是性能、可用性、事件和使用量度，因?yàn)樗鼈儗榉?wù)提供者市場(chǎng)收取所提供的服務(wù)使用費(fèi)提供必要信息。

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

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

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

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

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

14.4 Web Services 項(xiàng)目實(shí)戰(zhàn)

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

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

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

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

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

JAX-RPC的叫法有點(diǎn)用詞不當(dāng)，因?yàn)樗戎С諶PC類型的web services，也支持文檔類型的web services。

Web Services部署模型

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

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

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

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

在這兩種部署選擇中，你會(huì)使用哪一個(gè)呢?

Java 類對(duì)無(wú)狀態(tài)EJB:永無(wú)止境的爭(zhēng)論

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

使用J2EE 5.0簡(jiǎn)化SOA的開(kāi)發(fā)

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

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

　　當(dāng)你使用Web Services元數(shù)據(jù)開(kāi)發(fā)時(shí)，這是一個(gè)看起來(lái)如此簡(jiǎn)單的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類簡(jiǎn)化了EJB的開(kāi)發(fā)。通過(guò)利用EJB 3.0和Web Services元數(shù)據(jù)，開(kāi)發(fā)基于EJB的web services將會(huì)變得越來(lái)越簡(jiǎn)單。當(dāng)使用EJB 3.0和web services元數(shù)據(jù)時(shí)，這是一個(gè)看起來(lái)如此簡(jiǎn)單的HelloWorld EJB web service。你不必?fù)?dān)心創(chuàng)建WSDL，部署描述符等等，應(yīng)用服務(wù)器會(huì)在部署過(guò)程中生成這些定義文件。

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的實(shí)現(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");
}
}

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

14.4．2 Web Services 項(xiàng)目實(shí)戰(zhàn)

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

我們先創(chuàng)建服務(wù)器端的實(shí)體Bean，這和創(chuàng)建普通的Ejb3.0實(shí)體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接口是要實(shí)現(xiàn)的，@SOAPBinding(style=Style.RPC)，Soap的綁定方式也是需要的，不然在客戶端是找不到LoginDao 。

下面創(chuàng)建會(huì)話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ù)器端的類是建好了，這里又兩個(gè)問(wèn)題，需要說(shuō)明一下

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

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

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

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

<definitions name="LoginDaoService"

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

</message>

</message>

</operation>

</portType>

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

<soap:operation soapAction=""/>

<input>

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

</input>

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

</output>

</operation>

</binding>

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

</port>

</service>

</definitions>

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

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

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

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

哪幾個(gè)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è)置的幾個(gè)jar包，后面兩個(gè)可以不需要，第二個(gè)也可以不需要，后倆個(gè)只是保證運(yùn)行的時(shí)候沒(méi)有警告。

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

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

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

2 SOA的實(shí)現(xiàn)
本節(jié)是一個(gè)以SOA+struts實(shí)現(xiàn)登錄的例子。新建一個(gè)web工程，EmployeeWebService，然后將上面生成的幾個(gè)類放入你的src目錄下面，是放整個(gè)目錄，別只放幾個(gè)類進(jìn)去. 構(gòu)建struts資源。創(chuàng)建struts的過(guò)程就不在這里細(xì)說(shuō)了。創(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文件生成的類。現(xiàn)在就可以打包成叫employee的war文件，運(yùn)行它。至此，你便可以在瀏覽器中輸入http://localhost:8080/employee/login.jsp，運(yùn)行你這個(gè)SOA的應(yīng)用了。如果是把服務(wù)器端部署到別的機(jī)器上，只要把localhost改為相應(yīng)的ip就可以了。

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

posted on 2011-08-31 13:25 Daniel 閱讀(6468) 評(píng)論(0) 編輯收藏所屬分類: WebService

新用戶注冊(cè) 刷新評(píng)論列表


只有注冊(cè)用戶登錄后才能發(fā)表評(píng)論。




網(wǎng)站導(dǎo)航: 博客園 IT新聞 Chat2DB C++博客博問(wèn) 管理
相關(guān)文章: WebService與SOA的實(shí)現(xiàn) Difference Between RPC and Document Style WSDL Webservices with HTTPS JBoss nested exception is: Invalid invocation 調(diào)節(jié) MyEclipse + AXIS2

2025年6月

日

一

二

三

四

五

六

常用鏈接

留言簿(3)

隨筆檔案

2006年5月 (1)

文章分類

文章檔案

相冊(cè)

Fitment
Gril