WebService與SOA的實現

14.1 Web Services和麪向服務的軟件架構（Service Oriented Architecture，簡稱SOA）概述：

 

在最新Java開發世界裏，咱們常常會遇到這樣一個名詞：Web Services（Web服務）。同時還會發現，與這個名詞同時出現的可能是各大主流技術供應商，各大技術供應商無一不在關注這一領域的發展。從Microsoft的.NET架構，到SUN的SUN ONE，以及IBM的Web Services，都體現了這些重量級的技術提供者對Web Services的推崇與重視。

 

電子商務的發展促進了Web Services的發展。Web服務能夠使公司下降進行電子商務的成本，更快地部署解決方案以及開拓更多的新機遇。Web服務使應用程序的集成比之前更快、更容易並且更便宜。它更注重服務語義而不那麼注重網絡協議語義的消息，從而實現了業務功能的鬆散耦合。這些特性對於在企業之間和企業內部經過web鏈接業務功能是很是理想的。它提供了一致化（Uniform）的編程模型，從而在企業內外均可以利用通用的基礎設施並以一種通用的方法進行應用程序集成。

 

要理解Web Services, 首先須要認識面向服務的軟件架構（Service Oriented Architecture，簡稱SOA），Web Services是SOA架構系統的一個實例。

14.1.1面向服務的軟件架構（SOA）

 

1. 面向服務中的基本概念

在面向服務的架構中包含一些基本的概念，透過這些基本概念能夠進一步瞭解面向服務的架構。

(1) 服務的概念

在SOA中的服務是指可以處理一些任務過程的動做的抽象概念，這些服務能夠被描述，能夠被發現，能夠由服務代理負責向請求者提供服務並給出結果。代理是指請求或者提供服務的人所使用的軟件工具，人經過代理進行交互操做。

(2) 消息的概念

服務代理之間須要經過消息的傳遞進行交互操做，消息的內容含有必定的語義和數據，消息傳輸須要與某個通訊協議相綁定纔可以實現。

(3) 服務的描述和發現

衆多的服務組成一個開放系統，除了須要提供信息交互方式之外，還須要提供相互瞭解的機制，這就須要提供描述和發現的方式。代理能夠經過服務的描述來了解一個服務的內容，包括使用這個服務的技術信息、訪問這個服務的地址信息等內容。當新的服務被投入到系統之中後，它須要被註冊，而且要可以被發現，使它能夠被利用起來。

 

2.爲何須要面向服務的軟件

因爲軟件需求的擴大，軟件系統變得愈來愈複雜。面對複雜的系統資源，咱們須要一種更加合理的方式將不一樣類型、不一樣位置的子系統有力地結合起來，這種整合並非將它們之間綁定得更加緊密，而是利用更加鬆散的方式來創建這個系統。

SOA經過鬆散的方式將分佈式的軟件模塊結合起來，與舊有系統集成相比有着明顯的優點。對於服務的使用者來講，能夠簡單地經過服務的描述來獲取服務，系統各部分之間沒必要爲了某一部分的升級而改變，在服務的過程當中不一樣的軟件模塊能夠充當不一樣的角色，從而構成整個系統的工做體系。

在SOA當中，一個服務表明的是一個由服務提供者向服務請求者發佈的一些處理過程，這個過程在被調用以後，得到服務請求者所須要的一個結果。在這個過程當中，服務請求者能夠向任何可以提供此項服務的服務提供者來請求服務，服務實現的過程對於服務請求者來講是透明的。

隨着系統分佈式和多種結構複合程度的提升，SOA的巨大優點將進一步被挖掘。

(1) 創建鬆散耦合的系統

鬆散耦合系統的優勢已經被業內充分地承認，SOA做爲一種分佈式的系統，它實現了一種服務和描述等概念相結合的架構。

SOA中的服務在SOA架構中被標準的描述語言所描述，並經過與某種傳輸協議的綁定來實現相互之間的交互。這種基於服務的架構使整個系統成爲一個鬆散耦合的結構，利用與通訊協議的綁定將分佈式系統中的全部部分鏈接起來，利用語義和服務的描述，在代理之間進行交互。

(2) 提升軟件的重用性

面向服務的架構還提升了對軟件的重用性。與組件方式相比，SOA系統中的單個服務的改變不會對其餘部分形成嚴重的影響，同時利用服務的描述使同一服務能夠充分地被其餘系統所調用，各個系統之間造成了高度的重用性。

如今正在被普遍使用的一些服務，正在不斷地被各個系統所重用，重用的條件十分簡單，只要瞭解服務的描述，或者能夠訪問到服務的描述地址便可。與組件重用相比，服務的重用還具備與實現語言無關的特色，重用服務的客戶端程序不須要使用與服務實現部分一樣的開發語言，一切交互的過程都是利用與實現無關的方式進行的。

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

面向服務的架構也使得系統的實現虛擬化，在SOA架構中的請求和提供之間交互或相互代理的過程當中，可計算的代碼資源分佈在鬆散結構中的各個部分上，當請求發生時才被調用和服務，全部計算過程都是按照請求者的需求進行的。服務的對象分爲有狀態和無狀態兩種方式提供服務，按照需求提供服務，也能夠利用緩衝機制優化系統的系統。

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

 

14.1.2 SOA與 Web 2.0

另外，咱們補充一下SOA與目前一樣熱門的Web 2.0的關係。

實際上Web 2.0 和SOA的概念在很大程度上是相同的，只是被粉飾成爲軟件的不一樣部分（若是的確存在不一樣的話），也就是說SOA和Web 2.0有不少重疊的東西，例如都是基於調用（invoke）的服務，都能存在於網絡的任何位置等等。

SOA和Web 2.0的共性遠大於它們之間的區別，並且Web 2.0在推廣SOA方面起到了必定做用。到如今爲止，SOA和Web 2.0擁有不一樣的支持者- SOA更多涉及企業結構和商務開拓，而Web 2.0更關注用戶。這種差異隨着更多企業接納Web 2.0而在變化，可是這兩項技術有着不一樣的重心: Web 2.0告訴咱們數據是軟件應用中最重要的部分，而SOA告訴咱們服務纔是中心。SOA中傳輸數據的服務也很是重要，可是傳統SOA更關注IT系統的接合處而不是那些能使接合處更具價值的東西。也就是說，SOA也許是通暢的管道，但並非系統中經過的水的價值。許多行業領導者說企業同時須要SOA類方法的結構和Web 2.0方法的創業能力。

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

l 軟件重組

l 管理

l 軟件就是服務

l 應用就是平臺

l 無心識的使用

l 開放

l AJAX

l 互操做性

l 貨幣化

l 安全

l 網絡導向架構

特別要說的是，最後一條網絡導向架構或者Web Oriented Architecture（WOA）是關鍵的內容，最終有可能會將SOA和Web 2.0合爲一體。

 

瞭解了SOA後， 咱們來介紹什麼是Web Services。Web Services是SOA架構系統的一個實例。從技術角度來說，Web Services是一種新的技術架構、新的軟件應用環境。它的系統架構和實現技術徹底繼承已有的技術，能夠認爲Web Services是Internet的一種延伸，是現有的Internet面向更好的互操做能力的一個延伸。

14.2． Web Services的概念

Web Services，從字面上理解就是經過Web提供的服務。咱們能夠理解Web Services是自包含的、模塊化的應用程序，它能夠在網絡(一般爲Web)中被描述、發佈、查找以及調用；也能夠理解Web Services是基於網絡的、分佈式的模塊化組件，它執行特定的任務，遵照具體的技術規範，這些規範使得Web Sevices能與其餘兼容的組件進行互操做；也能夠這樣理解，所謂Web服務，它是指由企業發佈的完成其特別商務需求的在線應用服務，其餘公司或應用軟件可以經過Internet來訪問並使用這項應用服務

對於Web Services，不少人會與Web Service混爲一談，認爲兩者指的是同一個事物。其實否則，前者指的是用於建構Web Service的技術框架，後者指的是使用Web Services技術而建立的應用實例。Web Services是描述了一些操做的接口，基於標準化的XML消息傳輸機制，咱們能夠經過網絡訪問這些操做。Web Services使用規範的、基於XML的WSDL(Web Services Description Language)語言描述的，這稱爲Web Services的服務描述。這一描述囊括了與服務交互所須要的所有細節，包括消息格式（詳細描述操做的輸入輸出消息格式）、傳輸協議和位置。該接口隱藏了服務實現的細節，容許經過獨立與服務實現、獨立於軟硬件平臺、獨立於編寫服務所用的編程語言的方式使用該服務。這使得基於Web Services的應用程序具備鬆散耦合、面向組件和跨技術實現的特色。Web Services都履行必定的特定業務或任務，能夠實現同其餘Web Services一塊兒用於實現複雜的商業交易。

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

.無缺的封裝性：

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

.鬆散耦合

這一特徵也是源於對象／組件技術，當一個Web服務的實現發生變動的時候，調用者是不會感到這一點的，對於調用者來講，只要Web服務的調用界面不變，Web服務實現的任何變動對他們來講都是透明的，甚至是當Web服務的實現平臺從J2EE遷移到了．NET或者是相反的遷移流程，用戶均可以對此一無所知。對於鬆散耦合而言，尤爲是在Internet環境下的Web服務而言，須要有一種適合Internet環境的消息交換協議，而XML／SOAP正是目前最爲適合的消息交換協議。

.使用協議的規範性

這一特徵從對象而來，但相比通常對象，它更加規範化和易於理解。首先，做爲Web服務，對象界面所提供的功能應當使用標準的描述語言來描述(好比WSDL)；其次，由標準描述語言描述的服務界面應當是可以被發現的，所以這一描述文檔須要被存儲在私有的或公共的註冊庫裏面。同時，使用標準描述語言描述的使用協約將不只僅是服務界面，它將被延伸到Web服務的聚合、跨Web服務的事務、工做流等，而這些又都須要服務質量(QoS)的保障。其次，咱們知道安全機制對於鬆散耦合的對象環境的重要性，所以咱們須要對諸如受權認證、數據完整性(好比簽名機制)、消息源認證以及事務的不能否認性等運用規範的方法來描述、傳輸和交換。最後，在全部層次的處理都應當是可管理的，所以須要對管理協約運用一樣的機制。

.高度可集成能力

因爲Web服務採起簡單的、易理解的標準，Web協議做爲組件界面描述和協同描述規範，徹底屏蔽了不一樣軟件平臺的差別，不管是CORBA、DCOM仍是EJB，均可以經過這一種標準的協議進行互操做，實現了在當前環境下最高的可集成性。

 

14.2.1 Web Services的核心技術

 

Web Services 是一種基於組件的軟件平臺,是面向服務的Internet 應用。Web Services 是應用於Internet 的,而不是限於局域網或試驗環境，這就要求Web Services 框架必須適用於現有的Internet 軟件和硬件環境,即服務的提供者所提供的服務必須具備跨平臺、跨語言的特性。其次,Web Services 所提供的服務不可是面向人,並且需服務於其它應用系統。現有的Web網站也能夠認爲是面向服務的,但這種服務僅僅能夠提供給人使用(只有人類才能夠讀懂瀏覽器下載的頁面) 。而新一代的Web Services 所提供的服務應能被機器所讀懂,例如其它應用程序及移動設備中的軟件系統。這樣,咱們能夠看出,Web Services 的發展方向其實是構造一個基於現有Internet 技術之上的分佈計算系統。

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

XML是Web Services技術體系中最基礎的標準，Web Services的一切都創建在XML技術的基礎之上，包括Web Services的消息、描述和服務實現的各個環節。利用XML，Web Services的服務提供者和請求者能夠利用不一樣的開發語言來協做完成服務調用的過程。XML是Web Services技術體系中的不少標準得以創建的基礎，在Web Services系統中無處不在。

 

SOAP 是Web services 的通訊協議。SOAP是一種簡單的、輕量級的基於XML 的機制，用於在網絡應用程序之間進行結構化數據交換。SOAP包括三部分:一個定義描述消息內容的框架的信封，一組表示應用程序定義的數據類型實例的編碼規則，以及表示遠程過程調用和響應的約定。

WSDL表示WEB服務說明語言。WSDL文件是一個XML 文檔，用於說明一組SOAP消息以及如何交換這些消息，經過WSDL能夠描述一個服務的信息。這些信息使不瞭解這個服務的開發者能夠創建調用這個服務的客戶端代碼，或者經過WSDL幫助生成實現它的基本代碼結構。WSDL在Web Services的實際開發過程當中起着重要的做用。

 

　　Web Services是基於互聯網的應用程序模塊，用於在互聯網上運行，它採用開放的UDDI（Universal Description，Discovery and Integration，通用描述，發現，集成）標準。UDDI標準先由IBM、微軟、Ariba制訂，到目前爲止得到了130多家公司的支持。UDDI 提供一種發佈和查找服務描述的方法。UDDI 數據實體提供對定義業務和服務信息的支持。WSDL 中定義的服務描述信息是UDDI註冊中心信息的補充。UDDI提供了一個開放，平臺獨立的技術框架，來使企業之間能在互聯網上找到對方的服務，定義它們在互聯網上的交互活動，以及這些信息的共享方式。

 

Web 服務體系結構基於三種角色（服務提供者、服務註冊中心和服務請求者）之間的交互。

服務提供者。從企業的角度看，這是服務的全部者。從體系結構的角度看，這是託管訪問服務的平臺。 
服務請求者（用戶）。從企業的角度看，這是要求知足特定功能的企業。從體系結構的角度看，這是尋找並調用服務，或啓動與服務的交互的應用程序。服務請求者角色能夠由瀏覽器來擔當，由人或無用戶界面的程序（例如，另一個 Web 服務）來控制它。 
服務註冊中心。這是可搜索的服務描述註冊中心，服務提供者在此發佈他們的服務描述。在靜態綁定開發或動態綁定執行期間，服務請求者查找服務並得到服務的綁定信息（在服務描述中）。對於靜態綁定的服務請求者，服務註冊中心是體系結構中的可選角色，由於服務提供者能夠把描述直接發送給服務請求者。一樣，服務請求者能夠從服務註冊中心之外的其它來源獲得服務描述，例如本地文件、FTP 站點、Web 站點、廣告和服務發現（Advertisement and Discovery of Services，ADS）或發現 Web 服務（Discovery of Web Services，DISCO）。 

　　Web Services 的體系架構如圖1 所示

Web Services 服務提供方經過WSDL(Web Services Description Language) 描述所提供的服務,並將這一描述告知Web Services 註冊服務器。註冊服務器依據WSDL 的描述,依照UDDI (Universal Description Discovery and Integration) 的協定更新服務目錄並在Internet 上發佈。用戶在使用Web Services 前先向註冊服務器發出請求,得到Web Services 提供者的地址和服務接口信息,以後使用SOAP 協議(Simple Object Access Protocol) 與Web Services 提供者創建鏈接,進行通訊。Web Services 的技術主要創建在XML 的規範之上,這保證了這一體系結構的平臺無關性、語言無關性和人機交互性能。

 

14.2.2 Web 服務開發生命週期

Web 服務開發生命週期包括了設計和部署以及在運行時對服務註冊中心、服務提供者和服務請求者每個角色的要求。每一個角色對開發生命週期的每一元素都有特定要求。

Web 服務開發生命週期有如下四個階段：

1. 構建 
生命週期的構建階段包括開發和測試 Web 服務實現、定義服務接口描述和定義服務實現描述。咱們能夠經過建立新的 Web 服務、把現有的應用程序變成 Web 服務和由其它 Web 服務和應用程序組成新的 Web 服務來提供 Web 服務的實現。

2. 部署 
部署階段包括向服務請求者或服務註冊中心發佈服務接口和服務實現的定義，以及把 Web 服務的可執行文件部署到執行環境（典型狀況下，Web 應用程序服務器）中。

3. 運行 
在運行階段，能夠調用 Web 服務。在此，Web 服務完成部署，成爲可操做的服務。服務請求者能夠進行查找和綁定操做。

4. 管理 
管理階段包括持續的管理和經營 Web 服務應用程序。安全性、可用性、性能、服務質量和業務流程問題都必須被解決。

 

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

 

14.3．Web Services原理

 

首先，咱們將看看 Web 服務的一個概念性協議棧以及這個協議棧的細節。而後咱們將討論選擇網絡協議的標準。咱們還將回顧一下基本的基於 XML 的消息傳遞分佈式計算。咱們將用服務描述擴展基本的 XML 消息傳遞，而服務描述是根據它的協議棧來解釋的。接下來，咱們將討論服務描述在 Web 服務體系結構中的角色，說明支持靜態和動態 Web 服務應用程序的服務發佈技術的範圍。咱們還將圍繞服務發佈討論服務發現的角色。最後，咱們將描述基本 Web 服務體系結構的擴展，電子商務須要這些擴展才能使用 Web 服務。

 

14.3.1 Web 服務協議棧

要以一種可交互操做的方式執行發佈、發現和綁定這三個操做，必須有一個包含每一層標準的 Web 服務協議棧。圖 2 展現了一個概念性 Web 服務協議棧。上面的幾層創建在下面幾層提供的功能之上。垂直的條表示在協議棧中每一層必須知足的需求。

圖2. Web 服務概念性協議棧

Web 服務協議棧的基礎是網絡層。Web 服務要被服務請求者調用，就必須是能夠經過網絡訪問的。互聯網上能夠公用的 Web 服務使用廣泛適用的網絡協議。HTTP 憑藉其廣泛性，成爲了互聯網可用的 Web 服務真正的標準網絡協議。Web 服務還能夠支持其它互聯網協議，包括 SMTP 和 FTP。內部網域能夠使用可靠消息傳遞和調用基礎結構，如 MQSeries 和 CORBA 等等。

 

下一層是基於 XML 的消息傳遞，它表示使用 XML 做爲消息傳遞協議的基礎。選擇 SOAP 做爲 XML 消息傳遞協議有不少緣由：

它是使用 XML 傳送以文檔爲中心的消息以及遠程過程調用的標準化封裝機制。 
SOAP 很簡單；它基本上是一個用 XML 信封做爲有效負載的 HTTP POST。 
SOAP 比對 XML 簡單的 HTTP POST 更受青睞，由於它定義了一個標準機制，這個機制將正交擴展（orthogonal extension）合併爲使用 SOAP 報頭和對操做或函數進行標準編碼的消息。 
SOAP 消息支持 Web 服務體系結構中的發佈、查找和綁定操做。 
服務描述層其實是描述文檔的一個協議棧。首先，WSDL 是基於 XML 的服務描述的真正標準。這是支持可交互操做的 Web 服務所需的最小標準服務描述。WSDL 定義了服務交互的接口和結構。要指定業務環境、服務質量和服務之間的關係，咱們還須要另外的描述。WSDL 文檔能夠由其它服務描述文檔來補充，從而描述 Web 服務的這些更高級的方面。例如，描述業務環境除了使用 WSDL 文檔，還要使用 UDDI 數據結構。Web 服務流程語言（Web Services Flow Language，WSFL）文檔中則描述了服務組成和流程。

由於 Web 服務被定義爲能夠經過 SOAP 從網絡進行訪問，並由服務描述表示，因此該協議棧中的前三層須要提供或使用 Web 服務。最簡單的協議棧將包括網絡層的 HTTP、XML 消息傳遞層的 SOAP 協議以及服務描述層的 WSDL。全部企業間或公用 Web 服務都應該支持這種可交互操做的基礎協議棧。Web 服務，特別是企業內部或專用 Web 服務，可以支持其它的網絡協議和分佈式計算技術。該協議棧提供了互操做性，它使 Web 服務可以利用現有的互聯網基礎結構。這將使進入廣泛存在的環境的成本很是低。另外，靈活性並不會由於互操做性需求而有所下降，由於咱們能夠爲選擇性和增值的技術提供另外的支持。例如，咱們必須支持 HTTP 上的 SOAP，但也能夠同時支持 MQ 上的 SOAP。

協議棧的最下面三層確立了保證一致性和互操做性的技術，而它們上面的兩層，即服務發佈和服務發現，能夠用多種解決方案來實現。

任何可以讓服務請求者使用 WSDL 文檔的操做，無論它處於服務請求者生命週期的哪一個階段，都符合服務發佈的標準。該層中最簡單、最靜態的實例就是服務提供者直接向服務請求者發送 WSDL 文檔。這被稱爲直接發佈。電子郵件是直接發佈的載體之一。直接發佈對靜態綁定的應用程序來講頗有用。另外，服務提供者還能夠將描述服務的文檔發佈到主機本地 WSDL 註冊中心、專用 UDDI 註冊中心或 UDDI 運營商節點。

Web 服務若是沒有被髮布就不能被發現，因此說服務發現依賴於服務發佈。該層的各類發現機制和一組發佈機制互相平行。任何容許服務請求者得到對服務描述的訪問權，並在運行時使應用程序可以使用該服務描述的機制都必須符合服務發現的標準。最簡單、最靜態的發現的實例是靜態發現，其中服務請求者從本地文件獲取 WSDL 文檔。這一般都是經過直接發佈獲取的 WSDL 文檔，或者前面查找操做的結果。另外，也能夠經過使用本地 WSDL 註冊中心、專用 UDDI 註冊中心或 UDDI 運營商節點在設計時或運行時發現服務。由於 Web 服務實現是一種軟件模塊，因此經過組建 Web 服務來產生 Web 服務是很天然的。Web 服務的組合能夠扮演不少角色之一。企業內部的 Web 服務可能會相互合做，從而對外顯示出一個單獨的 Web 服務接口，或者，來自不一樣企業的 Web 服務能夠相互合做，從而執行機器到機器、企業到企業的事務。另外，工做流程管理者還能夠在參與業務流程的時侯調用每一個 Web 服務。最上面一層，即服務流程，描述瞭如何執行服務到服務的通信、合做以及流程。WSFL 用於描述這些交互。要使 Web 服務應用程序知足當今電子商務的迫切需求，就必須提供企業級基礎結構，包括安全性、管理和服務質量。這幾個垂直條在協議棧的每一層都必須獲得解決。每一層的解決方案能夠彼此獨立。隨着 Web 服務範例的採用和發展，將會出現更多此類垂直條。

該協議棧的最下面幾層表示基礎 Web 服務協議棧，它們相對於協議棧中上面幾層來講更成熟，也更標準。Web 服務的成熟和採用將會帶動協議棧中上面幾層和垂直條的開發和標準化。

網絡層

Web 服務協議棧的最底層是網絡層。該層可表示任意多個網絡協議：HTTP、FTP、SMTP、消息排隊（Message Queuing）、互聯網 ORB 間協議（Internet Inter ORB Protocol，IIOP）上的遠程方法調用（Remote Method Invocation，RMI）、電子郵件等等。在任何給定的狀況下使用的網絡協議都依賴於應用程序需求。

對於能夠從互聯網訪問的 Web 服務，人們選擇網絡技術的時侯一般會傾向於選擇廣泛部署的協議，如 HTTP。對於內部網中提供和使用的 Web 服務，使用另外的網絡技術也會被認同。咱們能夠根據其它需求選擇網絡技術，包括安全性、可用性、性能以及可靠性。這使得 Web 服務能夠利用已有的功能更高級的聯網基礎結構和麪向消息的中間件，如 MQSeries。在有多種網絡基礎結構的企業中，HTTP 能夠用來在這些基礎結構之間搭建橋樑。

Web 服務的好處之一在於，它爲專用內部網和公用互聯網服務的開發和使用提供了統一的編程模型。因此，網絡技術的選擇對服務開發者來講是透明的。

基於 XML 消息傳遞的分佈式計算

Web 服務體系結構最基礎的支柱是 XML 消息傳遞。當前 XML 消息傳遞的行業標準是 SOAP。IBM、Microsoft 以及其它企業都向 W3C 建議 SOAP 做爲 XML 協議工做組（XML Protocol Working Group）的基礎。XML 協議將代替 SOAP 做爲行業標準 XML 消息傳遞協議的位置。當 W3C 發佈 XML 協議的草案標準時，Web 服務體系結構就會從 SOAP 遷移到 XML 協議。

SOAP 是一種簡單的、輕量級的基於 XML 的機制，用於在網絡應用程序之間進行結構化數據交換。SOAP 包括三部分：一個定義描述消息內容的框架的信封、一組表示應用程序定義的數據類型實例的編碼規則，以及表示遠程過程調用（remote procedure calls，RPC）和響應的約定。SOAP 能夠和各類網絡協議（如 HTTP、SMTP、FTP 和 IIOP 或 MQ 上的 RMI）相結合使用，或者用這些協議從新封裝後使用。

雖然理解這個基礎很重要，但多數 Web 服務開發者沒必要直接處理這個基礎結構。大多數 Web 服務都會使用從 WSDL 生成的通過優化的特定於編程語言的綁定。當服務提供者和服務請求者都在相似的環境中執行時，這種優化可能尤其重要。

圖 4 展現了 XML 消息傳遞（即 SOAP）和網絡協議如何組成Web 服務體系結構的基礎。

 

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

網絡節點在基於 XML 消息傳遞的分佈式計算中扮演提供者和請求者角色的基本要求是構建、解析 SOAP 消息的能力（或二者兼而有之），以及在網絡上通訊的能力（接收、發送消息，或二者）。

一般，在 Web 應用程序服務器中運行的 SOAP 服務器將執行這些功能。另外，咱們也能夠使用在 API 中封裝這些功能的特定於編程語言的運行庫。應用程序與 SOAP 的集成能夠經過使用四個基本步驟來實現：

在圖 4 中，服務提供者的應用程序在（1）建立一條 SOAP 消息。這條 SOAP 消息是調用由服務提供者提供的 Web 服務操做的請求。消息主體中的 XML 文檔能夠是一個 SOAP RPC 請求，也能夠是一個服務描述中所描述的以文檔爲中心的消息。服務請求者將此信息和服務提供者的網址一塊兒提供給 SOAP 基礎結構（例如一個 SOAP 客戶機運行時）。SOAP 客戶機運行時與一個底層網絡協議（例如 HTTP）交互，而後在網絡上將 SOAP 消息發送出去。 
網絡基礎結構在（2）將消息傳送到服務提供者的 SOAP 運行時（例如一個 SOAP 服務器）。SOAP 服務器將請求消息路由到服務提供者的 Web 服務。若是應用程序須要，SOAP 運行時負責將 XML 消息轉換爲特定於編程語言的對象。這個轉換由消息中能夠找到的編碼模式所控制。 
Web 服務負責處理請求信息並生成一個響應。該響應也是一條 SOAP 消息。響應的 SOAP 消息在（3）被提供給 SOAP 運行時，其目的地是服務請求者。在 HTTP 上的同步請求／響應的狀況中，聯網協議的底層請求／響應本質用於實現消息傳遞的請求／響應本質。SOAP 運行時將 SOAP 消息響應發送到網絡上的服務請求者。 
響應消息在（4）由服務請求者節點上的聯網基礎結構接收。消息會通過整個 SOAP 基礎結構；可能會將 XML 消息轉換爲目標編程語言中的對象。而後，響應消息被提供給應用程序。 
本示例使用了請求／響應傳送基本原理，這種原理在大多數分佈式計算環境中都很常見。請求／響應交換能夠是同步的，也能夠是異步的。其它傳送基本原理，如單向消息傳遞（無響應），通知（推進式響應）以及發佈／訂閱，也可能用到 SOAP。

那麼，服務請求者如何知道請求消息應該使用什麼格式呢？這個問題在下面會獲得回答。

 

服務描述：從 XML 消息傳遞到 Web 服務

服務提供者是經過服務描述將全部用於調用 Web 服務的規範傳送給服務請求者的。要實現 Web 服務體系結構的鬆散耦合，並減小服務提供者和服務請求者之間所需的共識的程度和定製編程與集成的程度，服務描述就是關鍵。例如，無論是請求者仍是提供者，都沒必要了解對方的底層平臺、編程語言或分佈式對象模型（若是有的話）。服務描述與底層 SOAP 基礎結構相結合，足以封裝服務請求者的應用程序和服務提供者的 Web 服務之間的這個細節。

基本服務描述

Web 服務體系結構使用 WSDL 做爲基本服務描述。WSDL 已經被提交到 W3C 做爲標準。WSDL 是一種 XML 文檔，它將 Web 服務描述爲一組端點，這些端點會處理包含面向文檔或面向過程的（RPC）消息的消息。操做和消息都是被抽象描述的，而後它們會被綁定到一個具體的網絡協議和消息格式，用來定義端點。相關的具體端點被合併到抽象的端點或服務中。WSDL 能夠擴展爲容許端點和其消息的描述，無論使用哪一種消息格式或網絡協議進行通信均可以。然而，目前通過描述的綁定只能用於 SOAP 1.一、HTTP POST 以及多用途互聯網郵件擴展（Multipurpose Internet Mail Extensions，MIME）。

Web 服務體系結構中對 WSDL 的使用按照常規將基本的服務描述分紅了兩部分：服務接口和服務實現。這使每一個部分均可以被分開獨立定義，並能夠由另外一部分從新使用。

服務接口定義是一種抽象或可重用的服務定義，它能夠被多個服務實現定義實例化和引用。咱們能夠將服務接口定義想象成接口定義語言（Interface Definition Language，IDL）、Java 接口或 Web 服務類型。這使常見的行業標準服務類型能夠被多個服務實現者定義和實現。這相似於在編程語言中定義抽象接口而後獲得多個具體實現。服務接口能夠由行業標準組織定義。

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

服務實現定義是一個描述給定服務提供者如何實現特定服務接口的 WSDL 文檔。Web 服務被建模成 WSDL: service 元素。服務元素包含一組（一般是一個）WSDL: port 元素。端口將端點（例如網址位置或 URL）與來自服務接口定義的 WSDL: binding 元素關聯起來。

爲了說明職責的安排，開放應用程序組（Open Applications Group，OAG）爲開放應用程序組集成規範（Open Applications Group Integration Specification，OAGIS）購買標準定義了一個服務接口定義。這個服務接口定義會定義 WSDL: type、WSDL: message、WSDL: portType 和 WSDL: binding。

服務提供者能夠選擇開發實現 OAGIS 購買訂單服務接口的 Web 服務。服務提供者會開發一個服務實現定義文檔，描述 WSDL 設備、端口和地址位置元素，這些元素描述提供者的 Web 服務的網址及其它特定於實現的細節。

服務接口定義和服務實現定義結合在一塊兒，組成了服務完整的 WSDL 定義。這兩個定義包含爲服務請求者描述如何調用以及與 Web 服務交互的足夠信息。服務請求者能夠要求得到其它關於服務提供者端口的信息。此信息由服務完整的 Web 服務描述提供。

 

完整的 Web 服務描述

完整的 Web 服務描述創建在服務基本的 WSDL 定義之上。完整的 Web 服務描述能夠解決這樣的問題：什麼企業在託管這個服務？它是何種類型的企業？與服務相關聯的產品有哪些？各類公司和產品類別中與該企業或其 Web 服務相關聯的分類有哪些？有沒有服務的其它方面（如服務質量）會影響到請求者是否選擇調用服務？爲了使查找該服務更容易，能夠提供哪些關鍵字？

圖 6 中描述了一個完整的 Web 服務描述。

圖 6. 完整的 Web 服務描述協議棧

UDDI 提供了一個保存 Web 服務描述的機制。雖然 UDDI 一般會被認爲是一種目錄機制，可是它也定義了一個用 XML 表示服務描述信息的數據結構標準。UDDI 條目中有四種基本數據結構，如圖 7 中所示。

圖 7. 基本 UDDI 數據結構

UDDI 條目由 businessEntity 開始。businessEntity 元素對關於企業的信息進行建模，包括基本的企業信息（例如企業名稱和聯繫方式信息是什麼？）、分類信息（例如這是何種類型的企業？）以及標識信息（即 Dunn and Bradstreet 編號是什麼？）。businessEntity 包含一組 businessService 元素，每一個元素對應於企業但願發佈的每一個 Web 服務。每一個 businessService 元素都包含和 businessEntity 元素的 Web 服務有關的技術性和描述性信息。businessService 包含一組 bindingTemplate 元素。bindingTemplate 描述訪問信息（例如端點地址），還描述 businessService 如何使用各類不一樣的技術規範。技術規範在這裏的模型是 tModel。tModel 能夠爲不少不一樣概念建模，如：一種服務、一個諸如 HTTPS 之類的平臺技術或一個類別。與 businessService 相關聯的那一組 bindingTemplate 元素表明了 businessService 所使用的技術的印記。

在Web 服務體系結構中，完整的 Web 服務描述包括用於端點描述的一層，這個端點描述使用 UDDI 條目向服務描述添加企業和實現環境。

端點描述遵循結合 WSDL 使用 UDDI 的約定。端點描述使用 UDDI 提供企業信息和類別的標準表示。這個 UDDI-WSDL 約定規定了如何從和 Web 服務相關聯的 UDDI 條目中得出服務接口定義和服務實現定義的 WSDL 描述。這個約定對於在Web 服務體系結構中使用 UDDI 做爲基於 WSDL 的服務的服務註冊中心來講相當重要。

端點描述嚮應用到服務的特定實現的服務描述添加了另外的語義。安全屬性能夠定義對 Web 服務的訪問進行控制的策略。服務質量屬性指定面向性能的能力，例如服務在必定時間內做出響應的能力，或所支持的可靠消息傳遞的級別。服務開銷屬性描述服務的資源需求。還能夠定義支持哪些對話語義。

服務描述協議棧中的最後一層是協議描述。協議描述反映兩個企業夥伴之間爲了完成一個多步企業交互而進行的 Web 服務調用的一個簡單的編排。例如，「協議定義」定義了購買協議中諸如購買者和出售者之類的角色。協議定義規定了每一個角色必須達到的要求。例如，出售者必須有接受報價請求（request for quote，RFQ）消息、購買訂單（purchase order，PO）消息和付款消息的 Web 服務。購買者的角色必須有接受報價（RFQ 響應信息）、發票消息和賬戶摘要信息的 Web 服務。這個簡單的 Web 服務到企業角色的編排對於在企業夥伴之間創建多步的、面向服務的交互來講相當重要。在不少不一樣的企業協議標準下，一個給定的服務請求者或服務提供者也許可以扮演購買者或出售者的角色。經過顯式地創建企業協議和每一個節點在企業協議中扮演各類角色的能力，請求者能夠選擇在面對各類提供者企業夥伴時加入哪一種企業協議。

這個領域充滿了創新。對於企業協議定義來講，目前尚未一個單獨的標準。ebXML 協做-協議概要和協定規範（ebXML Collaboration-Protocol Profile and Agreement Specification）描述了這些概念，但不是根據做爲該體系結構的一部分描述的 Web 服務技術而描述的。Web 服務流程描述和 Web 服務端點描述這兩層正處於開發中，它們能夠提供這個級別的服務描述。

 

服務描述的發佈和發現

服務發佈

Web 服務的發佈包括服務描述的生成和以後的發佈。發佈能夠使用各類不一樣機制。

生成服務描述 
咱們能夠生成、手工編碼服務描述，也能夠根據已有的服務接口定義組成服務描述。開發者能夠手工編碼整個服務描述，包括 UDDI 條目。有些工具能夠從編程模型和可執行 Web 服務的部署生成 WSDL，還有可能生成來自元數據構件的部分 UDDI 條目。部分服務描述可能已經存在（例如，Web 服務能夠基於一個行業標準服務接口定義），這樣就只須進一步生成一小部分就能夠了。

發佈服務描述 
服務描述能夠使用各類不一樣機制來發布。根據應用程序將使用服務的動態程度，這些不一樣的機制提供不一樣的能力。服務描述能夠使用多種不一樣機制發佈到多個服務註冊中心。

最簡單的狀況是直接發佈。直接發佈意味着服務提供者直接將服務發佈給服務請求者。這能夠經過使用電子郵件附件、FTP 站點甚至光盤分發來實現。直接發佈能夠在企業夥伴雙方就在 Web 上使用電子商務的條款達成一致後進行，或在請求訪問服務的服務請求者支付了費用以後進行。在這種狀況下，服務請求者能夠保留服務描述的一份本地副本。

稍微更動態一點的發佈使用 DISCO 或 ADS。DISCO 和 ADS 二者都定義了一個從給定 URL 獲取 Web 服務描述的簡單的 HTTP GET 機制。加強的服務描述資源庫會提供服務描述的一個本地高速緩存，不過還提供了附加的搜索能力。對於在企業內部跨越主機的服務描述資源庫來講，服務提供者會向專用的 UDDI 節點發布。咱們能夠根據發佈到節點的 Web 服務的域的範圍，使用幾種專用的 UDDI 節點。

內部企業應用程序 UDDI 節點（Internal Enterprise Application UDDI node）節點：公司內部爲了進行內部企業應用程序集成而使用的 Web 服務應該被髮布到這一類 UDDI 節點。此類 UDDI 節點的範圍能夠是部門的或公司的單獨的應用程序。這些 UDDI 位於防火牆以後，容許服務發佈者對他們的服務註冊中心和它的訪問權、可用性以及發佈要求有更多的控制。 
門戶網站 UDDI 節點（Portal UDDI node）節點：由公司發佈以供外部夥伴查找和使用的 Web 服務能夠使用門戶網站 UDDI 節點。門戶網站節點運行在服務提供者的防火牆以外或之間。這種專用 UDDI 節點只包含公司但願向來自外部夥伴的請求者提供的那些服務描述。這容許公司保留對他們服務描述的控制、UDDI 節點的訪問以及 UDDI 節點的服務質量。此外，經過使用門戶網站中固有的基於角色的可見性，企業將服務描述的可見性侷限在容許看到它們存在的夥伴中。 
夥伴目錄 UDDI 節點（Partner Catalog UDDI node）節點：由特定公司使用的 Web 服務能夠被髮布到夥伴目錄 UDDI 節點。夥伴目錄 UDDI 節點位於防火牆以後。此類專用 UDDI 節點只包含來自合法企業夥伴的通過容許的、測試過的、有效的 Web 服務。此類 Web 服務的業務環境和元數據能夠被定位到特定的請求者。 
電子市場 UDDI 節點（E-Marketplace UDDI node）節點：對於服務提供者打算用來與其它 Web 服務競爭請求者的業務的 Web 服務來講，服務描述應該被髮布到電子市場 UDDI 節點或 UDDI 運營商節點。電子市場 UDDI 節點由一個行業標準組織或社團託管，包含特定行業中的企業的服務描述。咱們能夠要求這些服務支持特定的標準、可搜索元數據、接口或數據類型。電子市場 UDDI 節點通常會過濾掉某些非法的條目，並提供有保證的服務質量。 
UDDI 運營商節點：若是您但願 Web 服務能夠被潛在的新的企業夥伴或服務用戶發現，還能夠將其發佈到 UDDI 運營商節點。IBM、Microsoft 和 Ariba 都支持、複製和託管 UDDI 運營商節點。在發佈 UDDI 運營商節點的時侯，若是要讓潛在的服務請求者發現服務的話，完整的業務環境和通過深思熟慮的分類法是很必要的。

圖 8. 服務發現連續體

圖 8 展現了從發佈和發現中最靜態、最簡單的技術到最動態、更復雜的技術的連續體。Web 服務的用戶或實現者沒必要嚴格遵循這個發展順序。

服務發現

Web 服務的發現包括獲取服務描述和使用描述。獲取過程能夠使用各類不一樣機制。

獲取服務描述

和發佈 Web 服務描述同樣，根據服務描述如何被髮布以及 Web 服務應用程序可能達到的動態程度，獲取 Web 服務描述也會有所不一樣。服務請求者將在應用程序生命週期的兩個不一樣階段，即設計時和運行時查找 Web 服務。在設計時，服務請求者按照他們支持的接口類型搜索 Web 服務描述。在運行時，服務請求者根據他們通信的方式或公告的服務質量搜索 Web 服務。

使用直接發佈方法時，服務請求者在設計時對服務描述進行高速緩存，以在運行時使用它。服務描述能夠被靜態地用程序邏輯表示，並存儲在文件或簡單的本地服務描述資源庫中。

服務請求者能夠在設計時或運行時在服務描述資源庫（簡單的服務註冊中心或 UDDI 節點）中檢索一條服務描述。查找機制須要支持一種查詢機制，它提供按接口類型（基於 WSDL 模板）、綁定信息（即協議）、屬性（如 QoS 參數）、所需的中介類型、服務分類法、企業信息等等的查找。

不一樣類型的 UDDI 節點會顯示能夠選擇的運行時綁定 Web 服務的數目、多選一的策略，或者調用服務以前必須由請求者做出預選的量。

內部企業應用程序 UDDI 節點和夥伴目錄 UDDI 節點將不須要預選來創建對服務的信任。服務選擇能夠創建在綁定支持、歷史性能、服務質量分類、類似性或負載平衡的基礎之上。

電子市場 UDDI 節點將有更多的運行時服務能夠選擇。必須執行某種預選以保證 Web 服務提供者是有價值的夥伴。咱們能夠根據價格承諾、開銷、通過容許的夥伴列表的出席狀況，一樣還有綁定支持、歷史性能、服務質量分類和類似性來選擇服務。

若是服務請求者從 UDDI 運營商節點查詢 Web 服務提供者，他們在預選可能的服務提供者時就必須儘量謹慎和認真。應該有一個有效和準確的機制就位，過濾掉無用的服務描述和沒有價值的服務提供者。

使用服務描述 
在獲取了服務描述以後，服務請求者須要處理它以調用服務。服務請求者使用服務描述生成對 Web 服務的 SOAP 請求或特定於編程語言的代理。該生成能夠在設計時或運行時進行，從而對 Web 服務的調用進行格式化。咱們在設計時和運行時能夠使用各類工具從 WSDL 文檔生成編程語言綁定。這些綁定表示應用程序的 API，並封裝了來自應用程序的 XML 消息傳遞的細節。

在下一部分，咱們將描述基本 Web 服務體系結構的擴展，電子商務須要這些擴展才能使用 Web 服務。

 

在下一部分，咱們將描述基本 Web 服務體系結構的擴展，電子商務須要這些擴展才能使用 Web 服務。

 

14.3.2 真正的電子商務的 Web 服務

雖然對於可互操做的 XML 消息傳遞來講 SOAP 和 HTTP 就足夠了，並且 WSDL 也足能夠傳達服務請求者和服務提供者之間須要什麼樣的消息，可是要覆蓋電子商務的所有需求還須要更多的技術。爲了徹底支持電子商務，安全性、可靠的消息傳遞、服務質量、Web 服務協議棧的每一層的管理都須要擴展。

 

安全性

真的須要 Web 服務安全層嗎？對於基於消息的體系結構，業界已經有一套現成的並且普遍接受的傳輸層安全機制，好比，安全套接字層（Secure Sockets Layer，SSL）和網際協議安全（Internet Protocol Security，IPSec），爲何還要再加別的呢？爲了回答這個問題，咱們不只要研究要求，還將探討一些只依靠現有的幾類傳輸層安全機制並不能在 Web 服務模型內提供足夠的安全性的狀況。

一般，Web 服務安全層必須提供如下四個基本的安全性要求：

機密性（Confidentiality）是指信息對沒有通過受權的我的、實體或進程的不可用性或不公開性，並保證消息內容不對沒有通過受權的我的公開。 
受權（Authorization）是指權限的授予，包括根據訪問權限授予訪問權和保證發送方被受權發送消息。 
數據完整性（Data integrity）是指數據沒有以未經受權的方式或被未經受權的用戶不可察覺的改變或者破壞的性質，從而確保消息在傳送的過程當中不會被偶然或故意修改。 
原始性證實（Proof of origin）是對消息或數據的發送者進行標識的證據。斷言消息由正確標識的發送者傳送，而且不會從新發送之前傳送過的消息。這一要求隱含了數據完整性的要求。 
因爲須要在基於 XML 消息和工做流的動態 Web 服務世界中管理不一樣風格的資源訪問，因此必須從新評估策略、信任和風險評估這三者相互之間的關係。現有的基於我的身份的訪問控制模型正在發展成爲基於角色的信任域關係，在該種關係中，可信任的權威機構將執行某項任務的權限授予我的，其行爲受該權限限制。Web 服務體系結構定義了須要信息的代理（服務請求者）、提供信息的代理（服務提供者），有時還有提供關於信息的信息的代理（服務中介者、元信息提供者或服務註冊中心）。服務中介者常常會收到大量信息請求，這樣就須要它可以決定誰想要哪些信息以及請求者是否是已經被授予訪問權。基礎設施和關係變化迅速，所以有關的策略須要能靈活的容許或拒絕訪問。

此外，儘管 XML 發誓要爲這樣的服務提供通用接口，但 XML 不會提供實現這一夢想所須要的整個基礎設施。並且，XML 可能不適合構建整個 Web 服務安全層。目標是要肯定在哪些場合用 XML 格式提供信息以顧及通用數據交換較爲重要，以及在哪些場合利用目前已存在於平臺之上的現有安全性機制較爲重要。

SOAP 信封是用 XML 定義的，從而使您能夠向消息添加種類衆多的元信息，好比事務 ID、消息路由信息和消息安全性。SOAP 信封由兩個部分組成：頭和主體。頭是把功能添加到 SOAP 消息中的通用機制。SOAP 頭元素下一級的全部子元素都叫作頭條目。主體是爲最終的消息接收方想要的應用數據（如 RPC）準備的容器。所以，能夠把 SOAP 看做是在傳輸層（例如 HTTP）和應用層（例如，業務數據）之間引入的另一層，在此能夠方便的傳送消息元信息。SOAP 頭提供可擴展機制以擴展 SOAP 消息使其能夠適用於多種用途。雖然 SOAP 頭是向消息添加安全性功能最合理的地方，可是 SOAP 規範自己並無指定這樣的頭元素。

讓咱們仔細的分析一下在 Web 服務模型中現有的各類各樣的傳輸層安全機制爲何不夠，又爲何會須要 Web 服務安全層，以及這個安全層最初是怎樣的。

端對端的消息傳遞。安全傳輸協議，如 SSL 和 IPSec，能夠在傳輸過程當中提供消息完整性和機密性，但只有在點對點的狀況下，它們纔會這樣作。可是，由於 SOAP 消息是由中介體接收並處理的，因此即使兩兩之間的通訊鏈路（communication link）是可信任的，只要在全部的中介體間沒有信任關聯（trust association），那麼安全的端對端通訊就是不可能的。若是有一條通訊鏈路不安全，那麼端對端安全性也會被削弱。就 Web 服務拓撲來看，安全的傳輸對於 SOAP 消息的端對端安全性是不夠的。

中間件的獨立性。最終，惟一能提供端對端安全性的方式就在於應用層或中間件層。若是消息在通訊方之間的某點是純文本，那麼就有可能在這點受到攻擊。可是，既要在新的或現有的應用中集成加密功能，又不能引入額外的安全性弱點或增長風險，這是一項不容易又不受歡迎的任務。所以，在大多數狀況下，人們但願安全性功能儘量靠近應用，但不在應用自己中構建。

傳輸的獨立性。SOAP 中介體的原意是用來把信息轉發到不一樣的網絡上去，一般使用的傳輸協議也會有所不一樣。雖然全部的通訊鏈路都是安全的，中介體也是值得信賴的，可是，安全信息（如消息發送者的身份驗證）須要被轉移到消息路徑上的下一個傳輸協議安全性域，這個過程冗長並且複雜，還可能會致使完整性方面的缺陷。

異步多階消息傳遞。傳輸層安全性保證數據在通訊鏈路上傳輸時的安全。它與存儲在任何中介體上的數據都無關。在一次傳輸被接收並解密後，傳輸層安全性對保護數據免受沒有通過受權的訪問和可能的改變就不是頗有幫助了。在先存儲消息而後轉發的狀況下（持久的消息隊列），消息層保護是有必要的。

由於咱們已經看到安全的傳輸機制不足以知足 Web 服務開發方法和使用場景的要求，因此咱們的任務就是要建立一個概念性 Web 安全層，包括下列幾個組件：

對於網絡安全性： 
支持如 SSL 和 HTTPS 等提供機密性和完整性的安全傳輸機制。 
對於 XML 消息： 
若是通訊沒有中間節點，那麼發送方能夠依靠 SSL 或 HTTPS 來保證用戶標識和密碼的機密性。 
W3C 正在標準化 XML 數字簽名工做的支持。它定義了生成消息摘要與利用發送方的私鑰來簽發消息的標準 SOAP 頭和算法。所以，接收方就能夠證實消息發送方的身份。 
對網絡內部的、可信任的第三方驗證服務（例如 Kerberos）的支持。 
概念性 XML 消息傳遞模型還必須支持端對端保護消息及其子元素。爲了全面的支持，過程和流能力須要被擴展到包括消息交換的安全性特徵。應該有一種方式能夠定義多段消息和用預期接收方的公鑰來保護消息段。須要探討的一些論題有：

端點負責實現驗證及受權。應該支持在企業之間交換信息的合同的任何描述中都要定義哪些僱員能夠使用哪些服務。中介體負責審計和服務原始性證實。中介體還可能須要執行驗證、受權和數字簽名驗證以及有效性檢查。 
在服務端點的服務描述層中須要定義支持上文論述的安全性問題的面向安全性元數據。這些安全性描述將根據主體或角色定義 Web 服務層訪問控制。服務描述將會描述是否支持數字簽名、加密、驗證和受權以及如何支持它們。 
請求者將使用服務描述的安全性元素來查找服務端點，該端點應符合政策要求及其安全性方法。 
標準組正在調查以下主題和技術。隨着這些標準固定下來，它們將會被併入 Web 服務安全性體系結構。

W3C 有一個 XML 加密工做組，幫助提供數據元素的機密性，這樣驗證交換成爲可能。 
W3C 已發佈了一個 XML 密鑰管理服務（XML Key Management Services，XKMS）的備忘錄，來幫助分發及管理在端點之間進行安全的通訊所需的密鑰。 
OASIS 已經成立了一個技術委員會來定義受權和驗證斷言（Authorization and Authentication assertions，SAML）。這將幫助端點接受和決斷訪問控制權。 
OASIS 已經成立了一個技術委員會來標準化訪問控制權的表達（XACML）。這將幫助端點可以以一致的方式解析 SAML 斷言。 
隨着咱們不斷的研究 Web 服務模型中遇到的全部威脅和對策，Web 服務安全性體系結構也在不斷髮展着。

 

服務質量（QoS）和可靠的消息傳遞

服務質量垂直塔提供與 Web 服務概念棧每一層有關的信息的規範。對於網絡層，這將會暗示能使用各類級別的服務質量的網絡。

因爲須要經過網絡進行可靠的消息傳遞，因此得根據在這一領域內發送高質量服務的能力來選擇網絡技術。可靠的消息傳遞指基礎設施把消息一次發送（只發送一次）到預約目標或提供肯定的事件（若是發送沒能完成，也許會從新發送到源）的能力。結合網絡層與 XML 消息傳遞將須要支持四個等級的消息傳遞服務質量：

1. 最佳努力：服務請求者發送消息，服務請求者和基礎設施不嘗試重發。

2. 至少一次：服務請求者提出請求，並一直重試直到它接收到確認爲止。服務提供者重複消息處理不是問題，例如簡單的查詢處理。實現這可能意味着每一個消息包含惟一的標識。服務請求者以本身肯定的時間間隔重發沒有獲得確認的消息。服務提供者發出確認消息，爲 RPC 響應消息，若是不能處理的話，就發送不能處理的消息異常。

3. 至多一次：這創建在最少一次狀況的基礎之上。服務請求者試着請求直到它獲得迴應。象現有的全局惟一標識符（universal unique identifier，UUID）這樣的機制容許服務提供者抑制重複屢次的請求，以確保請求不會被屢次執行。例如，請求根據庫存目錄中的一個號碼拿一件東西。

4. 恰好一次：服務請求者提出請求，請求已經執行的迴應使其獲得保證。恰好一次交換模式排除了重傳請求的須要而且適應失效的狀況。

可靠的消息傳遞一般是經過標準設計模式傳送的，在該模式中，一件基礎設施，有時叫作端點管理器，將會被用來在通訊的每一端協調消息發送。在這種模式中，發送方經過同步請求把消息發給端點管理器。一旦發送到，發送方就能夠獲得保證，必定會把消息發送出去或引起肯定的事件（例如超時）。端點管理器與其它資源管理器參與本地事務，在一次事務中不只能夠由端點管理器對消息進行排隊，還有可能在數據庫中記錄業務過程步驟。應用程序應該指派端點管理器來負責發送消息或者檢測發送失敗的緣由，它在網絡傳輸層或 XML 消息傳遞層均可以起做用。

可靠的一次性消息發送的技術和目的都不會引發爭議。可是，圍繞如何在 SOAP 和 XML 的上下文中支持這項技術已經提出了重要的質疑。關鍵問題是：應不該該在 XML 消息層上定義必要的協議和消息格式，從而容許可靠的消息發送成爲兩端應用程序的責任，或者能不能在較低的層（如傳輸層上）定義協議和消息格式？

在沒有支持可靠的消息傳遞的傳輸方式的狀況下（即互聯網），XML 消息傳遞層將須要在不可靠的基礎設施之上支持這些服務質量。端點管理器將須要修改消息，而不是修改消息的傳輸信封，這樣才能成功扮演其角色。應用程序和業務過程的定義將必須考慮全部可能的結果，如拒收消息或在可接受的時間長度內發送不出去。可是，這些定義還須要考慮在發送過程當中發生的中間狀態。向業務過程公開這些狀態可能會大大增長其定義的複雜程度，但對於定義過程的業務分析師而言並沒有太大意義。在一些狀況下，使用 XML 消息傳遞來發送可靠的消息傳遞格式可能會致使使用現有的這些傳輸毫無效率。最好能開發一種在互聯網上使用的可靠的 HTTP 標準。

在有支持可靠的消息傳遞的傳輸方式的狀況下（即在企業內部），它能夠用於發送可靠的消息，而不是 XML 消息傳遞層（可能缺省爲空實現）。端點管理器將會只修改傳輸信封，而不會修改 XML 消息。使用可靠的傳輸使應用程序和業務過程定義不須要知道或處理消息發送的中間狀態。

須要在未來進行的幾點補充：

互聯網的 HTTP 須要加以改進才能提供能夠在企業間使用的簡單可靠的消息傳遞。這會帶來額外的好處：不止 SOAP，許多種消息類型均可以採用可靠的消息傳遞。須要 XML 消息傳遞層處理可靠的消息傳遞的狀況就會隨之減小，促進不依賴於網絡選擇的應用程序開發。 
HTTP 上的 XML 消息傳遞層也須要處理髮布和訂閱、消息排序、發送時間限制、優先級和多點傳送等等問題。 
服務提供者對可靠的消息傳遞的質量和實現的支持狀況將會在服務描述的綁定信息中定義。

服務實現層（例如，經過事務的或安全的 SOAP 綁定）的服務描述以及接口層（例如，從請求者開始等待來自提供者的響應以後最長通過多久）的其它服務描述中都會關係到服務質量（Quality of Service）信息。人們期待着開發出 WSDL 擴展或新的服務描述層來容許指定其它服務質量和功能的規範。

Web 服務層上的服務質量能夠在服務合成和服務流中使用。在爲流選擇服務或提示流管理器該開始恢復或其它的流時，預期的執行時間、超時值、歷史平均執行時間值均可以做爲輸入。服務描述棧的端點描述層和工做流描述層必須提供這一信息。

Web 服務的服務質量問題和解決方案仍然很緊迫。

 

系統和應用程序管理(Management)

隨着 Web 服務成爲商業運做的重要因素，就須要對其進行管理。在這種狀況下，所謂管理是指專爲應用程序定製的或從廠商那裏買來的管理應用程序能夠發現 Web 服務的基礎設施、Web 服務、服務註冊中心和 Web 服務應用程序存在性、可用性以及健康度。最使人滿意的結果是管理系統還應當可以控制和配置基礎設施及組件。

管理概念性 Web 服務棧各層的 Web 服務和 Web 服務模型組件一定是有可能的。對管理的需求能夠分紅兩個集中的領域。第一個領域是用於實現 Web 服務的基礎設施的可管理性。主要的考慮應當是確保可用性和提供服務描述、消息傳遞和網絡的關鍵元素的性能。Web 服務基礎設施提供者應當提供這一層上的系統管理。

企業對其本身的基礎設施及管理擁有徹底的自主權。可是，當企業在對等基礎上相互做用時，就應當提供對網絡層、XML 消息傳遞層、服務註冊中心和 Web 服務實現的基本報告和恢復辦法。此外，企業向其合夥人提供的管理接口應當是在服務層上操做的，而不是在相對低級的基礎設施層上。合夥人應該可以訪問到報告操做和請求處理的狀態和健康度的接口，但不必定要理解企業如何管理其請求的細節。

對於網絡層，現有的網絡管理產品幾乎支持目前全部的網絡基礎設施。這些產品應當用於管理企業內部的 Web 服務的網絡基礎設施。當企業相互做用時，就應該向其合夥人提供有關 Web 服務基礎設施可用性的基本報告。影響 Web 服務基礎設施可用性的網絡可用性應做爲因素之一寫入報告。

在 XML 消息傳遞層，協議應該在企業內部由現有的基礎設施管理工具來管理。在企業相互做用的狀況下，每一個站點都有必要提供協議的基本報告和恢復辦法。例如，若是站點 A 支持會話，就該向站點 B 提供可用於查詢活躍的 IBM Software Group Architecture Overview Web Services Conceptual Architecture 28 會話以及強行回滾的接口。協議層須要正常的頻道與協議和相似對等的控制接口。

管理的第二個方面是 Web 服務自己的可管理性。一些主要的考慮是性能、可用性、事件和使用量度，由於它們將爲服務提供者市場收取所提供的服務使用費提供必要信息。

服務描述能夠用於宣傳可管理性特徵和管理需求。這方面的約定正在開發之中。

服務註冊中心的任何實現，無論是用於私人消費仍是公共消費，都要求基礎設施是可用的、發送承諾的服務質量並可以報告使用狀況。這些系統管理元素對於成功採用 UDDI 是十分重要的。

對於 Web 服務應用程序組件來講，支持管理環境可能會大大增長應用程序的複雜性。因爲 Web 服務必須易於開發，因此必須儘量向開發者隱藏這樣的複雜性。Web 服務的管理方式要使基礎設施能自動提供量度、審計日誌、啓動和中止處理過程、事件通知和做爲 Web 服務運行時的一部分（也就是說，起碼是 SOAP 服務器）的其它管理功能。由於基礎設施經過觀察它所託管的組件的行爲不可能收集到全部的信息，因此 Web 服務實現也許會須要向託管它的服務器提供基本的健康度和監督信息。

Web 服務基礎設施應該爲服務提供一種簡單的方式以參與管理和利用管理基礎設施。可管理的服務的 WSDL 文檔的定義應當是 Web 服務能實現提供經過管理系統訪問 Web 服務的管理信息的功能。這一接口可能包括的能力是得到配置和量度數據、更新配置及接收來自可管理的 Web 服務的事件。

Web 服務體系結構的平臺獨立性使它不適合套用任何一條 Web 服務管理標準。所以，須要有一種基於 Web 服務並且容許 Web 服務與管理系統通訊的方法。爲了達到這一目的，還應當定義由 WSDL 文檔描述的、可接收來自可管理 Web 服務的事件以及量度更新的管理服務，並使其可用。管理服務的實現技術與 Web 服務無關。可是，對於基於 Java 技術的環境，Java 管理擴展（Java Management Extension，JMX）應該是合乎邏輯的並且廠商不可知的選擇。經過使用 JMX 這樣的開放標準，對現有的系統管理提供者來講，要把其目前所提供的產品擴展爲包括 Web 服務關鍵元素的管理應該是很容易的。Web 服務的管理體系結構仍在向前發展。

 

14.4 Web Services 項目實戰

14．4．1 Web Services實現

 

本書是重點講解EJB 3.0的。在理解了Web Services原理以後， 接下來咱們講解如何使用J2EE和EJB3.0來實現Web Services

 

Web 服務遵循 Java 2 平臺，企業版（Java 2 Platform，Enterprise Edition，J2EE）、通用對象請求代理體系結構（Common Object Request Broker Architecture，CORBA）以及其它針對與耦合較緊的分佈式或非分佈式應用程序集成的標準。Web 服務是部署並提供經過 Web 訪問業務功能的技術；J2EE、CORBA 和其它標準是實現 Web 服務的技術。

 

J2EE 1.4爲使用常規Java類或企業級Java Beans來建立和部署web services提供了一個全面的平臺。如下表格給出了J2EE 1.4中包括的web service APIs的細節。 

定義在Java Community Process的JSR 101之下的JAX-RPC，提供了建立和訪問web services的Java API,所以它是使用J2EE平臺建立和部署web services的「心臟和靈魂」。經過嚮應用程序開發者隱藏XML類型和Java類型映射的複雜性，以及處理XML和SOAP消息的底層細節，它提供了一個簡單的，健壯的建立web services應用的平臺。爲了引入一個方法調用範式，它提供了兩種編程模式:服務器端模式，使用Java類或無狀態EJB開發web service 端點，和客戶端模式，建立做爲本地對象訪問web services的Java客戶端。JAX-RPC 1.1要求使用SOAP 1.1，而且實現與使用其餘技術建立的web services之間的互操做性，好比微軟的.NET。實現了J2EE1.4規範的應用服務器，好比OC4J 10.1.3和SUN的Java System Application Sever,提供了對於JAX-RPC的支持。

JAX-RPC的叫法有點用詞不當，由於它既支持RPC類型的web services，也支持文檔類型的web services。

Web Services部署模型

在J2EE 1.4以前，全部J2EE商家都使用他們私有的部署模型支持web services。J2EE 1.4爲Java Web Services定義了部署模型。它爲J2EE平臺上的web services制定了開發，部署以及服務發佈和使用的標準。

有了J2EE 1.4對web services的支持，讓咱們學習使用J2EE平臺來建造web service的方法。

使用J2EE建立一個Web Service

把web service建立成一個輕便的和可互操做的分佈式組件不是一項瑣碎的任務。如以前討論的，你既能夠把常規Java類，也能夠把無狀態EJB部署成web services。常規Java類被打包在一個web模塊中，而EJB web services被打包在標準的ejb-jar模塊中。

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

Java 類對無狀態EJB:永無止境的爭論

你會選擇常規Java類仍是EJB做爲你建立web service的技術多是一個長期的爭論。Java類比EJB更容易開發，它是純的Java對象，而且它不具備EJB帶來的「額外輜重」。可是，EJB提供了幾個很好的特色，好比被聲明的事務和安全性，所以它使開發者將精力集中於創建商業邏輯，而不須要擔憂基礎服務架構。EJB 3.0大大簡化了設計模型，在它的規範中，EJB看起來就像常規Java類。

使用J2EE 5.0簡化SOA的開發

　　使用J2EE建立面向服務的應用程序確實很困難，所以經過使用由JSR 181定義的Web Services 元數據註解，J2EE 5.0將使開發更簡單。EJB 3.0和Web Services元數據具備類似的目標，就是向開發者提供親和力。

　　爲了在J2EE 1.4中開發一個簡單的Java web service，你須要幾個web service定義文件:WSDL，映射文件和幾個冗長的標準以及私有的web services部署描述符。Web Services元數據規範使用一種相似於EJB 3.0的缺省配置方法來使開發更簡便。Web Services元數據註解處理器(或web services 裝配工具)會爲你生成這些文件，所以你只須要關心類的實現。

　　當你使用Web Services元數據開發時，這是一個看起來如此簡單的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使用常規Java類簡化了EJB的開發。經過利用EJB 3.0和Web Services元數據，開發基於EJB的web services將會變得愈來愈簡單。當使用EJB 3.0和web services元數據時，這是一個看起來如此簡單的HelloWorld EJB web service。你沒必要擔憂建立WSDL，部署描述符等等，應用服務器會在部署過程當中生成這些定義文件。

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的實現類:

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元數據和EJB 3.0，服務開發正在變得愈來愈簡單。如今，你能夠在實現了J2EE規範的應用服務中，好比JBoss Application Server等，開始建立和部署你的web services了。

14.4．2 Web Services 項目實戰

14.4.2.1 Web Services的實現
本節使用EJB 3.0 實現一個web Services登陸的例子。下面咱們建立一個工程叫：EmployeeManager。加入用到的EJB 3.0的jar包。

咱們先建立服務器端的實體Bean，這和建立普通的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;

}

}

接着建立遠程接口：

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接口是要實現的，@SOAPBinding(style=Style.RPC)，Soap的綁定方式也是須要的，否則在客戶端是找不到LoginDao 。

下面建立會話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;

}

}

至此服務器端的類是建好了，這裏又兩個問題，須要說明一下

A． 兩個類的方法中都沒有拋出異常，可不能夠拋出呢? 能夠。但到實現SOA的時候會有一些問題，就是異常在經axis 經過WSDL2Java 生成後，在程序運行時有可能會出現找不到的情形。因此本文爲了讓你們在仿照這個例子時都能成功，因此也就拋棄了異常的拋出。

B． 兩個類的方法的返回值是基本類型，而不是自定義類型，爲何會這樣呢，自定義類型能夠不能夠呢，能夠。

如今咱們的webservice的服務器端就已經建立好了，咱們把服務器端的三個類和persistence.xml文件一塊兒打包部署到jboss服務器裏。包名是：empdEjb。

下面咱們來建立客戶端：

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!");

}

}

}

把服務器端發佈出去之後，服務器端會自動發佈一個webService，而且生成併發佈一個WSDL文件，經過訪問http://localhost:8080/empdEjb/LoginDaoBean?wsdl這個網址是能夠找到的。http://bean.webservice.ascent.com/jaws 和 LoginDaoService 字符串，在客戶端程序當中出現了上面兩個字符串，它們在你生成的wsdl 文件中有詳細的描述。在地址欄裏輸入http://localhost:8080/empdEjb/LoginDaoBean?wsdl，就能夠看到wsdl文件了。這裏你所須要作的是按照你本身的狀況編寫你本身的客戶端程序。啓動服務器後，在機子上運行客戶端程序就能夠了。固然你也能夠去編寫本身的jsp客戶端去調用它。wsdl文件的內容以下：

<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的例子就實現了。

14.4.2.2 SOA的實現
本例仍是基於前兩個例子的基礎上的，要保證上面的例子是能正常運行的。

1.WSDL2Java
從名字上能夠看出，是把wsdl 轉化爲java的.在上面的例子中咱們在服務器端生成了一個wsdl文件，如今要作的就是你把那個wsdl文件給別人或者別的公司，讓他們根據wsdl中所描述的你所提供的服務，去開發一個應用，來訪問你所提供的接口。拿到這個WSDL文件後要作什麼呢，to java。咱們來看看怎麼to java。

這裏，在原來的EmployeeManager工程下面建一個wsdl文件夾，將它放在下面，而後所要作的準備工做是，把包括axis在內的幾個jar包找到，設置在你的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 裏面所設置的幾個jar包，後面兩個能夠不須要，第二個也能夠不須要，後倆個只是保證運行的時候沒有警告。

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

2． 在命令行下進入E:\workspace\EmployeeManager\wsdl

3． 執行 java org.apache.axis.wsdl.WSDL2Java LoginDaoBean.wsdl

這個時候，你會發如今wsdl文件夾下面生成了一個目錄，它裏面包含了幾個java類。

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

2 SOA的實現
本節是一個以SOA+struts實現登陸的例子。新建一個web工程，EmployeeWebService，而後將上面生成的幾個類放入你的src目錄下面，是放整個目錄，別隻放幾個類進去. 構建struts資源。建立struts的過程就不在這裏細說了。建立的action內容以下：

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文件生成的類。如今就能夠打包成叫employee的war文件，運行它。至此，你即可以在瀏覽器中輸入http://localhost:8080/employee/login.jsp，運行你這個SOA的應用了。若是是把服務器端部署到別的機器上，只要把localhost改成相應的ip就能夠了。

小結本章首先介紹了目前一個前沿技術：Web Services和麪向服務的軟件架構（Service Oriented Architecture，簡稱SOA）。在理解了Web Services原理以後， 接下來咱們講解了如何使用J2EE和EJB3.0來實現Web Services。