【摘 要】针对自动工作流系统使用传统SOA建模工具存在的效率低下等问题，提出了一种基于Petri网思想进行SOA架构应用的方法，并从使用Petri建模进行服务识别和使用Petri中间件进行流程管理这2个方面详细阐述了SOA架构应用的具体内容，为此类工作流系统进行SOA架构应用改造提供了参考。
【关键词】面向服务的体系结构 服务识别 Petri 工作流 中间件
[Abstract] In view of the low efficiency of automatic workflow system using traditional SOA modeling tools， a SOA architecture application method based on Petri network was presented in this paper. From two aspects， including service identification by means of Petri modeling and process management by means of Petri middleware， SOA architecture application is expounded， which provides useful reference to the reformation of SOA architecture application in these workflow systems.
[Key words]SOA service identification Petri workflow middleware
1 引言
SOA（Service-Oriented Architecture，面向服务的体系结构）是构造分布式计算的应用程序的方法，它将应用程序功能作为服务发送给最终用户或者其他服务，通常认为SOA是一种技术架构或者架构风格。基于这种架构，业务流程或业务的变化可以通过服务编排调整快速适应，实现业务的敏捷性。随着SOA的快速发展，基于SOA架构的中间件产品也成为网络化商业系统的主要设计思路。
由于企业的业务现状、远景需求及IT系统现状等的差异，SOA架构存在不同的构建思路，但一般来说，SOA的开发、维护和使用的基本原则可以归纳为：
（1）可重复使用，模组性，可组合性，构件化以及具有交互操作性；
（2）服务的识别和分类，提供和发布，监控和跟踪；
（3）符合开放标准（通用的或行业的）。
从基本原则可以看出，SOA架构的重点是要找到可重用的服务，同时这些服务满足离散、自治和无状态等基本条件；其次是服务本身可以组合和编排，以满足流程整合的需要。
2 SOA服务识别的难点
SOA参考架构可总结为业务能力组件化及组件能力的服务化。服务识别的过程是通过自顶向下的分析，可以将流程的功能点逐层细分，直到最后一级的原子能力，再通过原子能力按照SOA架构的思想自底向上逐层组装，分析出可以重用的能力，重新编排为服务。
服务识别是SOA架构实施的难点之一。因为当实施SOA架构时，业务系统一般已经具有一定规模，业务人员以及技术人员对业务系统的系统划分、模块划分已经有一定约定俗成的概念，容易先入为主。无论是往下的逐层细分，还是向上的逐层组装，都需要参考SOA架构做出思维上的改变。
因此，需要引入一些成型的流程建模工具来引导这个过程。目前SOA的服务识别有很多成型工具和模式，比如BPM（Business Process Management，业务流程管理）和BPEL（Business Process Execution Language，业务流程执行语言），但是这些工具和模式也并非适合所有的系统。一方面，建模工具本质上是用于辅助设计，这些企业级别的工具和模式覆盖面过于大，复杂程度高，分析的周期也较长，对于自动工作流较多的系统，辅助设计过程中往往需要较为简单轻巧的工具；另一方面，纯设计层次的建模与有工作流引擎参与的建模实际是存在不同的，完成服务识别后，再转化为可以为工作流引擎使用的服务也比较困难。
3 Petri网思想在SOA架构中的应用
SOA架构设计本身是一种思维改变的过程，已经成型的系统会存在很多固定的模块划分和功能划分，造成SOA实施困难，需要采用一些建模工具来辅助思维。使用建模工具进行建模时，应该覆盖2个要点：首先，建模工具是辅助设计的过程，选择合适的建模工具是必要的；其次，纯设计方式流程建模和SOA的建模方式是有所区别的。建模工具既要符合SOA的设计模式，也要贴近目前的业务实际，更要让建模的结果在SOA工作流引擎中能够无缝衔接。
Petri网是分布式系统的建模和分析工具，可以清晰地描述系统中的进程和功能模块的顺序[1]。研究领域趋向认为Petri网是所有流程定义语言之母，理论上所有的流程建模工具使用的方法都可以用Petri网的概念来表达。由于Petri网相对BPM和BPEL这些工具更为简单及灵便，因此用于描述流程上相对简单的自动工作流系统，则更具有明显的优势。
相对于BPM和BPEL这些工具，Petri建模的优势在于：一方面，建模元素比较简单，更加注重流程本身；另一方面，代码逻辑和Petri图能够一一对应，可以更加有效地利用原有的应用实现而不用担心全部推倒重来。
3.1 Petri建模介绍
Petri网是对离散并行系统的数学表示[2]，作为一种能够用来有效地分析系统的并发、异步和不确定行为[3]，并能有效描述系统静态和动态的图形化模型，Petri网被广泛应用于生产制造领域、计算机领域、过程控制和专家系统等领域。Petri网既有严格的数学表述方式，也有直观的图形表达方式。 Petri网是过程模型，由库所和变迁两类节点、有向弧以及令牌等元素组成。
（1）Petri网的元素定义
◆库所（Place）：圆形节点；
◆变迁（Transition）：方形节点；
◆有向弧（Arc）：库所和变迁之间的有向弧；
◆令牌（Token）：库所中的动态对象，可以从一个库所移动到另一个库所。
（2）Petri网的规则
◆有向弧是有方向的；
◆两个库所或变迁之间不允许有弧；
◆库所可以拥有任意数量的令牌。
如果一个变迁的每个输入库所（input place）都拥有令牌，该变迁即为被允许（enable）。一个变迁被允许时，变迁将发生（fire），输入库所（input place）的令牌被消耗，同时为输出库所（output place）产生令牌。
3.2 使用Petri建模进行服务识别
Petri网模型本身具有子网的概念，可以将变迁逐层下转到最底层的原子变迁，也可以将所有Petri子网模型合成一个更大的Petri网模型，用来描述整个系统的动态行为模型[4]，这与SOA服务识别的过程是高度契合的。
（1）子网逐层向下分解
用Petri建模的思想，可以通过“映射”的思想和方法，按目前的详细设计或者代码逻辑将应用模块用Petri图画出。Petri网中的库所元素映射为程序数据，Petri网中的变迁元素映射为程序函数和方法，系统模型中的各对象子网映射为程序中的类[5]。对主要以数据驱动的自动工作流的程序，按照程序的状态，Petri网的建模一般如图1所示：
图1 数据处理程序状态的建模
图2 数据处理子网的建模
上图的每个变迁也可以继续理解成子网的概念，按照代码逻辑继续往下建模，直到变迁不可再继续细分，这正符合了SOA逐层细分的理念。
（2）变迁组装成服务
SOA服务要求具备可重用性，需要将可重用的组件能力开放为服务，这个可以映射为Petri可重用的子网。将每个变迁细化到“原子”级别的变迁后，首先需要对变迁进行分析，通过对变迁的输入输出令牌进行抽象，将能抽象成相同输入输出令牌的变迁视为一种服务，则这个变迁具备了SOA要求的可重用性。
重用度最高的同时也最容易分析的是系统底层的原子能力，如操作系统资源、数据库操作的服务，这些服务目前已经有成型的模式，此处不再赘述，主要难点在于业务级别的服务分析。对于业务级别的服务分析，重点应关注应用处理数据的状态。
图1示意了进程级别程序状态的建模，如果将数据状态的部分抽离出来，进一步考虑这个数据在整个应用中的状态，可以形成如图3所示的处理过程（忽略了异常处理）：
图3 Petri针对系统中数据状态的建模
图4是进程级别数据状态的建模，结合前文第一步子网逐层往下分解的结果，可以将整个数据处理的过程形成一张大的Petri网模型，然后对这张Petri网模型进行分析，就可以进行服务的识别。
图4 服务按照服务状态和数据状态的建模
服务识别的过程可以按照以下步骤进行：
◆可重用性分析：横向与其他数据的处理逻辑比较，通过Key-Value的方式对变迁输入输出的抽象，整理出可以重用的变迁，也就是可以转化为服务的变迁。
◆服务粒度设计：服务是需要通过工作流引擎来进行流程控制的，变迁的粒度不应该太细。如果太细，可能会影响整个数据处理的性能，需要在流程监控与性能之间做权衡的考虑。
◆数据流程监控分析：有些变迁虽然不可重用，但由于需要对数据的流程进行监控，需要将它转化为服务。
◆服务的校验：完成服务的识别后，可以通过Petri建模对服务进行建模。一方面，需要对模型本身进行校验，Petri可以提供形式化方法，以数学为理论基础，为系统设计的正确性、安全性提供了一种有效的验证手段[6]；另一方面，需要考虑是否满足工作流引擎的需要，对于自动工作流的系统，服务的Petri模型一定是同时关注服务状态和数据状态的（见图4），如果不满足这个条件，那么服务是无法被工作流引擎所调度的。
使用Petri建模将变迁组装成服务，可以很好地贯彻SOA组件能力开放为服务能力的理念，可重用的组件能力映射为可重用的子网，服务接口的抽象可以映射为输入令牌和输出令牌的抽象。由于Petri网建模的本质就是事件驱动的概念，因此能够符合工作流中间件的逻辑，也便于工作流中间件对服务控制和监控。
3.3 使用Petri中间件进行流程管理
使用Petri的另外一个优势就是可以采用引入中间件的概念，构建内部的流程管理平台。Petri的令牌驱动模式能够很好地抽象自动流程较多的系统。对于流程管理，其核心是判断流程中的每个环节下一步该做什么，这点可以通过Petri图令牌的当前位置来体现，如果某变迁的上游库所都有令牌，则接收上游库所的令牌，触发变迁点火，再由变迁将下游所有库所的令牌属性赋值。
按照上述思路可以构建一个Petri中间件，在界面上进行Petri建模，并定义好变迁的输入输出。应用（HLA）使用中间件提供的API进行研发。实际运行时，应用通过中间件的Agent与Master进行交互，完成流程控制与流程监控的目的，如图5所示：
图5 Petriware中间件体系架构
（1）Petri中间件的功能架构
由于Petri本身就是使用事件驱动的概念来进行建模，所以在SOA服务用Petri完成建模后，直接可以为Petri中间件服务，不需要考虑设计层面的服务与有中间件参与的服务的转变。Petri的建模图形也完全可以表达应用逻辑，通过应用与中间件的交互，做到对于流程和应用的监控。
