不少状况下企业当中所提供的服务不是由一个分布式业务流程就能够完成的,整个服务的提供须要多个分布式流程有机的组合,因而BPM就应运而生了。要将现有的服务经过配置、编排(关于配置与编排的区别后面将说明)以知足具体的业务流程的目的就不得不借助于工做流的相关内容。毕竟各个服务之间的配合是为了提供一项合理的业务流程,这样的话就必需要设计流程,说白了就是各个服务谁先谁后的问题。分布式
从字面上理解BPM所要作的就是对整个业务流程进行管理。这其中包括不少方面,好比分析业务、实现业务功能、检测业务流程、创建相应的操做流程的工具等等。在真正开始动手以前一般要作的将业务分解成已有的底层服务能够处理的小模块。工具
流程分解后最底层的一个个活动就是服务。服务是业务流程的组成部分。要想让服务发挥做用就必须先考虑业务流程。从业务流程的观点来看,这些个服务是基本服务仍是组合服务可有可无,重要的是服务之星了必要的业务功能。然而流程服务是不一样的东西,由于流程服务的目的是体现整个业务流程(或某个部分)。spa
能够经过自顶向上的方法将一个问题、系统或流程不断分解为更小的内容,直到抵达服务的层次。或者采用自底向上的方式依靠底层的服务组合为更通用的块来创建业务流程。固然方法不是惟一的,只是提供一个参考而已。每种方法都有利弊。自底向上会产生没必要要的服务或者产生知足不了业务需求的服务。而自顶向下极可能遇到技术上的困难,或实现上复杂的服务。设计
例如:若是要实现一个新的业务流程。这个业务流程就是顶层咱们须要实现的流程,而既存的系统或者说服务就是这个业务流程的底层,毋庸置疑底层是负责提供一些用服务方式体现的基本业务功能。下面的工做就是采用自顶向下的方式把整个流程分解成为小块,把复杂的流程分解为下层服务能够处理的小模块。orm
通常具体到实现到流程上就是有关工做流的层面的事情了。再具体一点说的话就是须要使用BPEL将整个流程描述出来。BPEL是一个抽象的概念,具体根据不一样的流程引擎会有不一样的表现形式。好比使用JBPM的时候那么担当描述部分的就是JBPM自身的所提供的JPDL,当使用普元的BPS平台的时候担当描述部分的将是普元自带的描述流程的语言。不过实现的方式是相似的:将流程节点与现有的服务绑定,最终发布定义,启动流程,执行流程等等。核心思想都是将现有的服务利用起来经过编排或配置产生新的符合需求的新服务。经过业务流程建模工具或引擎能够用来从现有的服务中组合(“配置”)出新的组合服务或流程服务。blog
JBPM仅仅是BPM的实现方式之一,因此以前若是对JBPM有所了解的话将有助于理解及使用BPM。和JBPM相似,BPM的要作的就是将复杂的业务划分为一个个简单的服务,而后分清哪些是必需要人参与的那些是能够借助IT自动完成的,随后配置和编排。当流程定制完成那么就能够开始执行整个的业务了。固然这其中须要一个中央控制者来协调全部活动。工作流
经过组合现有的服务来设计更高层次的服务和流程这个方法叫作“配置”。在配置的过程当中一般有一个中央控制者协调流程的全部活动。整个的组合自己能够看成服务使用。io
另外一个方法是“编排”,没有谁服从于谁的概念,每一个部分负责一个或多个流程中的步骤,处于流程之中的时候很难了解整个流程的全貌。“编排”因为没有中央控制器的约束因此更容易伸缩,可是没有管理者的一大弊端就是出现问题不知道该如何去处理。class
BPM和SOA的关系中还有不少是须要考虑的细节,相似JBPM集成到单个系统中同样。须要考虑角色与组织和BPM的关系,须要涉及到权限相关的内容,或者说是系统前台和后台的问题。这些问题将在后面的文章中具体描述。后台