设计移动 Web 服务

    从何时选择移动 Web 服务到总体设计指导原则再到用于移动 Web 服务的值类型，本文提出了在设计用于移动设备的 Web 服务时需要考虑的许多设计事项。文中还介绍了许多设计移动 Web 服务方面的最佳实践。从本文中，您可以了解如何决定何时使用 Web 服务、在设计 Web 服务时需要考虑什么事项，以及在规划移动 Web 服务时必须谨记哪些问题。

    Web 服务是一种集成技术。在集成异构系统时 Web 服务的价值可以得到最好的证明，因为其支持许多类型的编程语言、运行时环境和网络。当需要从不兼容的环境连接应用程序时，Web 服务就有了用武之地。通过 Web 服务，您可以将业务应用程序从 Java？ 2 Platform Enterprise Edition （J2EE） 连接到 .NET.您还可以使用某个运行在 Linux？ 中的应用程序将一个应用程序集成在 Windows？ 操作环境中。在本文中，我提供了一些针对移动 Web 服务的重要设计考虑事项，并且向您介绍了一些与之有关的最佳实践。

    首先，我将讨论在开始之前 需要考虑哪些事项。

    开始之前

    在开始设计整个系统的体系结构之前，您必须做出如下决定――何时使用移动 Web 服务以及何时不使用移动 Web 服务。

    对于移动设备，Web 服务是利用工作站的强大计算功能的一种最佳方式。Java Specification Request 172 （JSR-172） 定义了用于 Java 2 Platform Micro Edition （J2ME） 平台的 Web 服务 API.由于移动服务主要从客户端的角度进行编程并且是服务使用者，因此本文只需要介绍一部分远程服务调用 API （JAX-RPC） 和 JAXP （Java API for XML Parsing）。

    设计移动 Web 服务的主要目的在于使嵌入式设备能够使用由服务器提供的服务，换句话说，移动 Web 服务是从 Web 服务使用者的角度进行设计的，目的在于支持轻量级设备共享服务器的计算功能和数据库。

    移动 Web 服务无缝地集成了运行在不同平台上的两种不同的应用程序，并且提供了它们之间的互操作性。通常，在考虑移动设备的参与时，有三种类型的集成技术可以运用：

    套接字通信
    Web 服务
    消息传递技术（如 WebSphere？ MQ Everyplace）

    与套接字通信和消息传递技术相比，Web 服务有一些突出的优势。Web 服务使用可扩展标记语言 （XML） 来传输消息（包括结构良好的数据信息），使用简单对象访问协议 （SOAP） 来传输对象。如果您使用的是套接字通信，则必须完全负责定义要传输的数据结构。而且，如果客户端和服务器是用不同的编程语言编写的（例如 C++ 和 Java 编程语言），则您的工作量将大大增加――您必须负责数据传输和 C++ 和 Java 编程中的编码细节。

    消息传递软件可能是一种解决方案，但如果您所关注的是性能，并且不担心事务和安全级别，则消息传递软件真的不是一个非常好的选择。如果使用消息传递软件，您将花大量的时间和精力解决安全问题，并且您的客户很有可能站在您的门口问：“为什么这么慢？”

    我不准备告诉您正确的选择应该是什么，而给出一些理由来说明为什么 Web 服务可能是一个好的选择。

    其中的一个理由可能是服务器端编程。即使是像 Web 服务这样好的机制，也仍然由于 XML 处理以及传输和接收 SOAP 消息的开销的原因而不能满足严格的实时处理需求。因此在设计时需要考虑两个问题：

    1.与普通的 HTTP 访问和专用的消息传递方法相比，每次 Web 服务调用的开销都比较大，所以当您主要考虑性能时，您可能需要首先选择另一项技术。

    2.由于开销的原因，如果您只需要在应用程序的各层之间进行通信，就不必选择 Web 服务。例如，不要将 Web 服务放在应用程序的视图层和控制器层之间。

    现在，我假定您已经决定使用 Web 服务。那么，在总体设计方面需要考虑哪些问题？

    在决定使用 Web 服务之后

    您需要考虑的下一个问题是 Web 服务的总体设计。可以运用下列通用设计指导原则：

    1.管理 Web 服务的粒度。

    2.首先定义 Web 服务接口，然后加以实现。

    3.使用 Document/literal 作为编码样式。

    4.优先选择 JavaBean 组件而不是 Enterprise JavaBean （EJB） 组件作为服务提供者。

    5.避免 XML 元素嵌套太深，因为这可能大大延长解析、封送处理和取消封送处理的时间。

    下面详细介绍这些设计考虑事项。

    管理 Web 服务粒度

    关于粒度管理需要谨记以下几点：

    1.始终优先考虑粗粒度的 Web 服务；决不要在分布式系统之间使用细粒度 Web 服务调用。

    2.Web 服务是一个很好的工具集，但是当您以细粒度的方式使用 Web 服务时，它可能对应用程序的性能有很大的影响，因为 XML 解析、序列化和反序列化的开销很高；这种开销可能占处理时间的百分之三十。

    在本文中，我以 Task Management 系统中的登录功能为例。驱动程序首先登录到系统，如果登录成功，则有两列任务显示在屏幕上。

    对于此登录问题有两种解决方案：

    1.一种解决方案是首先调用登录方法，然后当该方法调用返回 true 时，调用一个方法来获取相应的任务。

    2.其他的事情将在一步中完成。如果驱动程序登录到 Task Management 系统，则返回驱动程序的角色以及分配的任务和启动的任务。如果登录失败，则返回指示驱动程序未登录到该系统的信息。

    对于第一种解决方案，它是细粒度登录系统，而显示任务列表需要两次调用 Web 服务；这可能带来很大的延迟。第二种解决方案是粗粒度登录系统，它返回您在一次调用中需要的所有信息，并确保由于网络延迟和系统 I/O 带来的影响最小。

    首先定义 Web 服务接口，然后进行实现。

    这不仅从移动 Web 服务的角度来看是适用的，而且从 Web 服务设计和（更高的层次）面向对象的软件设计来看也是适用的。正如您所知道的，接口是客户端和服务提供程序之间的契约，而且保持稳定非常重要（因为正如您所知道的，实现容易改变）。

    定义功能接口非常直接和直观――只需考虑：

    1.您的目标

    2.您需要获取什么信息

    3.您需要将何种结果返回到客户端

然后，您应该将该接口的相关要点写下来，并在这些要点的指导下完成所有实现细节。

    这是一条简单的设计指导原则。了解您的目标非常重要，目标可以驱动您编写测试用例，并且指导您编写功能实现，这也是为什么测试驱动开发 （TDD） 广泛地应用于各种开发技术的原因。

查看本文来源