同進程查找JDNI服務
比如說我們通過JNDI來查找Tomcat中配置的DataSource，代碼如下
Context context = new InitialContext();
DataSource ds = (DataSource)context.lookup("java:/comp/env/jdbc/oracleds");
將這兩行代碼放到JSP頁面中，在new InitialContext()之後，就能在JNDI服務上查到DataSource
這是因爲JSP和JNDI服務是在同一個進程裏的。但如果不是同一個進程，則不能new InitialContext()
這就好像是兩間屋子裏面的資源無法共享一樣，除非穿牆，否則是無法拿到對面屋子裏的資源的
所以在main()方法中是無法有效的執行這兩行代碼的
因爲在運行main()方法時，它會在一個進程中啓動JVM來解析class，而Tomcat那裏又是另外一個進程
所以在這兩個進程之間，只是通過簡單的new InitialContext()是找不到JNDI服務的，事實上這個過程就是在遠程調用
其實所謂的遠程，並不是說跨機器、跨網絡就是遠程，只要是兩個進程之間的調用，就算是遠程調用了
也就是說只要是不在同一個JVM裏面(更準確的來說是不在同一個地址空間內)的調用，它就是遠程調用
也就是說如果我們在同一個機器上，啓動兩個進程，然後進行互相調用，那麼這個過程就已經是遠程調用了
分佈式通信的基本原理
主要是使用客戶端上的Stub(存根)和遠程對象上的Skeleton(骨架)作爲中介，來實現分佈式通信的
在客戶端會有一個叫做Stub(存根)的東西，其實現採用的是非常典型的代理模式，是遠程對象在客戶端的代理
Stub會封裝所交互的數據的訪問細節(如何壓縮、壓包、編碼等)，然後通過相應的協議與Skeleton(骨架)交換數據
對於Java領域的分佈式通信技術，較常見的有EJB技術、CORBA技術、WebService技術等等
如果是EJB技術，那麼Stub就會採用RMI-IIOP協議來傳送數據給Skeleton
如果是CORBA技術，那麼Stub就會採用IIOP協議來傳送數據給Skeleton
如果是WebServices技術，那麼Stub就會通過SOAP(搜魄)協議來傳送數據給Skeleton
也就是說Stub會按照特定協議將信息傳送給Skeletion
而Skeleton會將Stub傳送過來的數據解析成特定的語言對象併發送給遠程對象，即服務端
比如說服務端是採用Java開發的，那麼Skeleton就會將接收到的數據解析成Java對象，再傳送給服務端
同理若服務端是採用C#開發的，那麼Skeleton就會將接收到的數據解析成C#對象，再傳送給服務端
接着服務端就會返回信息給客戶端，於是Skeleton就會將所要返回的信息進行壓縮編碼並通過相應的協議傳送給Stub
接着Stub就會將Skeleton傳送過來的信息解開，再傳送給客戶端，所以客戶端就獲得了相應的服務端的返回信息了
這裏的客戶端對象和遠程對象是位於不同的JVM中的，或者說是不同的系統平臺中，此即分佈式通信
它主要就是靠Stub和Skeleton來通訊，說白了，分佈式通信也就是Stub和Skeleton之間的通信
分佈式通信的舉例
假設有兩個服務器，本地的服務器採用的是Java開發的，遠程的是一個採用C#開發的天氣預報的服務器，二者可以通過以下幾種方式通信
1、如果二者不採用某些技術來通信的話，也是可以的
比如遠程服務器開放數據庫表，然後本地服務器使用JDBC訪問這個開放的數據庫表，也能夠實現分佈式通信
只不過開放數據庫表的做法，不太好。會暴露表結構、安全性也不是特別好、並且也是不標準的
另外有些數據，並不是單純的一張表就能體現出來的，可能要通過一定的算法計算出來結果的
2、如果二者採用WebServices通信的話，那麼就是使用SOAP協議來交互數據，該數據就是採用HTTP協議傳送XML文件
但此時雙方進行通信的過程中，由於採用的是SOAP協議，所以雙方交換的數據是大文本(通常是XML文件)文件
這時就有一個問題：假設需要請求10000條數據，那麼所交換的這個大文本文件的體積，將會是非常大的，傳送的過程就會很耗時
有一個解決辦法是：可以讓Java通過它的ZIP API壓縮該XML文件，然後上傳到FTPServer上，服務端再下載這個壓縮後的XML文件
接着服務端再解壓縮這個XML文件，然後讀取，再進行相應的處理，這也是解決SOAP協議傳遞大文本文件的速度特別慢的辦法之一
3、可以令遠程服務器把天氣預報的數據，定時的上報到某一個FTPServer，然後客戶端的Java程序也定時的到FTPServer上取數據
4、第三種方式的缺點是不實時。我們也可以讓客戶端發送消息給遠程的服務端，服務端會偵聽，然後再發送消息返回給客戶端
5、二者採用純粹的IIOP(屬於CORBA技術架構)協議來通信
6、如果遠程服務器是採用EJB開發的，那麼二者可以通過RMI-IIOP協議通信。而RMI-IIOP協議採用的是二進制傳輸，效率會更快
由於EJB也應用了CORBA的IIOP協議，所以在異構系統整合的時候，CORBA的互通性會比較好
步驟大致是服務器端先把EJB注射到JNDI樹上，然後客戶端的Java程序lookup這個JNDI樹上對應的名字，這樣EJB就傳過來了
也就是說此時Stub就動態的傳到客戶端的Java程序中了，然後客戶端就調用Stub，接下來就是Stub和Skeleton打交道了
另外EJB只能使用Java來寫，但是可以使用CORBA技術來調用EJB
EJB的前生
在EJB1.X的時候，對於分佈式通信的服務的支持還很差
比如寫一個EJB的話，則至少要寫三個類，然後編譯，編譯成Stub和Skeleton，這時大約會編譯出來5、6個類
後來有所改善，最先改的就是JBOSS。開發JBOSS的EJB容器的這個人，在Java技術上是非常厲害的一個人，傳說中的大牛吧
他引入了JDK的動態代理來完成Stub的自動生成，所以EJB的開發就簡單了一些，只寫三個類就可以了，存根會在運行時生成
也就是在把EJB注射到JNDI上之後，我們就可以在另一個JVM裏面lookup這個JNDI的名字，這樣便得到了EJB
然後它就會序列化的把EJB傳送到客戶端，它傳的就是Stub，而它在JVM內存裏面是看不見的
當我們在客戶端調用相應方法的時候，其實在內存裏面調用的就是Stub，然後Stub再與遠端打交道
WebServices——解決異構系統之間的通信(可以將其理解爲服務器通過特殊API，爲其他用戶提供服務的一種方式。它可以實現跨平臺調度。)
從標準上來說，整個技術架構是WebServices(帶s的)， 有時會看到很多人寫成WebService(不帶s的)，其實這是不標準的
WebService指的是單獨一個服務，而WebServices指的是它的技術架構
目前WebServices技術使用的稍多些，因爲它走的是HTTP協議，它可以穿越防火牆，它天生就能穿越80端口
但是WebServices的缺點就是：慢！！因爲WebServices是基於HTTP協議傳送大文本，實際傳送的是XML文件
而IIOP(屬於CORBA技術架構)協議傳送的就是二進制，所以它的效率要比WebServices快很多
所以在一些行業裏，也大量的使用了CORBA技術，比如說電信網
而CORBA的缺點就是：編程模型複雜，它是屬於重量級的
SOAP——簡單對象訪問協議
假設我們在本地通過Java寫一個main()方法與遠程的一個可以是用任何語言寫的取得天氣預報的服務打交道
如果打交道的過程中採用的是WebServices技術的話，那麼它傳送給遠程的就是XML文件，使用的是SOAP協議
SOAP即簡單對象訪問協議，其實質就是HTTP+XML，也就是說它是通過HTTP協議來傳送XML文件
也就是說SOAP是基於XML的簡易協議，可以使應用程序在HTTP之上進行信息交換
或者更簡單地說SOAP是用於訪問網絡服務的協議，而一條SOAP消息就是一個普通的XML文檔
使用SOAP協議通信的過程中，遠程對象會將所要返回的信息形成一個XML文件傳給Stub
然後客戶端就會把XML文件轉換成Java對象，而當客戶端在調用遠程服務時
客戶端就會把Java對象轉換成XML文件作爲參數傳給Skeleton，而Skeleton就負責把XML文件轉換成遠程服務的相應語言的對象
比如說服務端是採用Java開發的，那麼Skeleton就會將接收到的數據解析成Java對象，再傳送給服務端
同理若服務端是採用C#開發的，那麼Skeleton就會將接收到的數據解析成C#對象，再傳送給服務端
所以，WebServices能夠實現異構語言的通信，可以用來整合異構系統
同理，如果不是異構系統的話，也就沒有必要使用WebServices技術
比如說客戶端和遠程對象都是採用Java開發的，那麼就沒有必要使用WebServices了
因爲二者都是採用Java開發的，它們之間可以直接以二進制來傳輸數據，訪問效率會快的很多
而WebServices其實就是基於XML的數據交換，即WebServices所傳送的是大文本，效率自然就慢了
除非我們的系統是採用多語言開發的，那麼就可以考慮使用WebServices技術
或者說我們的系統想做的通用一些，則可以採用並開放WebServices的一些方法
其實SOAP就是用來最終完成Web服務的調用的，而WSDL則用於描述如何使用SOAP來調用Web服務
WSDL——WebServices描述語言
仍以上面爲例，即客戶端採用Java開發，服務端是採用C#開發的天氣預報的服務
作爲客戶端，它知道在服務端提供了一個能夠獲取天氣預報的服務，並且客戶端也可以調用該服務
但作爲服務端，應該對這些服務進行描述，以告訴客戶端都有哪些服務可供調用
而這個服務是不能用C#語言來描述的，因爲採用Java開發的客戶端是無法識別的
所以服務端就需要使用一套語言來描述它所提供的服務，這套語言就是WSDL
其實WSDL就是一個XML文件，也就是說WebServices定義了一套標準，裏面都是XML格式
使用這套標準來描述服務端對外提供的服務，比如C#的方法名、參數名、返回值等信息
假設服務端的天氣預報功能還沒有使用C#來實現，並且客戶端也沒有使用Java來實現
這時突然要求定義一套標準來描述一下即將準備實現的服務端的天氣預報的功能
並且客戶端可以任意調用這個天氣預報功能，此時就可以寫一套WSDL來描述方法名、參數、返回值等信息
當服務端的C#得到該WSDL時，就可以通過WSDL生成C#代碼，然後它就可以把取得天氣預報功能的邏輯補充上
而客戶端的Java在得到這個WSDL之後，同樣可以生成Java代碼，然後把相應的約定的接口實現補充上
在使用WSDL生成相應語言的代碼的過程中，就需要用到一些引擎來實現
比如在WebServices中就有：Axis、CXF、XFire等框架，它們就可以根據WSDL解析成Java代碼
所以WSDL是一種中立的語言
而CORBA架構中也有類似於WSDL的一種東西，叫做IDL，它的語法類似於C++語言，但IDL不是C++
UDDI——發現和整合服務
類似於JNDI。客戶端去尋找服務端所能提供的服務時，可以找UDDI索要，而UDDI就會把WSDL傳送給客戶端
實際上，該過程一般不通過UDDI，而是直接把WSDL拷貝過來就可以了，可以通過Email或硬盤直接拷貝
當客戶端得到WSDL之後，就可以通過SOAP協議與遠程的服務端進行通信了
轉自：原文鏈接