根据已普遍被人们接受的 SOA 架构，SOA ">基础架构中的集成层为其他组件提供了无状态服务。所以在任何 SOA 实现中，数据会流经后端与前端系统之间的集成层。依据这一方案，许多请求会反复访问相同的信息。因此，将数据缓存在集成层中是一种限制资源消耗和改善响应时间的有效方式。
在一个最新的项目中，作者面临着扩展简单的缓存模式的需求。集成层提供了服务，使一个基于门户的前端可支持用户使用滚动、过滤和排序等功能处理大量对象，同时将数据页面显示给他们。因为数据来自一个相对较慢的后端，所以缓存它很有帮助。但门户不能承载所有这些信息，因为它的每用户粒度会创建大量缓存的数据，进而显著影响性能。
因此，我们在集成层中实现了一个支持每用户粒度的数据缓存。为了实现对从后端检索的对象列表进行滚动、排序和过滤的功能，我们必须以一种有状态的、逐个用户的方式实现缓存，依据当前的 SOA 架构标准，这是一种罕见的模式。
本文将介绍此模式、基于它的解决方案，以及 IBM® WebSphere® Enterprise Service Bus（以下简称 WebSphere ESB）提供的基础技术。本文将介绍一个智能的、动态的、基于数据库的强大缓存模式，当与 IBM DB2 结合使用时，它使 WebSphere ESB 能将工作负载（尤其是处理元素列表的工作负载）从任何后端系统卸载掉。这个缓存解决方案所提供的价值在于，它能感知缓存的数据结构的语义，以便为调用方提供过滤、分页和排序机制。该缓存模式基于扩展预先打包的 WebSphere ESB 中介原语的能力，本文将概述如何开发您自己的中介原语。
为了充分理解本文，您应拥有使用 WebSphere ESB 的集成经验，基本了解 IBM DB2® 及其支持使用 SQL/XML 和 XQuery 语言对 XML 数据进行排序和查询的 pureXML 特性。
WebSphere ESB 基于数据库的缓存模式的概述和用途
WebSphere ESB 的基于数据库的缓存模式（称为有状态业务对象列表缓存）支持对包含一组业务对象的服务响应消息进行智能、有状态地缓存和反复检索，以便：
使基于浏览器的前端系统能够按页面检索数据集，对其进行过滤和排序，为最终用户提供更便捷的访问 最大限度地减少发送给后端服务和系统的请求数量
为了正常运行，WebSphere ESB 上的功能必须从调用方接收指定了数据检索条件的信息。因此，对有状态业务对象列表缓存的任何调用，必须包含用于检索已缓存业务对象列表的信息，服务请求方会将这些条件作为请求消息的一部分来进行传递。图 1 显示了对象 ResultRetrieveCriteria，表 1 详细描述了它的属性：
图 1. ResultRetrieveCriteria 业务对象
表 1. ResultRetrieveCriteria 属性 属性名称 描述 pagingStartIndex 定义列表的开始索引，以便进行分页 pagingMaxResult 定义将返回以 pagingStartIndex 开头的列表中的
多少个对象 sortField 定义将用于对该列表排序的字段。XPath 表达式必须是相对于响应对象中的列表根元素的路径。 sortASC 定义列表按升序 (true) 还是降序 (false) 排序 searchListName 定义响应对象中将应用于搜索的列表名称。 searchFields 将属性（nameXPath 和值）列表定义为搜索条件。属性名称的 XPath 表达式必须是相对于响应对象中的列表根元素的路径。 searchCombinationType 定义搜索组合类型。所有搜索条件都使用 AND 或 OR 链接。
缓存与图形用户界面 (GUI)（比如门户）结合使用，以显示对象列表和提供排序、搜索和分页等功能。WebSphere ESB 端缓存组件必须包含一个与前端系统的逻辑会话，才能将缓存的值与执行查询的用户相匹配。为了支持这种每用户粒度，每个缓存的元素由两个键标识（这两个键在结合使用时必须是惟一的）：
缓存会话键
这个键用于某个实体（通常是一个用户）与资产之间的逻辑会话。该键的值应在为
同一个用户创建的多个缓存条目中保持相同。可将前端会话的 HTTP 会话 ID 用于缓存会话键。 缓存条目键 这个键从业务数据视角惟一地标识缓存的元素。它可以包含请求业务对象的多个元素，这些元素的组合必须惟一地标识响应业务对象实例。
该缓存模式使用缓存会话键和缓存条目键将业务对象列表存储为数据库中的序列化 XML。该缓存模式使用 IBM DB2 及其 pureXML 功能来存储缓存的数据，并实现分页、排序和过滤。该缓存模式将对已缓存数据的请求转换为在数据库中执行的 SQL 语句。在逻辑上，该缓存模式充当着数据库功能的代表，将它们转换为服务调用。