近年来，基于流程引擎技术构建的应用系统越来越受到客户的追捧和认可，能否支持 “流程可定制、可更改、可运行”也逐渐成为客户衡量一个应用系统主要标准之一。

又比如目前被大家广泛提及的SOA（面向服务架构），为客户解决“业务敏捷性问题”提供了新的指导思想和方法。但是SOA的整体构架必须依赖于三方面技术的支撑：解决互通互联的技术与标准，比如我们所熟知的消息总线技术、JBI、SCA等等；解决流程管理的技术与标准，比如BPM，Workflow等；以及解决业务模型构建的技术与标准，正如我们所熟知的MDA（模型驱动架构）等。可见与流程应用相关技术的重要性。

最近也有很多企业的朋友向我抱怨他们给客户实施工作流项目的时候，不论是采用第三方的工作流产品，还是扩展开发开源的工作流引擎，总是非常棘手，碰到很多难以应对的问题，而且这些问题一般出现在项目后期。因为在需求调研的过程中客户也无法欲知，因为客户也不清楚流程系统应该具有什么功能。

可以说，从工作流项目实施角度可以阐述很多可以注意的事项，但是本篇确从另一个角度来辅助大家看待流程问题。这个角度完全是从一个“源”角度来探索—— 如果你清楚了一个过程引擎的实现思路和构架，我想你就不会在为那“怪异的客户需求”而惊奇了，相反，你可以很轻松的应对。

是的，本篇主旨就是讲解“微内核过程引擎的设计思路和构架”。

在进入文章正文之前，我还有必要稍稍补充两点：

在前一篇杨洪波先生已经为大家诠释了工作流（Workflow）与业务流程管理（BPM）的异同。为了减少名词概念方面的误导性，本篇采用了流程（Process）这个概念，来规避Workflow与Business Process所可能带来的概念差异性。当然，不论是工作流还是BPM，解决的根本问题都是流程（Process）问题。

过程引擎的实现技术已经超越了单纯的技术语言、技术模式、构架。在阅读本篇之后（或之前），如果您对工作流引擎的实现感兴趣，那么尽可能的把工作流基本概念、模型、建模方法、系统参考模型等方面的内容浏览一下，可能更有助于您阅读本篇。

当我们试图去实施一个工作流项目，或者研发一个过程引擎的时候，我们将面临很多的问题需要解决：流程有分支，有聚合；客户又要会签，还要回退；组织模型需要适配，权限要控制到数据；等等诸如此类的问题。

正如上面这张图所示，可能单个问题比较容易解决，但是这么多需要考虑的地方融汇在一起，就演变成一个非常复杂的问题了。

但是，再复杂的问题也都可以通过逐步分解、剥离，分步、分层的进行构建，从而逐步解决。本文的主旨就是通过提供一套设计流程的思路和引擎构架来辅助大家解决这个问题。限于文章篇幅，很多地方本文只能“点到即止”，如果对过程引擎构建干兴趣的化，那么在阅读本篇之后，还需要花费较多的时间巩固相关知识才可。