簡單的說， 就是客戶端根據(jù)WSDL 生成 SOAP 的請求消息， 通過 HTTP 傳輸方式（也可以是其它傳輸方式， 如 FTP 或STMP 等，目前 HTTP 傳輸方式已經(jīng)成為 J2EE Web Service 的標(biāo)準(zhǔn)）傳給對方， 服務(wù)方實現(xiàn)服務(wù)請求， 將結(jié)果以 SOAP 的消息格式返回給客戶端。
如果人工去創(chuàng)建和解析基于 XML 格式的 SOAP 消息還是一個非常復(fù)雜的過程， 這樣 JAX-RPC 應(yīng)時而生， 他實現(xiàn)了J2EE Web Sercive? 的遠程分布式調(diào)用。
JAX - RPC ：Java APIs for XML-Based Remote Procedure Call. 它本質(zhì)上是另一種RMI。 只是 JAX-RPC 以 SOAP 作為通信協(xié)議， RMI 以 RMI- IIOP或者 RMI - JRMP為通信協(xié)議。
?????????
構(gòu)圖.jpg)
客戶端需要根據(jù) WSDL 創(chuàng)建客戶端 Java 程序， 其中包括 Stub 程序。 客戶端調(diào)用相應(yīng)的Stub 程序， 進一步調(diào)用JAX- RPC 運行環(huán)境創(chuàng)建 SOAP 請求消息， 通過 HTTP 傳輸給服務(wù)器端。
Web 服務(wù)器端的JAX-RPC 運行環(huán)境在收到 SOAP 請求消息后， 對 SOAP 的 XML 內(nèi)容進行解析， 再通過 Tie 來調(diào)用服務(wù)接口實現(xiàn)類。（無狀態(tài)會話 Bean 或者 Java? 對象）?，得到結(jié)果后， 創(chuàng)建SOAP 響應(yīng)消息返回給客戶端。?
??
客戶端基于JAX- RPC 實現(xiàn)遠程分布式調(diào)用的基本原理
（1）通過 JAX-RPC 創(chuàng)建 SOAP 請求消息
（2）通過 JAX- RPC 將 SOAP 請求消息送到服務(wù)地址
（3）通過 JAX- RPC 解析 SOAP 請求消息
服務(wù)器端基于 JAX-RPC 實現(xiàn)遠程分布式調(diào)用的基本原理
服務(wù)器端的 JAX-RPC 的運行環(huán)境在收到了基于 XML 格式的SOAP 請求消息后， 會調(diào)用服務(wù)器端的 JAX-RPC Tie 對象的相應(yīng)服務(wù)接口方法checkUserLogin, 將上面的基于 XML 格式的 SOAP 請求消息中的參數(shù)值映射為 Java 對象類傳給 Tie 對象的接口方法， 將 loginName 和 password 都轉(zhuǎn)化為 Java 的String 類型。 這是前述的 WSDL 中所定義的類型。
利用設(shè)計模式
設(shè)計模式在設(shè)計Webservice的時候顯然可以起到相當(dāng)大的作用。設(shè)計模式的主要目的就是為解決某些在類似環(huán)境下的相像問題提供已有的較為成熟的設(shè)計方案。在這里，只簡單的提及一些很常用的模式，讓我們了解到模式在Webservice中可以起到的作用。
Adapter ：為內(nèi)部系統(tǒng)提供一個不同的接口
Fa?ade： 封裝復(fù)雜的內(nèi)部實現(xiàn)，提供一系列簡單的接口
Proxy： 作為其他對象的代理，代替它提供服務(wù)
?
Adapter模式用于將一個組件的接口轉(zhuǎn)化成客戶所需要的樣子，這里的客戶就是Webservice。一個常見的情況就是將原有的老的系統(tǒng)包裝成一個Webservice。比如現(xiàn)在使用的是J2EE的平臺，而原來有一個C++的系統(tǒng)實現(xiàn)了某些功能，現(xiàn)在需要將它發(fā)布成Webservice，那么就需要利用JNI技術(shù)做一個Adapter，為原來的C++組件提供一個Java的接口，然后再轉(zhuǎn)化為Webservice。
?
Fa?ade模式用于構(gòu)建粗粒度的服務(wù)，它包裝了細粒度的服務(wù)，從而為復(fù)雜的系統(tǒng)提供了一個簡單的接口。在J2EE中，Session Bean就象是一個Fa?ade，而Entity Bean則是細粒度的服務(wù)。在Webservice中也一樣，使用Fa?ade模式可以將已有的組件的功能發(fā)揮殆盡。
?
Proxy 模式用于充當(dāng)其他對象的代理，類似于中間人的作用，將處理工作從一個對象傳遞到另一個對象。在Webservice中，它主要用于隱藏Soap消息構(gòu)造的過程。也可以用于模擬對象（Mock Object）的創(chuàng)建。
?
以上僅僅是一些可以用于Webservice開發(fā)的模式，如果你熟練的將這些模式應(yīng)用于Webservice開發(fā)，你將會發(fā)現(xiàn)開發(fā)Webservice應(yīng)用，將好像做一種特殊的面向?qū)ο笤O(shè)計。
?
l???????? 安全
Webservice為作為方便的服務(wù)被用廣大領(lǐng)域使用的同時，也成為了黑客們的美食。在這里，本文將就目前對Webservice安全所能做的改進做簡單介紹。
在Webservice中的安全主要分為以下三個方面。
傳輸????? SSL/HTTPS 對連接加密，而不是傳輸數(shù)據(jù)
消息????? 數(shù)據(jù)加密(XML Encryption) ??數(shù)字簽名(XML-DSIG)
底層架構(gòu)? 利用應(yīng)用服務(wù)安全機制
?
傳輸時的安全是最容易被加入到你的Webservice應(yīng)用中的，利用現(xiàn)有的SSL 和HTTPS協(xié)議，就可以很容易的獲得連接過程中的安全。
?
然而這種安全實現(xiàn)方法有兩個弱點。一是它只能保證數(shù)據(jù)傳輸?shù)陌踩?，而不是?shù)據(jù)本身的安全，數(shù)據(jù)一旦到達某地，那么就可以被任何人所查看。而在Webservice中，一份數(shù)據(jù)可能到達多個地方，而這份數(shù)據(jù)卻不該被所有的接受者所查看。二是它提供的是要么全有要么全無的保護，你不能選擇哪部分?jǐn)?shù)據(jù)要被保護，而這種可選擇性也是在Webservice中所常要用到的。
?
第二層的保護是對于消息本身的保護。你可以使用已有的XML安全擴展標(biāo)準(zhǔn)，實現(xiàn)數(shù)字簽名的功能，從而保證你的消息是來自特定方并沒有被修改過。XML文件的加密技術(shù)從更大程度上加強了Webservice的安全，它能夠定制數(shù)據(jù)傳輸?shù)胶?，能否被接受者所查看，進一步完善了傳輸后的安全，業(yè)界也在不斷的制定Webservice的安全標(biāo)準(zhǔn)，比如SAML 和 WS-Security。
?
最后一層保護就是依靠底層架構(gòu)的安全，這更多的來自于操作系統(tǒng)和某些中間件的保護。比如在J2EE中，主持Webservice的應(yīng)用服務(wù)器。目前很多的J2EE應(yīng)用服務(wù)器都支持Java Authentication and Authorization Service (JAAS)，這是最近被加入到J2SE 1.4當(dāng)中的。利用主持Webservice的服務(wù)器，實現(xiàn)一些安全機制這是很自然的做法。另一種利用底層架構(gòu)的安全方法就是，做一個獨立的負責(zé)安全的服務(wù)器，Webservice的使用者和創(chuàng)建者都需要與之取得安全信任。