拉近SOA和BPM的距离

作者 Boris Lublinsky 译者 胡键 发布于 2009年10月10日

领域

企业架构

主题

业务流程管理 ,

SOA

标签

Buzzwords ,

服务设计 ,

业务/IT整合

在其最新的博文——隔离你的SOA和BPM项目中，JP Morgenthal认为：

……将SOA和BPM搅和到一起充满了问题和失败。每个项目应该单独进行，而且在每个项目的确定目标中不要将对方列为产出之一。如果作为SOA所提供的合理化的一部分，碰巧有那么一些暴露的服务可以简化某条特定的流程，那绝对是一个大灌篮。然而，SOA和BPM每个有自己的成功标准以及障碍。把它们弄到一起，嗯，“沸腾的海洋”一词浮现到我的脑海中。

按照JP的说法，尽管：

在历史上，SOA和BPM几乎同时变得流行起来。SOA，主要由技术从业者领导，通过技术响应了BPM从业者对一个捕获和实现新设计、高效的跨组织业务流程框架的需要。

他的观点遭到了Zapthink的Jason Bloomberg的强烈反驳，Jason Bloomberg提倡一种以流程为中心的SOA观点，其要旨是构建松耦合的业务服务将支撑实现业务流程的元数据驱动的组合。这种方法的基础是流程同构模式（Process Isomorphism pattern），它可以帮助组织将它们的BPM和SOA成果结合在一起，提高它们的SOA项目和核心业务驱动之间的对齐。

……如果你建模一个业务流程，并以一个单独的方式建模实现这个流程的服务组合，结果这两个模型有相同的结构，那么它们就是同构的。

Jason解释说，流程分解可以被用作服务定义的一个基础，由此可以提供业务和IT努力之间的公共语言，但只有在SOA设计已经正确完成时才可以：

……流程子任务和支撑服务之间是一一对应的决不是件肯定的事，实际上，很多组织并没有按照这种对应关系设计它们的组合。很多时候，问题是SOA努力过于自底向上了，其中架构师基于现有能力指定服务。这种自底向上的方法通常导致服务并不匹配流程需求。同样，BPM努力通常过于自顶向下了，其中它们试图优化流程，但又没有考虑合适程度的细节供服务去实现流程步骤。只有采用迭代的方式，在每个迭代中结合自顶向下和自底向上的设计，组织才有可能获得流程同构。

在Jason看来，流程同构的本质优点是能够使用流程来表示服务组合，以及使用服务组合表示流程。

这种信息等价给我们提供了很多好处。例如，假如流程步骤直接对应服务，那么服务重用就要比步骤和服务之间的对应关系不清晰时更容易实现。服务重用可以被放在流程重叠的上下文中去讨论。如果两个流程共享一个子任务，那么实现这些流程的SOBA[Service-Oriented Business Applications，面向服务的业务应用]将共享这个支撑服务。此外，这个组合逻辑的元数据表示，如一个BPEL文件，将表示这个流程逻辑本身。要是没有流程同构，BPM团队得出的流程逻辑将不会直接对应于用于支撑组合的BPEL逻辑。这种脱节可以直接导致IT能力和业务需求的不对齐，同时限制了业务的敏捷性，因为流程和支撑组合之间缺乏清晰的关系会导致二者之间无意识的紧耦合。

可组合性是业务服务的主要特征。正是可组合性允许由相同的服务集合构建不同的业务解决方案。在构建可组合（业务对齐的服务）的过程中，一种最常见的方法就是以流程分解为基础去定义它们。另一方面，业务流程是将单个服务组合成业务解决方案的流行方法之一。由Jason Bloomberg提出的流程同构模式是形式化服务和流程之间对齐的重要工具，同时也是改善两者的重要工具。

查看英文原文：Bringing SOA and BPM Closer Together

译者 胡键 热心开源技术，《开源技术选型手册》作者，《SOA实践指南》译者。目前致力于Groovy/Grails的研究和推广。

• 更早的 >