Web服務（Web Services）是目前程序設計領域中的一項新技術，是一個嶄新的分佈式計算模式，在不同系統平臺之間具有互操作性，通過因特網，實現不同應用程序之間的遠程過程調用。Web服務使用基於XML 的消息處理作爲基本的數據通訊方式，消除使用不同組件模型、操作系統和編程語言的系統之間存在的差異，使異類系統能夠作爲單個計算網絡協同運行。開發人員可以用象過去在創建分佈式應用程序時使用組件一樣的方式創建將來自各種源的Web服務組合在一起的應用程序。 Web服務是建立在一些通用協議的基礎上，如HTTP，SOAP，XML，WSDL，UDDI等。這些協議在涉及到操作系統、對象模型和編程語言的選擇時，沒有任何傾向，因此將會有很強的生命力。
J2EE的Web服務工作原理
1.J2EE的Web服務模型
大家知道，普通Web服務的系統架構是面向服務的，服務的發佈的發現是Web系統架構中首先要解決的主要問題。在java編程環境下，Web 服務通過JAXR（java API for XML Registries）實現自身的發佈。客戶使用同樣的JAXR API尋×××，使用JAX-RPC綁定和調用Web服務。如下圖1所示：
圖 1
2.J2EE在消息發送層（SOAP）和傳輸協議層（HTTP）的工作過程
用下圖2可以說明，在具有Web服務功能的應用程序服務器上運行着一個標準的J2EE應用程序。在圖中的左上角是Java，C++或C#客戶機，現在，這個應用程序發出SOAP請求。該SOAP請求把Web服務操作封裝在一個XML有效載荷中，然後，通過HTTP協議傳送。在Web服務端，傳輸層繼續把該調用輸送劍SOAP服務端，然後，服務器就調用相應的已經展現爲Web服務的J2EE功能。Web服務產生的任何響應都會被再編碼成爲一個SOAP響應，並通過HTTP協議傳輸回客戶機去。
圖 2
從圖2中可以清楚地看出，利用消息發送層(Messaging layer) (SOAP)和傳輸協議層(Transoort Network laver) (HTTP)就可以完成應用程序內部的通信。應用程序內部通信的問題通過一些銷售商的專有技術(例如CORBA和DCOM等)以前就已經解決了。這些技術操作起來很麻煩，並且，也不能通過防火牆。因此，現在我們用SOAP，通過簡單的XML這個開放式的標準，就可以有效地實現應用程序內部的通信，不會使自己鎖定在某個銷售商的專有機制上。
3.J2EE在消息發送層（SOAP）、傳輸協議層（HTTP）和Web服務描述（WSDL）的工作過程
圖3顯示的是對前面所介紹的Web服務模式的簡單擴展；在圖3中只需要在兩個應用程序之間傳遞的SOAP消息之間存在着緊密的耦合。現在，有了一個附加的Web服務描述層，服務提供者就可以用建立和發行WSDL文檔的方法來描述他們的Web服務。WSDL文檔中不僅包含有該Web服務的抽象定義，而且也包含有實現(綁定)該Web服務的細節。這意味着服務的消費者(即例子中的客戶應用程序)需要得到WSDL文檔，它不僅可以從這個文檔中得到包括Web服務的消息和數據類型的不同操作，而且還能夠重新得到該Web服務的終端(例如URL)，SOAP消息可以在終端上交換。如果J2EE服務是通過SMTP消息展示功能的，那麼WSDL文檔也會描述這一點。
圖 3
4.J2EE使用UDDI、WSDL和SOAP三種技術的工作過程
在圖4中假設服務提供者已經決定把某項商業功能展示成Web服務。該Web服務駐留在一個基於Java的Web服務系統中。通過圖中的順序步驟看一下整個的工作機制。
圖 4
1）服務提供者的第一步是編寫WSDL文件。當前市場上有好幾種工具，可以幫助我們用現有的對象定義產生出WSDL文件。然後，需要發佈關於它自己的信息，把商業和這項Web服務的技術規範作爲-個WSDL文件發佈到中心UDDL註冊表。這樣，用寫WSDL文件的方法使得Web服務的描述佔據了服務描述層。但是，在Web服務棧中我們看到，發佈的商業信息和WSDL文件表現的是Web服務棧中的服務發佈層。
2）服務消費者應用程序可以發現它有興趣使用的Web服務。發現不僅涉及到要搜索商業和它的服務，而且還要下載WSDL文件中所提到的技術規範。發現的步驟對應於Web服務棧中的服務發現層。
3）最後，服務消費者應用程序用WSDL文件來確定，爲了與服務提供者的Web服務通信，需要傳送哪些消息，並且它還要決定綁定信息。爲了達到這個目的，綁定信息就是HTTP上的SOAP。這個步驟對應於Web服務棧中的XML消息和傳輸層。
J2EE的基本Web服務體系結構
下圖5是對J2EE系統的Web服務體系結構整體描述。
圖 5
商業功能性
上圖是一個Web服務提供者展示他們Web服務的功能。重要的是要理解，商業機構不會選擇他們現有的基於J2EE應用程序，並把他們的EJB展示爲Web服務的。雖然用Web服務平臺或目前市場上出售的工具在技術上是可行的，但是在商業上這樣做是沒有現實意義，因爲商業不在組件中展示方法調用。在商業上他們展示的是商業功能，這些功能會轉換成一系列執行該商業功能所需要的協調動作。在即時返回服務消費者的響應中可能有也可能沒有結果，還可能需要幾天的時間才能完成。商業也需要通過多層開發系統的功能性，需要記住幾個安全性等級和由不同的內部應用程序使用。例如，假設有一個在因特網上售書的商業機構G，比方說，他們決定在因特網上把一項在線訂書服務展示爲Web服務。當顧客下訂單的時候，訂單信息在商業企業G內部啓動了一個交易過程。這個交易過程需要執行多項行動，例如，檢查圖書訂單的總量或執行一個財務事務處理過程。這涉及到顧客把錢劃到商業G賬上，最後，給運輸部門送一份消息，讓他們把書送給顧客。從圖5中的J2EE系統功能圖可以看出，這個交易過程可能需要與各種EJB發生交互作用，而這反過來又與企業信息系統或跨機構的數據庫產生交互作用。在所有這些交易過程中，交易的完整性以及顧客想從認真企業級的交易過程中得到的任何其他標準都需要保存起來。
Web服務系統
Web服務系統類似於J2EE中的容器(container)的概念。它給執行Web服務提供了一個運行時間環境。爲了進行討論的目的，完全可以說在較高的級別上Web服務系統會包含一個Web服務運行時間環境，該運行時間環境能接受SOAP請求並把它們映射到對應的Java組件，即在商業功能性中共享的Java類或EJB。同時，從該商業過程中收集的所有結果都是可靠的，並被封裝在SOAP響應中，送回Web服務的客戶機。
Web服務器
Web服務器是從Web服務客戶機發出SOAP請求到服務提供者收到這個請求的過程中最主要的網關。Web服務器通過HTTP協議進行通信，通常在端口80收聽。因爲SOAP消息需要在HTFP上傳輸，所以它很適合進入我們的XML消息層和傳輸層。我們在圖5上應當注意到的一件重要事情是，事實上WSDL文件是存放在Web服務器上的，因爲這樣它給服務的消費者提供了全球性的可訪問機制，使他們能查閱WSDL技術規範。因此，如果我們提供了一個在UDDI註冊表作爲URL引用的WSDL文件的話，服務消費者就可以很容易地通過URL找到該WSDL，並對它進行轉換，以確定該機構支持的服務和服務的終端。
Web服務器還在整個系統中執行另外一種重要功能。這種功能會把適當的SOAP請求轉送到Web服務系統去。
Web服務客戶機
Web服務客戶機是Web服務的消費者。由於Web服務是不確定平臺的，因此用目前任何一種主流編程語言寫成的客戶機都可以調用Web服務。例如，它可能是一個Java程序，一個Visual Basic程序或者一個C++程序。Web服務客戶機要做的第一步工作是查閱UDDI信息，查找能提供它感興趣的Web服務的商業。從UDDI信息中重新得到WSDL URL引用，並從可公開訪問的URL下載WSDL文檔。通常，URL指的就是從圖5中的Web服務器。一旦得到了WSDL文件，服務消費者就有了調用該Web服務所需要的技術信息。技術信息我們指的是該Web服務中的方法。該方法需要的參數，該方法的數據類型和終端信息。可以根據WSDL文件產生SOAP客戶代碼，然後再把產生的SOAP客戶代碼嵌入到客戶機巾，以便調用該Web服務。