事件驱动SOA：更好的SOA方式

原文：http://www.tibco.com/resources/solutions/soa/event-driven_soa_wp.pdf

专家们都同意面向服务架构(SOA)是开发全新企业架构的正确方法。你的公司可能已经开始向SOA迈进，但是从长远来看你们是否在正确地实施SOA？如果你们没有支持事件处理的话，答案可能是没有。

事件驱动SOA：未来的基础 
        SOA被公认是一种开放企业IT基础架构之业务价值的方法。SOA允许架构师将集成的应用程序分解成能被不同的应用程序重用的单独服务。通过将信息和事务转换为抽象化、标准化了的服务，SOA为开发新型的的业务应用程序提供了基础——无须从头开始而由已存在和新的服务组成的“复合”应用即可。它能让企业以更低成本快速的部署新的业务服务。

        然而，SOA架构并不能满足对实时业务的动态性能的要求。设想这样的场景：在不同的行业中的应用会存在微小的差别。

        一家电讯公司为特定的用户提供服务，承诺提供一种新型的电话和费用计划。上述计划被证明是成功的，并且这些客户因为一个电话客户服务代表而开始倾向于更换服务。

        这个例子中的核心业务运作是SOA应用模型的成功。服务从数据仓库中找出了服务最可能发生的变化趋势。通过服务，将客户名称，电话号码和其他信息置入CRM/呼叫中心应用系统的功能集成成为可能。其他的服务可接受并且和票据系统一起处理服务请求。最终，一个订单处理流程会被使用账目系统/仓库的服务调用，物流处理流程将新的电话和费用计划发送给这个用户。

        然而，这个故事还没有结束。结果是，促销是如此的成功，以至于此品牌的电话脱销并且库存量下降迅速。订单被执行完毕之时，电话即刻从仓库中运出。这些电话没有被装船运出。订单处理被“粘滞”并且发出出货没有完成的报警。但是，那样就太晚了。到时客户服务代表只能通知客户到货延迟或者改定其他品牌的电话，而客户也已经失去了信心。它决定继续和他以前的供应商签订一个新的服务合同和电话。

图1：SOA成功地建立了一种促销模式，但是有还些东西遗漏了。

        发生了什么呢？是SOA导致的失败吗？不，这是一个企业不能发现迅速变化的业务事件和形势并快速反应的一个例子。那些可以提示出一些像“电话出现脱销”情况的事件在“事件云”中丢失了。这个例子指出，SOA应根据形势和业务事件来进行调整。

图2：增加复杂事物处理，可以使业务能够动态的对时效性强的业务环境做出反应。

一个SOA的短过程

        为了能了解上面描述的业务缺陷，有必要理解什么是SOA和什么不是SOA。SOA是对网络中经安全认证的人和应用程序开放和有效的一种抽象的分布式架构。通过可以被其他应用程序使用的标准化了的格式（WSDL, SOAP, XML）和传输协议（HTTP, JMS），数据和功能可作为能重用的服务被提供出来。如果对私人隐私的担忧被适当解决了的话，这其中能够包括像客户电话号码、地址或者不同类型用户的购买趋势等内容。

        也许最大的优势之一是信息处理被所有者分享，比如企业资源计划(ERP)系统，客户数据库或者一个桌面程序。

请求/响应
   
        基于Web服务的SOA,使用典型的请求/响应消息交换模式作为通信方式。通常是，有一个服务和一个可以访问这个服务的客户端。客户端在指定的时间，对指定的服务进行请求并被获得信息或者处理信息。根据请求/响应的性质，这种服务和客户端之间的关系通常是松耦合的、同步的。这是一种被动的，基于请求的结构。

编排

        对于大多数Web服务应用程序，企业通常都使用服务编排。Web服务编排目前是大多数SOA工具和架构的核心功能。服务编排是对服务集合的流程图形化以实现系统间的信息处理自动化。比如，如果业务对象是向客户关系管理（CRM）系统中导入客户信息，一个流程可能需要访问拥有客户信息，票据信息和地址/电话类型信息的数据仓库，并且将上述信息插入到CRM系统中。流程中可能会用到数据转换和一些简单的规则。通常，这类流程是由一个请求/响应动作的事件触发，然后此事件会触发一串请求/响应的交互操作。它是基于事件的，但是基于清晰的过程，因为这个事件触发的是一个规定的硬编码流程，而不是说明性的，它是由预先已经编写好的过程来触发的。

        那些触发一个编排好的业务流程或者调用一个Web服务的业务事件，通常不是可预测和被请求的。在某些情况下，一个事件被一些随机的业务活动触发。在很多情况下，这类事件被记录到应用程序的数据库中。

ESB: 企业中的分布事件

        企业应用总线是一个可接受的刚性编排SOA基础架构问题的解决方案。ESB是服务请求通过SOA消息传送的通常方式。ESB保证从客户端的消息能够发送到服务或者相反，无论它是什么样的消息（请求查看客户信息、实际数据等等）。它也提供应用程序模块间的事务级的消息发送，并不止是Web服务，比如，Java对象。

        如果能被适当的应用，发布/订阅和通知服务在很多消息产品中保证ESB能够处理事件，甚至是异常事件。通过合适的计划安排，ESB可以成为通用的SOA或者事件处理的一个基础要素。

        用户需要处理事件，响应和适应各种环境。在大多数情况下，这是不会发生的。结果是企业并不能检测到业务事件和形势，包括快速产生的机会或者威胁。这是一个在业务优化中的明显区域，通常被认为是复杂事件处理(CEP)。我们将在后面更详细的讨论CEP。

为什么事件重要
什么是业务事件？

        业务事件是可以影响业务的显著业务活动。在事件驱动的SOA中，事件被基础软件系统直接或者间接的创建和记录，并且会对业务产生某些影响。

        根据业务规模的大小，每天可能会发生数以百万计的显著事件。一个客户代表为用户输入了一个新的地址；一个网络设备发出了一条高温警报消息；一场暴风雪在某地区发生导致了员工迟到；一托盘的货物运错了目的地。这些都是业务事件，并且都会对公司的运作产生些许影响。有些事件会产生消极影响，有些会有积极影响，会有某些机会，还有一些可能无法评论。

        所有的业务都是事件驱动的。实际上，整个世界都是事件驱动的！

        考虑一下那一托盘的货物要通过一个东海岸仓库中的RFID（射频识别器）。大多数的IT经理会有一个系统，它向库存跟踪程序发送信息，而库存跟踪程序准确的记录了仓库中库存货物的数量。这个系统也会向物流应用程序发送信息，以确认订单已经被收到。它甚至可以将产品描述和购买订单中的信息进行核对，来确认发货的准确性。通过SOA，可以使业务应用程序具有上述功能而且可以变得更简单。到现在为止，都还不错，但是，这不是全部。

        上文提到了，船运这一托盘货物实际上是坏消息，因为货物对方在东部海岸的仓库中，而由于一系列的强有力的促销活动，中西部的销售形势迅速上升。通过电话对这一情况作出反应可能会出现问题，因为关键客户因为某个地区的暴风雪而不在办公室里。

        这个一个零售业中无视业务事件的反面例子。每个行业都是事件驱动的。企业花费了他们大多数的时间去处理事件驱动流程。误导的资源，暴躁的客户，欺诈，偷窃，突然增加的销售和其他的可想象的情况表明事件是如何影响业务的。

什么是复杂事件处理？

        “复杂事件处理是一项从消息系统中提取信息的新技术。”

        很多观察家相信，对企业来说需要处理复杂事件的能力来对业务流程和环境的改变做出快速反应。复杂事件处理系统(CEP)使组织能够处理分布式的业务事件，并发现机会和威胁。业务事件可能被独立追踪，像股票的交易流，或者与其他的事件相关联，发起过程或“复杂”事件（通常被叫做“环境”）。

        要让这些业务事件有意义，需要事件处理技术和专业技术。通常，用户必须理解并且创建业务模型，对业务对象和前后的历史信息之间的事件流程中的依赖和关系进行建模。

图.CEP系统使企业能够处理事件，发现趋势与模式，预报特定环境的影响。

        事件以及和业务事件相关的趋势需要与历史业务模型映射和关联。对业务模型的事件映射构成了识别可能正在发生的事件模式的基础。在业务模型开发和业务事件与模型的关联中，规则是重要的一个部分。对于企业，事件处理的重要部分是对负面情况的快速响应或者抓住突然出现的机会的能力。

        总之，业务处理，或者CEP，为企业提供追踪和关联事件；处理事件，发现趋势和模式；并且最终，预报特定环境影响的能力。由此可以采取快速的措施以阻止对企业的威胁或者使损害降到最小。比如一个客户没有按时收到产品而取消订单。另一方面也是一样，可以将积极的环境更迅速有效的转化为效益，比如突然出现的贸易或者客户增加购买的机会。同样可以对环境进行分析，来改进基本的业务处理过程和应用，这对业务操作来说是最根本的。

SOA和事件处理 – 把他们放到一起
        SOA和事件处理都是业务优化所需要的，当他们结合在一起的时候，可以创造出巨大的价值。SOA和事件处理也可以使在应用系统和数据库内部的信息变为共享。

        服务和SOA通常能将信息和IT流程共享给其他的应用系统并且建立新的合成的应用系统。事件是企业的关键系统，在被SOA所使用后，可以向企业内部和外部所有被授权方发送业务事件。CEP通过从分布的企业事件中发现威胁和机会扩展并且创建价值。

        在功能层面上，SOA和事件彼此需要。当创建一个事件驱动的应用程序，不论大小，SOA可以从事件中受益。比如，一个事件可以触发一个或者一系列服务去解决业务问题。将事件处理创建成服务也很重要，因为事件和CEP应用程序可以从SOA的业务对象中受益。实际上，服务可以被用于事件驱动应用程序的每一步功能中。

        在类似的情况下, 由于快速敏捷的事件处理设施和高适应性的业务处理流程可对不断变化的机会和威胁做出响应，SOA变得更加强大。业务服务或者服务的编排的成果通常就是另一个业务事件。

结论
        回到最初的问题：你正在为长期目标实行正确的SOA吗？如果你正在实行一个对任何事件驱动的通信支持事件处理和消息的ESB，那答案就是“是”。如果你没有实行ESB，比如，你使用应用服务器，集成代理和代码来实现SOA,那答案是“不是”。你需要ESB。

        接着是下一个问题：你什么时候需要CEP？最好的策略是现在就问这个问题并且用与你鉴别你的第一个SOA对象同样的方式鉴别第一个CEP对象。考虑一下在任何一个业务领域中，追踪流程或者处理突发意外事件的状态大大增加了业务的价值。