ligang1111

上接系列一..

        因为SOA是一种分布式架构业务与技术的方式方法，所以必须要有一个强有力的自治策略来管理之。的确，将SOA引入一个企业或组织经常是从弱管理（自治）往强管理（自治）的一根导火索，促进governance的发展。

        笔者的思路打算是从SOA策略的自治、SOA的组织以及对SOA自治的思索开始向下延展。坚决贯彻毛主席的方针，先从战略上谈，再谈具体的战术，最后对展开的进行反思。我再这里也只是给出一个小的思考模式，希望大家沿着这个思路也能开拓出自己的认知之路。

 我们再考虑SOA自治时，总是趋向于使用自顶而下的方法。我们正是由一个策略和业务的关注点出发，沿着自己的路一路走下去，从而形成一个越来越适合日常工作的SOA自治设计与实现模式集。许多开始使用了SOA的组织将会发现他们开始的时候并未为使用SOA而需要的策略跳跃做好准备，而是首先去建立起更技术化的专门技术。换句话说，这也是为什么SOA总是在IT部门开始的原因，IT部门里在并未为提升价值链做好准备，也未考虑一个全盘的、聚焦业务的基于SOA的改革措施，而去创建并培育SOA专门技术。大多数情况下，SOA自治的实施者应该正视SOA策略的自治，然后才去做组织SOA、反思SOA自治的工作。事实上，应该在启动阶段基于服务开发的生命周期采取分阶段的方略，最终完成向一个敏捷性企业的转变。

        1）SOA策略的自治

        SOA是一个大工程，长远运作的工程，要有明确的方略，既然前面提到分阶段的方略，则笔者大致将其分为3个阶段：1、服务生命周期阶段；2、SOA项目生命周期阶段；3、企业向面向服务企业转变的生命周期阶段。这三个阶段管理的范围越来越扩大化。第一阶段主要在自治服务的实现期间吸取经验，第二阶段则可以有效地管理IT项目，且这些IT项目可以有效地创建并复用服务，而第三阶段，对规划以及策略有了自治机制以及控制，顺利转变为面向服务的企业。

         上面也看到了，最大化成果的SOA自治必须能够控制并帮助提升企业策略从而创建面向服务的企业。这就要求IT技术组与业务组匹配并良好地运作。值得一提的是，许多IT组织过去习惯于在他们各自的“竖井”里工作，要么是没技巧，要么是对业务如何运作莫不关心，从而使得业务需求滞后于项目需求。SOA自治的责任就是要管理业务敏捷度，从而改变现状。这个转变要求企业架构组于业务组密切合作，设置必要的控制机制，趋使向业务敏捷性方向趋近。没有一个方向性的规划，一个企业是不可能成功转变为“面向服务的企业”的。

         对SOA策略的思索，一般人的思维也能想到IT敏捷性和业务敏捷性。这些无可厚非是最重要的目标，但似乎少了些内容。这么来看，无疑还是将IT与Bussiness剥离来看，应该关注“IT与业务的融合”。同时读者也思索下，当然要实现SOA的策略自治，根基是什么？除了上述所提到的，自然就是对IT自治的考虑了。

暂时想到这么多，系列文章未完，待续…………

最近,一段时间都忙于学习,已经很久没上blog写文章了，而查看SOAer里面的一个帖子,发现有同志对我写的SOA governance比较感兴趣,所以也就产生了写一系列对SOA governance理解的文章.这些文章会作为一个系列,是笔者本人的理解,希望对大家有所帮助.

SOA governance最近在serverside网站上也是时常看到相关的内容,可见其Hot的程度了.把SOA摆在现实中看来,更觉得它是一个体系,包容万千,想一个绚丽的万花筒,从不同的角度看出不同的内容,而围绕着它也相应产生出了一系列相关的术语.研究SOA这么久,大家都有一个共识:服务的设计粒度难以把握.这块对于设计者来说可谓是"仁者见仁,智者见智".虽然SCA规范给出了基础设施技术上的规范,但仍然让"年轻"的SOAer们有足够的勇气迈入SOA的实验场.现实是现实,理想是理想,如果还是不跟上SOA的潮流,中国将在新的一轮"软件革命"中陨落,让我们踏上SOA governance的学习历程吧.

既然研究和学习的对象是SOA governance,那么就从什么是governance开始吧.governance其实就是有目的地运用策略、计划、过程和组织机构来做决策并控制一个实体（这里的实体可以是企业、政府等，任何可以运营的实体）从而达到业务目标。SOA governance则关注于需要创建或已经存在的SOA实现中的服务。我们知道，采纳SOA的主要目的就是要实现业务和IT的敏捷性。SOA是一种利用企业架构实现公司业务战略的可重用服务方法。那么，要创建一个环境，以便里面的纵多的可复用服务以及好处可以得以实现，必须有经过慎重考量、明文给出、可实现且可以维护的管理规划。可能更多的人会提到SOA的好处，而在这里我想提出的是，SOA的好处是其指导意义，它的真正有效的现实价值在于它可以创建一个“面向服务的企业”。“面向服务的企业”则是围绕着以更水平的模式连接业务流程。

一般做规划可能产生两种极端，一类是过于全局化，设置重重看似完美、其实繁冗的官僚机构的控制以及得出堆积如山的纸质文件，最近因为陷入管理的泥潭无法自拔，项目被迫取消；而另一类则为赶进度或其他原因，每个业务单元更多从自身的需求出发，无视对全局的影响，最终导致各个业务系统间的数据和业务冗余，而后期进入无休止的集成期。

我们不禁反思，我们需要的是什么？答案很简单，我们需要的不过是一个“面向服务的企业”。它应该走中庸路线，某些控制是必须的，而另一些则无须繁冗的横加管涉，便于增值好的服务和敏捷性。管理模型趋向于通过普遍的自治策略、规划、程序和规则来实现多组织间的联邦制。其实，这不禁让我们想到英国的国情了，英国的历史其实就是一个入侵与被入侵、统治与被统治的历史。国力强盛的英国曾经被称做“日不落帝国”，它有中央集权时期，后来终于因为哪里有压迫，哪里就有反抗，废除了。现在的英国就称为“英联邦”，这种松散但又有组织的制度，维持着这个国家。这也是中庸的结果。看来中国的圣人们就是牛呀。把话题拉回来，刚才说到管理模型的联邦制。借助这种模式，可以分别通过两种方式催生出一个“面向服务的企业”，“自上而下”，“自下而上”。

SOA可以看做是拥抱变化的催化剂，而不能看做是解决变化的银弹，如果使用适当，会融合业务和IT技术的优势。现在有很多公司申明有一系列基础设施技术，其实最多就是一个消息中间件而已。升级一个组织并引入SOA技术架构的能力是相对容易的，如使用ESB组织服务,XML实现异构系统消息交换等等并不难。虽然，这有价值，但只是SOA之旅万里长征的第一步，仅仅升级技术并不能带来什么现实的益处。

未完待续。。。。。。

初识jBPM

作者 ：李刚  [ ligang1111 ]

Email ：ligang1111@sohu.com

Blog ：http://gocom.primeton.com/blog_19935.htm

MSN ：ligang1111@hotmail.com

QQ ： 45449899

一、为什么需要流程、流程管理

       有很多人搞了多年的工作流，突然有人问他一个简单的问题“为什么需要流程和流程管理？”，他也许会愣住。对呀，这个问题其实会难倒很多搞技术的人，他们只知道埋头苦干，甚至一头栽进去不能自拔，很少有时间思考这个问题。现在笔者讲讲自己对流程以及流程管理的必要性，毕竟它是我们后面要讲的内容的前提。如果连目标都未认清楚，怎能充分发挥个人的主观能动性将工作流技术学好呢！当然，这个问题我也思考良久，个人愚见仅供参考。综观国内外管理学的发展历程，从著名的汽车组装流水线“福特模式”到如今的“科技以人为本”，管理学家在做的同一件事就是如何让企业运作得更好，小企业如何做大，大企业要如何规避因为组织庞大而造成的管理滞后性，做到“大象也能跳舞”。管理学上认为一个人最多只能同时管理7件事情。基于这个原理，各大企业、政府机构开始划分出等级森严的科层制。以财政厅为例子，机构组织结构如下：

图一 组织图

       众所周知，这种科制层等级众多，审批要层层上报，任务要层层下达，行事效率低下。同时，处于各层的人员更关注的是与自己直接上下级之间的联系，很少出现跨层的联系，必然导致各层人员看到的是业务的局部，难以把握业务的全局。所以，只有组织扁平化、成立专项小组才能提高企业、政府的行事效率，从而提高客户服务的质量。要站在业务的全局，以客户为中心，必然将流程以及流程管理推到了前台。这也是为什么近年来“流程管理”如此火暴的原因。

二、从工作流管理系统谈起

“工作流管理系统是什么”这个问题在google上可以search出许多不同的答案，在此笔者就不再“重复造轮”，而只是想从另一个侧面谈谈自己对工作流管理系统的看法。谈到工作流管理系统，必然涉及到工作流，其英文为”workflow”，字面的意思来说就是工作流动起来了，就成了工作流。而工作流管理系统自然就是管理工作流的专门的系统。

正如jBPM项目的leader Tom Baeyens在其《工作流现状》的文章中提到的，“如果说数据库系统像受人尊敬的智者在讲述条理清晰的故事，那么工作流就像一群乳臭未干的小子在大谈各自的‘哲理’”，确实如此，各大规范组织都在推销自己的标准，但并没有哪一大标准被广泛的实际采用，整个工作流规范界到目前为止处于混沌的状态（注：具体可以参考本人写的文章《浅谈工作流规范》）。品种繁多的工作流规范足以打败刚刚涉足工作流学习初学者的信心。然而，在规范标准如此百家争鸣的“春秋战国”时期，却存在一个共同的“道”，那就是工作流管理系统负责业务流程的定义、创建、执行、监控等功能，这一说法毋庸质疑。众多的工作流相关的规范主要争夺的就是业务流程建模定义这块主战场。看来只能如荷兰著名工作流领域学者W. van der Aalst所展望的，工作流管理系统最终应该像数据库管理系统一样，以坚实严谨的数学逻辑理论为基础，形成一个统一的国际标准，我想这样应该是工作流领域发展曲线的最好归宿了（注：数据库技术以，而工作流可以以Petri Net为数学理论基础，数据库技术有统一的SQL92标准，工作流技术也应该有一个统一的标准）。

三、jBPM脱颖而出的理由

如今开源产品如此之多，其中不乏性能优越的工作流产品，为什么会选出jBPM呢？我想从以下几个方面来阐述理由：

1、  jBPM的理论基础GOP

jBPM的leader Tom Baeyens在业务流程建模语言方面有自己独特的见解，其信奉多种流程语言，相信不同的环境或目标需要不同的特定的流程语言。而面向图编程（GOP）则是一种新的实现技术，且是所有基于图的流程语言的基础。GOP的好处就在于它是所有流程语言的基础性技术。如下图

图二   基于图语言的位置

当前的软件开发依赖于越来越多的领域相关语言（Domain Specific Languages）。一个典型的Java开发者就会用到一些领域相关语言。各种框架所需要的XML配置文件内容就可以看做为领域相关语言。工作流、BPM、Pageflow等基于有向图的执行。而hibernate mapping文件, ioc-configuration等则不然。面向图编程（GOP）是所有基于图执行的领域相关语言的基础。同时，jBPM以UML中Activity Diagram为图形元素为基础，易用性自然不用说，大大减少业务人员与软件开发者之间的沟通鸿沟。

2、  jBPM本身的jPDL设计的合理性

如果用过jBPM的流程建模eclipse插件的开发者都会被其简洁而又强大的jPDL语言所折服。jBPM对流程的建模，把两大主要开发角色（业务分析者 Bussiness Analysist和软件开发者Software developer）的职能区分清晰，但又支持他们之间的合作开发不受影响。在jBPM的建模工具中，最终建模结果中可视化的元素都是由业务分析者所创建的，而隐藏的各种事件（event）以及相应的Action都是由软件开发者构建。业务分析者只要关注各种节点（node）、迁移（transition）以及泳道（swimlane）等元素的创建，同时软件开发者可以在不改变业务分析者所创建的元素的前提下加入相应的编码功能。这种合作与将网站开发模式中的网页美工与程序员的工作分离同时又可支持完美合作开发有异曲同工之妙。

3、  jBPM的可扩展性

jBPM虽然是以UML中的Activity Diagram的建模元素为基础，但其支持根据需求扩展开发其它种类的图形元素，所以其可扩展性是极强的。而其它建模语言，一般以某一规范为基础，其元素是封闭的，并不开放。同时荷兰工作流领域学者W. van der Aalst给出的21种复杂的工作流模式足以认证工作流建模的复杂性，必须考虑其建模元素的可扩展性，而不应该仅仅绑死在与规范相关的既有建模元素上而无法扩展。

有图版请点下列图标下载