在多個容器上部署 Java Web 服務可能會給開發人員帶來一些問題。通過閱讀本文，您可以了解若干部署描述符實現，并了解 Java 社區如何開始處理這個問題。
引言
在過去數年里，隨著萬維網聯盟(World Wide Web Consortium，W3C)更新了核心規范，并引入了彌補 Web 服務最初缺陷的新規范，Web 服務發生了大量的變化。W3C 的 Web Services Activity 小組所維護的規范以獨立于供應商的方式將 Web 服務作為一組 XML 規范進行處理。
同時，Java™ Community Process (JCP) 也在維護自己的規范集，以將 W3C 的建議合并到 Java 語言中。Java APIs for XML(JAX-RPC、JAXB、JAXP、JAXR 和 SAAJ)是一組使用 Java 語言實現 Web 服務規范的接口。
W3C 所維護的當前 Web 服務規范和 JCP 維護的 Java Web 服務 API 處理“網絡上”的 Web 服務，以確保平臺獨立性和語言獨立性。遵循 XML 規范或使用 Java API 的開發人員將確保應用程序能夠通過任何通信協議在任何平臺上與采用任何語言編寫的 Web 服務進行通信。Web 服務可擴展任何應用程序的訪問范圍，是經過驗證的對目前基于 Web 的應用程序有價值的集成技術。
但當基于 Web 的應用程序需要跨多個 Web 應用程序容器(如 IBM® WebSphere® Application Server、BEA WebLogic 和 Tomcat 等，這里僅指出三個)部署時，跨網絡兼容性不夠。對于 Java Web 服務，沒有跨多個 Web 應用程序容器實現的標準部署的“web.xml”可用。
如果您希望應用程序支持多個 Web 應用程序容器提供的 Web 服務實現，則 Java Web 服務應用程序的部署可能會成為一項挑戰。可以在 Web 應用程序中使用單個 Web 服務實現，如來自 Apache Web 服務項目的 Axis。對于 Web 服務客戶機，這個策略通常能跨多個 Web 容器工作，因為客戶機代碼并不依賴于任何 Web 服務部署描述符。對于 Web 服務提供者(服務器)，如果將 Web 服務實現嵌入 Web 應用程序存檔(Web Application Archive，war)文件中，可能會導致意外加載器沖突，因此使用供應商的 Web 服務實現是最理想的部署選擇。
本文剩下的部分將討論 Java Web 服務的部署問題，向您展示各種部署描述符實現，并討論 Java 社區如何開始處理這個問題。
開發跨多個容器部署的單個 Web 服務
對于 Web 應用程序部署，我們希望進行開放性的選擇。如果您的客戶在 WebSphere 或 WebLogic 等商業 J2EE 實現進行了投資，他們將希望利用其投資的平臺。另一方面，如果您的客戶希望降低初期投入成本，則可能希望采用 JBoss 或 Apache Tomcat 等開放源代碼解決方案。在這兩種情況下，如果您希望盡可能提高開發工作的可重用性，則可能無法依賴于可用的供應商特定 IDE。使用 J2EE 應用程序供應商提供的 IDE 進行開發工作可能會限制處理 Java Web 服務時的靈活性，隱藏部署 Web 服務的很多細節。
本文中的示例使用開放源代碼社區提供的免費標準的開發工具集來為每個目標 Web 應用程序容器構建 Web 服務部署描述符。所有這些工具均在開發人員中得到了廣泛應用，且支持各種開放標準技術。
我們的目標是，獲得能夠生成可使用 Axis 跨目標 Web 應用程序容器(WebSphere、WebLogic、JBoss 和 Tomcat)部署的 Web 服務的單個項目。相應的 war 文件應該能夠在只需很少修改而絕對不需要重新編譯源代碼的情況下部署到我們的目標 Web 應用程序容器上。
本文并不打算作為有關 Web 服務或 Web 服務部署的教程，而旨在說明 Java Web 服務的一個問題，并闡述將來可以如何處理這個問題。如果您僅使用一個 Web 應用程序容器，而沒有打算更改 Web 應用程序容器，則可以跳過有關 Web Services Metadata (JSR-181) 的部分(此 JSR 可能會影響您將來的開發工作)。
為了提供有關我們的部署示例的足夠信息，我創建了一個需要為接口使用映射文件的 Web 服務。傳統的 Hello World 或 Stock Ticker Web 服務將無法提供足夠的信息來說明我們的 Web 服務部署需求。
我們的 Web 服務端點將具有多個方法，這些方法可用于說明部署期間所需的各種文件。我們的示例 Web 服務將返回有關遠程應用程序性能的信息。當然，我們的示例實現并不會返回任何實際的信息，它只不過是一個簡單的示例，用于說明更為復雜的 Web 服務接口的要求。下面是用于創建我們的 Web 服務端點的接口文件。
清單 1. Web 服務端點接口
| public interface StatsService extends java.rmi.Remote { public StatsContainer[] getAllStatistics() throws java.rmi.RemoteException; public StatsContainer[] getStatistics(String category) throws java.rmi.RemoteException; public void resetAllStatistics() throws java.rmi.RemoteException; public void resetStatistics(String category) throws java.rmi.RemoteException; public void clearStatistics() throws java.rmi.RemoteException; public String[] getCategories() throws java.rmi.RemoteException; } |
此接口具有兩個不同的返回類型，需要進行映射。第一個類型是 StatsContainer 對象數組，而另一個類型則是 string 對象數組。StatsContainer 是簡單容器對象，該對象具有若干基元類型和兩個字符串。我們的目標是，從此接口和實現文件入手，使用我們的開放工具集中提供的工具構建所需的部署描述符，以便將 Web 服務部署到目標平臺上。我們將描述此過程中的每個步驟以及生成的各個文件。
構建過程的描述
我們的 Web 服務的構建過程中將使用各種自動化工具，這些工具由可利用 Java 自檢構建 Web 服務構件的 Web 服務實現提供。對于我們的部署，將使用兩種不同的構建工具，因為部署描述符分屬兩個不同的組:支持 J2EE 1.4 的部署描述符和自定義 Web 服務部署描述符。
為了構建標準 J2EE 1.4 Web 服務所需的構件，我們使用了 Java Web Service Developers Pack (JWSDP v1.5) 所提供的 wscompile 命令。wscompile 命令會創建 Web 服務描述語言(Web Service Description Language，WSDL)文件、Web 服務映射文件和實現文件，以便在 Web 服務和調用的應用程序之間進行封送處理。
為了運行 wscompile 命令，您首先需要編寫一個 XML 配置文件，在其中描述您希望 wscompile 執行的操作。在此示例中，我們希望處理我們的服務端點并創建實現所需的 XML 構件和序列化代碼。下面是 wscompile 命令所需的配置文件的示例:
清單 2. 示例配置文件
| <?xml version="1.0" encoding="UTF-8"?> <configuration xmlns="http://java.sun.com/xml/ns/jax-rpc/ri/config"> <service name="StatsWS" targetNamespace="http://services.symmetrysolutions.com/stats" typeNamespace="http://types.symmetrysolutions.com/stats" packageName="com.symmetrysolutions.statsws"> <interface name="com.symmetrysolutions.statsws.StatsService" servantName="com.symmetrysolutions.statsws.StatsServiceImpl"/> </service> </configuration> |
在此配置文件中，我們使用 service 元素描述我們的 Web 服務。此元素告知 wscompile 命令以下內容:將與接口關聯的命名空間以及與該接口關聯的類型。除了命名空間外，service 元素還告知 wscompile 命令為生成的任何源代碼使用的包名稱以及其將自檢的接口的名稱。
運行自動化工具并不是部署符合 J2EE 1.4 的 Web 服務的最后一步。根據所使用的 Web 應用程序容器的不同，最后的步驟將有所變化。無論在何種情況下，必須包含的最后一個 Web 服務部署構件都是 webservices.xml 文件。此文件告知 J2EE 1.4 應用程序容器在何處查找 Web 服務描述，以及將什么接口和實現類用于 Web 服務。
Axis Web 服務
Axis Web 服務的構建過程與 J2EE 1.4 Web 服務不同，因為 Axis 具有自己的部署描述符。Axis Web 服務運行時需要 deploy.wsdd 文件提供的信息，以確定服務端點的名稱和將其作為 Web 服務發布的方式。deploy.wsdd 文件將發送到 Axis 服務器，Axis 服務器將利用此信息對 Web 服務進行自檢，并創建 Web 服務運行時所需的信息。注意:上述過程并不符合 J2EE 1.4 (部署構件)，但符合 SOAP 1.1，因此 Axis Web 服務將能夠與任何 Web 服務客戶機進行互操作。
要構建 Axis Web 服務部署描述符，可以手動進行，也可以使用 Axis WSDL2Java Ant 任務來處理 Web 服務的 WSDL。在我們的示例中，由于我們決定使用 Web 服務端點的接口，因此沒有 WSDL 文件。幸運的是，Axis 還提供了一個 Ant 任務來處理接口并輸出 WSDL 文件。因此，Axis 構建過程包含兩個步驟，如下所述:
- 使用 Java2WSDL 任務從接口創建 WSDL 文件。
- 從 WSDL 創建 Web 服務框架(本文中將不使用)和部署描述符(將在本文中使用)。
構建了 Axis Web 服務后，必須告知 Web 應用程序容器要部署的服務以及如何進行部署，以便進行部署。這是通過將 deploy.wsdd 文件傳遞給部署 Web 服務的 Axis 管理員任務來完成的。這意味著，在 Web 容器啟動后，Axis Web 服務需要進行部署 Web 服務的步驟。有關詳細信息，請參見 Tomcat 上的 Axis 部署部分。
部署過程的描述
創建了所需的全部 Web 服務部署描述符后，最后一步是在每個目標平臺上部署應用程序。我們將說明為了部署 Web 服務而需要在每個目標 Web 應用程序平臺上進行的最后步驟。
IBM WebSphere 和 JBoss 4.0.4
IBM WebSphere 和 JBoss 4.0 均符合 J2EE 1.4，可以使用 Java Web Services Developer Pack (JWSDP v1.5) 或類似工具來生成 JAX-RPC Web 服務構件。唯一還沒有為部署生成的 Web 服務構件是 webservices.xml 文件，該文件描述如何將所有組件組合到一起。
在 JBoss 4.0.4 上部署
要在 JBoss 上部署 Web 服務，必須進行以下步驟:(請注意，我們必須使用 JBoss 4.0.4，因為在 JBoss 的早期版本上部署數組類型會出現問題。)
- 創建 webservices.xml 文件來描述我們的 J2EE 1.4 Web 服務部署，如下所示:
清單 3. 示例 webservices.xml 文件
| <?xml version="1.0" encoding="UTF-8"?> <webservices xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://www.ibm.com/webservices/xsd/j2ee_web_services_1_1.xsd" version="1.1"> <webservice-description> <webservice-description-name>StatsWS</webservice-description-name> <wsdl-file>WEB-INF/wsdl/StatsWS.wsdl</wsdl-file> <jaxrpc-mapping-file>WEB-INF/mapping.xml</jaxrpc-mapping-file> <port-component> <port-component-name>StatsWS</port-component-name> <wsdl-port>StatsServicePort</wsdl-port> <service-endpoint-interface> com.symmetrysolutions.statsws.StatsService </service-endpoint-interface> <service-impl-bean> <!—This servlet is declared in our web.xml file --> <servlet-link>StatsWS</servlet-link> </service-impl-bean> </port-component> </webservice-description> </webservices> |
- 修改 web.xml 文件，以將 Web 服務端點聲明為 Servlet，如下所示。請注意，正是在此處將
StatsWS 綁定到實現類。以下聲明位于 web.xml 文件中，用于將實現綁定到 Servlet。
清單 4. web.xml 中的 Web 服務 Servlet 引用
| <!-- This name is declared in the webservices.xml file --> <servlet> <servlet-name>StatsWS</servlet-name> <servlet-class> com.symmetrysolutions.statsws.StatsServiceImpl </servlet-class> </servlet> |
- 構建并打包 Web 應用程序存檔 (war)，然后部署 Web 應用程序。
IBM WebSphere Web 服務的構建過程與 J2EE 1.4 Web 服務類似，唯一不同的是使用了 WebSphere 特定的工具來生成所需的部署描述符(J2EE 1.4 標準 + WebSphere 特定)。要構建 WebSphere Web 服務部署描述符，您可以手動進行，也可以使用 WSDL2Java 任務來處理 Web 服務的 WSDL。在我們的示例中，由于我們決定使用 Web 服務端點的接口，因此沒有 WSDL 文件。因此，WebSphere 構建過程包含兩個步驟，如下所述:
- 使用 Java2WSDL 任務從接口創建 WSDL 文件。
- 從 WSDL 創建 Web 服務部署描述符。
通過完成上述任務構建了 WebSphere Web 服務后，必須將所有生成的構件(序列化類和部署描述符)打包到 war 文件中，以便能在 WebSphere 服務器上部署。
Tomcat 上的 Axis 部署
部署 Axis Web 服務需要在 Web 容器內執行 Axis 特定的命令，以告知 Axis 引擎部署 Web 服務。這在生產應用程序中可能比較困難，因為要依賴手動步驟重新啟動來部署 Web 服務。為了處理此問題，可以為 Web 應用程序發布的 Web 服務發出所有部署命令，然后將生成的 service-config.wsdd 文件嵌入到 war 文件中。Axis 引擎啟動時(根據 web.xml 文件中的配置設置)，它會查找 service-config.wsdd 文件，并自動重新部署 Web 服務。
要部署 Axis Web 服務，需要執行以下步驟:
- 修改 web.xml 文件，以包含 Axis 引擎的聲明(Servlet 聲明)，如以下的清單 5 中所示。
- 從 WSDL 創建 Web 服務部署描述符。
清單 5. web.xml 中的 Axis 引擎的 Servlet 聲明
|
<!-- AXIS servlet definition --> <servlet-mapping> <servlet-mapping> |
- 打包并部署 Web 應用程序。
- 運行 Axis AdminService，以部署為 Web 服務生成的部署描述符。如果生成的配置未包含在 war 文件中，則必須在每次啟動服務器時執行此步驟。
- 或者，可以將 service-config.wsdd 重新打包回 war 文件中，以供將來進行部署。這樣將避免在每次啟動 Axis 引擎時執行前述步驟，但是，如果打包和部署所使用的 Axis 引擎版本不同，Axis 引擎可能無法正常工作。這只應該在部署時進行，以便在 Axis 引擎發生變化的情況下能生成新的 service-config.wsdd 部署描述符。
BEA WebLogic
BEA WebLogic 商業 Web 服務容器在 8.1 及更早版本中使用自定義部署描述符。它還使用標準 JAX-RPC 描述符(可以通過使用符合 JSR-181 的注釋生成)。BEA 將 JSR-181 引入了 Java Community Process。根據 WebLogic 9.x 開發者指南，WebLogic 平臺的建議部署流程采用 Web Services MetaData(下面描述的 JSR-181)來標記用于實現 Web 服務的 Java 文件、使用 JDK 5.0(用于提供注釋支持)編譯帶注釋的文件，以及使用 WebLogic JSR-181 處理器來處理最后所得到的類文件。這將產生符合 J2EE 1.4 規范的其他 Web 服務構件。WebLogic 提供了稱為 jwsc 的 Ant 任務來執行最后一個操作。運行了 jwsc 任務后，就可以將 Web 服務部署描述符打包成 war 文件，以進行部署。
JSR-181 簡化 Web 服務開發和部署
前面討論的觀點具有雙重意思:
- 說明跨多個 Web 應用程序容器部署 Web 服務所需的步驟
- 說明開發人員嘗試在 Java 平臺上部署 Web 服務時將遇到的困難
在說明 JSR-181 在簡化 Web 服務部署方面的好處時，我們將重點討論這兩個目標中的后者。
JSR-181 是由 BEA Systems, Inc. 引入 Java Community Process (JCP) 的，用于簡化使用 Java 平臺開發和部署 Web 服務的過程。JSR-181 中描述的規范依賴于 J2SE 5.0 的功能來對描述 Web 服務實現的 Web 服務元數據進行注釋。通過在源代碼中使用一些簡單的 Web 服務注釋，Web 容器將能夠在無需滿足任何其他開發要求的情況下發布 Web 服務。
如規范中所述，JSR-181 所涉及的范圍如下:
- 定義用于進行 Web 服務應用程序編程的帶注釋 Java 語法
- 提供可促進和加速開發的簡化 Web 服務開發模型
- 提供可通過工具進行操作的語法
- 定義構建和部署 Web 服務的標準，而無需了解通用 API 和部署描述符的知識和使用相關實現
此規范的總體目標是使 Java Web 服務簡單且易于部署，以提供最常見的 Web 服務功能。此規范并未定義 Web 容器必須執行何種操作來部署 Web 服務，從而使得所得到的 WSDL(Web 服務契約)跨 Web 容器保持一致且符合開發人員的設想。
JSR-181 編程模型
JSR-181 引入的編程模型建立在 J2EE 1.4 服務器模型和 JAX-RPC 的基礎之上，簡化了開發人員需要維護的 Web 服務構件數量。根據服務實現的起點不同，JSR-181 可以大幅度減少為了實現 Java Web 服務所必須維護的構件的數量。該規范描述了開始 Web 服務開發的若干不同方法以及 Web 服務注釋功能如何幫助進行開發工作。Web 服務入門編程模型如下所述。
從 Java 入手
從 Java 入手將可能是 Java Web 服務創建者最常采用的方法，同時也是該規范唯一要求 的編程模型。此編程模型允許開發人員創建實現類，并為所需 Web 服務功能添加注釋。其他 Web 服務構件(WSDL、模式和部署描述符)將自動由 JSR-181 處理器從帶注釋的 Java 類生成。WSDL 的缺省生成將遵循 JAX-RPC 1.1 所定義的 Java 到 XML/WSDL 的映射，但開發人員可以通過使用 Web 服務注釋來自定義 WSDL。
從 WSDL 入手
從 WSDL 入手的編程模型用于生成服務端點接口以及表示模式定義的類和 WSDL 內定義的各個消息部分。 在此模型中，JSR-181 注釋直接在實現文件中使用——而實現文件必須由開發人員創建，以定義 WSDL 服務契約未確定的細節(如綁定或服務位置信息)。
從 WSDL 和 Java 同時入手
從 WSDL 和 Java 同時入手的編程模型用于將實現映射到 WSDL 中定義的接口契約。支持此編程模型時，JSR-181 處理器必須 在實現文件中描述的注釋與 WSDL 中定義的契約不匹配時提供反饋信息。
JSR-181 處理器
JSR-181 規范對 Web 服務容器內的 JSR-181 處理器的實現細節的規定仍然十分開放，唯一的要求就是處理器能產生可運行的 Web 服務。這個開放性的實際結果就是，JSR 實現開始在市場上出現。開發人員將來可以使用多種不同類型的處理器來實現從 Java 入手的編程模型。例如，一個模型可以就是產生符合 J2EE 1.4 的 Web 服務構件的預處理器。在這種情況下，預處理器可能產生一個配置文件和 webservices.xml 部署文件，并調用 Java2WSDL 編譯步驟。另一個實現可以提供拖放 Web 服務部署，會在運行時處理注釋，以直接從 Web 應用程序中包含的類直接發布 Web 服務。
JSR-181 中的 Web 服務注釋
如果繼續構建之前的示例 Web 服務，我們可以使用 JSR-181 注釋實現它，以幫助生成 J2EE 1.4 Web 服務構件。通過使用 JSR-181 處理器，我們前面的示例將不需要在開發時包含任何部署構件，可以從實現文件中的注釋生成可行的 Web 服務。下面是 JSR-181 提供的一些注釋的簡單描述。有關 Web 服務注釋的完整討論，請參見“參考資料”部分提供的規范。
清單 6. WebService 注釋
| @WebService( name = "StatsWS", targetNamespace = "http://services.symmetrysolutions.com/statsws", serviceName = "StatsWS" ) |
WebService 注釋(必需)位于 Java 文件中的類或接口聲明之前。當 WebService 注釋位于類聲明前時，它將類標記為實現 Web 服務，除非使用 WebMethod 注釋顯式聲明，或聲明了 endpointInterface，否則所有公共方法都將成為 Web 服務接口的一部分。當 WebService 注釋位于接口聲明前時，它將接口標識為 Web 服務接口，接口內的所有方法都被視為 Web 服務端點的一部分，而不會考慮接口內的 WebMethod 注釋。
清單 7. SOAPBinding 注釋
| @SOAPBinding(style = SOAPBinding.Style.RPC, use = SOAPBinding.Use.ENCODED) |
SOAPBinding 注釋(可選)位于 Java 文件內的類或接口聲明前。SOAPBinding 注釋允許開發人員控制 Web 服務在 SOAP 消息協議上的映射。
清單 8. WebMethod 注釋
| @WebMethod(operationName = "getAllStatistics") |
WebMethod 注釋(可選)在方法級別聲明，用于自定義作為 Web 服務操作公開的方法。在實現類中使用時，將允許開發人員限制將哪些方法作為 Web 服務公開、與操作關聯的名稱以及 SOAPAction 綁定。在接口文件中使用時，僅用于控制與操作關聯的名稱以及 SOAPAction 綁定。
清單 9. WebParam 注釋
| @WebParam(name = "category", mode="IN") |
WebParam 注釋(可選)在方法內聲明，用于自定義 Web 服務操作內的參數。WebParam 最常與 RPC 樣式綁定一起使用，但也可以用于將元素名稱的參數與采用 DOCUMENT 樣式綁定的命名空間關聯。
清單 10. WebResult 注釋
| @WebResult(name = "categoryList") |
WebResult 注釋(可選)在方法級別聲明，用于自定義 Web 服務操作的返回值。
從上面提到的列表中可以看出，使用 JSR-181 處理器部署 Web 服務可以大幅度減少基于 Java 的 Web 服務的開發和部署的工作量。此注釋列表并不完整，但卻代表了可能在典型部署中使用的最常見注釋。我建議您閱讀完整的 JSR-181 規范，以全面了解 Web 服務注釋的所有功能。
使用 Web 服務注釋
如果搜索支持 JSR-181 的 Web 應用程序容器，所得到的結果將非常有限。撰寫本文時，只要極少數產品支持 JSR-181，包括 JBoss 4.0.4、BEA WebLogic 9.x 和 JSR-181 參考實現。為了測試帶注釋的 Java Web 服務，我建議執行以下步驟:
- 確保安裝了 J2SE 1.5 (5.0)，且它是您的缺省 Java 編譯器。當嘗試編譯注釋時，可以立即知道它是否是缺省 Java 編譯器。
- 下載 JSR-181 實現。我決定使用 JBoss 4.0.4，因為它是唯一具有全面 JAX-RPC 支持的 JSR-181 開放源代碼實現。
- 安裝 JBoss 4.0.4 并確保選擇了 EJB3 選項(可能不一定需要進行此步驟)。到撰寫本文時，JBoss 4.0.4 的 GA 版或更高版本應該可以獲得。如果不能獲得此版本，請確保下載并安裝 JBossWS 的 GA 版，因為此版本提供了對 JSR-181 的全面支持。
- 將注釋添加到 Web 服務實現或實現和接口中。
- 編譯并打包 Web 應用程序。
- 將 war 文件拖放到 JBoss 的部署目錄，并啟動。現在 JBossWS JSR-181 處理器應對您的 Web 服務進行部署。
從前面的步驟可以看出，在 Web 容器內實現 JSR-181 處理器時，Java Web 服務部署可能簡單到執行一次拖放操作即可完成。
正如前面所提到的，JSR-181 規范對 Web 容器中運行的處理器并沒有任何特殊的要求。唯一的要求是，JSR-181 處理器完成工作后，將獲得具有一致的 WSDL 契約的可部署 Web 服務。這個要求將很可能采用多種方式實現。第一個方法通過 JBoss 4.0.4 服務器進行了說明，即支持拖放部署。此方法并不會產生開發人員可用的任何部署描述符構件，但卻是最簡單的部署方法。在需要對部署描述符進行某些自定義的情況下，此方法可能行不通。在此情況下，繼續采用前面所述的標準 J2EE 1.4 部署可能是最佳選擇。
另一個部署方法就是采用集成開發環境(Integrated Development Environment，IDE)的外接程序組件或可以在構建過程中運行的 Ant 任務。(請參見上面有關部署 BEA WebLogic 的描述。)處理器外接程序可以在將產品打包為 war 文件前正確運行，并且將基于注釋為 Web 服務生成服務器特定的部署描述符。Apache Beehive 項目好像正在開發這樣的組件，在不久的將來可能會提供一個通用 JSR-181 實現。(請參見“參考資料”部分中有關 Apache Beehive 的信息。)通過使用這種實現方法，處理器將生成可允許開發人員進行進一步自定義的部署描述符。
Web Services MetaData (JSR-181) 無疑將使得構建和部署 Java Web 服務的工作比目前簡單得多。開發人員將不必了解很多不同的部署描述符，還可能不必在部署時對 Web 應用程序進行修改。Web 服務注釋是 Java 語言將如何發展的一個例子，它提供了應用程序體系結構設計和應用程序部署之間一個重要的聯系。架構師可以描述接口的用途，而運行時平臺能夠將此轉換為可部署的解決方案。
查看原文：http://www-128.ibm.com/developerworks/cn/webservices/ws-deployjava.html