引言
在過去數年裡，隨著萬維網聯盟（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服務的描述
為了提供有關我們的部署示例的足夠信息，我創建了一個需要為接口使用映射文件的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;
|-------10--------20--------30--------40--------50--------60--------70--------80--------9|
|-------- XML error: The previous line is longer than the max of 90 characters ---------|
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服務
為了構建標准 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服務的步驟。
部署過程的描述
創建了所需的全部 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，如下所示。請注意，正是在此處將 <servlet-link>StatsWS</servlet-link> 綁定到實現類。以下聲明位於 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 上部署
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 -->
<listener>
<listener-class>
org.apache.axis.transport.http.AxisHTTPSessionListener
</listener-class>
</listener>
<!-- Axis servlet declaration -->
<servlet>
<servlet-name>AxisServlet</servlet-name>
<display-name>Apache-Axis servlet</display-name>
<servlet-class>org.apache.axis.transport.http.AxisServlet</servlet-class>
</servlet>
<!-- Servlet mappings -->
<!-- AXIS Definitions -->
<servlet-mapping>
<servlet-name>AxisServlet</servlet-name>
<url-pattern>/servlet/AxisServlet</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>AxisServlet</servlet-name>
<url-pattern>*.jws</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>AxisServlet</servlet-name>
<url-pattern>/services/*</url-pattern>
</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 語言將如何發展的一個例子，它提供了應用程序體系結構設計和應用程序部署之間一個重要的聯系。架構師可以描述接口的用途，而運行時平台能夠將此轉換為可部署的解決方案。
