InfoQ

InfoQ

新闻

我的书签

登录注册 以永久保存书签。

该内容已经被标记书签!

标记书签错误,请重试!

CEP是EDA或SOA的必要条件吗?

作者 Dilip Krishnan 译者 黄璜 发布于 2008年11月23日

领域
企业架构
主题
CEP ,
业务流程管理 ,
SOA ,
商业 ,
架构 ,
企业架构

Jack Van Hoof在一篇文章里比较了CEP和EDA以及它们如何关联到SOA。他表示:

CEP (复杂事件处理) 在指定的时间帧里关联了多条消息。EDA是从业务事件角度对信息系统建模的架构方式。EDA与SOA的不同在于其关注的焦点。SOA是以服务为模型的中心,而EDA则以业务事件为中心。 SOA的方式将会带来同步通信风格的结果,而EDA方式是一种异步的通信风格。

他相信市场并未真正理解EDA并解释到CEP为何从根本上与EDA不同;即CEP是工具而EDA是架构。

CEP从定义上就不是关于业务事件的。CEP是处理消息流的一种技术。这些消息并不要求要代表业务事件。一个业务事件意味着当发生某种情况(状态改变)你的业务能够按照预先计划的方案来应对它。一个业务事件可通过消息来表达,但并非所有消息都是业务事件的代表。CEP是关于消息的,EDA是关于业务事件的。CEP能够被用来实现EDA。你可能会说:EDA是业务层次的CEP。

作为回应,Progress Apama的Giles Nelson详尽阐述了SOA,EDA和CEP三者的关系,并指出了几个关键点。Joe McKendrick在为什么‘事件驱动架构‘不仅仅是复杂事件处理这篇文章里也表达了相同的观点。同样的还有Udi Dahan,他以一个优雅的order-to-cash 处理案例举例说明了这些概念在真实世界业务问题是如何相互作用的。他以下列评述总结了自己的立场。

CEP,虽作为一个富有挑战的工程领域,并在某种条件下管理着一个项目要成功所面对的必要的技术风险,而且当以SOA/EDA为背景时能真正发挥出其闪光之处,但就其本身而言,实不益被用于架构层次的最高级。

Jack以强调EDA的重要性作为了其文章的总结。并表示“我认为EDA最终将完全地改变我们现在对业务应用的认识,包括SOA”。

我们之前也曾从架构的角度对这一争论进行了关注。看起来CEP,SOA和EDA这三者之间的相互关系颇为混淆,这很大程度上是由于供应商的原因。如若对企业是如何采用这些技术的来一个直观的透视将会非常有趣。那么CEP在你的企业中扮演着什么角色呢?它们是如何被运用于EDA和SOA项目的呢?

查看英文原文:Is CEP a pre-requisite for EDA or SOA?

译者 黄璜 糊口靠的是Java Web,赶过SOA的潮,追过Cloud的风,真正欢喜的是Linux,向往的事情是研究网格计算。

看了一下Udi Dahan那个“优雅的order-to-cash 处理案例” 发表人 yao avant 发表于
  1. 返回顶部

    看了一下Udi Dahan那个“优雅的order-to-cash 处理案例”

    发表人 yao avant

    这个案例是这样的:

    在SOA中,即使已经识别好了服务,还是有不同的设计决策,试举一个简单的例子:设想一个“订购-兑现”过程,其中有“登记订单”这块。假设有两个服务,“订单服务”和“库存服务”,要做的是登记订单并预定相应的库存。有A、B、C三种设计选择:

    A.
    1.“过程/应用程序”向“订单服务”发送“registerOrder”消息(同步或异步);
    2.“过程/应用程序”向“库存服务”发送“reserveStock” 消息(同步或异步)。

    B.
    1.“过程/应用程序”向“订单服务”发送“registerOrder”消息(同步或异步);
    2.“订单服务”向“库存服务”发送“reserveStock” 消息(同步或异步)。

    C.
    1.“过程/应用程序”向“订单服务”发送“registerOrder”消息(同步或异步);
    2.“订单服务”发布“orderReceived”事件;
    3.“库存服务”订阅“orderReceived”事件。

    仅仅“已经识别好了服务”没有给出太多的意义。

    如果从业务服务角度来审视这个例子,着眼于构成该过程的业务事件,或许会别有天地。

    三个业务服务:销售库存装运


    • 销售,提交一个订单,通过所有的内部验证,引发“OrderTentativelyAccepted”事件。

    • 库存,订阅“OrderTentativelyAccepted”事件,检查是否每个订单项都满足。如果每项都有库存,就为该订单分配库存,发布“InventoryAllocatedToOrder”事件;否则启动一个长时间运行的过程,监控库存的改变,一旦“InventoryChanged”事件发生,满足该订单所需(会有一些优先选择的逻辑),就发布“InventoryAllocatedToOrder”事件。

    • 销售,订阅“InventoryAllocatedToOrder”事件,如果接收到该订单的所有相关事件,发布“OrderAccepted”事件。

    • 库存,订阅“OrderAccepted”事件,收到后生成装货清单,发布“PickListGenerated”事件。

    • 装运,订阅“PickListGenerated”事件,收到后开始配备车辆。


    还可以继续用SOA+EDA的方式处理诸如最优化装运、客服通知、支付等等。

    业务服务主要是发布事件、订阅其它服务的事件,干这个的,可不是老古董的经纪人?:)