近六個月來，有關Web services生命周期，安全，協作，事務方面的許多標準紛紛出現。JSR已經開始用一種標準的方式來定義Web services的各個方面如何從J2EE應用服務器中得到支持。

　　JSR 109專門討論本地客戶端如何訪問Web services，服務器生命周期和Web services的部署。JSR 104,105和106聯合在一起來描速web服務安全，包括信任服務的API，數字簽名和加密。JSR 156 和157定義支持Web services的事務和合作的基礎，包括支持2PC (JTA) 和商業事務。本文將介紹JSR 109 的內容并考察它對Web services在J2EE環境中實現的影響。

　　JSR 109: Web'>http://jcp.org/en/jsr/detail?id=109">Web Services 在J2EE上的實現。當前規格說明書狀態：版本0.3(正式發布版本 1.0) 15-April-2002
　　
　　JSR 109介紹

　　在過去的這些年里，J2EE成為提供web服務的主流標準。同時也出現了許多把應用端功能移植至web前端之后的標準, 其中Web services是的。J2EE一開始使用的是servlets，JSP和無狀態會話企業java
　　
　　bean, 然后EJB規范發生了調整開始支持有狀態的企業java bean, 在后來是實體bean, 開始支持基于消息的java bean。
　　
　　毫無疑問J2EE將會繼續的發展和進步。JSR 109是的描述擴展J2EE的規格文檔之一。JSR 109 定義了J2EE應用服務器應該如何以一種標準的方式提供對Web services的部署，管理和訪問的本地支持。 明確的說，JSR 109覆蓋以下重要的領域：
　　
　　客戶端的編程模式??J2EE如何把Web services作為傳統的遠程對象來訪問服務器端的編程模式??怎樣用servlets和無狀態會話EJB來實現Web services并使Web services具有和他們一樣的生存周期Web services部署和部署描述器??如何在應用服務器上部署Web services
　　
　　在這篇文章里，我們要考察JSR 109的許多領域來理解每個領域到底帶來了什么樣的好處。但是在讀這篇文章的時候，你要記住規格說明文檔是描述解決問題的結論。我們在研究一種技術的時候常常只是注意它能做什么而忘記它要解決的問題是什么。在我們讀這篇規格說明文檔的時候，我們要一直問自己“它究竟要解決什么問題？”　規格說明文檔描述解決問題的結論，它描述的范圍不應該寬于也不應該窄于問題的范圍。
　　
　　首先，JSR 109 嘗試定義一種實現Web services的編程模式，在這種模式下無論Web services是如何實現的，對調用端來說看起來都是一樣的。因為Web　services同時被其他很多的規范所控制和定義，JSR 109不可以要求Web services在實現和部署范圍以外有任何的改變。我們來簡單的看看部署和部署模式。
　　
　　JSR 109 嘗試定義一種模擬其它J2EE編程模式的客戶端編程模式；熟悉“傳統”遠程方法調用的開發人員會很容易的理解JSR 109。所謂的“傳統”，我們指JSR　109定義了一種和其他J2EE應用一致的客戶端編程模式，使用JNDI等方式來獲取遠程接口然后調用引用的對象。
　　
　　注意：一些支持Web services的公司，比如說Sun 和 BEA，他們表示對JSR109持有保留意見。需要查看完全的描述，參考http://jcp.org/en/jsr/results?j=109&t=1&c=1">投票內容。
　　
　　客戶端編程模型
　　
　　JSR 109客戶端編程模式的目的是清楚的定義java應用如何能夠像訪問EJB那樣訪問Web service。這個問題只是許多復雜情形中的一種。其它的JSR定義和應用服務器不在一起的Web　services的訪問；然而，這種方式給客戶端應用帶來了一定的編程復雜度。在部署Web service的應用服務器內部訪問Web service我們定義為直接訪問。JSR
　　

　　109的客戶端編程模式定義了一種簡單易懂的訪問本地部署的Web service的方式。
　　
　　三種模式
　　

　　JSR 109定義了三種客戶端編程模式??用戶管理端口訪問模式，容器管理端口訪問模式，動態端口訪問模式。我們將側重于用戶管理訪問模式，這種模式基于原來的WSDL為Web　service定義了一個接口。使用用戶管理訪問模式的時候，應用系統需要為一個特定的接口提供一個端口。容器管理端口訪問模式和用戶自管理模式類似，但是容器直接管理對實例的調用，而用戶只是申請一個普通的可以訪問不同接口的端口。
　　
　　端口　在了解Web service之前，我們必需先理解端口的概念。一個端口是Web service的一個實例。一個客戶應用訪問Web service必需通過服務接口訪問服務，這時應用服務器可能啟動一個已經存在的實例或者創建一個新實例來實現這個請求。熟悉EJB編程模式的讀者會發現JSR　109的客戶端編程模式非常熟悉。
　　
　　動態端口訪問模式不需要事先了解WSDL的定義，調用會在端口不工作的時候發生。雖然明顯看來動態端口訪問模式更加強壯，但是在現實應用中動態端口訪問模式并沒有多大用處。在將來??當動態編程變得更加普遍的時候??這種方式也許會是非常有用的。本文的余下篇章中，我們將使用更加傳統的容器管理端口訪問模式，在這種模式里用戶事先知道Web　service接口的定義。我們待會再解析用戶管理端口訪問模式和容器管理端口訪問模式。
　　
　　步：首先我們得到一個在任何JNDI客戶系統中都要用到的InitialContext。（對JNDI的描速已經超出了本文的范圍，有興趣的讀者可以直接訪問JNDI培訓）當我們考察Web　services部署的時候，我們將了解訪問Web service實際名稱的細節；直到這個時候，我們才需要使用Web services的名稱。當然，應用服務器應當保證實際的Web services已經被綁定到JNDI樹上了。
　　
　　例1.用戶管理端口訪問模式
　　
　　00 InitialContent ic = new InitialContext();
　　
　　01 SomeSpecificServiceInterface srv = (SomeSpecificServiceInterface)ic.lookup (java:comp/env/service/SomeSpecificServiceInterface);
　　
　　02 ServiceInstance si = (SomeSpecificService)srv.getServiceInstancePort();
　　
　　讓我們來逐行研究這個程序片斷，行00是傳統的JNDI查找。行01，我們得到接口ServiceInterface的一個特定實例。所有的服務都需要實現Services接口，這個接口定義了訪問服務的一些公用方法，例如返回特定實例。如果你熟悉EJB規范，你將發現Services接口和EJB本地接口有類似之處。行02，我們得到了定義了實際使用的方法的遠程對象的一個實例。
　　
　　當Web service的定義在開發的時候已經完全已知的情況下我們一般使用用戶管理端口訪問模式。如果因為某種原因應用服務器不能返回支持行01 cast操作的實例，異常將會被拋出。
　　
　　例2.容器管理端口訪問模式
　　
　　00 InitialContent ic = new InitialContext();
　　
　　01 Service srv = (Service)ic.lookup
　　
　　(java:comp/env/service/SomeSpecificServiceInterface);
　　
　　02 ServiceInstance si = (SomeSpecificService)srv.getPort();
　　
　　例2和例1僅有很小的差別。在01我們只需要對象的一個公用接口。沒有指定返回的接口名稱，所以容器可以自由的返回任意的匹配被請求的JNDI名稱的實例。行02也有一些差別：我們使用一個普通的getPort()調用方法而不是像我們在例1中使用的那種特定名稱的get　port>Port調用方法。
　　
　　規格說明書中聲明當用戶僅僅訪問對象的服務定義時可以使用容器管理端口訪問。行02假定客戶端知道服務可能不支持的一個特定接口。如果容器不知道所需求的cast操作，異常將被拋出。更可能的是，客戶端在build的時候沒有一個完全的WSDL定義，因此他們不能用the　getPort()方法，但是他們會指定合適的實例類型??這種方式看起來更可行。
　　
　　服務器編程模型
　　
　　服務器編程模式可能是JSR109重要的部分。理解Web service在不同的生命周期的工作方式將幫助Web service開發人員創建在不同條件下都可以按預定方式工作的Webservice。EJB規格說明書定義了不同類型EJB的生命周期。JSR 109更進了一步，它擴展了EJB模式，定義了Web services如何在Web　services容器里工作。JSR 109 關于服務器編程的定義是一個解決行為一致性的嘗試。
　　
　　快速背景貼士　Web 應用和EJB 一般在“容器”內執行。容器提供EJB或者Web 應用運行時需要需要的所有服務。事務，JNDI,JDBC,所有類似的服務都由容可提供。一般來說，一個應用服務器里有兩種容器??Web 應用容器和EJB容器。它們都提供相似的服務，比如生命周期管理，但也會有微小的差異，這個要看提供的是何種服務。Web應用容器知道如何加載servlets；EJB容器知道如何加載EJB。
　　
　　在我們了解JSR 109規范內容之前，讓我們先了解我們需要什么來支持Web services順應J2EE的工作方式。首先，Web service的實現應該對客戶透明。Web　service在應用服務器內實現這個事實不應該改變客戶端對服務行為的認識。況且我們需要在很多的應用服務器里使用Web service。因此，編程模式應該是輕便強壯的，不僅支持現在的實現也要支持將來的實現。
　　
　　另一點比較重要的是和現存J2EE服務的無縫整合，例如 JDBC。我們希望我們的Web services能夠方便的利用J2EE現存的優勢而不危及到服務自身的完整性。
　　
　　有了這些目標，JSR 109定義了對Web services兩個領域的支持：無狀態會話bean和servlets。JSR 109一個讓人失望的地方是它在沒有解釋的情況下忽略了消息驅動bean的定義。消息bean支持可擴展的同步消息，這是Web　services的一個重要部分。由于消息bean的行為可以被無狀態bean和servlets所模擬，所以我們需要編寫額外的代碼。
　　
　　在Web services里端口的定義十分重要，JSR 109 定義了在J2EE應用服務器里如何將端口和服務進行映射。Web service的端口在概念上類似于JVM里的實例。