EDA与CEP如何与SOA相匹配

　　大多数的组织在对SOA思考的时候都会处于这样的境地：他们想确定他们最终在何时以及是否应该投资SOA，以及很多其他的问题，例如进行这项工作应该选用哪些工具以及哪个软件生产厂商的产品。但是，由于技术解决部门应该有这种方案，很多在SOA领域的软件厂商现在都在面向SOA的客户推出一个全新的概念，那就是事件驱动结构(EDA)。这个概念看上去是一个新的术语，其使用了在SOA领域广泛实用的首字母缩写的方式。因此，我们将来看看EDA这个概念到底是什么意思，以及它是如何和SOA市场相关的。

　　让我们先从探索当我们在企业软件部分谈及事件的时候，我们会最有可能想到什么事情这件事出发。对于很多人来说，他会让大家要么想起信息中间件，要么想起什么异步通信，出版/订阅标题，JMS，MSMQ或者是其他一些能够建立事件提示的技术。当然了，这些都不是什么新的技术，因此我们可以将目光转向能够解决简单情形的Web服务标准。在Web服务标准中，你可以看到Web服务事件(WS-Eventing)，它是由OASIS组织的W3C(Web服务公告)制定的。咋一看去，这是一个将基于服务的架构和事件处理混合起来的东西，但是，事实上，这是一个很精妙的想法。

　　而EDA是一个更加广泛的概念——很像SOA自身也是一个方法一样——EDA在事实上已经被研究了很多年。如果在过去几年你曾经听说过有软件厂商推出过复杂的事件处理流程(CEP)，那么实际上你已经对EDA所涉及到的部分有所了解了，尽管也许你并没有意识到那三个缩写字母的含义。而对那些不熟悉这一概念的人们来说，在CEP和EDA之后的假设是在存在确定的系统事件的基础上运行的商业逻辑。事实上这样做是发源于非常广泛的媒介中的，甚至包括前面提到的出版/订阅中间件来进一步描述类似通过RFID扫描仪进行事件探索以及平凡如在数据库里发生的事件的设置的情况。

　　在这种判断下，CEP的软件厂商开拓出了跨行业的充满机会的市场。特别是在事件敏感逻辑对企业非常重要的财务和制造行业，股票指令触发或者完成操作等对企业都会产生重大的影响。但是在面临这类问题领域的过程中，不止一个的CEP软件厂商都不得不为企业特定的系统中存在的有意义的事件开发特别的方法，创建过多的所有权引擎，适配器，查询语言以及理所当然的各自的管理、监控和编辑工具。

　　上述的种种都导致了在早期的SOA建议者、CEP软件厂商以及事实上有效的EDA这些SOA2.0的组成部分的分离。站在CEP的立场上，几乎没有能够使得CEP实现成为事实的目的的SOA的技术或者是其他相关的技术。这使得CEP在2000年在生产类型的情况下，没有SOA的影响就取得成功的原因。

　　但是，让我们再看一看到底是什么使得CEP对企业而言是特殊的。绝大多数CEP解决方案的卖点在于他们能真正提供实时的事件处理。而这正是和中间件事件处理系统的静态方式完全相反的。这样做避免了在相关的找回存档事件中或者仅仅是在简单的为了描述极端的事件流程而决定行动的路线的活动中承担延时。因此就像俗语中描述的那样：通过SOA的设定，我们获得了基础的鸟瞰图：基于标准的松散的耦合的接口/服务，能够跨越企业层级和不同平台的访问等。举个相关的例子，就是通过用相同方法访问事件的可能性简化了的对企业大多数数据的访问。

　　尽管对CEP的需求仅仅是在一小部分行业中是至关重要的，但是，他并没有花费SOA供应商太多的精力去描述存在利用同样的基础设施加载SOA以实现CEP需求的商业机会，其所导致的术语有：事件驱动SOA、作为SOA2.0的EDA，包括围绕同样的范例的大量的引擎和产品公告。直到在CEP市场中旧的防护被关注——如果你愿意就是非SOA营地——在同样的语句中联合SOA、EDA和CEP上存在一定的抵抗性，尤其是在SOA风暴之前大多数都做得很好。

　　事实是SOA从CEP中获取了很多，就像CEP从SOA中获取很多一样，在现在的状态下，基本上每一件SOA产品线都缺乏实时的事件处理能力，而其在小的CEP引擎中存在，从另一方面来说，大多数CEP引擎拥有成帧技术——读取供应商占据——以执行实时事件处理，他们都能从已经开发的SOA设计中获益。不管是术语SOA2.0或是EDA都将会被如“模糊”的已经成功的中介所惩罚，但是其将很快成熟，在流行的SOA供应商和小的CEP供应商的产品之间存在一个倒数关系，不管其是如何称呼的。