*****普及环境中面向服务的体系结构（SOA）

*****普及环境中面向服务的体系结构（SOA）

本文描述了一种面向服务的方法，用于为普及设备提供公用接口。本文用财政案例演示了如何通过关键 Web 服务应用程序类型，包括事务、通讯、基于位置的服务以及更多，将 Web 服务扩展到普及环境中。

引言

普及运算是信息技术的下一阶段。业界分析家预言移动设备将是下一个范例转换，并且包括 IBM 在内的供应商都在为构建普及运算应用程序大力投资，以开发最好的工具。象移动电话、PDA、寻呼机这样的普及设备在数量上已经远远超过台式机和膝上型电脑，而且趋势正在扩大。除此还正在用严格的运算能力和通讯链接构建各种各样的装置，例如空气调节系统、吸油烟机、汽车监控系统，为了在除 PC 和工作站以外的设备上构建应用程序，首先要了解在新的运算环境中的巨大投资。

在本文中，我们提出了一种面向服务的方法，用于提供独立于设备的公用接口。该方法为普及运算环境作出了很大的贡献。我们的目的是指出用于各种应用程序类型的独特服务。我们将用一个财政案例来演示面向服务的体系结构 (SOA) 在普及环境中的扩展。本文首先简要介绍了 Web 服务和普及运算环境。接着是概述部分，描述了如何通过关键 Web 服务应用程序类型，包括事务、通讯、基于位置的服务、同步、设备管理、数据管理和媒体应用程序，将 Web 服务扩展到普及环境中。

SOA 概述

从概念上讲，SOA 是一种实现动态电子商务的体系结构。它是一种软件系统设计方法，通过已经发布的和可发现的接口为终端用户应用程序或其它服务提供服务。服务为封装离散的业务功能提供了一个更好的方法，因此，服务也是开发支持业务流程应用程序的一个好方法。

图 1. 通常的 SOA 环境

Web 服务组件

在任何面向服务的环境中都需要进行一些基本操作：

• 需要创建 Web 服务，并定义其接口和调用方法。
• 需要将 Web 服务发布到一个或更多的内联网（Intranet）或互联网（Internet）储存库中，供潜在的用户查找。
• 需要查找 Web 服务供潜在的用户调用。
• 无论基于什么好处都要调用 Web 服务。
• 当 Web 服务不再可用或不再需要时，需取消其发布。

图 2. SOA 模型

服务是一个逻辑实体，其合约是由一个或多个已经发布的接口定义的。

服务提供者是一个网络节点，它为处理一系列特定任务的软件资源提供服务接口。服务提供者节点能代表商业实体的服务，或者它甚至能代表可重用子系统（实现服务规范的软件实体）的服务接口。

服务请求者是一个网络节点，它发现并调用其它的软件服务来提供商业解决方案。服务请求者节点常常代表执行远程过程调用分布式对象或者服务提供者的商业应用程序组件。提供者节点可能就在本地的企业内部网内，或者在远端的因特网上。从概念上来说，SOA 本质上是将网络、传输协议和安全细节留给特定的实现来处理。通常称为 客户端，但是，服务请求者也可以是终端用户应用程序或别的服务。

服务定位器是一类充当注册表的特定服务提供者，允许查找服务提供者接口和服务位置。

服务中介者是一个网络节点，作为储存库、电话黄页或票据交换所，产生由服务提供者发布的软件接口。商业实体或者独立的运营商能代表服务中介者。

这 3 种 SOA 参与者、服务提供者、服务中介者以及服务请求者通过 3 个基本操作： 发布、 查找、 绑定相互作用。服务提供者向服务中介者 发布服务。服务请求者通过服务中介者查找所需的服务，并绑定到这些服务上。

SOA 实现技术

SOA 实现技术包括：

• XML：可扩充标记语言 (Extensible Markup Language) 1.0 标准是一个基于文本的 World Wide Web 组织 (W3C) 规范的标记语言。与 HTML 使用标签来描述外观和数据不同，XML 严格地定义可移植的结构化数据。它可以作为定义数据描述语言的语言，例如标记语法或词汇、交换格式和通讯协议。
• SOAP：简单对象访问协议 (Simple Object Access Protocol) 是一个基于 XML 的，用于在分布式环境下交换信息的轻量级协议。SOAP 在请求者和提供者对象之间定义了一个通讯协议，这样，在面向对象编程流行的环境中，该请求对象可以在提供的对象上执行远程方法调用。SOAP 规范是由 Microsoft、IBM、Lotus、UserLand 和 DevelopMentor 联合制订的。该规范随后发展并建立了 W3C XML 协议工作组，有超过三十家公司参与其中。在大多数厂商的 SOA 实现中，SOAP 为分布式对象通讯构建了基础。尽管 SOA 没有定义通讯协议，但由于在 SOA 实现中的普遍使用，最近 SOAP 被称为面向服务的架构协议 (Services-Oriented Architecture Protocol)。SOAP 的优点在于它完全和厂商无关，相对于平台、操作系统、目标模型和编程语言可以独立实现。另外，传输和语言绑定以及数据编码的参数选择都是由实现决定的。
• WSDL：Web 服务描述语言 (Web Services Description Language) 是一个提供描述服务 IDL 标准方法的 XML 词汇。WSDL 是融合 NASSL (IBM) 和 SDL (Microsoft) 之间的活动产物。它为服务提供者提供了一个简单的方法，描述远程方法调用 (RMI) 的请求消息和响应消息的格式。WSDL 不依赖于底层的协议和编码要求来涉及服务 IDL 这个主题。通常，WSDL 提供一种抽象的语言，利用各自的参数和数据类型来定义被发布的操作。该语言还涉及了服务的位置和绑定细节的定义。
• UDDI：统一描述、发现和集成 (Universal Description, Discovery, and Integration) 规范提供了一组公用的 SOAP API，使得服务中介得以实现。UDDI 规范是由 IBM、Microsoft 和 Ariba 制定的，促进了基于 Web 的服务的创建、描述、发现和集成。在 UDDI.org 之后的动机是为 B2B 互操作性定义一个标准。

Web 服务应用程序设计

图 3. Web 服务标准

Web 服务通讯可以使用 XML，但它可能要传输二进制数据，它通常使用 SOAP 消息头，但是不需要为消息体进行 SOAP 编码。它可能用 HTTP 进行传输，但是也还可以用 SMTP 或其它的方法。为描述和发现 Web 服务，有两种定义完好的标准：WSDL 和 UDDI。

背景及相关工作

用面向服务的方法进行运算已经引起了研究人员和业界的广泛关注。主要目的包括用于构建软件组件的面向服务的编程 (SOP) 和用于分布式应用程序的面向服务的体系结构 (SOA)。

SOP 引入并实施面向服务的编程，但它是面向启用进程内和进程间通讯的软件组件的开发的。用 SOP 开发的软件程序可以作为多线程程序，在多线程程序中，各个线程可以通过明确定义的接口交换消息。程序的组件设计集中在为组件所提供的服务定义接口。SOP 提供的特性包括合同、组件、连接、容器和上下文。SOP 软件应该具有联合性、易部署性、移动性、安全性和可用性。

SOA 建立在 SOP 上来构建系统和应用程序以获取软件组件所提供的服务的最大限度的复用，同时要确保他们交互中的松散耦合。基本元素是服务，SOA 指定一组实体（服务提供者、服务消费者、服务注册表、服务条款、服务代理和服务契约），这些实体详细说明了如何提供和消费服务。遵循 SOA 观点的系统必须要有服务，这些服务是可互操作的、独立的、模块化的、位置明确的、松耦合的并且可以通过网络查找其地址。

Web 服务技术是以 SOA 概念为基础的。该项技术直接面向企业应用程序集成，为半自动交互式和组织内部的业务流程提供了公用数据交换平台。构成 Web 服务的技术包括 XML、UDDI、HTTP、SOAP 和 WSDL。XML 用于定义 Web 服务间消息的结构。UDDI 是可供查询的 Web 服务资源库。HTTP 是底层的通讯媒介。SOAP 是交换消息的容器。WSDL 用于描述 Web 服务。相关研究已经进展到涉及交互和协调性问题，虽然没有提及或整合针对 Web 服务合成的研究，反之亦然。

Jini 是另一个主要的 SOA 目标，它已经以服务为基础直接面向构建本地运算环境。假设设备能提供服务，并且 Jini 指定特定的特性，例如发现、结合、查找、联合、租赁以及其它的能实现网络部署的特性。Jini 紧密绑定到 Java ^TM 编程语言。例如，通过 Java RMI 进行通讯，以 Java 对象接口作为服务接口规范。

在普及环境中使用 SOA

下面的部分概述了普及环境中的 SOA 和 Web 服务。

普及环境简介

普及运算方案可以看作是针对特定问题的特定解决方案，其中问题通常表现为案例。从这方面来看，他们趋向于传统的嵌入式系统设计，只是规模更大一些，而且添加了网络。对于嵌入式系统设计，各种方案倾向于创建自定制解决方案，这些解决方案是专有的而且缺乏可扩展性。看上去缺少的东西正好适合于编程普及运算环境。相反，各种普及运算案例似乎设想了一种软件的无缝系统，该系统根据用户的期望和目的运行。我们认为这种观点既与可能越来越多的采用这种方案这个现实矛盾，又与各普及运算设备供应商无疑会扩大生产的多样性相矛盾。因此，我们提出了一种标准的基于服务的编程环境供普及运算所采用。

普及运算是由 NIST（简写）为强大新兴趋势的朝向所定义的：

• 无数的、方便使用的、通常无形的运算设备
• 频繁移动的或内嵌在环境中的
• 与日益无处不在的网络结构连接

目的是为了使任何需要运算的地方更容易。各种研究人员已经证实了为实现这个设想，需要网络和中间件基础设施。这种普及基础设施的特征包括规模、移动性和普遍存在性。这个规模将使任何现有的设施显得太矮小。基于这一点，我们可以推断出基础架构必须要涉及到各种附加问题。由于故障和/或连接中断是一个至关重要的问题，而且随着组件数量的增加，组件发生故障的可能性也随之扩大。即使系统不出故障，它也必须有容错功能。在本质上，基础架构应该是对等的，而不是客户端/服务器端或多层的形式，但目前在中间件和构建数据网络中通常使用的是这些形式。就因特网而言，这么大的系统能否有单独的授权域很是值得怀疑。假设有大量能移动的授权域，还需要一些访问者身份，既用于连接到外部网络的移动设备，又用于他们的所有者下面的移动应用程序。因此，访问者身份必须既要保护外部网络的完整性又要保护移动数据的安全性。普遍存在性和可移动性意味着设备期望能一直连接到基础设施。最后，这样的系统能不异构很是值得怀疑。

另一方面，普及运算方案常常采用提供单一集成解决方案的方法，通常是针对特定案例或案例集的。因此，普及运算需要一个能用于编程的公用抽象，在这个抽象中各种问题都可以解决。这种抽象必须足够强大能捕获现有的方案，而且要足够灵活能在普及运算内实现各种突出问题解决方案的开发。我们认为基于服务的方法可以提供这样的抽象。该方法能为普及运算环境作出重大的贡献。

首先，它提供了一种查看普及运算系统的方法。目前，大量关于普及运算的研究结果都是围绕案例展开的。因此，普及运算到底是什么还不是很清楚。基于服务的方法将普及运算定义为一种无处不在的可用的服务环境。

其次，它提供了一个架构，在这个架构中可以查看现有的普及运算方案。因此，我们可以确定那些方案所缺少的特征。我们还可以以各种方案实现我们的服务视图的方法为基础对这些方案进行比较。

第三，我们的方法允许在无处不在的可用的服务环境中进行普及运算的增量开发。

普及运算安全性

普及运算环境依靠各种客户端和服务器间通过不同网络所传输的信息的交换。在这种设置中，由于信息要从源传输到目的地，通常要冒数据被拦截的危险。Web 服务事务也要冒同样的安全性危险。在使用 SOAP 进行传输的 Web 服务事务中，服务调用方和服务提供方之间所传送的数据是简单的 XML，因此任何人拦截了该消息都能读取所交换的数据。在 Web 服务案例中，基于以下原因，安全性方面变得更复杂：

• 可以用不同的应用程序或传输协议，例如 HTTP、SMTP 等来发送 SOAP 消息，这些程序或协议可能会有一些安全模型，从非常高级的模型到根本什么模型都没有。因此，Web 服务应用程序需要一个全面的安全性架构，能适用于所有类型的传输协议。
• 可能有一些合法的中介需要访问甚至修改部分或整个 SOAP 消息。因此安全性模型必须足够全面，从而可以允许这些中介。

下面的部分定义了 Web 服务安全性的各个方面，他们可以应用于 在普及应用程序中使用 SOA中所描述的应用程序类型。

Web 服务安全性指导方针

W3C Web 服务体系结构需求概述了全面安全性架构的六个重要的安全性考虑：

• 认证保证任何有认证身份的人都可以访问服务。
• 授权保证通过认证的人有权访问服务或数据。
• 机密性保证请求方和提供方之间传输的数据不会被窃听者窃取。
• 完整性使消息从请求方到提供方这条传输通道上不会被修改。
• 不可抵赖保证消息的发送者不能否认他/她稍后会及时发送消息。
• 可访问性确保服务一直是可用的，并且不会被拒绝服务 (denial-of-service，DoS) 这样的攻击所削弱，无论是从托管服务系统的外部还是内部进行攻击。

如今的 Web 服务安全性

Web 服务安全性还处在不成熟的阶段。不断地有新的标准和应用程序被开发和应用。如今，可以从两个层面实现 Web 服务安全性：

1. 传输层：传输层的安全性利用传输技术的内置安全特性，例如 HTTP、IBM WebSphere MQSeries、IBM Websphere Everyplace Connection Manager 等等。
2. SOAP 或通讯层：目前正在广泛研究该层以及例如 OASIS 这样的安全性小组所开发的规范。这一层以及 XML 文档层的安全性包括使用数字签名、证书等等。

用 HTTP 保护 Web 服务

可以用下列方法保护通过 HTTP 传输的 Web 服务事务：

• HTTP 基本授权
• 带安全套接层 (SSL) 的 HTTP
• HTTP 基本授权 + HTTPS

但是，HTTP 安全性没有涉及到前面所描述的整个 Web 服务安全性指导方针。最好的可能配置是使用带 HTTP 基本授权的 HTTPS，这样的 HTTPS 涉及到了 Web 服务安全性中除不可抵赖和可访问性之外其余的所有方面。

HTTP 基本授权：基本授权 (BASIC-AUTH) 是 HTTP 中所使用的一种简单的机制。使用该机制，可以防止未授权用户访问 Web 资源。要使用 HTTP BASIC-AUTH 访问受保护的资源，用户需要提供用户名和密码。Web 站点系统管理员用一列合法的用户和用户可以访问的资源来配置 Web 服务器。因为通过 HTTP 调用 Web 服务和访问端点 URL 是类似的，所有可以利用 BASIC-AUTH 限制 Web 服务访问。

HTTP 安全 (HTTPS)：安全套接层 (SSL) 是一种允许 Web 浏览器和 Web 服务器通过安全连接进行通信的技术。也就是说，发送的数据由一方加密，在处理之前由另一方来传输和解密。这是一种双向的过程，即在发送数据之前，服务器和浏览器都要对所有的传输进行加密。

HTTP 基本授权 + HTTP 安全：为 Web 服务事务提供了极好的安全性。它还通过签名证书为用户提供了授权机制。但是，如果复制的证书也可用，那么任何人都可以充当代理。因此，安全性的最佳形式是结合使用 HTTP BASIC-AUTH 和 HTTPS。这既满足了 Web 服务安全性前四个方面的要求，又为防止抵赖提供了更好的保护。在接下来的部分中，我们将说明如何配置 Web 服务应用程序来利用这种安全性方法。

在普及应用程序中使用 SOA

本文剩下的部分描述了如何用 SOA 和 Web 服务为关键普及应用程序类型提供公用接口。对于关键普及应用程序，我们主要关心的是：通信、事务、设备管理、同步、基于位置的服务、数据管理以及多媒体服务。为了帮助说明如何在这些应用程序中使用 SOA 和 Web 服务，我们将以一个财政服务为例。该案例是基于下列体系结构的：

图 4. 常见的财政门户体系结构

财政服务案例概述

下面的图表演示了这里所描述的财政服务案例：

1. 新银行客户通过膝上型电脑签约在线银行，包括例如欺骗发现警告、有新的产品和在线帐单付款之类的服务。
2. 客户决定检查帐户余额情况（使用膝上型电脑或智能设备）。
3. 然后客户决定进行在线付款（使用膝上型电脑或智能设备）。
4. 客户收到一个警告，说已经从帐户中提取大量的金额。警告使客户得以响应，并通过通讯或语音与银行服务代理进行交谈。
5. 客户在他们的普及设备上使用银行的 Web 服务客户端在线处理事务。

图 5. 场景 1


图 6. 场景 2 和 3


图 7. 场景 4


图 8. 场景 5

用于通讯的 SOA

通讯的概念包括将消息分散给一组通过许多无线网络和协议进行传输的普及设备。通讯操作的实例范围很广，从广播型，例如新闻、股票报价和事件通知到个人通信型，例如寻呼机消息和即时传送 (instant messaging，IM)。近来在无线技术，例如短信服务 (Short Message Service，SMS) 和会话发起协议 (Session Initiation Protocol，SIP)，领域中的更多进展已经提供了创新解决方案，这些方案利用了 Web 服务的功能。

应用程序需求

• IM 应用程序的无缝集成：目前在其它的一些专有提供者中存在一组相当支离破碎的 IM 服务提供者，包括 AIM、MSN 和 Yahoo。为了提高可用性和管理需要巩固这些服务。Trillian Pro 已经通过允许用户从单一客户端配置和使用这些服务在桌面应用程序领域中涉及到了这个问题。通过遵循公用接口加强 IM 服务提供者这一原则在普及环境中也可以工作得很好。
• 会话管理：新近完成的 SIP 规范促进了 IM 应用程序在移动设备上的开发，代表了流行桌面 IM 应用程序和无线 SMS 系统的融合。SIP 提供会话管理支持，允许用户从传统的请求和响应对象中存储和检索数据，这些对象实际上跨越了多个 SIP 请求。有关详细信息请参阅 JSR 180。
• 保证传送：如今很多 IM 应用程序不能保证消息的传送，他们是“发送并忘记”型的。在 IM 会话过程中发送给不可用的用户的消息通常会丢失。虽然这在大多数情况下还是可以接受的，但有时可能需要保证传送高优先级的消息。这无疑会引起更复杂的问题，包括对消息的认可以及排列或高速缓存不被认可的消息，直到用户在线回答。
• 高级通讯：SMS，EMS，MMS
• 安全性：参阅 普及运算安全性。

如何使用 Web 服务

Web 服务充当了一个公用的、独立于设备的接口，提供者可以从这个接口向已经订阅的客户端发布他们的服务。该接口也可能直接由客户端或其它的服务调用。这个特性允许使用上面提到的 IM 集线器，在 IM 集线器中可以将各种专有 IM 服务提供者合并为一个客户端应用程序。对于桌面应用程序领域，这样可以提高管理的可用性和易用性。Web 服务通过调用可发现的接口满足客户端的需要竭力提取后端处理同样重要。

最基本的解决方案由一个连接到设备的胖的、客户编写的 Web 服务客户端组成。虽然开发这种方法需要更多的时间和精力，但是由于通过应用程序控制和表示细节给予了客户端详尽的责任使得该方法具有更大的灵活性。而且，各方面通常由容器来处理，包括安全性和会话管理，所以不需要涉及这些问题。

您应该注意到虽然 Web 服务技术对于桌面应用程序和企业应用程序已经很成熟了，但是还需要考虑很多额外的问题使其能适应普及设备在容量上有限这样的局限性。例如，解析 XML/SOAP 消息就需要相当集中，尤其需要考虑处理能力。为缓和这一点， JSR 172规范将提供一个对应于 J2SE/J2EE 的更“瘦”版本。有关详细信息请参阅 J2ME 和 Web 服务。

图 9. 胖客户端环境

通过允许较小的处理能力或内存，从客户端提取后端处理增加了可用设备的实际数量。如果假设客户端支持对 Web 接口的访问，即通过 TCP/IP 进行通信，那么合并 portlet 集和 WebSphere Portal Server (Portal) 将是一个完美的解决方案，如下所述。通常，客户编写的 portlet 以及专门的可复用 Java servlet 能组成门户页面上的定义区，并且能访问很多不同的应用程序、服务和 Web 内容。Portal 支持对 Web 服务后端 porlet 的部署。这使关注由 Portal 所处理的管理的开发人员自由了，并且允许开发人员将重心转移到实现特定业务逻辑上。 有关实现的详细信息请参阅 创建自己的 portlet 和 Web 服务和 利用 Web 服务从远程系统中获取数据来开发 portlet。

图 10. WebSphere EveryPlace Connection Manager 和 Portal Server 环境

WebSphere EveryPlace Connection Manager (Connection Manager) 充当了客户端设备和 WebSphere EveryPlace Access 服务器间的可选传输通道。Connection Manager 允许从后端应用程序中提取低层的详细信息，例如无线协议，因此产生了复用和分离关注点。

Connection Manager 的通讯服务装备启用 Web 应用服务器与前面提到的那些普及设备进行交互。虽然通讯服务支持更流行的 SMS 和不被认可的 WAP 推传送，但是它还启用了很多其它的消息模式，包括通过专有网络传送短信、通过 SMTP 和 SNPP 发送邮件。有关详细信息请参阅 IBM WebSphere Everyplace Connection Manager 版本 5 手册。

Everyplace Access 充当了移动客户端和企业环境之间的连接。Everyplace 客户端，作为 Everyplace Access 的一个核心产品，充当了一个附属软件包，提供了带更健壮设备环境的各种 PDA。它提供了取出即可用（out-of-the-box）的 IM 服务，但是，目前还只局限于 Lotus Sametime。

Everyplace Access 的另一个高级特性是智能通知服务 (Intelligent Notification Services，INS)。该服务在订阅通知应用程序和触发器的基础上让企业自动通知移动用户。这是由 Everyplace Access 系统管理完成的，在系统管理中，用户指定信息源、通知标准以及一些爱好和订阅设置。更多详细信息请参阅 WebSphere Everyplace Access 版本 4.3 开发人员手册。

图 11. Portal 环境

因为 Portal 被评价为是一个高可配置的、被认可的架构，因此可以利用它的很多内置功能来减少开发时间和费用。Portal 结合 Everyplace Access 通过用任何标记语言生成页面来支持移动设备，包括用于 WAP 的官方支持的 WML。请求一个页面时，Portal 处理后端流程来自动检测设备类型并以适当的标记语言返回呈现页面内容的 portlet。

财政服务案例中的通讯

在财政服务案例中，通讯为用户带来了更多特性和便利。例如，可以将系统基础架构设置为当检测到可疑的帐户活动时，例如提取大量资金，警告用户。正如上面所提到的，Everyplace Access 的 INS 支持基于订阅的通知，在这种通知中，消息由用户订阅的特定事件触发。

然后用户可以通过 IM 应用程序选择连接代理并进行通信来解决问题。由于会话的本性和重要性，可能将消息作为保证传送，一直保留直到客户端认可该消息。

用于事务服务的 SOA

考虑普及环境中的事务时，必须要考虑到普及环境强加在事务上的限制能够执行。而且，由于普及环境能包含不同功能的任意数量的不同设备，所以有必要考虑如何用相同的事务来服务不同的设备和他们的功能。

对于这个问题，最明显的回答是从客户端提取事务普通的详细信息。有两种方法可以实现这一点。其一是使抽象层完全不知道哪些客户端访问了它。这需要客户端足够智能化，能捕捉并显示适当的数据。很明显，这指的是胖客户端，胖客户端能使服务面向多种客户端，但是对每个客户端可能有较高的 CPU 和内存需求。

使抽象层足够智能化的另一个方法是区分请求它的服务的客户端的不同功能。在这种情况下，每种设备的不同功能的详细信息必须由服务提供者来说明。客户端将被看作一种提供低 CPU 和内存需求的瘦客户端，但是需要受服务提供者支持的有限数量的设备。

Web 服务和 SOA 能涉及提供简单的抽象层还是智能抽象层之类的问题。下面的部分演示了这种 Web 服务如何提供所述功能。

应用程序需求

普及环境中的事务服务同样需要考虑传统应用程序中的事务问题，以及客户端能运行在几个不同类型的有着不同功能的硬件和软件环境中。同样的，设备可以放在任何地方，并且由于要在给定的环境中显示信息，所以必须要注意其类型问题。下面的列表并没有准备详尽列出潜在的需要考虑的地方，但是考虑普及环境中事务的实现需要一个合理的开端：

1. 由于设备只能显示一定数量的结果，因此用户可能需要在服务器端缓存一些会话。
2. 在服务器端将事务合并为几个集合调用，从而减少通过宝贵的低无线带宽传输的网络调用。
3. 让服务器端执行一些复杂的排序或其它的 CPU 密集型操作。
4. 同步和异步事务之间的区别。如何实现这两类事务？
5. 在线和离线事务。
6. 关键是要最大限度使用有限的在线时间。尽量最少时间，因为设备需要等待结果。这样可以减少在线费用。
7. 发送并忘记事务。排队等候代表设备的作业。然后当设备反方向检查时，就能得到结果。
8. 安全性更容易受到威胁。基于显示在这些设备上的信息种类问题，需要特别关注。例如，银行型的事务可能允许主用户修改他们的帐户信息，但是用无线通信进行相同的事务可能不允许编辑功能，只有查看功能。

如何使用 Web 服务

在普及环境中有两层可以使用 Web 服务。一是在远程设备上实现 Web 服务客户端，这样将直接调用 Web 服务。该方法如下所示：

图 12. 使用 Web 服务胖客户端模型的普及事务

这个案例的好处是远程设备已经完全控制了如何显示数据。设备将知道它自己的局限性并以适合于那台设备的方式显示返回的数据。

这个方法还有一个好处，即允许嵌入式程序对事务进行优化。这是通过允许设备存储大量的事务直到它认为在时间上适于发送或请求数据实现的。适当的时间可以由排队等候的事务总量决定，或者在普及环境中网络可能断断续续的可用，因此可以一直保存事务直到网络可用。

在这里，SOA 还有一个好处，即客户端不需要担心调用事务的任何详细情况。客户端不需要担心数据库连接、特定的协议、专有数据格式以及不断变化的后端系统。它所需要做的是构建 XML 并利用 Web 服务客户端发送数据。因为这些都是开放的标准，所有能创建各种设备都能支持的单独事务。Web 服务提供者不需要编写特定的代码来支持不同的设备。这也从根本上普及了事务本身，从而通过允许在各种不同设备的服务提供者间共享中央逻辑促进不同设备间数据的一致性。

财政服务案例中的事务服务

要继续银行实例，我们先来看一下用户想用手持 PDA 设备在线购买商品的情况。那个设备可能有一个内置的客户端，可以查找从银行请求临时信用卡数量的 Web 服务事务。客户端然后可以使用这个信息来填充商品的购买信息。同样地，智能电话也可以用于运行同样的 Web 服务事务，但这时购买一罐苏打水的信息可能是被传送到自动售货机的。因为有些 Web 服务客户端可以运行在任何设备上，一个事务也可以供多个设备所用。

用于设备管理的 SOA

随着无线设备的数量到 2006 年将达到 11,100,000， 设备管理也变得越发困难。而且，由于多媒体性能和带宽问题不断的严重，通过这些设备运行的应用程序的复杂性也无疑会增加。为了通过被部署的应用程序进行维护控制，必须要管理所有这些设备。

可以迅速的将新的特性和功能添加到移动设备中。因此，最新的、高级移动设备中的设备罢免和软硬件的更新也变得越来越常见，多得让网络操作人员也感到吃惊。

应用程序需求

和一直围绕着 LAN 和受后端防火墙保护的 PC 和服务器不同，无线设备，例如智能电话、PDA 甚至很多主流移动电话在本质上来说更难管理。他们通常既充当运营工具又充当私人生产性设备，并且很容易丢失或损坏，而且换代非常频繁。因此，CIO 和网络操作人员必须要认识到移动设备常遭受设备管理上下文中规则的不同设置。下面列出了一些关于设备管理应用程序 人们想要的功能：

1. 通过无线网络 (OTA，Over The Air) 向设备发送升级包
2. 存储、管理和提供软件映象
3. 驻留在移动设备上的客户端
4. 软件部署
5. 资源和配置管理
6. 故障管理
7. 设备控制和数据安全性
8. 备份和恢复

主要区别是在移动设备上进行实现自我诊断和自我处理的能力，通过无线网络与客户端软件协同工作的集中管理的、基于 Web 的控制台，以及以带宽和网络连接为基础进行更新的智能传送。

如何使用 Web 服务

在这个案例中，设备系统管理员通过 Web 服务接口调用对所有设备的更新处理。Web 服务接口允许对任何能用 Web 浏览器查找设备管理服务器的客户端的管理。更重要的是，它在所有不同设备的专有管理接口间添加了一个抽象层，允许用一个统一的接口管理所有的设备。下图演示了这种思想：

图 13. 通过 Web 服务和专有接口进行设备管理

通过 Web 服务提供设备管理的另一个好处是能从单一集中的位置管理包含在安全环境内的设备。所有要做的是让每个单独的位置包含一个启用了 Web 应用服务器的 Web 服务，例如 WebSphere Portal Server 5.1，并通过防火墙访问端口 80 和 443。这种情形尤其适于两种情况：一是可能不能从公司内联网访问远程办公室，二是远程办公室位于内联网中的安全子网内部。下面的图表描述了这种情形：

图 14. 设备管理体系结构

另一个要考虑的设备管理情形是在设备意识到它需要更新的情况下。有人可能允许专有设备接口直接由远程设备调用。但是，这可能有很重要的含意，假设有很多不同的设备类型，并且每种都需要封装自己的专有设备接口。这些设备接口中的每一个都必须按照企业的需要来确保他们的安全。只有一个 Web 服务供设备调用可能要更容易一些。每个设备都将传送企业所需的适当的安全性证书请求。经过验证和认证后，Web 服务将调用适当的专有设备接口来发送必需的更新。

财政服务案例中的设备管理

回到我们的银行实例中，假设有一个包含银行应用程序的 PDA。当 PDA 运行银行应用程序时，它首先调用一个 Web 服务，检索最新的软件版本列表。设备用一列当前安装的软件和认为余额应用程序需要更新的通知与这个列表匹配。然后设备调用软件来更新 Web 服务和安全性证书以及为标识它自身所需的信息和需要下载的软件。Web 服务用适当的参数依次查找特定于 PDA 的软件更新设备接口，从而标识设备并找出需要部署到那个设备的软件的位置。在该实例中，Web 服务就设备和专有设备更新软件间的安全性提供了一个抽象层，并指出了关于如何管理以及在哪里管理可部署的软件。每种设备都调用相同的 Web 服务，因此企业不会受到安全性或软件版本的干扰，并且管理计划也是由专有设备接口提供的。

用于基于位置服务的 SOA

基于位置的服务 (Location-based services，LBS) 是为用户提供定制内容的通道。全球定位卫星 (Global Positioning Satellite，GPS) 系统是一个提供准确用户三角位置的测量机制。这样的系统需要普及组件设备提供更多的功能。并不是所有的设备都有这样的功能，因此必须通过用户基本信息和用户输入来提供 LBS。最初的检查可以通过 IP 路由和发现用户的可能位置进行管理。

客户端应用程序需要提供通过 Web 服务向服务器发送信息的功能，从而为客户端提供内容，这些内容用户可以使用。由于服务器知道用户的位置，所以它可以向客户端发送例如以用户当前 GPS 位置为基础的本地信息之类的数据。

应用程序需求

• 运行在设备上的客户端应用程序
• 允许设备定位的可选 GPS 硬件
• 用于设备定位的可选用户输入或配置设置

如何使用 Web 服务

在客户层使用 Web 服务允许在用户指定位置的基础上按需发现和传送内容。Everyplace Access 服务器还有额外的功能，例如内部 UDDI 发现。尽管没有预封装产品也可以提供开发和功能，但是使用 Everyplace Access 可以节省时间。

考虑到普及运算的本性，LBS 必须和其它的服务一起使用，来决定是否以用户设备为基础将指定内容传送给用户。为了将内容传送给指定的普及设备必须进行代码转换。例如 Everyplace Access 服务器这样的预封装产品有预先定义的针对各种设备的代码转换模板。所有的片段都能从头进行开发，但是正如前面所提到的，这样将需要更多的时间和精力。在设计和开发的过程中，SOA 允许公用 API 和函数提供帮助。

Everyplace Access 服务器提供了很多用于实现 LBS 的工具。Everyplace Access 中的 知道位置的服务 实现了知道位置的应用程序的快速开发和部署。为了支持知道位置的服务，Everyplace Access 提供的 API 使开发人员以标准的方式添加知道位置的 portlet。服务适配器必须由各个服务提供者编写，从而允许在知道位置的环境中提供服务。服务适配器可以扮演很多角色，例如接口转换、服务调用和错误处理以及带服务提供者的身份验证。根据 Everyplace Access 提供的知道位置的服务 API 所编写的服务能够处理通常的身份认证和其它特性，不需要开发人员对那些公用片段进行改写。

用于 LBS 的自动售货机案例

在快餐店自动售货机实例中，普及设备以其位置为基础，可以通过 Web 服务连接邻近的服务提供者，并获得一列可用的自动售货机及其内容。邻近的服务提供者可以由内容浏览应用程序来提供，这些内容浏览应用程序接受用于用户位置的用户输入，或由客户端应用程序提供，客户端应用程序足够智能化能发现邻近的服务提供者并查询可用的服务。然后用户能够通过浏览可用商品，并用他们希望的商品继续执行自动售货机。购买业务也可以在设备上进行，如果这项特性可用的话。服务提供方可能会列出区域周围可用的其它服务，例如本地地图、商店以及更多。有了多种独特的客户端设备和 Everyplace Access 服务器提供的带援助的知道位置的服务，就可以定义公用服务了。Everyplace Access 服务器能处理很多常见步骤，例如认证和事务处理。如果不能处理，它会将请求向前传送给能处理请求的服务。

财政服务案例中的 LBS

在我们的财政服务案例中，用户能以他们当前的位置为基础签名，他们当前的位置是用户输入的或由 LBS 决定的。可能已经安装了客户端应用程序和设备，因此可以与服务提供者进行无缝通信。信息可以通过 Web 服务发送并以他们的位置为基础及时向用户提供必需的信息。Web 服务可以用于传输客户端和服务提供者之间的数据，但是基于用户的当前位置，并不是所有的服务都可以。例如，如果用户在加油站，他们可能只能选择财政服务案例中的选项 2，该选项是用来检查用户帐户余额的。这可以结合用户位置、用户对应用程序的预配置设置或各种其它可能的案例来确定。这也可能是由于位置缺少服务或要冒安全危险而造成的。在几个街区之外的别的位置中，相同的用户可能能执行前面提到的所有情形。有关实例请参阅图 15：

图 15. 基于位置的案例

Everyplace Access 与 Portal Server 一起能提供例如身份验证这样的功能，但是，如果有必要它也能单独实现。

用于同步服务的 SOA

同步服务可以让用户同步发送邮件、PIM 数据以及常用数据。设备上需要有客户端来同步发送数据。使用 SOA 能允许通过 Web 服务以常用方式传送客户端和服务器之间的数据。从普及运算的角度来看，数据传送必须考虑客户端的性能，例如处理数据的能力、存储量和带宽。

设备在尺寸上可以不尽相同，这就带来同步数据必须能适合各种类型的设备，包括进行代码转换向客户端设备提供内容。Everyplace Access 服务器用大型邮件服务器提供了同步发送邮件和 PIM 数据的功能。有了 SOA 和标准，就可以扩展这样的 Web 服务，从而为能解析这样数据的任意类型的客户端提供同步服务。

应用程序需求

• 能够提供同步服务和为用户提供有用信息的客户端应用程序
• 带各种存储介质的数据存储机制
• 确保数据合法性的数据完整性 (CRC) 机制

如何使用 Web 服务

LBS 还可以通过启用应用程序来确定用户的位置，然后以那个位置为基础同步传送特定的数据来帮助数据的同步传送。Web 服务发现还可以用于帮助查找提供所需数据的同步服务提供者。在公司内部使用同步服务非常重要，因为这样可以允许用户在公司内依靠用户的位置同步传送所需的数据。使用 SOA 和 Web 服务的常用方面的好处在于他们允许同步传送无限多的数据。常用的弊端是需要更长的开发时间，这是由于很多方面都没有定义而造成的。有关实例请参阅图 16：

图 16. 公司内部的数据同步

假设用户从大型商店部门出发，并希望同步发送数据，那么详细信息也会同步发送。假设用户进入了财政部并决定同步发送数据，那么财政数据也将同步发送。

在大型商店购物中心实例中，通常，大型商店结算过程需要预扫描商品，虽然会员们正在排队等候。商品在无线普及设备上进行预扫描。会员登记时，收银机服务员扫描会员的会员卡。一旦卡被扫描，系统就能拖出所有的预扫描商品，事务很快就能完成。这加快了结算过程，因为不需要在购物车间转移商品。SOA 为无线设备和结算登记都提供了公用接口。即使大型商店有时突然决定要更新或更换设备，但是接口保持不变，而且还可能减少实现费用。

财政服务案例中的同步服务

用户的设备可能有一个私人资金管理应用程序，这样用户就应该和他们的银行提供者同步。Web 服务实现能提供同步发送用户银行信息的公用方法，无论是否要发送信息类型。如果用户检查他们的余额，会给他们提供一个选项，可以将数据下载到设备上。以客户端设备为基础，服务提供者能确定同步传输数据的数量。用户还可以在客户端设备上准备离线付款，并且稍后和服务提供者一起同步进行，最后当数据同步发送后，事务完成。客户端应用程序还可以连接其它的实现了相同体系结构和数据传输/通讯方法的财政服务提供者。

用于媒体应用程序的 SOA

媒体应用程序特指音频/视频流和或回放。这些类型的应用程序可以用于员工培训和身份验证甚至是新闻和基于信息的服务。媒体应用程序主要关注的是客户端设备能够按照指定的媒体格式解码和回放。已经有很多带各种硬件规范的无线设备。为了支持用于媒体应用程序的所有这些设备，我们需要了解哪些类型的媒体格式可以形成流或甚至回放。Web 服务复用的完美实例是使用设备管理服务处理大多数设备。我们还必须考虑用什么协议来支持媒体格式的传输。例如，如果有一个商业案例需要视频/音频回放，我们可以安全地假设作为一种客户端设备上的传输方式 SMS 消息将不被支持。

应用程序需求

• 客户端设备上的高处理能力
• 支持流的客户端设备
• 支持媒体格式回放

如何使用 Web 服务

下图演示了如何在瘦客户端设计中使用 Web 服务：

图 17. 瘦客户端设计

在瘦客户端设计（也称为客户端/服务器端设计）中，开发人员可以假设他们支持能访问 web 接口的客户端设备，例如浏览器，因此允许他们查看 http 请求并能回放 Real Network、Quicktime、Media Player 甚至 Macromedia Flash 媒体格式。有了这个解决办法，开发人员就不用担心设备支持哪些协议，只需要服务提供者允许访问因特网即可。

对于瘦客户端设计，多数实现是由服务器端的代码处理的，检测客户端设备的性能并决定用什么格式形成流甚至下载到设备上供回放。可以发现，这个解决方案与为桌面应用程序架构 Web 应用程序的客户端/服务器端方法没有什么不同，这是因为开发人员还需要考虑客户端的性能。唯一的区别是现在包括了对小型存储设备的额外检查。

这些瘦客户端设计中的服务器端应用程序可以是自产的，可以运行在任意的应用服务器上。记住，定制应用程序将延长开发时间并需要长期的维护费用。IBM 提供了作为 Portal Server 一部分的替代解决方案。Portal Server 已经有一个被业界认可的架构，该架构易于扩展用来支持额外的设备和容量，并有一些受支持的现成的 (out of the box) 设备。Portal Server 能否允许客户修饰编写的 portlet 取决于客户端是否有这方面的请求。自产的解决方案还必须提供认证、授权、报告等等之类的功能。

在 SOA 中，定制实现和 Portal Server 都能利用 Web 服务来封装媒体应用程序和利用现有的 Web 服务。然后，可以将其用于实现推模式设计，在这种设计中，Web 服务自己调用客户端设备上的命令，从执行程序或想要发送广播或目标消息的管理程序将公司广播形成流。另外，我们可以使用订阅和基于位置的服务来跟踪设备。

下图演示了一个样本胖客户端设计：

图 18. 胖客户端设计

胖客户端设计增加了更多复杂性，例如需要一些其它的胖客户端体系结构。有了胖客户端，设备就能分解和组装 Web 服务消息了。胖客户端设计限制了能受支持设备的数量，这是由于目前在北美市场上设备性能有限。和任何其它应用程序类型类似，胖客户端设计可以使用设备专有接口。缺点是需要在设备和应用服务器间安放相同类型的传输通道。

和瘦客户端设计不同，在胖客户端设计中，客户端设备和服务器端（WebSphere Application Server 或 Portal Server）都需要实现。架构客户端实现使开发人员可以选择使用设备专有接口或调用 Web 服务从非专有设备编码中得到好处。在媒体应用程序实例中，两种解决方案都是可行的，因为第一个选项可以使用 SMS 通过 MMS 来请求要发送的媒体。

正如上面所提到的，例如 SMS 或 MMS 这样的解决方案需要在客户端设备和应用服务器间安放象 Connection Manager 这样的传输通道。有了 Web 服务，就不需要 Connection Manager 和对 SMS 和 MMS 的专有调用了，取而代之的是一个能与支持 Web 服务消息的其它设备进行通信的普通接口。

财政服务案例中的媒体应用程序

在财政服务案例中，可以利用媒体应用程序来支持想为其用户和客户提供无能服务的客户端。胖客户端实现可以用于通过 Web 服务封装基于事务服务传输的 VoiceXML，从而处理银行事务。

用于数据管理应用程序的 SOA

为了向客户提供适时信息，数据管理应用程序控制、保护并促进了数据的访问。这些功能都是由数据库管理系统提供的。

应用程序需求

• 针对瘦客户端解决方案的客户端设备上的 Web 接口
• 针对胖客户端解决方案的 SQL 客户端
• 常用数据的获取、验证、处理、存储、检索和显示界面

如何使用 Web 服务

在瘦客户端模型中，通过 Web 接口可以促进服务器端的数据管理服务。如今这种设计与典型的 web 应用程序不再有很多区别，尽管 Web 服务设计可以利用基于事务的服务和基于同步的服务执行提交和回滚来保持数据是准确和最新的。对于瘦客户端设计，实现都是在服务器端进行的。

用于数据管理服务的胖客户端设计有两种解决方案。和任何其它胖客户端解决方案一样，Web 服务的便携性和可复用性使其成为最简单的解决方案。第二种解决方案需要在客户端设备和应用服务器间安放一个工具，用于将设备上的指令进行代码转换从而传送给应用服务器上的服务。

Web 服务设计还允许体系结构在数据管理实现能驻留在客户端设备上这方面的灵活性，允许其访问上面提到的其它服务来帮助促进作为数据管理包的一部分的事务和同步性。另一个可能的解决方案是将数据管理服务当作 Web 服务自身来实现，因此其它的需要数据管理的服务都能使用。

第二种设计要求将 DB2® Everyplace 安放在客户端设备和应用服务器间，从而方便数据管理。有了 DB2 Everyplace，就能构建使数据管理随处可用的 PDA 应用程序了。您的应用程序可以连接常见的 PDA，例如 Palm ^TM、Handspring ^TM、HP® Jornada、Cassiopiea ^TM以及 Compaq iPAQ ^TM 设备。DB2 Everyplace 还支持基于 EPOC 的 PDA 和带内嵌 Linux 的设备。

财政服务案例中的数据管理

数据管理服务可以作为财政服务开发中的一个辅助工具。允许财政指令的灵活性是在客户端还是服务器端实现依赖于安全性、数据的准确性以及其它需求，从而将数据管理封装为 Web 服务既利于瘦客户端设计又利用胖客户端设计。如果使用数据管理服务是应用程序设计的中心，那么数据的分析和报告会更准确。

结束语

本文描述了如何在普遍环境中利用 SOA 为使用 Web 服务提供简明的解决方案。本文描述了各种应用程序类型，在设计解决方案中可以使用这些类型。我们用一个财政服务样本演示了如何在特定的情形下实现特殊的服务。最后，描述了能够帮助使 Web 服务更便于使用的工具，例如用于应用程序的基础设施安全性和可扩展性的网关或代理装置。

附录：J2ME 和 Web 服务

就目前的情况而言，在面向服务的体系结构 (SOA) 环境中，还没有标准和有效的机制供启用了 J2ME 的设备利用 Web 服务技术。虽然已经详细定义了用于 J2SE 和 J2EE 领域的 Web 服务规范，但是没有涉及到 J2ME 领域中的额外限制问题。这些限制包括要求 Web 服务技术符合平台性能和容量要求。更明确的讲，必须在运行时内存和处理需求内执行 API，并且要满足目标设备的内存要求。此外，还必须考虑到部署环境的局限性，包括低带宽和高延迟。

来自 Java Community Process Program 的 JSR 172试图通过引入两个附加包来涉及这些问题，这样将能在启用了 J2ME 的设备上实现 Web 服务技术。因为 XML 是消息格式的实际标准，所以即将引入的附加包主要负责优化 JAXP 和 JAX-RPC。

JAXP 为操作结构化的 XML 数据提供了必需的基本的 API。J2ME 版将包含一个为 J2SE 和 J2EE 平台而定义的严格的子集。它将通过只支持起决定性的功能实现这一点，包括 SAX 解析以及对 XML 名域空间、UTF-8 和 UTF-16 编码的支持。包括 XSLT 和其他 XML 解析的变体——如 DOM，将不被支持。之所以不支持 DOM，是由于它的实现容量和运行时的内存占用问题。

JAX-RPC 为实现来自 J2ME 基于 XML 的 RPC 通信提供了 API 和规定。再一次将它与 J2SE 和 J2EE 中的对应版本相比，可以看出不支持 SOAP 1.1 编码，扩展类型映射和服务端点能使 JAX-RPC 得以优化。

JSR 规范，加上这种功能受限设备的最佳实践设计模式，到底会产生什么样的效果呢？本部分主要集中讨论概念层次的问题，所有省略了实现细节。有关下列模式的进一步描述和实现细节，请参阅 James Noble、Charles Weir 和 Duane Bibby 撰写的 小型存储软件：存储受限系统的模式。

Web 服务客户端案例

SAAJ

客户端通过 SAAJ 与 Web 服务通信包括几个过程。首先，它必须程式化的创建一个消息，并依照 DTD 强制规定的预定义格式添加内容。然后，获得一个 SOAPConnection 对象，发送消息，收到响应消息后阻塞。

• 处理：打包：将应用分成包，只有当需要某个包时，才加载它。
• DTD：资源文件：在二级存储器中保存配置数据，根据需要加载和释放数据条目。
• 连接工具：只读存储器：在只读存储器中保存只读代码和数据。
• 响应消息：数据文件：每次处理少量的数据，把其余的保存在二级存储器中。压缩数据：在结构内部压缩数据条目，以使它们占用最小的空间。

JAXR

同预定的方案（如在 SAAJ 中）相比，客户端可以选择向 Java WSDP 注册服务器 (Java WSDP Registry Server searching) 动态发送查询请求，通过 JAXR 查询支持 JAX-RPC 的 Web 服务。它必须首先通过查找连接工厂建立一个连接，设置连接属性，获得 RegistryServiceObject 对象。利用 RegistryServiceObject 对象，然后客户端能够用相应的 BusinessQueryManager 方法进行查询，例如 findOrganizations、findServices 和 findServiceBindings。这些方法返回 BulkResponse——一个对象集。要想进行优化，客户端可以选择缓存和创建一个发行人的本地数据库。

• 处理：打包：将应用分成包，只有当需要某个包时，才加载它。
• 连接工具：只读存储器：在只读存储器中保存只读代码和数据。
• BulkResponse：数据文件：数据文件：每次处理少量的数据，把其余的保存在二级存储器中。压缩数据：在结构内部压缩数据条目，以使它们占用最小的空间。
• 缓存：共享：一次保存数据，在任何需要的地方共享。

JAX-RPC

一旦通过 JAXR 构建了相关的 Web 服务资源库，客户端就能够通过 JAX-RPC 执行业务逻辑。实现此功能的方法之一是创建静态存根或动态代理。更常见的是，结果以 Java Bean 集返回。以前，客户端首先创建存根对象，设置存根的端点地址来访问特殊的服务，并且向服务器端点接口投掷存根。

创建动态代理时，客户端创建一个服务对象，该服务对象带有一个 ServiceFactory 和两个参数：WSDL 文件的 URL 地址 和 Qname（受 XML 限制的名称）。然后创建一个服务端点接口型的代理。

• 处理：打包：将程序分成包，只有当需要某个包时，才加载它。
• 存根/代理工具：只读存储器：在只读存储器中保存只读代码和数据。
• 参数/结果集：数据文件：数据文件：每次处理少量的数据，把其余的保存在二级存储器中。压缩数据：在结构内部压缩数据条目，以使它们占用最小的空间。

通用 J2ME 应用程序设计模式

• JavaBeans：
  • 压缩数据：在结构内部压缩数据条目，以使它们占用最小的空间。
• 接口：
  • 小型接口：设计接口让客户端控制数据传输。
• 属性文件：
  • 资源文件：在二级存储器中保存配置数据，根据需要加载和释放条目。
• 内存使用情况：
  • 应用程序转换：将您的系统分为独立的执行部分，一次只执行其中的一个。
  • 内存限制：为每个组件限制它能够使用的最大内存，当超过界限时择存储单元分配失败。
  • Captain Oates：宁可为不太重要的组件牺牲内存，也不能让重要的任务出现故障。
  • 局部故障：确保内存溢出时，系统总是处于安全状态。
  • 存储单元分配池：对于类似对象，预分配一个对象池，并回收无用的对象。
• 存储器：
  • 压缩数据：在结构内部压缩数据条目，以使它们占用最小的空间。
  • 压缩：在内存中移动对象，来移除它们之间无用的空间。
  • 自适应压缩算法。