Richard Veryard 在他新的一篇博文里，讨论了 SOA，BPM 和事件之间的关系。Richard 写到：
从 SOA 的早期，我们就提到将企业理解为一个服务的网络，但这显然不是唯一可能的立场。我们能不能把企业理解为一个事件的网络呢？
Ramesh Loganathan 也和他有着同样的观点，描述了他最近一次的探求 － 一个咨询公司构建一个治理与风险防范 (GRC) 解决方案的项目。从架构的角度上，该实现是基于如下的模式：
- 一个业务事件作为进行中的业务处理的一部分而发生
- 该事件包括了相关的业务数据
- 一系列的 GRC 检测与规则被实施
- 任何的违反都会被记录并且发会出警示
这一咨询公司更进了一步，将整个业务领域建模为一系列关键业务事件的集合，而这对于该领域的任何人都是能充分理解的。每个业务事件包括了一个对于相关数据的清晰定义。
目前为止，我们见证了将企业展现为一系列调用服务集合的业务流程的建模方式。在上面的快速视图中，企业是由一系列的业务事件来建模的…前者是定义业务流（流程）来构成企业业务处理的一个视图。而后者更像是交付一个企业实际情况的快照－作为“发生”在企业中的业务事件。两者都有着明确的目的并且清楚的对牵涉的数据进行了建模，但前者的方法，流动的是数据。而后者的方案中，所“产生”的数据会提交一个业务活动。
对于 Ramesh 的文章，Richard 这样评论到：
从策略的层次上，我们有必要理解外部可能事件与内部可能事件相互的关系。每个企业都有以特定方式对特定的外部事件类型进行响应的能力。要使得企业更灵活意味着使得企业能对更广阔的外部事件作出更为合适的响应，而不用增加不必要的复杂性，从系统思维的角度来说这叫做必要多样性。
所以如果我们将企业思考为一个事件的网络，这给了我们直接的方式去考虑战略性业务改进。
这样的讨论已屡见不鲜。比如，回顾 2006 年， Jack van Hoof 就写过：
…SOA 的这一同步的指挥与控制天性是一种应用组件紧耦合的方式…从技术的领域 SOA 或许是松耦合的，利用了共通的 web 服务技术，但在功能领域肯定不是这样，在这一领域 SOA 与‘调用’外部 (可重用的) 服务与消除数据冗余联系起来…与 SOA 相对的是，EDA 提供了一种松耦合的方式。 EDA 不是一种同步的指挥与控制的模式类型，相反却是：一种异步的发布与订阅模式类型。发布者完全不知道订阅者，反之亦然；组件仅只共享消息的语义，从而达到了松耦合。
出于一些原因，人们仍然认为 SOA/BPM 与 EDA 是两种相对立的方案。这种误解很大程度上是由于 Web 服务传统的 RPC 结构而造成的。随着 SOA 实现的进步以及不同消息交换模式的显现，包括单向消息，SOA 与 EDA 之间的差异开始逐渐模糊。用 Bobby Wolf 的话说：
…任何方式，你都是在实现服务，问题在于服务被调用的方式。它们是以一种非常直接的 SOA 方式由消费者直接来调用提供者呢？还是一种更为抽象和间接的风格，由事件促发处理器去调用服务？
事件和业务流程都是企业业务模型的重要部分。一个优化的 SOA 实现可以被定义为一系列的企业业务流程来编配服务的执行。这些流程可以由其它流程直接调用或者响应内部 / 外部的企业事件。流程同样会发出事件，可用于调用其它的企业流程或者由业务活动监控器来评测企业运转的效能。
暂无签名
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论