创建了所需的全部 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 文件

　　修改 web.xml 文件，以将 Web 服务端点声明为 Servlet，如下所示。请注意，正是在此处将 StatsWS 绑定到实现类。以下声明位于 web.xml 文件中，用于将实现绑定到 Servlet。

　　清单 4. web.xml 中的 Web 服务 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 声明

　　打包并部署 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 服务。