在 WebSphere Enterprise Service Bus 中实现基于数据库的缓存模式

学习如何通过使用一组额外的中介原语扩展已打包的原语,在 WebSphere ESB 中创建一种基于数据库的动态缓存模式。本文将介绍该缓存模式的架构,展示如何实现您自己的原语。

Thomas Bohn, 经过认证的 IT 专家,IBM Software Services for WebSphere, IBM

Thomas Bohn 的照片Thomas Bohn 是德国 IBM Software Services for WebSphere 团队的一名经过认证的 IT 专家。他已在该团队工作了 12 年,目前主要关注 BPM 和软件集成项目的架构设计。他专攻的产品包括 WebSphere Application Server、WebSphere ESB 和 WebSphere Process Server。



Susann Fritzsche, IT 专家,IBM Software Services for WebSphere, IBM

Susann Fritzsche 的照片Susann Fritzsche 是得多 IBM Software Services for WebSphere 团队的一名 IT 专家。她自 3 年前加入 IBM 时就加入了此团队,她目前专攻的领域包括 Business Process Management 和 WebSphere ESB。



2013 年 1 月 08 日

简介

根据已普遍被人们接受的 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 业务对象
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 语句。在逻辑上,该缓存模式充当着数据库功能的代表,将它们转换为服务调用。有关 DB2 PureXML 功能的更多信息,请参阅文章底部的 参考资料

缓存流

这一节将介绍缓存流的外观。图 2 展示了有状态业务对象列表缓存的执行阶段。此缓存模式中使用的原语将在 缓存原语 一节中更详细地介绍。

图 2. 缓存流
缓存流
路径 1
执行位于请求流中的 StatefullBOListCacheGet 原语。它执行缓存会话键并计算缓存条目,然后使用二者检查数据库中是否存在相应的条目。如果找到一个缓存条目,那么该原语就会执行路径 4。如果没有找到缓存条目,那么该原语就会执行路径 2。
路径 2 -- 缓存失败
StatefullBOListCacheGet 原语将缓存会话键、缓存条目键和其他数据缓存到 StatefullBOListCachePut 原语中。StatefullBOListCacheGet 原语调用缓存失败终端。您必须将请求消息中包含的 ResultRetrieveCriteria 对象放在一个可供 StatefullBOListCachePut 原语访问的地方。建议的位置在关联上下文中。然后会将请求消息发送给后端业务服务进行处理。控制流将继续执行路径 3。
路径 3
后端业务服务使用一条发送给 StatefullBOListCachePut 原语的响应消息作为响应。该原语检索 StatefullBOListCacheGet 原语提供的数据,以便将响应消息插入数据库中。数据对象列表经过序列化后,存储在一个 XML 类型的数据库表列中。StatefullBOListCachePut 原语然后检索 ResultRetrieveCriteria 对象,以便生成一个数据库查询,该查询将应用请求方希望在响应消息中包含的业务对象列表上执行的过滤、排序或搜索功能。StatefullBOListCachePut 原语执行数据库查询,并将其响应发送回请求方。
路径 4 -- 缓存命中
StatefullBOListCacheGet 原语检索请求中的 ResultRetrieveCriteria 对象,以便生成一个数据库查询,该查询将应用请求方希望在响应消息中包含的业务对象列表上执行的过滤、排序或搜索功能。StatefullBOListCachePut 原语执行数据库查询,并将其响应发送回请求方,以避免调用后端业务服务。

缓存原语

这一节将介绍有状态业务对象列表缓存使用的原语。

StatefullBOListCacheGET

此原语是中介请求流的一部分。

cacheFail 终端(如果 sessionID 和键的缓存条目存在,则调用它)返回请求消息,以便可以将原始消息传递给后端。cacheHit 终端(如果 sessionID 和键的缓存条目存在,则会调用它)返回已应用了搜索、分页和排序机制的响应消息。应该将此响应传递回调用方,而不是进一步调用后端系统。表 2 给出了 WebSphere Integration Developer 中 Properties 视图的 Details 部分中的原语属性:

表 2. StatefullBOListCacheGet 原语属性
属性描述
Cache DB data source JNDI name数据源的 JNDI 名称
XPath to unique ID that identifies the client's session with the cache此 ID 是一个实体(通常为一个用户)与资产自检的逻辑会话的一个键。为了清除某个用户的所有活动,该键的值应在为同一个用户创建的多个缓存条目中保持相同。例如,一个前端系统的 HTTP 会话 ID 可用作缓存会话键。
XPath to object of type ResultRetrieveCriteria that specifies how the response should be sent back.该 XPath 表达式应指向操作输入对象中的 ResultRetrieveCriteria 对象。
XPath to integer attribute in the response message that holds the count of result objects in the BO list.该 XPath 表达式必须指向一个持有 BO 列表中满足搜索、分页和排序条件的结果对象数量的整数属性。
XPath to the response message list root and attribute that is subject to caching.该 XPath 表达式必须指向作为列表根元素的属性。该路径应从操作响应对象级别开始。
Cache keys从业务数据视角惟一地标识缓存的元素。它可包含请求业务对象的多个元素,这些元素的组合必须能够惟一地标识响应业务对象实例。

StatefullBOListCachePUT

此原语是中介响应流的一部分。它使用定义的缓存键和来自 Get 原语的惟一会话标识符,将来自后端系统的序列化的响应消息存储在缓存数据库中。此外,它依据请求输入对象中定义的 ResultRetrieveCriteria,对存储的对象列表执行搜索、分页和排序。表 3 给出了 WebSphere Integration Developer 中 Properties 视图的 Details 部分中的原语属性:

表 3. StatefullBOListCachePut 原语的属性
属性描述
Cache DB datasource JNDI name数据源的 JNDI 名称
XPath to object of type ResultRetrieveCriteria that specifies how the response should be sent back.该 XPath 表达式应指向 ResultRetrieveCriteria 对象。

Put 原语的输出终端将返回响应对象,其中包含满足 ResultRetrieveCriteria 的对象列表。此响应对象可传递给输入响应节点。

StatefullBOListCache INVALIDATE WITH KEY AND SESSION

此原语删除了一个针对给定键和会话 ID 的缓存数据库条目。它位于 Get 原语前的请求流中。前端系统通过在操作输入对象中设置一个标记来触发执行,确保已将请求发送给了后端系统。表 4 显示了 WebSphere Integration Developer 中 Properties 视图的 Details 部分中包含的原语属性。

表 4. StatefullBOListCache INVALIDATE WITH KEY AND SESSION
属性描述
Cache DB datasource JNDI name数据源的 JNDI 名称。
XPath to unique ID that identifies the client's session with the cache此 ID 是一个实体(通常为一个用户)与资产自检的逻辑会话的一个键。为了清除某个用户的所有活动,该键的值应在为同一个用户创建的多个缓存条目中保持相同。例如,一个前端系统的 HTTP 会话 ID 可用作缓存会话键。
Cache keys从业务数据视角惟一地标识缓存的元素。它可包含请求业务对象的多个元素,这些元素的组合必须能够惟一地标识响应业务对象实例。

StatefullBOListCache INVALIDATE FOR ENTIRE SESSION

此原语删除所有属于某个特定会话 ID 的缓存条目,在用户会话过期时作为一个独立服务由前端系统调用。表 5 给出了 WebSphere Integration Developer 中 Properties 视图的 Details 部分中的原语属性:

表 5. StatefullBOListCache INVALIDATE FOR ENTIRE SESSION
属性描述
Cache DB datasource JNDI name数据源的 JNDI 名称。
XPath to unique ID that identifies the client's session with the cache从业务数据视角惟一地标识缓存的元素。它可包含请求业务对象的多个元素,这些元素的组合必须能够惟一地标识响应业务对象实例。

StatefullBOListCache INVALIDATE FOR COMPLETE CACHE DB

此原语使整个缓存数据库失效,可由计划程序服务调用(例如每晚一次)来清除缓存。表 6 给出了 WebSphere Integration Developer 中 Properties 视图的 Details 部分中的原语属性:

表 6. StatefullBOListCache INVALDIATE FOR COMPLETE CACHE DB
属性描述
Cache DB datasource JNDI name数据源的 JNDI 名称。

构建您自己的中介原语概述

StatefullBOList 缓存使用了自己的中介原语。下面概述了如何构建您自己的中介原语:

  1. 构建插件项目。它定义视觉方面,指定原语的 Details 部分中提供了哪些属性。
  2. 构建包含您原语的逻辑和实现的 Java™ 项目。
  3. 将插件项目作为 Eclipse 插件部署到 WebSphere Integration Developer 中,以便将它显示在 Mediation Flow Editor 面板上。
  4. 部署 Java 项目并使实现可供运行时使用。
  5. 测试您的自定义中介原语。

有关每一步的详细描述,请参阅 “参考资料” 中的前两项。

结束语

本文介绍了 WebSphere Enterprise Service Bus 中一种智能的、动态的、基于数据库的强大缓存模式,概述了该模式和它的架构。该缓存模式基于一组中介原语。本文随后还简要概述了如何构建您自己的中介原语。

致谢

感谢 IBM Software Services for WebSphere 的 Shili Yang 帮助审阅本文。

参考资料

学习

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=854264
ArticleTitle=在 WebSphere Enterprise Service Bus 中实现基于数据库的缓存模式
publish-date=01082013