在其最新的博文——隔离你的 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 提出的流程同构模式是形式化服务和流程之间对齐的重要工具，同时也是改善两者的重要工具。
暂无签名
腾讯大规模云原生技术实践案例集
本案例集详细阐释了 QQ、腾讯会议、和平精英、小红书、斗鱼、微盟等十多个亿级用户产品背后的大规模云原生...
评论