用于 Java 2 平台袖珍版 (Java 2 Platform, Micro Edition，J2ME) 的 Web 服务 API (WSA) 是由 Java Community Process 为 Java 规范请求 172 (JSR 172) 而定义的，这些 API 是两个相互独立的可选包，用于远程服务调用和 XML 解析。

他们是针对基于连接设备配置 (Connected Device Configuration，CDC) 和有限连接设备配置 (Connected Limited Device Configuration，CLDC 1.0 和 CLDC 1.1) 的框架的。为什么用户应该关注这些呢？因为 JSR 172 在设备层为远程服务调用和 XML 解析提供了支持，也就意味着开发人员不用将这项功能嵌入到每一个应用程序中。本文介绍了远程服务调用可选包 API。

J2ME 中的 Web 服务

Java 2 平台袖珍版 (J2ME) 平台中的 Web 服务是由 Java 规范请求 172 (JSR 172) 定义的，它与标准 Web 服务遵循同样的规范、结构以及调用模型。我们来回顾一下清单。

与标准 Web 服务的比较 JSR 172 Web 服务 API (WSA) 遵循下面这些核心 Web 服务规范：

简单对象访问协议 (SOAP) 1.1，定义传输和数据编码。
Web 服务定义语言 (WSDL) 1.1，定义如何描述远程服务。
XML 1.0，定义 XML 标记语言。
XML Schema，毫无疑问，定义 XML 模式。
注意 JSR 172 不支持统一描述、发现和集成 (UDDI) 2.0 规范，该规范定义了如何发现远程服务。

由于有相当多的与 Web 服务相关并且涵盖了不同技术的规范出台，而且越来越多，Web 服务互操作组织 (WS-I) 定义了 WS-I 基本概要 1.0 (WS-I Basic Profile，Version 1.0) 来定义 Web 服务规范的最小集，和一致性规则一样，所有的基础 Web 服务提供者和消费者都必须遵守该概要。JSR 172 规范也遵守 WS-I 基本概要。

与标准 Web 服务具有相同的体系结构：

JSR 172 WSA 从客户端访问 Web 服务，从服务－消费者的角度来看，WSA 提供远程服务调用 API (JAX-RPC) 以及运行时环境，从而允许 J2ME 应用程序在 Web 上消费服务，而不是作为服务生产者（端点）来运行。除了这一点差别之外，JSR 172 WSA 体系结构的其它部分与 Web 服务的标准体系结构/组织一致，如下图所示：



图 1 - WSA 高级体系结构

该高级体系结构组织如下：

客户端，Web 服务消费者：它是 J2ME 应用程序，例如 MIDP 或个人版基于框架的应用程序，JSR 172 存根和支持类，以及 JSR 172 运行时。

网络：指的是无线和有线网络以及通信协议，无线和有线网络是 Internet 的一部分。注意 JSR 172 本身没有规定在设备上使用 XML 编码方法，而允许执行程序（只要它们对消费者和生产者是透明的）使用更有效的编码方法，例如在设备和无线网关之间使用二进制协议。

服务器，Web 服务生产者：它是一个 Web 服务器，通常位于防火墙和/或代理网关的后面。该服务器可以访问后台资源。

调用模型和数据流与标准 Web 服务相同： J2ME 应用程序通过 JSR 172 存根和运行时调用远程服务，通常要通过 HTTP 和 SOAP 来进行传输。存根和运行时将与远程服务调用相关的复杂部分都隐藏起来了，包括输入值和返回值如何编码并解码，以及与服务器进行网络通信的管理。方法调用遵循同步请求－应答模型，如下图所示：



图 2 - JSR 172 调用模型

由于调用是按模块进行的，所以您应该把这些调用分派到不同的执行线程中。

消费 Web 服务

要消费 Web 服务，您必须首先创建服务调用存根。让这些存根来执行任务，例如对输入值和返回值进行编码和解码、与 JSR 172 运行时交互来调用远程服务端点。存根通过运行时的服务提供者接口 (SPI) 与运行时进行交互，这样通过概述运行时执行的详细情况，使存根在不同厂商之间的执行更便捷。

存根通常是用工具生成的，该工具读取一个 WSDL XML 文档，文档描述了将要使用到的 Web 服务。同样的，WSDL 文档通常也是通过工具生成的，该工具读取接口定义，例如 Java 接口产生了 WSDL 文档。

从我们移动开发的角度来看，需要消费的 WSDL 文档通常已经存在，您需要做的仅仅是生成 JSR 172 WSA 存根。要生成这些存根，您应该使用例如 J2ME Wireless Toolkit 2.1 存根生成器这样的工具，如下图所示：

图 3 - 生成 JSR 172 WSA 存根

该生成器生成存根 Java 文件，以及相关的支持类。如下一部分所描述的，它还考虑到了 WSDL 到 Java 的数据类型映射。

一旦生成了 JSR 172 JAX-RPC 存根和支持文件，您的应用程序就已经被编译并部署到启用了 JSR 172 的设备上了，消费 Web 服务是很简单的而且几乎是透明的。您很快就会看到，调用远程方法几乎和调用本地方法一样简单。

JSR 172 JAX-RPC 子集 API JSR 172 远程方法调用 API 是以基于 XML 的 RPC 的 J2SE Java API (JAX-RPC 1.1) 的子集为基础的。它同样遵守 WS-I 基本概要。下面来详细研究一下 JSR 172 JAX-RPC 子集 API：

它支持：

SOAP 1.1。 任何可以传送 SOAP 消息的传输，例如 HTTP 1.1，都有一个定义好的用于 SOAP 1.1 的协议绑定。 SOAP 消息的文字表示代表一个 RPC 调用或应答。下面（是）数据类型和相应的 Java 映射：

xsd:boolean 到 boolean 或 Boolean。
xsd:byte 到 byte 或 Byte。
xsd:short 到 short 或 Short。
xsd:int 到 int 或 Integer。
xsd:long 到 long 或 Long。
xsd:float 到 float，或 Float。对基于 CLDC 1.0 的平台，该数据类型映射到 String。
xsd:double 到 double，或 Double。对基于 CLDC 1.0 的平台，该数据类型映射到 String。
xsd:string 到 String。
xsd:base64Binary 到 byte[]。
xsd:hexBinary 到 byte[]。
xsd:complexType 到基本类型和类类型序列。
xsd:QName 到 javax.xml.namespace.QName。
以 XML 数组模式为基础的基本类型和复杂类型（结构中包含基本类型或复杂类型）数组。
它不支持：

带附件的 SOAP 消息。
SOAP 消息处理器。
SOAP 消息的编码表示。
服务端点（不是 Web 服务生产者）。
服务发现支持 (UDDI)。
设备端没有规定 XML 编码方法。这样做是通过允许执行程序使用更有效的数据编码方法来帮助减少网络传输，例如在设备和无线网关间使用二进制协议（只要这样编码对消费者和生产者是透明的）。

JSR 172 远程调用 API 包括下面这些包：

javax.microedition.xml.rpc
javax.xml.namespace
javax.xml.rpc
java.rmi （包括确保 JAX-RPC 相关型）
注意这些 API（有一些异常 API，例如 RemoteException）不是直接由应用程序调用，相反，应用程