最近几个月来,关于业务流程管理(bpm)和面向服务架构(soa)之间关系的讨论热闹非凡。二者也是多年来的热门话题,但是关于它们的讨论通常都出现在互不相关的论坛上,讨论它们的人通常也属于不同的圈子。不过现在这种情况正在改变,因为这两个概念以及相关技术的使用者和提供者正日渐将二者结合起来看待。
为了澄清这些误解,我认为有必要阐明bpm与soa的不同本质:soa是一种架构方法;bpm则是一组协调活动。
如果部署一个不使用soa的bpm套件,则可以获得快速创建、执行和监控/管理业务流程的能力。业务流程的模型可以由业务分析人员创建,但是其完整实现则需要与底层it系统的集成(以及定义用户如何与该流程交互,但是现在我们暂不考虑)。bpm套件(如bea的aqualogic bpm suite)支持使用各种不同的技术(面向服务的或不是面向服务的)对应用程序和数据库进行轻松访问。实现由代码和来自于并依赖于底层系统接口的元数据组成,因此,对底层数据库和应用程序的任何更改都将导致对业务流程的更改。
但是,如果bpm套件由一个小组部署,并消费来自另一个小组的系统的服务,那么协调和管理每个小组中的更改的任务很快就会变得非常困难。这是soa要解决的典型问题,因此,soa可以应用于bpm套件的部署,就像应用于其它地方一样。
* 将业务流程连接到系统的过程会更简单,因为it可以公开更有用的接口,比如聚合的数据服务或使用标准协议而不是专有协议的服务。这减少了实现流程所需的it工作量,并允许流程人员将精力集中于流程,而不是粘合流程与底层系统所需的技术。
* 它在bpm套件之外提供了一个独立的控制和管理层。这允许it小组更好地管理他们所拥有和维护的服务的策略和资源。
无疑,这些优点只有在it基础架构足够复杂,并且/或者bpm项目达到一定的范围和规模时才能显现出来。因此,在很多情况下,应该首先开发出bpm,而将soa组件留待以后考虑。