如何在雞尾酒會上談論Jini,J2EE和Web服務

1、如何在雞尾酒會上談論Jini，J2EE和Web服務作者: Kathy Sierra 和Bert Bates, Head First Java, 2nd Edition的作者翻譯：kelvincheng寫于：06/15/2005 編輯說明：Kathy Sierra 和Bert Bates是OReilly的Head First系列的后臺智囊。他們第一次寫這篇文章是在2003年Head First Java發(fā)行的那時候。這本書變得十分流行，我們現在仍然收到訂單。如此多的訂單讓我們決定重新帶給讀者，這就導致Head First Java,2nd Edition的發(fā)行。所以如果第一次發(fā)行的時候你沒趕上，

2、現在就讓Kathy和Bert告訴你如何與Java初學者交談。這些都是可以預測到的：當你在一個宴會中，喝著次等的馬提尼酒，不可避免的就會談到分布式編程。怎么辦？放松點，因為在這里我們會解決3種最有意思的分布式編程，就在用完的餐巾上畫圖，你可以用來提高你的 whuffie. (不知道 whuffie是什么? 讀讀 Richard Koman's interview with Cory Doctorow.)但是首先，萬一你真的現在就在某個宴會上，我們首先從幾個即使你不懂Java也可以使用的短語。然后，對于那些確實知道一些Java技術的人，我們會談得更深入一點?！笆裁词莿討B(tài)發(fā)現？你知道，它的含

3、義就是在網絡上，盡管客戶端和服務事先對對方一無所知，但能動態(tài)地發(fā)現對方。這所有都是基于IP廣播的?！薄笆裁词亲詣釉\斷網絡 (self-healing network) 呢？它指Jini網絡總是能夠反映當前所有可用的服務的狀態(tài)-就像這樣：OK,這個服務起來了，那個服務當掉了沒有任何人的管理！”當然，大多數路由器禁止了IP廣播，所以你不準備在web上用Jini。但是Jini是為本地網絡的工作，或者本地網絡的集合而設計的，所以這并不是個大問題。“J2EE最酷的東西是提供商獨立,你可以專心于你的商業(yè)邏輯，將那些重擔交給廠商。你可以在你特殊的商業(yè)規(guī)則上工作，把那些安全，事務，并行，持久化，甚至網絡代碼實

4、現的任務交給服務器。而你只需要去學一個API，你可以重新部署你的J2EE程序給所有廠商的與J2EE兼容的服務器。所以現在廠商必須改變以前那種將你鎖起來，并且你必須乞求廠商添加新的功能以解決bugs的方式?！薄癢eb服務中酷的東西是嗯，OK,也許現在的情況Web services沒有什么真正酷的東西。但是會變的，就在不久的未來，當所有標準都提出，工具成熟了，以及.”“但是如果要說Web 服務酷，這也許因為你可以采用你已有的商業(yè)程序，甚至舊的程序，讓他們通過XML那樣的接口暴露在Web上?？蛻舳送ㄟ^可互操作的方式發(fā)送一個XML信息（通過一種叫SOAP的格式）給服務?！薄鞍踩褪聞帐乾F在Web服務的

5、兩個明顯的缺陷，這意味著所有人必須加入自己的解決方案。在Web上沒有足夠的事務管理設置，而你所擁有的唯一的安全是互動驗證 (mutual authentication) 的Https?！薄癑ini和J2EE都是Java技術。通過J2EE，就像規(guī)格說明說的那樣：“哦，你不需要擔心你這個小程序員去解決那些巨大的困難的東西。廠商會考慮這些問題，而你可專注于自己的特殊領域的需要（比如，如何賣出更多的婦女內衣）。但是，通過Jini,就好像規(guī)格說明說的那樣：你必須靠自己，別指望其他人使用許多基礎設施來救你。這是貧乏而又簡陋的，寶貝，但你可以做最令人驚訝和體面的事情。當你在那時，檢驗一下JavaSpaces

6、。”“Web服務不是針對于java的技術，但是java可以讓其更容易的使用，特別是如果你去使用J2EE 1.4。不,你說的對。J2EE 1.4還沒發(fā)布，但是會在今年年底發(fā)布，你將在2004年初見到許多廠商支持?！保ㄔ谖覀兝^續(xù)下去之前，先提出一些免責聲明：首先，如果你對于這篇文章的高級含義有任何問題，重新讀一下標題。對于這些內容我們有酒吧侍應的牌照，我們不會告訴你什么是錯的，但是你也不會試圖去了解整個故事。每個主題都需要相應的一本書（但如果我們不說出任意一本書來，這是很可恨的。比如，Head First EJB，或是哪一本呢？）讓我們僅僅通過雞尾酒會的觀點來看這個問題并不是你想來操縱你的下個結構

7、。（我們知道你知道這些，但對于那些可能會誤解這篇文章是篇嚴肅的技術論文的人，我感到有必要談談我們的a*es）.）原文如此所以現在是時候進入下一個層次了。我們將首先開始看看什么是服務，而且更重要的是如何向別人顯現你自己。換種說法，你如何將你的服務告訴你潛在的客戶呢？通過Jini,J2EE,和Web service,目的是讓客戶去訪問服務。什么是服務呢？你所能做的事就是將消息從一個軟件傳遞給另一軟件（也許包含人工指向，也許也不包含）。你也許有一個為基因匹配進行大規(guī)模計算的服務?；蛘咭粋€玩簡陋的Go游戲的服務。或者一個讓你買演唱會門票的程序?；蛘哳A定異國熱帶風情的巡游?；蛘呱踔翆⒛愕奈淖謧鬟f給一臺高

8、容量(high-volume)打印機。換種說法，服務就是所有像軟件一樣開始但是結果并不一定留存在軟件中的東西。你也許有個服務來移動攝像機，利用打印機打印，撥電話。沒關系?；蛘咧辽贈]關系。主要目標之一，就像OO的任何情況下的目標一樣，盡可能減少耦合，此例中，即客戶端和服務器端之間的耦合。換種說法就是我們要讓那些參與者（客戶端和服務端）盡可能地少了解對方。但是讓我們說說你有一個服務現在怎么辦？客戶端如何找到你？如果他們找到你，他們怎么知道你的服務可以干什么？換種說法，他們如何知道他們調用你的服務的方法？這樣，你必須將你自己暴露給客戶，我們的3種技術在這方面稍有不同。不考慮我們在討論Jini,J2E

9、E,或者Web服務,可是必須在某個地方有個接口。這個接口說明了你可以做的東西。服務接口作為一個服務開發(fā)人員，你必須告訴人們你的服務可以做什么?；蛘哒f，你必須聲明你的服務的方法。這包括聲明客戶端傳遞給你的方法什么（參數）以及服務返回什么（返回類型）。上面這個接口是為一個叫Advice的服務。它具有一個方法，getAdvice()。你可以調用這個方法，得到一個字符串，里面包含極好的有用的隨機選擇的建議。（我們選擇不在我們假的小類似于UML的圖中顯示返回類型。這是非常小的事）。對于Jini和EJB(Enterprise JavaBeans-J2EE的核心和靈魂)，接口通常是Remote。一個Remo

10、te的接口通常意味著開發(fā)者寫一個基于java.rmi.Remote的擴展java接口。耶，Remote所有方法（意思是Remote接口中的所有方法）必須聲明一個java.rmi.RemoteException的異常。一個強制性的異常(checked exception)，告訴客戶端：“事情變得很糟糕，小心準備?！睂τ赪eb Services,接口被定義在一個WSDL中(讀作“wizdle”，與“fizdle”押韻)-一種特殊格式的XML文檔。所以總括來說，你可以在隨意的談話中說以下這段話：“可以說，在Jini和EJB中，你通過java接口暴露你自己，但是在Web服務中，你通過XML接口暴露你自

11、己?！保蚀_地說，如果你是一個java開發(fā)者，你通過寫一個java接口來創(chuàng)建WSDL，按那個在你的開發(fā)工具中神奇的紅色按鈕，將你的java接口變成XML WSDL。這就夠了，像他們說的，這超過了一個雞尾酒會談話的范圍。）OK，現在我們有了服務，有了暴露我們服務的接口?，F在呢？客戶端如何知道這個接口？他們如何真正取得這個接口，他們還需要和我們服務交流些什么呢？這要看服務的類型。這3種類型是不同的。你訪問Jini,J2EE和Web服務將有少許不同，文章的其他部分將著重于一些細節(jié)和主要不同之處。首先，讓我們從一些Java的Remote Method Invocation（RMI）的背景開始。這是大部

12、分的java分布式技術的主干，Jini和EJB都基于此。事實上，自從所有分布式技術在概念上如RMI的技術上運行時，你在這里了解的東西將幫助你弄清楚整個分布式的世界，Java或者非Java的。通過RMI，你寫你的服務并將此變成為Remote對象。讓其成為Remote僅是小菜一碟-寫分布式接口，創(chuàng)建Remote類來實現它。創(chuàng)建Remote接口1 擴展 java.rmi.Remote2 為每個方法聲明java.rmi.RemoteException1. public interface Advice 2. extends java.rmi.Remote 3.4. String getAdvice()

13、 throws 5. java.rmi.RemoteException;6.7. 創(chuàng)建Remote類1 實現你的Remote接口2 為接口方法寫真正的商業(yè)邏輯1. public class AdviceImplementation implements Advice 2.3. public String getAdvice() 4.5. / monumentally important 6. business logic here7.8. 9.10. （OK，所以代碼對于雞尾酒會有點多，因為在這都是初學者.）所有東西的關鍵：The Stub當你已經有了接口和類，你通過RMI編譯器（rmic）運

14、行你的類，RMI編譯器已在J2SE中（如果你已經有javac，你就有rmic了）。那個程序建立了stub這個你可以幾乎在所有現代分布式編程模型中發(fā)現的東西。Stub僅是客戶端的助手，通過像服務那樣實現遠程接口來扮演遠程對象的角色。但是事實上，Stub僅是一個取得方法調用，打包，并通過網線傳遞給真正的遠程對象的小對象?；蛘哒f， stub知道如何打電話回家并叫真正的服務去做真正的工作。Stub所有方法都是虛假的。他們是方法，有一大堆代碼，包括用于服務聯系的網絡和I/O內容。但是他們并不是真正的商業(yè)代碼。所以對于Advice服務， stub有getAdvice()方法，但是這個方法僅僅從客戶的請求傳

15、遞給在服務器上真正的AdviceImplementation。那邊，客戶端假裝他在調用遠程對象，但是我們知道由于遠程對象運行于不同的JVM堆中這并不真正發(fā)生。（是的，在服務器端依然有些東西接受來自客戶的Socket連接，解包方法調用，打包并裝載返回值等等。但是我們并不準備在這篇文章中談論這些。那是個更微不足道的過程，因為你不需要擔心傳遞功能給客戶。所以在服務器上Stub的功能有同伴，但是你并不需要擔心這個。）RMI基本結構籍由RMI，遠程對象是一個服務。暴露RMI如果你有個客戶端，你想通過遠程服務（或者說遠程對象）做些東西，你必須有遠程服務的接口（在編譯時和運行時），而且你必須有stub對象（

16、運行時）。記住，是Stub真正知道如何傳遞你的方法調用給遠程對象（并傳遞回返回值），所以你可不能沒有它。很多時候，你將從服務開發(fā)者那得到接口和stub .class文件。但是有個更酷的方式運行時取得stub類而不需要在運行前取得，那就是通過一個叫動態(tài)代碼下載（Dynamic code downloading）的進程。這是你在java中可以使用的最強大的東西之一，而且也不難。但是，你也可以以守舊的方式從開發(fā)者的Email中取得stub類文件，或者從別人那里下載到你的電腦。查找服務（例如擁有stub，這樣你可以調服務中的商業(yè)方法）在RMI中，你通過RMI登記(附在J2SE中)查找到stub。RMI

17、登記就像一本小的電話簿，你找到名字，然后就得到stub。記得當stub對象過來的時候是串行化的。這意味著在其來到客戶端時要使其反串行化。同時為了讓其工作，the stub類必須在當前的classpath中或者可以用動態(tài)代碼下載來找到。這是java基本知識-一個實例不能在沒有其類時反串行化。發(fā)現查找服務（RMI Registry）通過RMI，你必須知道the stub在哪里？你必須為RMI Registry知道IP地址和TCP端口號（同時也恰好是遠程對象/服務所在的服務器那里）。事實上我們大概并不一定要知道端口號，因為有默認的端口號，但是如果服務部署人員更改了，你則需要知道?？蛻舳酥蛔隽撕唵蔚膯?/p>

18、行的查找，利用靜態(tài)方法（java.rmi.Naming.lookup()）,這時奇跡發(fā)生了，它有了一個即時的反串行化的stub。對象知道如何打電話回家了?，F在我們已經注意RMI，這部分將會更有意義。Jini就像是Extreme RMI。我們這里用Extreme這個詞是指其運動含義，而不是XP中的意思。動態(tài)發(fā)現：服務和查找服務如何發(fā)現對方這是普通的RMI與Jini差別最多的地方。在RMI中，客戶端必須知道很多東西，服務必須通過RMI Registry清楚地登記（用邏輯名稱），注冊必須在與服務的同個機器中。但是通過Jini,所有東西僅是在那兒，在某處。沒有人知道除了接口外的其他東西。這里有句話關于

19、這個的，我們發(fā)現這放在這個對話中的戰(zhàn)略時刻相當有意義?！巴ㄟ^Jini，服務通常嘗試去發(fā)現查找服務，客戶端也通常發(fā)現查找服務，而查找服務通常在讓服務和客戶端知道他們（查找服務）就在這。所有都是自動的?！彪m然在Jini中你也可以將整個服務發(fā)送給客戶端本身，而不是讓服務變成服務器上100%的遠程對象，但是基本的Jini結構采用RMI。當客戶端要求服務的參考時，將取得遠程對象的stub（如果服務被實現為一個遠程對象），或者重新得到整個該死的服務，在上面進行簡單的舊的本地調用。事實上，通過Jini,客戶端甚至可以一個混合體或者“智能代理”（公開說這句話會有特別的聲望）。-那樣，一個非遠程java對象包含

20、一個遠程對象的stub（就好像，實例變量）。那樣，客戶端直接對服務進行本地調用，但是服務本身可能會將其跳轉，讓遠程調用到其他地方?！爸悄艽怼笨梢酝ㄟ^在客戶端做某些工作提高在客戶端和服務上的表現。Jini架構Jini和其他所有分布式技術（普通的RMI,EJB和Web services）有另外一個主要不同點是Jini利用分布式租約幫助建立自愈網絡。如果Jini服務是遠程的，例如，他給客戶端一個租約并說：“這是你的租約。如果你不更新它，我將假設你已經離開，我將停止你在這里代表的任何資源?！弊钚碌木W絡如何保持依賴于這些租約的時長。例如，一個兩小時的租約將意味著客戶端可能斷開將近兩個小時，而你（服務）

21、卻不知道。多么浪費！另一方面，一個一秒鐘的租約意味著最近的網絡，但是所有人花費其所有的周期和帶寬去更新租約！所以那是筆交易，這依賴于服務的類型以及其他服務質量問題。自愈型網絡另一個很酷的東西是：既然Jini查找服務是一個Jini服務，查找服務給Jini服務一個租約。所以在這種情況下，Jini服務對于Jini查找服務是個客戶。那樣，當一個普通客戶端（或者說，一個本身不是Jini服務的客戶端，而是想用Jini服務的程序）來查找一個服務，比如打印機，如果服務沒有通過查找服務更新客戶端將不視其為“可用”。此外，租約時間越短，就越是最近的網絡的寫照，越不可能會令到一個客戶選擇一個不再可用的服務。Jini

22、暴露如果你是一個客戶端，你想從Jini服務中取得某些東西，你必須有對于這個服務的接口。不想RMI，Jini具有更靈活性，因為你除了接口外不需要知道其他東西。你并不需要知道注冊的名字或者Service的位置。只要你知道接口以及你在一個可以發(fā)現查找服務的網絡，你就可以工作了。今天，幸運的是開發(fā)者給你接口。但是有少量的接口到處漂浮，變成某種標準，包括Bill Venner的名聲不好的ServiceUI.發(fā)現服務類不像RMI，在Jini中你將不可以選擇是否使用動態(tài)代碼下載。你幾乎被迫使用它。（你也可以不使用它，但是這違背了Jini的本來目的。）通過Jini，你不需要知道網絡中內容的位置，你也不需要知道

23、誰建立這個服務。記著，所有你要的只是接口，而且在很多情況下，你需要擔心的你需要去實現服務的接口（也許是個stub，也許是真正的服務，或者集合體）。記著，在RMI中，你在客戶端中需要的類通常是Stub類，而不是服務本身。在Jini中，如果服務被實現為遠程對象，或者是真實的服務，你調用方法的應該在stub中-例如，一個實現了接口并真正工作的類就在客戶端本地。查找服務通過Jini，你使用Jini 查找服務(lookup service)，而不是RMI Registry。Jini查找服務更靈活和強大，而且它可以像服務對象那樣提供信息給你，哪個，是或者不是遠程對象stub，這依賴于服務是否是個服務器上的

24、遠程對象或者是轉載在客戶端上的非遠程對象。最好的東西是你不需要知道查找服務在哪！在RMI中，你必須知道遠程服務的IP地址和端口號來找到服務stub所在的RMI Registry。而在Jini中，你僅知道大概在某處，在那兒的網絡上有不少于一個的查找服務，通過IP廣播達到。這就是Jini。但是Jini是個瘋狂的邊緣，這里沒有人知道任何東西，而你就在你自己的模型上，J2EE正好是相反的東西。J2EE的主要思想就是服務器（通過容器）給你一堆額外的服務，否則這些服務你也許要自己寫，或者將不同的部分拼湊起來，或者從私人廠商那購買。我們現在談論的是巨型的服務，像事務管理，并行管理，安全，資源/生命周期管理，

25、查找服務，持久化，信息服務等等。那樣，你開始專注于你的自己的商業(yè)規(guī)則，而不是重新去做那些繁瑣的重復的事情。其他應用服務器已經存在了一段時間了-如CICS和TUXEDO都是經典的例子。但是在那種環(huán)境下你必須學私有的API，你被廠商鎖住了。J2EE是企業(yè)級商業(yè)中間層的標準，所以你僅僅需要學一個API，無需考慮你要選擇的服務器。其中最好的就是你可以部署你的應用到任何符合J2EE標準的服務器，所以你可以對廠商的枷鎖說拜拜了。當然，事實上由于各種原因，將J2EE程序部署在不同的服務器上并不容易。但是你可以。而且如果你有足夠的錢換掉你現在的提供商，知道這個不更好？更好的是，讓廠商知道你可以這樣做。首先，澄

26、清一下J2EE和EJB的不同：J2EE是一個為可運行EJB的服務器設立的規(guī)范。但是J2EE服務器同樣要支持servlets和JSP。你可以認為J2EE就像一個整合的服務器將servlet和支持JSP的Web服務器以及EJB服務器整合在一起的服務器。在J2EE領域，我們叫它子服務容器。所以我們在J2EE服務器中擁有Web容器和EJB容器。因為beans比servlets和JSP更吸引人，我們在這里專注于EJB方面。同時在EJB的世界，服務就是bean。EJB有樣很酷的東西就是基于組件的開發(fā)模型。你建立可重用組件，這些組件是可以在部署時定制而不需要改動java代碼。組件比java類更易用，所以他是

27、下一個層次的重用。你利用XML文件來部署你的組件（例如beans），而這些文件說明服務器應該如何處理bean,所以你可以配置安全，事務，資源使用等等，都聲明在XML文件中，你只需要在開發(fā)工具中按幾個按鈕即可。（如果你真的想，你當然可以直接編寫XML文件。但是現在的工具十分好，而你并不需要去做那些工作。）J2EE架構J2EE和普通RMI一個很大不同之處就是服務器必須介入客戶的調用和服務（例如bean）的被調用中。如果客戶端遠程調用已開放的bean方法，服務器會介入并讓其隱蔽的過多的bean與客戶端直接聯系。例如，假如客戶端扮演特定的顧客調用bean中的getAddress()方法。首先，服務器必

28、須驗證客戶端是否經授權去調用這個方法，但是假設客戶通過了安全檢查，現在服務器必須去做其他東西讓bean準備好去接受調用。如果bean返回客戶的地址，比方bean會重新去數據庫記錄中取得客戶的資料。這需要變成事務的一部分，而其他客戶也許準備好使用這個客戶，還有.J2EE的解決方案是讓bean成為非遠程對象,被遠程對象保護。所以即使bean真的是服務（或者說，這里含有客戶想調用的商業(yè)邏輯服務方法），而bean在RMI方式中并非是遠程的。但是客戶依然和RMI副本以及遠程對象相互作用；就像和EJB相互作用那樣，遠程對象更像是bean的保鏢。遠程對象（在J2EE中叫做EJB對象）接受客戶端遠程調用（例如

29、，客戶端在stub上的調用），并同時讓服務器加入來決定如何，何時和調用是否到達bean。J2EE暴露通過EJB，在RMI規(guī)劃圖（除了服務外）中加入另一層。EJBObject是遠程對象，但不像RMI中，EJBObject并不是個服務。所以那樣現在這里對于服務有兩個幫手，而不像普通的RMI那樣子有一個(stub)。你的服務接口依然是遠程接口，而不是直接實現java.rmi.Remote，你的服務接口實現EJBObject-一個本身擴展自java.rmi.Remote的接口。盡管bean不含有相同的方法，注意bean如何不擴展服務接口（Advice）。（不要過于拘謹擔心，絕大多數注重EJB的開發(fā)工具

30、確認bean和服務接口會匹配。）找尋服務接口通過J2EE，你通常與客戶端開發(fā)者同在一個企業(yè)工作，則你可發(fā)Email給他接口，或者你可以在內部的知識庫中公布。無論如何，重要的是，就像RMI和Jini，客戶端必須在編譯時有此接口。同樣，對stub類 ，你可以選擇提前給客戶端或者用動態(tài)代碼下載。但是這種情況下動態(tài)代碼下載依賴于你特定的J2EE服務器，也許不可行，所以你也許會被困于自行將stub類傳遞給客戶端的情況。大多數J2EE服務器為你部署bean準備了小而精的客戶JAR。找到服務警告：我們在這節(jié)擴展了雞尾酒會知識的限制，所以這段人們就會說：”哇噢，在你寫到這之前我都跟得上你?！边@不是我的錯，是我

31、們的。所以這里如果你想掠過，你可以直接跳入Web服務，別人也不會知道。盡管如此，如果你是單身而且想找對象，你若想要到對方的號碼，你就要注意這部分啦。這與RMI的工作很像，除了查找服務現在是JNDI而不是RMI Registry或者Jini查找服務。JNDI是一個工作在名字和目錄服務（Naming and Directory services）范圍中的接口，需要J2EE支持。客戶端在bean的邏輯名上查找并取得個stub，就像RMI中。這里有些東西我們忘記談到了。在EJB中，客戶端不可直接要求JNDI取得遠程對象（the EJBObject）的stub?；蛘哒f，客戶端不可通過JNDI的服務方法取

32、得stub。在JNDI中，客戶只能取得bean的Home。Home僅是bean的工廠；其生命的主要目的管理對EJBObjects的引用?；蛘哒f，Home給你EJBObject的stub-你可以藉此調用服務方法。但是Home本身是遠程對象，所以當客戶想調用bean中的服務方法時，必須跳過許多額外的步驟，而直接通過RMI則不需要。1. 進行JNDI對bean的邏輯名（不管bean部署者如何稱呼它）進行查找。2. 客戶取得遠程對象的stub。3. 客戶調用Homestub的遠程方法，請求服務本身的stub。他不可能引用真正服務the bean但是客戶端可以有最接近的方式：bean的保衛(wèi)的副本,the

33、 EJBObject實現bean服務接口的遠程對象。對于整個EJB規(guī)劃有所放棄從EJB2.0（最新版本J2EE的一部分）開始不是所有的客戶接口必須遠程。或者說，the Home和 EJBObject對象可以在客戶端而不是RMI遠程對象。這意味著客戶和bean運行在相同的JVM中！覺得太過于分布式了，是嗎？不是的，因為你失去了最有價值的東西位置獨立。如果你將客戶端和bean放在一起，的確可以由于減少了副本變成遠程對象的過程，取得性能提高，但是你放棄了將你所謂的分布式程序的某些部分移到你的網絡的其他節(jié)點的機會。這是強迫的，甚至是命令式的原因來用本地Home和EJBObjects，但是必須通過持久實

34、體bean實現，所以你僅僅在十分特別的情況下考慮它。眼下，總之當你是一位J2EE設計者，你可以在你的休息時間考慮其細微之處。）現在我們已經領會到RMI，Jini和J2EE，我們都認為他們是比Web Services更好，整潔，適量，新鮮的技術。事實上我們并不過多的討論Web服務，因為在Web服務領域粗糙且不清晰。但我們也會討論下，讓你度過喝東西的時間。Java RMI，Jini，J2EE和EJB都是完全的java技術，而Web服務不是。Web服務取得你現有的程序（即使有些種類是建立針對于部署為Web Service的新建的程序，但是比較少。），將他們暴露在Web上。大部分時候，是在企業(yè)內部網中

35、。即使Amazon和Google提供Web services讓你可往你的站點添加Google或者Amazon的功能，但現在很少有機會你可以找到在網絡上供公共訪問的Web服務。我們都認為那是特殊情況。今天，大多數Web服務的案例是用于他們自己商業(yè)程序間的綜合。但是理想的情況是以B2B以及C2B（Business-to-Business and Consumer-to-Business）的方式有大量的WebService共同工作，而不需要了解關于除了商業(yè)領域外其他程序的預先知識。例如，最經典*的例子是：你由于成為最新的銷售冠軍進行多個城市的巡回演講，“這不僅僅是移動”但是你要去的下一個站電量停電，

36、而現在你的整個計劃都是都要改變。所以你使用你的手提電腦的程序，讓其幫你做好這些事情。它更改機票，預約好酒店并租了汽車。當然你可以去很多個網站輪流更改那些，那會是痛苦的，但是記著你在一個網吧，你可以做更好的事。（*“經典”在這里形容“web服務”是矛盾修飾法。我們可以更改這個故事，比如是一個旅行銷售員。）Web服務存在的缺陷是它不可以沿著你過去寫企業(yè)程序的方式進行，因為事務和安全只是基本的加入你的公開的web中。對于Web沒有事務管理，而J2EE服務器中有。同樣沒有任何部分管理安全。所有這些問題集合起來就是你不可以知道誰或什么將訪問你的web 服務。這樣將web 服務暴露會令到服務于客戶端不需要

37、緊密地聯系（例如要求客戶端和服務使用相同的編程語言）。在某些方面，Web services允諾是具有一些特性，就像Jini中，通過一定程度上的動態(tài)發(fā)現。事實上既難設計出來也難完成。但是這些情況每天都在改變。記著，這是互聯網時代。Web服務架構這張圖片比以前的圖片更高層，所以這里包括了其他的所有成員包括了不同類型的stub（Web服務有他們自己的stub），更多借口和更多進行XML處理的部分。RMI驅動的技術和Web服務最大的不同在于其他大都基于java方法調用。對stub的調用依然是java方法調用。當然，stub建立socket和流，并用特定的協議來傳遞方法調用（通常是RMI-IIOP，另一個令人印象深刻的縮寫），當時一旦其經過服務所在的服務器后，就會變成普通的方法調用，調用遠程服務對象。在Web services中，利用SOAP協議以及XML來發(fā)送消息。SOAP就是消息的信封，消息和事實上客戶端要求服務器執(zhí)行的“方法”調用沒有區(qū)別。（雖然在我們談論java中的web services時，其的確轉換乘真正的含有參數和返回值的java對象的方法調用，但我們在這里用泛義的“方法”。）Web 服務中的大部分繁重的工作是在所有地方進行的XML處理工作，而其解析XML是十分慢的。這意味著性能是個很大的問題（你可加上其他web服務的問題例如沒有事務支持，很少安全）。但是，XML最美之處