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