SOAP
當商業用戶通過UDDI找到你的WSDL描述文檔后，他通過可以Simple Object Access Protocol (SOAP) 調用你建立的Web服務中的一個或多個操作。
SOAP是XML文檔形式的調用商業方法的規范，它可以支持不同的底層接口，象HTTP(S)或者SMTP。之所以使用XML是因為它的獨立于編程語言，良好的可擴展性以及強大的工業支持。之所以使用HTTP是因為幾乎所有的網絡系統都可以用這種協議來通信，由于它是一種簡單協議，所以可以與任何系統結合，還有一個原因就是它可以利用80端口來穿越過防火墻。
SOAP的強大是因為它簡單。SOAP是一種輕量級的，非常容易理解的技術，并且很容易實現。它有工業支持，可以從各主要的電子商務平臺供應商那里獲得。
從技術角度來看，SOAP詳細指明了如何響應不同的請求以及如何對參數編碼。一個SOAP封裝了可選的頭信息和正文，并且通常使用HTTP POST方法來傳送到一個HTTP 服務器，當然其他方法也是可以的，例如SMTP。SOAP同時支持消息傳送和遠程過程調用。以下是一個SOAP請求。
POST /StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI"
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
<SOAP-ENV:Header>
<t:Transaction xmlns:t="some-URI" SOAP-ENV:mustUnderstand="1">
 5
</t:Transaction>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<m:GetLastTradePrice xmlns:m="Some-URI">
<symbol>SUNW</symbol>
</m:GetLastTradePrice>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
JAX/RPC
為了使開發人員專注于建立象SOAP那樣的基于XML的請求，JCP正在開發基于RPC (JAX/RPC) 的Java API。JAX/RPC是用來發送和接收方法調用請求的，它基于XML協議，象SOAP，或者其他的象XMLP (XML Protocol，要了解更多可以參考http://www.w3.org/2000/xp/)。JAX/RPC使你不用再關注這些協議的規范，使應用的開發更快速。不久，開發人員就不用直接以XML表示方法調用了。
目前有很多第三方實現了SOAP，開發人員可以在不同的層次上調用SOAP，并選擇使用哪一種。將來，JAX/RPC會取代這些APIs并提供一個統一的接口來構造以及處理SOAP RPC請求。
在接收一個從商業伙伴那里過來的SOAP請求的時候，一個Java servlet用JAX/RPC來接收這個基于XML的請求。一旦接收到請求后，servlet會調用商務方法，并且把結果回復給商業伙伴。
ebXML
對于具有高擴展性的商業交易來說，他們需要一種可信任的結構來實現商業事務，多請求的事務，計劃以及文檔流程，應用的需求經常超越了基于純SOAP的實現。因為SOAP只是提供了一個底層的結構，而你可能需要一個更高級的框架結構。
ebXML就是為了這個目的的，它是一套處理B2B應用間的合作與通信的XML規范。以下是ebXML中的關鍵組件：
Collaboration Protocol Profile (CPP)
CPP提供了一種標準并且簡單的方法描述了公司提供的產品。另外，它還描述了消息交換的能力以及公司支持的商務合作。它也描述了公司的商務處理方法，包括合伙人如何與公司合作。CPP定義了B2B交易中雙方的商務協作。例如，它同時定義了買賣雙方的商務處理方法。
Collaboration Protocol Agreement (CPA)
CPA描述了兩個公司之間進行交易時的詳細需求以及機制。它包含有由手工或者自動從經過買賣雙方認可的CPPs中的信息。這個CPA是雙方進行指定交易的合約。
CPP和CPA的樣例，以及關于規范的細節可以從以下網站獲得：
http://ebxml.org/project_teams/trade_partner/cpp-example.xml http://ebxml.org/project_teams/trade_partner/cpa-example.xml http://www.ebxml.org/specs/ebCCP.pdf
Business Process and Information Modeling
ebXML還以XML的形式描述了商業事務處理的規范。它包括交易，文檔流程，數字通信，數據封裝格式以及其他更多。這些規范是用來建立CPPs，描述以及共享商業事務和信息時用的。

Core Components
ebXML中另外一個重要的部分是一系列的XML標記，我們叫它核心組件。這些標記包含了商務數據，象日期，稅，賬戶，交易合同以及其他的。它指明了商業合約和實體，但對每個不同的行業，可能都不一樣。
Messaging
ebXML消息格式包含了所有相關的消息導向信息（同步或者異步，可靠性）。一般來說，一個ebXML消息包含了CPA中的可視化內容，并強制執行交易規則。
EbXML是建立在SOAP消息封裝機制上的。它擴展了SOAP的協議，增加了多層框架結構來支持附件，安全性以及傳送的可靠性。
Registry/Repository
EbXML注冊中心是存儲CPPs, CPAs, ebXML核心組件和與ebXML相關的文檔的服務。它具有強大的查詢功能，允許用戶查找相關的組件以及發掘潛在客戶。JAXR API也可以用來訪問ebXML注冊中心。商業服務定義了CPPs，并且被存儲在ebXML注冊中心，然后發布到UDDI中。一個關鍵的概念是，UDDI提供了一個全球唯一的Web服務的描述信息，但那些真實的信息，還是保存在本地的ebXML庫中。這樣的話，一個潛在的客戶首先到UDDI中查找相關內容，然后根據這些到ebXML庫中找CPPs或者其他相關文檔。
JAXM
當從商業合作伙伴那里接收一個Web服務的請求時，我們需要Java API實現一個Servlet來處理ebXML消息，就象我們用JAX/RPC來處理SOAP請求一樣。
Java API for XML Messaging (JAXM) 是集成XML消息標準（象ebXML消息或者SOAP消息）的規范。這個API是用來推動XML消息處理的，它檢測那些預定單的消息格式以及約束。它控制了所有的消息封裝機制，用一種直觀的方式分割了消息中的信息，象路由信息，發貨單。這樣，開發人員只要關注消息的有效負載，而不用去擔心那些消息的重復處理。
目前的開發人員用JAXP來實現JAXM將要提供的功能，JAXM將會提供一套非常具有針對性的API來處理基于XML的消息傳送。這將大大簡化開發人員的代碼，并使它們具有統一的接口。
JAXM和JAX/RPC的差別在于處理消息導向的中間件以及遠程過程調用的不同。JAXM注重于消息導向，而JAX/RPC是用來完成遠程過程調用的。以下是圖解。


圖 4
請注意，在JAXM 和 JAX/RPC技術成熟之前，開發人員還是依賴于第三方的SOAP APIs，象Apache SOAP, IdooXOAP, 以及 GLUE。當JAXM 和 JAX/RPC正式發布后，它將為當前不同的SOAP和ebXML消息提供統一的接口。就象JDBC位多種不同的數據庫提供統一的接口。
以上是對于讓商業合作伙伴訪問你的Web服務的討論。下面我們來討論瘦客戶端和胖客戶端。
Thin Client Connectivity
瘦客戶端（象瀏覽器或者無線設備）只對瀏覽頁面感興趣。Web服務的職責是執行需要處理的Web請求，象運行B2C交易，然后給出訂單確認。
為實現這個，開發者用JSP來寫動態頁面。JSP組件技術時一種可以根據后臺數據處理的結果，來動態生成頁面的技術。它們在提供JSP組件的容器中運行。
JSP可以表現后臺用各種方法來實現的業務邏輯（e.g. EJBs，普通的Java對象，或者標準的JavaBean）。它可以生成標準的HTML或者XHTML來顯示結果。
JSP組件與其說是可編程接口，不如說是用戶界面。比方說，一個股票報價服務可能需要調用一個統計股票平均報價的應用中的Web服務，然后利用JSP技術把最終結果顯示出來。
以下顯示了JSP組件的角色。



圖 5
Thick Client Connectivity
有些Web服務的連接適合用胖客戶端。比方說，公司的內部網。用戶界面的響應以及功能可能更加重要。
一個胖客戶端可以用很多種方法來聯接Web服務。比方說，可以用UDDI, WSDL, SOAP以及ebXML。這是一個性能比較低的例子，因為客戶端和服務端可能是由同樣的開發組開發的，所以不需要處理很多的XML傳送或者解析。
一個提高性能的方法是，胖客戶端通過其他更有效的端口來聯接，象Java RMI-IIOP。
V. Implementing Web Services
現在我們來看，如何在內部實現Web服務。
數據傳送和轉換
在進入Web服務之前，我們必須解決如何把傳送進來的XML數據轉換成我們自己的服務能夠方便處理的格式，然后再把處理結果轉換成XML格式返回給客戶。因此一個開發人員需要一個強壯的機制來解析XML文件，綁定到Java對象，生成XML文件，并且傳送各種不同的XML格式文件。有時由于我們的應用程序支持不同的接口（例如：B2B伙伴的SOAP，基于瀏覽器的HTML格式，或者是無線的WML訪問同樣的Web服務）我們可能需要不同的服務接口來處理這些不同客戶端傳送過來的請求。
JAXP
用來處理XML的Java APIs是一套Java本地接口，它提供了可插入到XSLT引擎中的接口SAX，DOM。這些構成了解析和處理XML文檔的基礎。這些APIs對Web服務來說，是非常底層的，它給了我們用Java來訪問，修改以及創建XML文檔的全部功能。
For more information, please see:
http://java.sun.com/xml/tutorial_intro.html
http://java.sun.com/xml/xml_jaxp.html
JAXB
XML綁定技術可以把XML文檔和Java對象進行自由轉換。用JAXB，你可以在后臺的EJB層，把XML文檔轉換成Java對象。同樣你也可以把從EJB中取出的Java對象轉換成XML文檔返回給用戶。
JAXB接口提供了比SAX和DOM更高級的方法來處理XML文檔。它提供的特性可以在XML數據和Java類之間互相映射，提供了一個簡單的方法來轉換XML數據。它比逐個解析標記更簡單。

XSLT
從商業伙伴那里傳送過來的XML文檔可能和內部使用的格式不相同，比方說商業伙伴那里用"OrderNum"，而內部使用"OrderID"。
我們經常為了響應不同的客戶請求，而重新格式化XML數據文檔。舉例來說，一個商業伙伴的請求可能傳送一個SOAP表單，而一些瀏覽器用戶可能是一個XHTML。在一個更復雜的系統中，我們可能需要支持很多種不同的表現形式，象WML表單或者VoiceXML。這要求我們有一種機制來把各種XML以基本的XML響應格式來傳送給我們系統中不同的接口。
XML Stylesheet Language Transformations (XSLT) 是一種轉換XML格式的機制。一個stylesheet可以指定一系列的模版對應規則，并把它們賦給一個可遞歸的，象DOM這樣的模型。一個XSLT引擎可以用stylesheet來轉換XML文檔。XSLT stylesheet的語法是非常有表現力的，包含了循環，條件和數學表達式等。還有類似于函數（function）的機構和概念上的遞歸。
Shared Context
當兩個商業發生交易的時候，通常有一個上下文的關系。這個關系是指定給合作伙辦的一個協議，或者是一種商業規則，這樣就可以給不同的合作伙伴進行交易。此外，一個商業協作在一段時間內可能調用不同的接口。每一個這樣的調用都是處理同一個商業關系的，可能出現在整個商業生命周期中。
在J2EE Web服務中，為這個關系建一個離散的位置是一種建議的實現方法。作為一個開發人員，你應該在復雜的Web服務中需要這樣的關系，并且為你的系統結構設計一個離散的組件來控制它。目前這種關系是通過數據庫訪問（JDBC）來實現的。但是，Context API可以把Web服務中需要對這種關系的訪問操作作為一種流控制。這樣，這些共享的數據就可以由各種組件來訪問，象Servlet, JSP或者EJB組件。
Business Layer
當傳送進來的XML數據被轉換成Java對象后，這個數據已經準備被傳送到EJB商務層做處理。EJB技術是一種用Java來創建商業組件的標準。用EJB組件，你可以從容器中得到一些服務，象安全性，狀態保持，連接池，負載平衡以及失敗恢復。
在EJB2.0標準中有3中EJB組件：
Session Beans 進行客戶端的工作。一般來說，Session Bean生命周期短，執行快速的操作，象提交訂單，計算交易稅額。
Entity Beans 表現商業數據。一般來說，Entity Bean生命周期長，并且映射到后臺的存儲介質內，象RDBMS或者OODBMS系統。Entity Bean分為兩種類型：bean-managed persistent 和container-managed persistent
MessageDriven Beans 是消息導向組件。它們通過消息導向中間件來接收消息象IBM MQSeries或者TIBCO Rendezvous。消息也可以通過Java客戶端利用Java Message Service (JMS) 標準來發送。當消息到達后，一般用JMS API來訪問。
一般來說，session beans 通過調用entity bean來完成希望的操作。比方說，一個用來計算訂單價格的session bean，可能調用到表示產品和訂單的entity bean。 Message-driven beans 用來接收消息，或者傳送消息到那些session beans 或者 entity beans.
圖6顯示了一個EJB組件交互的機制。


你可以用Java Naming和JNDI API來創建，查找以及刪除EJB組件。這個API是用來訪問J2EE發布系統中外部資源的標準API，可以訪問包括數據庫驅動，消息中間件，或者創建EJB的程序。
更多 EJB資料， 請查閱:
·http://java.sun.com/products/ejb/white/white_paper.html
·http://java.sun.com/products/ejb/
·http://www.theserverside.com
·"Mastering Enterprise JavaBeans" by Ed Roman, published by John Wiley & Sons.
VI. Performing Back-End Integration
最后來討論用J2EE來開發Web服務的時候，如何與后臺系統相連，象數據庫，原先的系統和其他的商業伙伴。
Database Connectivity
為了聯接關系數據庫，開發人員必須選擇APIs:
The JDBC API 是一個用來訪問支持SQL的關系數據庫API.。（這個相信大家都知道了。）
SQL/J 是用Java編寫的標準的嵌入式SQL。類似于在HTML中嵌入JSP組件。
Legacy System Connectivity
在企業級開發中，與現存的系統相連接，一直都是一個比較困難的任務。大部分企業應用都是一個大雜燴，包含象SAP R/3, Siebel, i2以及一些客戶服務系統。整合工作是一個手工任務，因為對現存的系統可用方案并不多。軟件獨立開發商被要求編寫一個在任何平臺上都可以運行的客戶適配器，但這缺乏一個統一的標準平臺。
J2EE Connector Architecture (JCA) 是在工業中應用的，一個針對現存系統的適配器。你可以用它來連接現在的系統，或者編寫你自己的適配器。它可以運行在與任何J2EE兼容的環境中。
用 JCA，你只要編寫一個適配器，就可以在任何J2EE環境中運行。對于軟件獨立開發商來說，這為他們提供了一個整合現存系統的方案。事實上，這些適配器正在開發中，對最終開發者來說，這的確是令人激動的。
Business Partner Connectivity
后臺系統的最后一個類型是商業伙伴的Web服務。商業伙伴用全球認定的XML標準來暴露出一些他們自己的系統，在我們發布自己的Web服務時，可能會用到他們的這些服務。一般來說，UDDI用來注冊Web服務，WSDL用來描述Web服務，SOAP和ebXML用來處理商務交易。
你的EJB組件可以調用JAP套件來訪問商業伙伴的Web服務，這在之前已經介紹過了。
用 Java API for XML Registries (JAXR) 在UDDI注冊中心查找商業伙伴的Web服務。
用 Java API for XML RPC (JAX/RPC) 處理到外部Web服務的請求。
用 Java API for XML Messaging (JAXM) 發送SOAP 或者 ebXML 消息到外部Web服務。
用 Java API for XML Parsing (JAXP) and the Java API for XML Binding (JAXB) 把Java數據轉換成適用于合作伙伴的XML格式。同樣可以用來把合作伙伴那邊的數據轉換成易于自己處理的XML格式，或者進行XSLT數據轉換。
結合使用Java標準APIs和J2EE Web服務構架，我們就可以建立強大的跨平臺的系統。利用它們，我們可以與商業伙伴共享數據，提供完整的end-to-end的Web服務解決方案。見圖7。