给SOA加上事件触发器

开篇：润墨网以专业的文秘视角，为您筛选了一篇给SOA加上事件触发器范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！

事件驱动(EDA，Event Driven Architecture)是Gartner在2003年引入的术语，用于描述基于事件的范例。

按照Gartner的观点，EDA定义了一种用于设计系统和实现应用的方法―在这些应用和系统里，事件在解耦的组件和服务之间传输。

今天，随着soa日渐成为企业IT建设的主流趋势，EDA与SOA的结合也许可以给企业IT带来更大的价值。

对企业来说，获得灵敏性是一项重大挑战。无论是金融交易员希望在国外市场获得套利机会，企业在接到零售商客户大量退货的消息后需要及时调整生产线，还是保险公司经理们期望根据变化万千的因素开发出一种新的风险管理产品，无不要求企业迅速采取有效的响应措施。由此，及时响应实时的变化和事件成为企业级架构的重要需求。

研究这些事件我们会发现，这些事件都是由诸多环节组成的，而且环节之间有密切的相互关系，一旦哪个环节发生了变化，其结果往往谬以千里。不能及时响应实时的变化和事件，就增加了意外事件发生的概率。

发现潜在的意外事件

以航班延误这个突发事件为例。航班延误对常常旅行在外的人来说似乎变得越来越司空见惯了，这让他们备感沮丧。但同样沮丧和郁闷的还有航空公司的工作人员，因为航班延误或者取消就意味着他们之前为保证航班正常所做的一切工作都在付之东流―航空公司每天的航程表都经过精心的编排，它牵涉到乘客、行李、飞机、机组人员和地勤人员等多个环节。每个环节都受时间的严格限制，一旦某个环节出现延误，且延误超过预留时间，就会影响其他环节―超过x时间后，X乘客延误了班机；超过y时间后，Y飞机必须停止使用、送去检查；超过z时间后，Z机组人员无法执行另一趟航班。更糟糕的是，航空公司的工作人员为了应对这些变化，需要采取响应措施。而为了拿出响应措施，每用掉一秒钟，其他每个部分的可用时间就相应减少，更糟糕的结果是最终没有其他响应办法！

跟航空公司类似，这类事情也会发生在其他公司―由于无法根据目前的相关事件实时地预测未来发生的事件，因而也就无法采取相应措施获得最佳结果。现代业务流程随时都在产生海量的、不同种类的事件，要想从中发现有价值的事件无疑是大海捞针。帮助企业发现意外的事件，需要一种新的软件模式来处理数量众多的不同事件。

事件驱动(EDA，Event Driven Architecture)是Gartner在2003年引入的术语，它定义了一种用于设计系统和实现应用的方法―在这些应用和系统里，事件在解耦的组件和服务之间传输。与事件机制类似，EDA指定“服务”与“业务事件”的挂钩方式，犹如JavaScript或4GL环境中，可以将触发器(可执行程序代码段)与按压按钮、更改域值或提交查询等事件相挂钩。

EDA架构渐行渐近

根据Gartner观点，现代的、灵活的企业IT架构模式应该是面向服务(SOA)和事件驱动(EDA)的。

SOA是未来企业IT建设的新趋势。SOA把功能编制成松散耦合的组件组成的统一服务包―这些组件可使用标准的消息传送协议进行相互联系，从而使IT基础架构与业务流程相一致。SOA解决了访问来自不同系统的数据流这个问题。

EDA是设计和创建应用程序的方法，这些应用程序中的事件所触发的消息可以在独立的、非耦合的模块之间传递，这些模型彼此并不知晓对方。EDA极大地改进了企业响应不同的、表面上毫无关联事件的能力。通过提供瞬时过滤、聚合和关联事件的能力，EDA可以快速地检测出事件并判断它是机会还是威胁，从而帮助组织机构快速、恰当地响应这些事件。

用SOA的思想设计EDA架构即事件驱动SOA(EDSOA),近年来蓬勃兴起。EDSOA将SOA的“请求―响应”和事件驱动架构(EDA)的“事件―订阅”模式结合起来，支持快速和广泛的响应，其目的就是扩展SOA,以便能在海量的数据流里发现有价值的事件。EDSOA结合了实时系统、数据流管理和复杂事件处理的经验，并将其用于业务应用的开发。用户和系统可以了解影响其业务运行状态的微秒级变化，并且立刻知道哪些事情是需要特别注意的。

EDSOA可以帮助组织机构构建系统来及时发现机会或者检测出危险，以防止它们变得更严重。在前面列举的航空公司航班延误例子中，如果有EDSOA，即使这些突发事件之间有大量复杂的交叉，工作人员只要将所有这些事件编入EDSOA框架的应用程序中，就能快速发现突发事件，并采取适当的响应措施。航空公司也由此大大增强了对航程表不可避免受到的干扰进行响应的能力。这不但节省了资金，还提高了乘客满意度。

航班延误实例表明，应对面向事件的挑战需要三项功能：首先是全面集成所有事件源和目的地，其次是构建灵活的事件驱动模型，第三是实时确认事件模式。当然，一旦事件驱动应用发现了值得关注的模式，企业通常需要响应，因此，外部集成就变得很重要。在这方面，SOA就能充分发挥作用了―它能与实施基本响应机制的系统集成，或者调用能够协调复杂响应的业务流程编制引擎。

如何实现事件驱动SOA

将服务和事件处理流程结合起来能带来非常大的敏捷性。然而，今天基于Java的解决方案并不能支持二者结合的需求―至少到目前为止是这样的。这是因为基于Java的中间件产品根本就不是为了从容处理复杂事件处理规则而设计的，Java没有提供相应的架构支持。因此，基于Java的EDSOA面临的主要挑战是延迟和吞吐量，因为没有人需要这样的系统：运行环境在收集废料时，突然停止了几十秒；也没有人需要这样的系统：危机发生时，迟迟没有启动事件处理机制；更没有人需要这样的系统：入站事件的数量大大增加后，速度却大大减慢。

基于Java的中间件产品需要针对事件优化其特殊的运行环境，以便在事件处理方面提供有保障的停顿时间、每秒几万个事件、可扩展的集群功能，它还需要高级服务，用于动态、数据驱动事件定义。最后，基于Java的中间件产品还需要一套工具、框架和组件，用于构建、部署及监控事件驱动应用。

不久前，BEA推出了BEA WebLogic事件服务器，这是一个功能齐全的轻量级Java应用服务器平台，特别适合用于处理大容量的流式数据、可预测的实时响应需求和复杂事件处理(CEP)。由于它内置了事件特性，因此客户可以在这个平台上构建自己的应用，无需把CEP引擎和多种不同的平台集成起来。而在此之前，还无法使用Java以实时、高可预测性的方式来管理这些类型的事件需求。

BEA WebLogic事件服务器提供了这样的功能：既能以C/C++所具有的速度和可预测性来处理大容量的复杂事件，又能具有Java可大幅度降低总拥有成本的优点。BEA WebLogic事件服务器可以实时聚合来自分布式系统的信息，然后根据规则来发现可能原本不被注意的模式和趋势，从而使用户有能力建模、确认、预计及迅速响应看似无关的事件所带来的机遇和威胁。该产品作为SOA一些关键方面的基础架构，使用户无需改动现有或计划中的SOA基础架构，就可以实现高性能计算，从而让用户能最大程度地利用已有投资。此外，WebLogic事件服务器能够支持XTP，提供了高吞吐量、高可预测性及实时响应，以帮助用户满足严格的服务级别协议(SLA)。该产品支持简单Java(POJO)编程和Spring框架，并支持事件处理语言(EPL)，可以在定义事件处理必不可少的时序规则及非线性规则应用方面补充及扩展SQL。

利用WebLogic事件服务器的完整基础架构，客户可以避免大量费用，并迅速把新的事件驱动应用推向市场。这种方案能够简化为现有应用添加面向事件功能的过程。

WebLogic事件服务器结合了BEA WebLogic实时版本和BEA WebLogic Server虚拟版本的功能，不仅能为事件驱动型SOA带来关键的功能，同时为在极限事务处理(XTP)主流硬件上部署大规模业务关键应用提供了必不可少的坚固基础。