SOA浪潮下的BPM

作者：

欢迎访问e展厅 展厅 3 CIO信息化管理展厅 电子商务/企业门户, IT运维管理, 制造执行系统MES, 流程管理BPR/BPM, SOA/SaaS/云计算, ... SOA出生的年代，正是BPM发展的第一个高峰，当时论坛上到处都是有关BPM的讨论，甚至连学术期刊也充斥着BPM的文章；前几年是SOA默默发展期，BPM反倒销声匿迹了，关于SOA和BPM的讨论也都出现在互不相关的论坛上，讨论它们的人通常也属于不同的圈子；但是现在，SOA的茁壮成长带动了BPM重振雄风，相关技术的使用者和提供者正日渐将二者结合起来。 SOA出生的年代，正是BPM发展的第一个高峰，当时论坛上到处都是有关BPM的讨论，甚至连学术期刊也充斥着BPM的文章；前几年是SOA默默发展期，BPM反倒销声匿迹了，关于SOA和BPM的讨论也都出现在互不相关的论坛上，讨论它们的人通常也属于不同的圈子；但是现在，SOA的茁壮成长带动了BPM重振雄风，相关技术的使用者和提供者正日渐将二者结合起来。 在SOA和BPM联合发展的浪潮下，我们首先要明确的是，BPM与SOA的本质是截然不同的:SOA是一种架构方法;BPM则是一组流程协调管理理念。没有SOA之前，BPM产品已经出现并成功应用，BPM的主要应用场合有如下几点： ·业务流程自动化。这是BPA的概念，BPA按照业务需求，自动化流程，这是现在工作流技术还在继续做的事情。 ·整合应用系统，实现异构系统之间无缝交流。这涉及到EAI的概念，不过实现方法和老的EAI技术是完全不同的。 ·企业流程建模分析。这个是BPM的核心，在详细了解企业流程划分之后，用全局的视角，对一堆的流程进行梳理，并给出企业流程全局图。 ·监控企业活动，实现企业流程持续改进。这是BAM的功能，BAM需要用前面的企业流程全局图，分析企业流程效果和效率，提供优化方向，实现企业级的流程管理。 ·在上面描述的BPM的四大应用场合中，每个都和SOA有千丝万缕的关系。从技术层面看，SOA和BPM结合有多种方法,SCA的WS-BPEL客户端和实现模型规范说明了WS-BPEL2.0怎么样和SCA结合在一起使用，具体方法有如下三种： BPEL流程作为构件的实现 在SCA中，可以把一个有效的BPEL流程作为一个构件的实现。对于一个构件的定义来说，可以使用子元素来表示本构件是用一个BPEL流程来实现的。子元素的process属性指明了这个可执行的BPEL流程的目标名称。 这个方法是从BPEL开始的：我们先定义好一个BPEL流程，然后把它纳入到SCA容器中去。示例图如下所示： BPEL流程定义一个构件的类型 当一个构件使用了一个BPEL流程定义的构件实现的时候，BPEL流程定义也决定了这个构件的类型。如果一个构件类型只使用WSDL接口来定义服务和引用，我们可以用BPEL来得到这样的构件类型。这个可以通过“反射”机制来实现： BPEL中的合作伙伴链接对应于SCA中的服务和引用。在SCA中，服务和引用的区别是在一次会话中，哪一方第一次发起通信；而在BPEL中，合作伙伴链接是不关心谁是会话的发起者的。所以，为了在BPEL流程和构件类型中做一个映射，必须找到一个办法鉴别出会话的发起人。在BPEL中，一个合作伙伴链接要想发起一个会话有如 下可能：在活动中接收一个消息；在 活动的子元素中接收一个消息；在一个事件处理器的子元素中接收一个消息。在上面情况下，应该把合作伙伴链接映射为SCA中的服务；反之则映射为SCA中的引用。 如果合作伙伴链接映射为SCA中的服务，那么服务的类型就对应于BPEL中的合作伙伴链接类型。合作伙伴链接中的指定了服务的WSDL的portType；如果有 ，则它对应于服务的回调接口的WSDL的portType。如果合作伙伴链接映射为SCA中的引用，就和服务的情况相反。component的service是可以有WSDL PortType接口的。 为BPEL加入SCA扩展 我们可以在BPEL中加入SCA扩展，从而产生SCA的构件类型定义，并利用它来完成SOA的装配。例如，一个BPEL的变量声明可以包含一个SCA的扩展： 从上面的讨论看出，BPM和SOA的结合的方法可以帮助BPM实现更多的功能。当前日益复杂的业务流程充满更深层的跨系统交互以及更丰富的用户协作，因而需要更强大的业务流程管理能力，这也正是SOA对BPM产品的引人注目的业务优势。在SOA环境下的BPM与非SOA环境下的旧式工作流相比有如下的不同： (一) 跨组织的业务流程描述语言和工具。在工作流系统上马早期，经常会发现同一个企业内部不同组织单元、部门的流程采用不同的描述方法，比如A/B/C/F四个部门的账目管理系统采用某种工作流系统，而A/B/D/E四个部门的订单和销售管理系统又采用另外一种工作流系统。这种情况在大型企业集团内部尤为明显，影响了各业务单元的业务协同和业务最佳实践的提炼和推广。而BPM致力于跨组织的业务流程描述语言和工具，避免了企业各部门进行业务流程交流和沟通时各说各话的情况。 (二)统一的流程架构。企业内部从单一管理主题出发进行设计的工作流，通常在企业中缺乏对业务运营活动的总体考虑，局限于本部门或者本业务的业务需求，各部门和各管理专题之间的流程无法衔接，信息的共享和传递困难，存在大量流程断点。而BPM在流程之间进行衔接、协调，避免了流程孤岛的产生；BPM的目标是形成端到端的流程体系，提高整个业务流程运行的效率、成本、质量，在激烈的市场竞争环境下，满足客户的需求。 (三)无“甲方优势”现象。如果用一般的工作流系统做接口，我们发现一个有趣的现象，就是服务提供方的甲方优势现象。通常，一个工作流系统要和另外一个已经存在的系统做接口，工作流系统是有求于已经存在的系统，也就是已经存在的系统有“甲方优势”。这样，工作流系统就必须按照已经存在的系统的技术规格来实现，离“跨组织的业务流程描述语言和工具”就越来越远了，更不用谈“跨企业的业务流程管理”。而BPM是在“工作流系统”和“已经存在的系统”之间建立了一个公平的约定，不存在“甲方优势”。 (四)流程的持续改进。由于工作流系统的存在，相关的业务人员通常已经忽略其内嵌 的业务流程，业务部门对信息系统内嵌的流程缺乏直观认识和关注，工作流系统的改进非常的复杂，更不要谈什么持续改进了。但是BPM帮助业务人员密切关注信息系统内嵌流程与其它业务流程衔接关系，随着业务内外部环境的变化，及时进行流程的调整；这种情况下，流程的持续改进，成为提高企业整体流程运行效率的最主要因素。 (五)BPM的SOA本质。SOA是创建更灵活的企业基础架构的架构方法，而BPM是一套协调的业务流程活动。SOA使用户可以轻松完成将业务流程连接到基础系统的任务，从而节省时间和IT资源。与之相比，将流程链接到传统的应用通常要依赖大量不同的专有技术。而且，在采用BPM的同时转向SOA可以促进SOA组件的再利用，从而最大程度地降低业务流程本身的复杂性。 (六)BPM一定是企业级的。要实施BPM，一定要树立流程战略、 流程设计、流程实施和流程监控的循环管理理念:从企业的发展战略出发制定流程的战略，将战略指标分解为流程的目标体系，通过流程实现战略的落地;根据流程战略进行业务流程的梳理、设计和优化;通过组织结构和信息系统的调整来实施业务流程;通过流程合规管理和流程绩效监控，对流程 执行情况进行监控，根据结果调整业务流程设计。 BPM已经和SOA联合为相映成辉的状态，对于一个企业业务流程的高级涉众，应该从战略高度针对企业流程进行梳理分析规划，同时在战术层面需要物色合适的企业系统架构师，以便正确地实施BPM和SOA的混合分步部署。在BPM流程分析基础上，持续改进，识别出最有价值的业务流程模型去实施企业级SOA；在企业级SOA基础上，逐步积累，更加深入广泛地推广BPM应用。而合理采用融合SOA和BPM的软件产品，比如普元的EOS平台，会带来事半功倍的效果。 (end)

文章内容仅供参考 (投稿) (如果您是本文作者，请点击此处) (11/20/2007)