评论专栏: 服务集成的多事件(和多状态)挑战

大部分涉及到面向服务架构 (SOA)(大部分项目都是这样)的 IT 项目还要处理服务与其使用者之间的集成和连接的各方面。本文介绍一种向集成层增添额外方面的相对较新的趋势,这些方面包括状态处理、决策制定和事件处理,它们由变得更加以客户为中心的业务期望所驱动。 本文来自于 IBM WebSphere Developer Technical Journal 中文版

Andre Tost, 高级技术员, IBM

Andre Tost 的照片Andre Tost 是 IBM Software Services for WebSphere 组织的高级技术员,他帮助 IBM 客户建立面向服务的架构。他尤其关注 Web 服务和 Enterprise Service Bus 技术。在担任目前的职位以前,他在 IBM 软件开发方面担任过各种合作伙伴支持、开发和架构师角色,最近还从事过 WebSphere Business Development 小组的工作。Andre 出生在德国,现在居住在明尼苏达的罗彻斯特。在闲暇时间,他喜欢与家人在一起,喜欢踢足球和看足球比赛。


developerWorks 大师作者

2011 年 12 月 22 日

向服务集成层引入状态的需要

大部分企业提供了多种渠道作为其业务的切入点。银行提供了 ATM、支行、网络银行和电话银行,作为客户访问其帐户的方式。零售连锁店拥有实体店和零售网站。政府机构通过网络、呼叫中心或其公开办公室提供服务。在所有这些情况下,所提供的信息和相关的功能应该在所有渠道上保持一致,这就形成了一个通用层 —— 集成层,它位于各种后端系统与特定于渠道的前端逻辑之间。

这个集成层包含一个具有中介的服务总线。这些中介支持公开现有提供商逻辑的非语义方面。它们还包含一个服务创建组件,其中现有的提供商在语义上形成了新服务。要了解这些概念的详细描述,强烈建议阅读 Greg Flurry 和 Kim Clark 编写的 这篇文章。图 1 给出了该文章中提供的集成层的结构。

图 1. 集成层
图 1. 集成层

为了支持与速度和敏捷性相关的需求,尤其是在关注以客户为中心的业务需求时,就会出现将信息推送到需要它的渠道附近的需要。换句话说,集成层无法完全依靠现有的后端系统来提供信息,它必须能够非常快地传送重要数据,而这常常只有在它将此数据存储在本地时才可能实现。这进而要求集成层是多状态的。由于许多相关业务计划关注客户的性质,在最广泛意义上讲,最常存储在本地的是与客户相关的信息。

因此,我们需要支持尽可能将(客户)数据推送到离其使用者较近的地方。而这带来了许多挑战,下面将更详细地对这些挑战进行分析。


不同的缓存类型

服务集成层中有两种类型的缓存发挥作用。一种是响应缓存。简言之,响应缓存是预测服务调用结果的能力,无需实际执行服务提供程序。这可能在以下情形下最有用:需要多次将完全相同的请求消息发送给一个服务,且其中每个请求不出所料会引发相同的响应消息。在服务总线中建立这种类型的缓存很有用,它不会真正违背总线的无状态性。支持托管服务和服务总线中介的大部分产品都会提供这种类型的缓存。再次说明,只有在服务调用频繁重复发生,以及可以保证存储在缓存中的信息准确度时,环境才能从响应缓存获益。

还有一种不同的缓存类型,我们将它称为操作缓存。在此缓存中,信息不由总线中介使用,而由集成层的提供程序创建部分使用。图 2(基于前面提到的 ESB 文章中的一个图)显示了集成层的不同组件,以及两个缓存组件。

图 2. 集成层中的缓存
图 2. 集成层中的缓存

在部署操作缓存时,必须制定各种架构决策:

  • 缓存的数据的结构。 通常,缓存中的数据只需一个键即可访问,也就是说,不支持复杂的查询功能。如果存储了业务对象集,那么它们可以以单一实体的形式放在缓存中,或者分解为必须由调用逻辑恰当地重新组装的较小部分。

    与此相关地,可能必须构建索引,以允许在独立存储在缓存中的实体之间的关系上进行导航。例如,在银行场景中,如果缓存了客户和帐户数据,可能必须能够在客户与其帐户之间的关系上进行双向导航。这意味着,应该可以检索给定客户的所有帐户和检索拥有给定帐户的客户。索引表可帮助实现此功能,但无论如何,此需求常常需要两个必要步骤才能检索信息。

  • 数据在缓存中的寿命。数据的寿命受到多个条件的影响,例如:
    • 是否对底层后端数据存储的所有更新都要经过集成层,或者更新能否以其他方式进行?如果数据只能通过托管缓存的集成层更新,则很容易保持缓存的数据准确无误。
    • 是否可接受缓存中的数据可能没有与后端完全同步?基于使用者需求,对来自系统中其他地方的业务对象的更改可能无需立即在集成层缓存中反映出来。

    不同的缓存技术可为缓存的内容提供不同类型的寿命支持。内容可以基于上一次使用、基于它的加载时间从缓存删除,或由客户端应用程序显式删除。

  • 将数据加载到缓存中的方法。可采用两种主要原则来将数据加载到缓存中:
    • 边缓存(Side cache):其中,使用缓存的客户端逻辑还负责加载内容。该逻辑将查找数据,如果没有找到,它将从后端检索该数据并将其存储在缓存中供以后使用。
    • 内联缓存:在此情形下,缓存包含能够从合适的后端检索数据的逻辑。客户端逻辑尝试从缓存检索数据,如果数据不在这里,缓存本身将加载它。
    • 客户端加载器:完全静态的内容也可以离线加载到缓存中。例如,很少更新的交叉引用表可由各个应用程序预先加载到缓存中,以便在正常生产用途中无需向缓存中加载数据。
  • 访问模式和更新场景。缓存不是一个记录系统。它(通常)也不是一项事务资源;它无法参与分布式事务。这意味着如果缓存的内容被更新,将独立运行对后端(记录系统)的相关更新,并且必须手动处理潜在的异常。例如,如果对远程后端的更新超时,您不知道相关的事务是否已完成。这意味着缓存的内容可能必须手动与后端同步,或一起删除。

    而且,如果多个并发线程可能会访问缓存中的相同信息,必须在缓存中定义能否在缓存内容上获取任何类型的锁,或者是否和如何解决乐观锁定冲突。

我并不认为任何这些考虑因素都是特定于服务集成层,或者特定于 SOA 内容的。在要使用缓存来实现更高的解决方案性能的任何场景中,很可能也必须回答相同的问题。再次说明,使这些额外方面变得特别有趣的是将数据移动到接近其最终使用者的期望(我发现这也是我常常遇到它所在的环境),而且服务集成层是可能发生这些事件的位置之一。但请记住,基于您的具体用例和需求,响应缓存和操作缓存可能都无法实现或带来好处。


规则

另一个逐渐形成集成层中一个独立组件的方面是一个决策制定部分:规则引擎。正如 Greg Flurry 和 Kim Clark 在他们的文章中指出的,集成可以包含业务逻辑,更确切地讲,包含涉及语义方面且由业务目标拥有和驱动的逻辑。这种类型的逻辑处于集成层的提供程序创建部分中。

此类型的逻辑的很大一部分都与如何撰写现有提供程序来创建新服务提供程序有关,而在撰写的过程中,必须制定业务决策。在传统上,“业务集成” 逻辑中所包含的决策在提供程序逻辑中实现。但如果导致决策结果的条件频繁改变或者至少定期改变,可能将决策制定逻辑委托给业务规则引擎很有用。业务规则引擎使用的业务规则甚至可由业务人员开发和维护,无需 IT 参与。

再次说明,此逻辑属于集成层的提供程序创建部分,因此不是服务总线的一部分。图 3 显示了我们添加的其他组件。

图 3. 向集成层添加一个规则引擎
图 3. 向集成层添加一个规则引擎

当然,这不是说规则引擎仅存在于集成层中。也可以在总体架构中的其他地方利用它。这里,它处理集成的(业务)决策制定方面,以此来促进作为一种核心架构原则的额外的关注点分离。


业务事件

以前让业务更加关注客户的主题仍在延续,企业不仅希望让客户信息容易供其所有渠道使用,他们还希望能够快速响应和适应客户行为、市场需要和快速变化的业务目标。

对于 IT 组织,这意味着要引入使用相关业务事件的能力,恰当地关联它们,以及触发结果操作。事件源贯穿整个 IT 领域,从后端系统一直到前端系统。

同时关注前端和渠道系统以及核心的后端环境的一个地方就是集成层。因此,向该层增加事件处理组件常常很有用。

不过,您可能会争论说,在结构良好的架构中,这样的事件处理组件不属于集成层。而且常常可能遇到此情形,但是,我看到过一些具体的案例,其中事件与服务之间的关系是如此的紧密,以至于将二者放在相同层(集成层)中很有用。

据我所知,描述面向服务性和事件处理之间的关系(以及可能重叠)的术语不是很容易理解。它们中的每一种似乎代表着一种拥有自己的术语和概念的不同软件工程学科。这里不会尝试解决此问题。我的讨论仅限于处理集成层中的业务事件,将它作为存在于该层中的服务相关组件以外的独立架构组件。无可否认,二者会彼此交互:事件触发服务,且服务触发事件。

而且,服务总线的一些元素可在处理事件时重用:事件数据可能必须转换才能支持正则模型,事件使用者和生成者可能仅通过特定协议通信,或者服务总线可能会来回于正确位置处理路由事件数据。因此,将服务总线放在事件处理组件前面常常很有效,这是将事件处理包含在集成层(当然它也包含服务总线)中的另一个原因。


业务事件处理、决策制定和缓存之间的关系

我们向集成层添加了 3 个新组件,分别是缓存、规则引擎和事件处理程序,要考虑的一个问题是,新组件是否和如何彼此交互。

  • 缓存和事件

    缓存可能希望发布有趣的事件;例如,当将内容添加到缓存或从中删除内容时,或者当缓存更改时。但是,依我看来,这些并不是真正的业务事件,常常无法保证能通过事件监视缓存状态。

    但是,利用操作缓存对于事件处理程序很有用,尤其是在考虑必须关联事件来触发正确的操作时。必须存储来自多个事件的数据(可能经历了很长时间才收到),才能将它放在公共上下文中。而且,实际事件中包含的数据可能不足以检测合适的关联,可能需要缓存中已存在的或存储在那里供以后使用的额外数据。

  • 缓存和规则

    缓存与规则组件之间的关系非常相似。因为缓存组件通常是一个被动元素(也就是说,它会被要求查找数据或被要求存储数据),它很少会将任何决策制定委托给业务规则处理引擎。

    但是,如果规则引擎必须依靠状态数据来制定某些决策,那么此状态数据完全可以包含在缓存中。

  • 规则和事件

    这一组件组合很有用。事件关联和触发恰当操作的需要都关乎决策制定。决策并不是基于一组可一次提供的输入数据,而是基于彼此独立发生的一些事件。

    我发现,在这些类型的环境中,最常见的用例就是事件处理程序和决策引擎都依靠缓存来存储它们需要的数据,事件处理程序至少将其部分处理工作委托给规则引擎,尤其是在规则由业务人员创建和维护时。


结束语

对这样一种集成层的需求正在与日俱增,它同时包含具有中介的服务总线,以及支持从现有提供程序创建新服务的服务创建层。而且,在许多情况下,还有对决策制定和事件关联的额外需要,也需要认识到相关状态必须缓存在集成层中以供更快和更轻松地予以访问。

因此,我们增强了该架构模型,添加了一个缓存组件、一个决策制定组件和一个业务事件处理组件。企业已开始构建包含这些新组件的系统,这一趋势一定会在未来变得更加普遍。

参考资料

学习

获得产品和技术

讨论

条评论

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, Web development
ArticleID=781986
ArticleTitle=评论专栏: 服务集成的多事件(和多状态)挑战
publish-date=12222011