BPM和SOA的关系

　　自 20 世纪 80 年代末期以来，业务分析师始终在全力以赴地推广业务流程再造 （Business Process Reengineering）这一理念。之所以会出现这样一种趋势，主要是因为业务逻辑已经淹没在功能性的 IT 系统当中不见踪影，导致业务人员完全失去对它们的控制能力。

　　业务人员希望从业务驱动的角度来做事情，即采用自上而下的方式，在设计业务流程时先不与 IT 相关联，然后进一步深化到更细粒度的细节内容。直到最近，随着业务流程建模（Business Process Modeling，BPM）工具的出现，业务人员和业务分析师终于将他们的理论落到实处，他们将 BPM工具用做自己的“有力武器”，希望由此夺回对流程的控制权。

　　与此同时，在得到绝大多数 IT 人士支持的 SOA 阵营中，大家都坚信 SOA 才是真正能够使 IT 与业务变化保持一致的最佳途径。但SOA 并没有给予业务层面足够的重视，而是将工作重点过多地放在解决 IT 和集成挑战这类问题上。因此，绝大多数 SOA 工具和方法论仍旧只是停留在相对自下而上方法的水平。

　　由此可见，BPM和SOA分属不同的领域和不同层面，BPM在业务和管理层面，通过流程定义和建模，从而实现业务和管理的流程化。流程的实现过程不光需要IT，更需要人的参与，因此实现的成功与否和每个员工的配合程度有很大的关系。从这层意义上看，BPM和企业实施的ERP、OA、Portal等系统非常类似。

　　虽然BPM与OA有着本质的不同，但又有着千丝万缕的联系。

　　1. 经过BPM改造过的各业务系统仍然彼此相互独立地存在，SOA作为面向服务的IT架构方式可以不依赖这些业务系统，通过将各业务系统服务化（Service Enable）来消除“信息孤岛”，从而实现各业务系统之间的信息和业务逻辑的共享；

　　2. BPM通过组合单独业务和流程实现复杂的业务应用，而这些业务功能和流程同样可通过SOA使其服务化，把业务流程变成独立于应用程序及其运行平台的可复用组件；

　　3. 对于实现BPM来说，SOA虽然不是必需的，但由于BPM工具不能真正将变化的流程图与实际的IT系统有机地联系在一起，无法在足够深的层面确保底层的 IT 系统能够根据业务的变化随机应变；因此，目前能使BPM很好落地的技术还离不开SOA。
  
　　既然BPM和SOA有这么多联系，而且不管是自上而下方法的BPM，还是自下而上方法的SOA，都无法彻底解决企业面临的诸多问题。因此，我们很自然地寻找能取两者之长的解决方案。

　　设想一下，如同设计建筑物的体系结构一样，我们可以使用BPM工具来设计业务流程，然后将它分割成为相对较大的各部分（自上而下）。接下来，轮到 IT 通过使用砖块（自下而上）的方法来构建这些大块的组成部分。不过，问题在于单靠砖块可能无法修建出建筑物所需的形状，我们还需要用做粘合剂的“水泥”，由此将基础的砖块塑造成所需的形状。

　　BPEL —— BPM和SOA的粘合剂

　　业务流程执行语言（Business Process Execution Language for Web Services，BPEL）这一标准的方法将流程的范围从业务分析落实到技术实现。许多组织正从面向对象的业务流程管理范例转移到面向服务的方法，实际上，服务正在成为业务流程建模（BPM）的基本元素。同时，业务流程执行语言（BPEL）已经成为编排这些服务和管理业务流程的无缺陷执行的事实标准。通过BPEL，SOA可以对服务化的业务系统实现：无需人工参与、自动化的处理和调用，从而实现更灵活、更经济、更高效地管理业务流程。

　　由于BPEL的标准性、先进性和自动化的特点，使得BPEL成为了构建在BPM和IT系统之间的桥梁，使得BPM可以和SOA架构技术很好地融合，SOA中的服务编排（Service Orchestration）通过对BPEL的执行来实现BPM。

　　将BPM作为SOA的一部分进行部署，这意味着当一个业务流程连接到底层系统时，它连接到由企业服务总线所提供的代理服务，这样就隐藏了底层应用程序和数据库的复杂性。这具有以下优点。

　　1．将业务流程连接到系统的过程会更简单，因为IT可以公开更有用的接口，比如聚合的数据服务或使用标准协议，而不是专有协议的服务。这减少了实现流程所需的IT工作量，并允许流程人员将精力集中于流程，而不是粘合流程与底层系统所需的技术。

　　2． 对底层IT系统的更改不必影响流程所使用的接口。

　　3． 它在BPM工具之外提供了一个独立的控制和管理层，这允许IT人员更好地管理他们所拥有和维护的服务和资源。
  
　　IONA Artix Orchestration实现SOA和BPM的汇聚

　　1．技术中立解决方案

　　Artix Orchestration 与 Artix ESB 协同工作，可对任何传输方式、协议或消息格式的服务进行编制，创建合成服务。

 

　　2．测试和部署

　　流程模拟和调试：设置断点和调试流程；

　　故障处理：模拟来自外部服务的消息；

　　实时测试：在真实的 Web 服务环境中进行测试；

　　故障容错：驻留的有关流程和所有运行实例的信息允许在服务器宕机后，都能够恢复流程的状态；

　　集群：尖端的集群技术使 Artix Orchestration 具有极强的伸缩性，可满足要求最苛刻的企业应用要求。

　　3．BPEL 执行

　　多层验证：验证所部署的 BPEL 流程定义，并检验所有接收到的消息实例的格式；

　　流程持久性强: Artix Orchestration 在流程执行过程中的关键点获取，并保存状态信息，使得服务器宕机后恢复运行时，流程能够自动继续运行；

　　服务版本化：当部署新版本的流程时，Artix Orchestration 会自动将该新版本用于所有新的流程实例，同时继续将老版本用于未完成的实例。