您可以在这里快速查找：


 
您的位置： 编程学习 > java教程 > 200511
文章分类

Java技术
2005: 03 04 05 06 07 08
09 10 11 12
2006: 01 02

Asp.net
2005: 07 08 09 10 11 12
2006: 01 02

VB编程
2006: 02

Asp编程
2005: 11 12
2006: 01 02

C++/VC
2005: 10 11 12
2006: 01 02

Delphi
2005: 12
2006: 01 02

其它

 本文章适合所有读者

J2ME Web 服务入门

mobilechannel

简介

WSA 设计用于与 J2ME 配置文件协同工作，J2ME 配置文件要么基于 Connected Device Configuration (CDC)，要么基于 Connected Limited Device Configuration (CLDC 1.0 或 CLDC 1.1)。远程调用 API 基于 J2SE 的 Java API for XML-Based RPC (JAX-RPC 1.1) 的一个完整子集，它包含了一些远程方法调用（Remote Method Invocation，RMI）类，以满足 JAX-RPC 依赖。XML 解析 API 基于 Simple API for XML, v2 (SAX2)的一个完整子集。

WSA 的目标是把对 Web 服务调用和 XML 解析的基本支持集成到设备的运行时环境，这样开发人员就不必在每个应用程序中嵌入这样的功能了——在像移动电话和个人数字助理这样资源有限的设备中，这算是一个特别浪费资源的问题。

核心规范

Web Services Interoperability Organization (WS-I) 促进了定义 Web 服务的核心规范和应用层协议，并且它们受 World Wide Web Consortium (W3C) 和 Organization for the Advancement of Structured Information Standards (OASIS) 的指导。4 个关键标准规定了如何创建、部署、发现以及如何使用 Web 服务：

Web 服务标准 描述
Simple Object Access Protocol (SOAP) 1.1 定义了传输和数据编码
Web Services Definition Language (WSDL) 1.1 定义了如何描述远程服务
Universal Description, Discovery, & Integration (UDDI) 2.0 定义了如何发现远程服务
Extensible Markup Language (XML) 1.0 和 XML Schema 定义了可扩展标记语言（Extensible Markup Language ，XML） 和 XML 模式（Schema）

这些主要规范往往非常广泛，而且 Web 服务开发人员已发现难以实现完全互操作性。为了解决标准解释中存在的差异，WS-I 已定义了一组称作 WS-I Basic Profile, version 1.0 的一致性规则。JSR 172 符合基本配置文件（Basic Profile）。

J2ME 平台上的 Web 服务

JSR 172 规定了标准化客户端技术，允许 J2ME 应用程序在典型 Web 服务架构上使用远程服务，如图 1 所示：
图 1  在典型 Web 服务架构上的 J2ME Web 服务

在高层，该 Web 服务架构具有三个元素：

  • 驻留在支持 WSA 无线设备上的网络感知应用程序。该应用程序包括使用 JSR 172 运行库与网络进行通信的 JSR 172 存根。下文将会描述存根和运行库所扮演的角色。
  • 无线网络和 Internet 以及对应的通信和数据编码协议，包括二进制协议、HTTP 以及 SOAP/XML.
  • Web 服务器，扮演服务提供者的角色，通常在一个或多个防火墙和代理网关后面。Web 服务器通常提供对专用网络上后端应用程序和服务器的访问。

WSA 的第一个版本只解决了 Web 服务的使用，不支持服务端点的创建和开发；J2ME 设备可以是服务用户，但不可以是服务提供者。JSR 172 还没有规定使用 UDDI 的服务发现的 API。

了解 JSR 172

首先考查如何组织典型的基于 JSR 172 的应用程序，开始了解 J2ME Web Services 是如何运作的：

该应用程序本身是一个基于移动信息设备配置文件（Mobile Information Device Profile，MIDP）或个人基础配置文件（Personal Basis Profile，PBP)）的智能客户机，具有特定于业务的逻辑、用户界面、持久性逻辑以及生命周期和应用程序状态管理。该应用程序可以使用 JAXP 子集 API 来处理 XML 文档。还可以使用 JAX-RPC 子集 API 来使用 Web 服务，从而使用 JSR 172 存根和运行库。

在像手提电话这样的设备中，应用程序和 JSR 172 存根通常驻留在设备内存中，而所有 JSR 172 元素连同基础配置文件和配置一起嵌入到设备本身。

JSR 172 运行库和服务提供者接口

在 JSR 172 操作的中心是运行库，带有服务提供者接口，允许存根执行所有与调用 RPC 服务端点有关的任务：

  • 设置特定于 RPC 调用的属性。
  • 描述 RPC 调用输入和返回值。
  • 编码输入值。
  • 调用 RPC 服务端点。
  • 对应用程序解码并为其返回服务端点所返回的全部值。

图 3 描绘出了客户机应用程序、存根以及运行库三者之间的关系：

图 3  JSR 172 运行库和 SPI

虽然 JSR 172 运行库隐藏了像连接管理和数据编码这样的复杂性，但 SPI 从运行库实现细节分离出了存根，从而允许存根在供应商实现之间的可移植性。

客户机应用程序不直接与运行库和 SPI 进行交互；而是使用存根。运行库和 SPI 主要为打算开发 JSR 172 运行库和自动化工具的第三方供应商所关心，比如开发人员用于生成存根的 WSDL 到 Java 映射工具。

由于应用程序开发人员不直接使用 SPI，因此本文不会较详尽地介绍运行库和 SPI。如果想了解关于它们的更多信息，可以查阅 JSR 172 规范。

JSR 172 JAX-RPC 子集 API

正如前面所提到的，JSR 172 Web 服务远程调用 API 基于 J2SE 的 JAX-RPC 1.1 API 的一个完整子集。以下列表在高层描述了该子集。要了解详细信息，请参阅 JSR 172 specification：

  • 符合 WS-I Basic Profile。
  • 支持 SOAP 1.1。
  • 支持所有传输，比如 HTTP 1.1，它可以传送 SOAP 消息，而且具有一个捆绑 SOAP 1.1 的已定义协议。
  • 支持全套数据类型：逻辑型、字符型、短整型、整型、长整型、浮点型、双精度型、字符串型（String）、基本类型数组以及复杂类型（包括基本或复杂类型的结构）。
    注意，真正的浮点支持只在基于 CDC 或基于 CLDC 1.1. On CLDC 1.0 的软件堆栈中出现，浮点型和双精度型映射为 String。还要注意，所支持的数据类型会约束所支持的 WSDL 数据类型。后面的部分将讨论 WSDL 到 Java 数据类型映射。
  • 支持表示 RPC 调用或响应(使用 Document/Literal 消息传递模式的 WSDL 操作)的 SOAP 消息的 Literal 表示；不支持 Encoded 表示。
  • 不支持带有附件的 SOAP 消息。
  • 不支持 SOAP 消息处理程序。
  • 不支持服务端点；即不允许设备是 Web 服务提供者。
  • 不提供发现支持(UDDI).
  • 要减少对网络带宽的需求——以及要节省用户的时间和每字节的开销，请不要在设备本身上强制使用 XML 编码。
    注：实现可能会使用更高效的编码，比如设备与无线网关间的二进制协议，只要它对消费者和生产者来说都是透明的。

下表描述了 JSR 172 JAX-RPC 子集中的软件包：

Java\ 软件包
描述
javax.microedition.xml.rpc
定义了存根使用的 Type，它是合法简单类型的枚举：逻辑型、字节型、短整型、整型、长整型、浮点型、双精度型、 String
定义了存根使用的 ComplexType，它是表示 WSDL xsd:complextype 定义的特殊类型
定义了存根使用的 Element，它表示 WSDL xsd:element 定义
定义了存根使用的 Operation，它表示服务端点的 WSDL wsdl:operation
定义了 FaultDetailHandler，这是一个处理自定义故障的存根所实现的接口
定义了存根使用的 FaultDetailException，这是一个 Exception 类，表示运行时实现抛出的作为 JAXRPCException 结果的异常；为 service-specificDefines 返回存根异常详细值所使用的 QName（限定名）类，并将相关的 QName 返回给 Stub 实例
javax.xml.namespace
定义了存根所使用的 QName（限定名）类
javax.xml.rpc
定义了 Stub 接口，这是所有 JAX-RPC 存根的基本接口；还定义了 NamespaceConstants 以及与 JAXRPCException 有关的类
java.rmi
标准 java.rmi 软件包子集，包含它以满足 JAX-RPC 依赖性；只定义了 Remote 处理程序和三个异常类：MarshalException、 RemoteException 和 ServerException
 

除了像 RemoteException 这样的异常，存根还使用大多数上述 API；应用程序本身使用存根。

在应用程序中使用 JAX-RPC 子集

创建 JSR 172 JAX-RPC 客户机的一般步骤如下：

  1. 从描述远程 Web 服务的 WSDL XML 文档生成 JSR 172 JAX-RPC 存根类。
  2. 在自己的代码中创建生成存根的实例。
  3. 实例化之后，调用生成存根的方法。这些方法与 WSDL XML 文档中服务端点的 wsdl:操作相对应。

生成 JSR 172 JAX-RPC 存根

客户机应用程序通过存根和设备的 JSR 172 运行库与远程服务进行交互。该运行库隐藏了与连接、SOAP 以及数据编码管理相关的复杂性。

要与运行库进行交互，客户机通常使用存根生成器所生成的存根或者 WSDL 到 Java 的映射工具，它们用于在 WSDL 文档中输入远程服务接口定义，并生成使用 JAX-RPC 子集 API 和运行库 SPI 的存根类。虽然也能手工开发这些存根，但使用该生成器效果会更佳。下图概述了存根的生成：

生成 JSR 172 存根的一般步骤。
最后所得到的存根类实现了 Stub Interface 和服务的远程接口，并使用了支持类。

生成 JSR 172 JAX-RPC 存根的步骤类似于创建基于 RMI 的应用程序的步骤。在标准 RMI 中，RMI 编译器 (rmic) 从远程接口定义生成存根。如图 4 所示，创建 WSA 应用程序之后，WSDL 到 Java 的映射工具从 WSDL XML 文件生成存根。映射工具生成远程接口 Java 文件和支持类，它们由生成的存根本身所使用。然后将 JSR 172 存根编译为 Java 类，并同应用程序一起打包。

Sun 的 J2ME Wireless Toolkit V2.1 包含 JSR 172 JAX-RPC 存根生成器——本文稍后将讲述如何使用它。第三方供应商提供了自己的存根生成器。

使用 JSR 172 JAX-RPC 存根

存根一旦生成了，应用程序就可以使用它了。以下代码片段使用了称作 PubService 的服务，以便检索无线技术文章：

package j2medeveloper.pubwebservice // MIDP import javax.microedition.midlet.MIDlet; import javax.microedition.lcdui.Display; import javax.microedition.lcdui.Form; ... // JAX-RPC import java.rmi.RemoteException; // JAX-RPC String serviceURL = "www.j2medeveloper.com/pubwebservice"; String articleID = "IntroJSR172"; ... // Instantiate the service stub. PubService_Stub service = new PubService_Stub(); // Set up the stub. service._setProperty(Stub.ENDPOINT_ADDRESS_PROPERTY, serviceURL); service._setProperty(Stub.SESSION_MAINTAIN_PROPERTY, new Boolean(true)); ... try { // Invoke the PubService method getArticleByID() to retrieve // a specific article by ID. A WirelessArticle represents an // article and has methods to get the article´s author, date, // title, summary, and body. PubService also has a method to // get the PubService´s RSS feed. WirelessArticle article = service.getArticleByID(articleID); // Create a Form to display the article. javax.microedition.lcdui.Form form = new Form(article.getShortTitle()); form.append(wrap(article.getSummary())); ... ... display.setCurrent(form); } catch (RemoteException e) { // Handle RMI exception. } catch (Exception e) { // Handle exception. } ...

使用存根会使远程服务调用变得非常容易。该代码用例子说明了 PubService_Stub，初始化了实例，并调用了它的其中一个方法 getArticleByID()，以便对文章本身进行检索。然后，应用程序使用了文章的访问方法来获取文章的标题、摘要等等。

注意，因为调用 PubService_Stub.getArticleByID() 是分块调用，因此在实际应用程序中，要用分离的线程来分派该调用。在 WSA 中，方法调用遵循常见的客户机/服务器交互的同步请求-响应模型：客户机向服务器发出请求，然后等待服务器的响应：

图 5  同步请求/响应模型

如何对方法及其参数进行编码、序列化和发送，以及如何接收、解码和反序列化响应，对应用程序来说是完全透明的。JSR 172 存根和运行库处理所有这些单调冗长的细节。

将 WSDL 数据类型映射到 Java

下面简要考察一下 JSR 172 的 JAX-RPC 子集 API 中的 WSDL 到 Java 的数据类型映射：

WSDL 数据类型
Java 数据类型
xsd:string
String
xsd:int
int 或 Integer
xsd:long
long 或 Long
xsd:short
short 或 Short
xsd:boolean
boolean 或 Boolean
xsd:byte
byte 或 Byte
xsd:float
String、float 或 Float
xsd:double
String、double 或 Double
xsd:QName
javax.xml.namespace.QName
xsd:base64Binary
byte[]
xsd:hexBinary
byte[]
Arrays
取决于 XML 数组的模式
xsd:complexType
基本和类类型的序列

别忘了，因为 CLDC 1.0 不支持浮点类型，因此一定要将浮点型和双精度型映射为 String 型。当目标既包含 CLDC 1.0 又包含 CLDC 1.1 平台时，开发人员应使用该默认映射。

要了解关于 WSDL 的更多信息，请参阅 JSR 172 specification 和 W3C´s WSDL specification。

在应用程序中使用 JAXP 子集

现在将注意力转移到 JAXP 子集——其他 JSR 172 API。记得 JAXP 和 JAX-RPC 都是可选软件包；它们彼此独立地存在。

JAXP XML 解析 API 基于 Simple API for XML v2（SAX2）的一个完整子集。虽然标准 SAX2 API 中的大多数类没被包含在该子集中，但保留有所有必要的核心功能。

以下列表在高层描述了 JAXP 子集。要了解更多信息，请参阅 JSR 172 specification：

  • 基于 SAX 2.0 的一个完整子集
    不支持 SAX 1.0，因为 SAX 2.0 已将它取代了。
  • 支持 XML 命名空间
  • 既支持 UTF-8 又支持 UTF-16 字符编码。
  • 要么不支持文档对象模型（Document Object Model (DOM)）的 Level 1.0 ，要么不支持 DOM 的 Level 2.0 ，因为考虑到它太笨重。
  • 不支持可扩展样式表语言转换（Extensible Stylesheet Language Transformations，XSLT）。
  • 支持文档类型定义（Document Type Definition，DTD）。
    解析器可以根据 XML 文档类型的指定内部或外部定义来对这些文档进行验证。 JSR 172 规定，文档验证是可选的，因为该操作开销极大，一个文档在限制较高的基于 CLDC 的环境不适合，但可能会在更高端的基于 CDC 的平台上获得成功。如果跳过 DTD 处理，DefaultHandler.skippedEntity() 方法就会通知应用程序。该逻辑符合 XML 1.0 规范。