根据工作流产品在运行时刻与业务应用系统的关系，可以将国内市场上的工作流软件产品分为嵌入式和独立运行两大类。本文希望通过分析这两类工作流产品的各自特点，为选择工作流产品的用户提供一些参考。
因为工作流软件一般应用在电子政务、企业办公和管理软件上，同时在这些领域使用J2EE架构已是一种趋势，所以本文只着重于介绍基于J2EE技术实现的 工作流引擎。
嵌入式工作流引擎
![]()
在部署上，嵌入式工作流引擎是不能单独运行的，它是以一个软件组件（或者说构件）的形式运行在使用它的业务应用中。因为工作流技术主要是解决复杂业务流程灵活定制和方便更改的问题，因此在应用逻辑层次上，我们可以把嵌入式工作流引擎看作是业务逻辑层的一部分。
在与业务应用的交互方式上，嵌入式工作流引擎通过提供WAPI（Workflow API）为展现层或业务逻辑层的其他部分提供服务（如启动指定工作流程、查询工作任务、设置流程运行业务数据）。另一方面，工作流引擎经常需要业务相关的数据或逻辑来决定流程流转，或者需要在不同任务之间传递业务数据，这时候，流程引擎会调用业务应用中业务逻辑或数据访问模块提供的API接口来完成相应操作。
独立运行工作流引擎
![]()
独立运行工作流引擎本身就是一个单独的应用。作为服务应用如果又没有基于某个中间件技术的话，独立运行工作流引擎必须自己实现多线程同步、网路通讯处理、资源池等服务端技术，因此实现的成本高、技术复杂。
在与业务应用的交互方式上，独立运行工作流引擎会以远过程调用的方式提供WAPI（Workflow API）。对于使用Java技术的独立运行工作流引擎，远过程调用方式可以是RMI、JMS，或者能够跨越异构系统的Web Service。
另外，独立运行工作流引擎也必须为反过来如何调用业务应用提供解决办法。一般情况下，独立运行工作流引擎应该能够直接调用外部业务应用提供的远程接口（如基于RMI、JMS或者Web Service的业务接口），另一方面，业务应用也必须为独立运行工作流引擎提供远过程调用业务方法。
当然也有省事而走捷径的方法，比如国内市场占有率比较高的一款Java独立运行工作流产品，虽然提供了基于RMI/JMS的WAPI，却没有提供工作流引擎直接调用外部业务远程接口的方法。如果要让工作流引擎调用外部业务逻辑，你必须编写一个实现厂商特有接口的Java类，然后将它上传并注册到工作流引擎中。
![]()
像上图这种方式是可以解决实际业务问题（你自己编写的java类可以做任何事情，比如远程调用或者访问数据库）。但很明显，本来很多不该二次开发做的工作现在必须在二次开发时做了。同时，业务应用逻辑分散在多个应用（你的应用和工作流引擎）中并且某些业务应用逻辑（上传到引擎的Java类）反过来要依赖厂家的接口，这些都是良好的架构设计要避免的情况。一旦系统后期要做一些变动就会带来很大麻烦。
对比
下面我们就部署、二次开发的难易程度、性能、是否支持分布和EAI，对这两类工作流引擎做一个对比。
1、部署: 对于一个基于Java技术的嵌入式工作流引擎，在部署时非常简单，你只要将对应的jar文件加到classpath中就可以了。独立运行工作流引擎因为是独立的应用，并且必须通过RMI/JMS/Web service等远程调用技术与业务应用交互，所以部署起来要麻烦得多；
2、二次开发: 由于大部分独立运行工作流引擎也会在客户端，提供方便远程调用的本地调用API，所以在二次开发时，程序员大部分时间都可以不大关注引擎是本地的还是远程的。但在传递某些业务参数和例外处理中，远程调用还是有些特殊的要求和限制的。因此总的来说，在二次开发上独立运行工作流引擎对程序员要求高一些；
3、性能：毫无疑问，因为没有远过程调用，嵌入式工作流引擎要占明显优势；
4、分布和EAI：独立运行工作流引擎能够和多个业务系统打交道，嵌入式工作流不能直接和宿主系统以外的系统交互。因此只有独立运行工作流引擎支持分布式应用，和支持通过业务流程做企业应用集成（EAI）。
如何选择
通过上面的对比已经很清楚了。如果你需要工作流程在多个系统中流转，那么选择独立运行工作流引擎。在其他情况下，选择嵌入式工作流引擎。
同时，即使你因为分布或EAI而准备选择独立运行工作流引擎，你也应当选择在业务与引擎两个调用方向上，都直接支持远过程调用的工作流产品。如果独立运行工作流引擎在某个调用方向上（比如回调业务应用）没有提供方法，需要用户在二次开发时自己解决，这种情况下请选择嵌入式工作流引擎。
发展方向
一般国内独立运行工作流产品历史会比较长，大部分是在7-8年前开始立项开发的，那时候正是分布式应用理论最火热的时候。可随着人们在实践中的经验教训和积累，发现很多情况下我们不需要复杂的分布式应用。这也是近几年来在Java世界里，许多人提倡“轻量级”、“no-EJB”的原因。
事实上，嵌入式工作流引擎经过一定的扩展也能够处理跨系统的流程交互：
![]()
在上图中，新的嵌入式工作流引擎通过附加工具能够为外部业务接口（不管是RIM/JMS/Web Service）自动生成适配器（Adapter）供引擎使用，另外引擎会对外提供远程WAPI（包括客户端适配器）。具备了远程交互能力的嵌入式引擎仍然可以作为组件在主要的业务应用中使用，从而使得大部分业务逻辑和引擎之间的交互为本地调用，不会造成性能的损失。
国际著名工作流专家Michael zur Muehlen 在其 “Workflow-based Process Controlling”一书中谈到：“在上个世纪80-90年代，大部分工作流应用采用第一种应用方式（独立）。现在，对于包含复杂流程的应用系统，许多软件提供商重新定位和设计它们的工作流产品，使其成为应用系统的构件模块（即嵌入式）”。你的看法呢？
因为工作流软件一般应用在电子政务、企业办公和管理软件上，同时在这些领域使用J2EE架构已是一种趋势，所以本文只着重于介绍基于J2EE技术实现的 工作流引擎。
嵌入式工作流引擎
在部署上，嵌入式工作流引擎是不能单独运行的，它是以一个软件组件（或者说构件）的形式运行在使用它的业务应用中。因为工作流技术主要是解决复杂业务流程灵活定制和方便更改的问题，因此在应用逻辑层次上，我们可以把嵌入式工作流引擎看作是业务逻辑层的一部分。
在与业务应用的交互方式上，嵌入式工作流引擎通过提供WAPI（Workflow API）为展现层或业务逻辑层的其他部分提供服务（如启动指定工作流程、查询工作任务、设置流程运行业务数据）。另一方面，工作流引擎经常需要业务相关的数据或逻辑来决定流程流转，或者需要在不同任务之间传递业务数据，这时候，流程引擎会调用业务应用中业务逻辑或数据访问模块提供的API接口来完成相应操作。
独立运行工作流引擎
独立运行工作流引擎本身就是一个单独的应用。作为服务应用如果又没有基于某个中间件技术的话，独立运行工作流引擎必须自己实现多线程同步、网路通讯处理、资源池等服务端技术，因此实现的成本高、技术复杂。
在与业务应用的交互方式上，独立运行工作流引擎会以远过程调用的方式提供WAPI（Workflow API）。对于使用Java技术的独立运行工作流引擎，远过程调用方式可以是RMI、JMS，或者能够跨越异构系统的Web Service。
另外，独立运行工作流引擎也必须为反过来如何调用业务应用提供解决办法。一般情况下，独立运行工作流引擎应该能够直接调用外部业务应用提供的远程接口（如基于RMI、JMS或者Web Service的业务接口），另一方面，业务应用也必须为独立运行工作流引擎提供远过程调用业务方法。
当然也有省事而走捷径的方法，比如国内市场占有率比较高的一款Java独立运行工作流产品，虽然提供了基于RMI/JMS的WAPI，却没有提供工作流引擎直接调用外部业务远程接口的方法。如果要让工作流引擎调用外部业务逻辑，你必须编写一个实现厂商特有接口的Java类，然后将它上传并注册到工作流引擎中。
像上图这种方式是可以解决实际业务问题（你自己编写的java类可以做任何事情，比如远程调用或者访问数据库）。但很明显，本来很多不该二次开发做的工作现在必须在二次开发时做了。同时，业务应用逻辑分散在多个应用（你的应用和工作流引擎）中并且某些业务应用逻辑（上传到引擎的Java类）反过来要依赖厂家的接口，这些都是良好的架构设计要避免的情况。一旦系统后期要做一些变动就会带来很大麻烦。
对比
下面我们就部署、二次开发的难易程度、性能、是否支持分布和EAI，对这两类工作流引擎做一个对比。
1、部署: 对于一个基于Java技术的嵌入式工作流引擎，在部署时非常简单，你只要将对应的jar文件加到classpath中就可以了。独立运行工作流引擎因为是独立的应用，并且必须通过RMI/JMS/Web service等远程调用技术与业务应用交互，所以部署起来要麻烦得多；
2、二次开发: 由于大部分独立运行工作流引擎也会在客户端，提供方便远程调用的本地调用API，所以在二次开发时，程序员大部分时间都可以不大关注引擎是本地的还是远程的。但在传递某些业务参数和例外处理中，远程调用还是有些特殊的要求和限制的。因此总的来说，在二次开发上独立运行工作流引擎对程序员要求高一些；
3、性能：毫无疑问，因为没有远过程调用，嵌入式工作流引擎要占明显优势；
4、分布和EAI：独立运行工作流引擎能够和多个业务系统打交道，嵌入式工作流不能直接和宿主系统以外的系统交互。因此只有独立运行工作流引擎支持分布式应用，和支持通过业务流程做企业应用集成（EAI）。
如何选择
通过上面的对比已经很清楚了。如果你需要工作流程在多个系统中流转，那么选择独立运行工作流引擎。在其他情况下，选择嵌入式工作流引擎。
同时，即使你因为分布或EAI而准备选择独立运行工作流引擎，你也应当选择在业务与引擎两个调用方向上，都直接支持远过程调用的工作流产品。如果独立运行工作流引擎在某个调用方向上（比如回调业务应用）没有提供方法，需要用户在二次开发时自己解决，这种情况下请选择嵌入式工作流引擎。
发展方向
一般国内独立运行工作流产品历史会比较长，大部分是在7-8年前开始立项开发的，那时候正是分布式应用理论最火热的时候。可随着人们在实践中的经验教训和积累，发现很多情况下我们不需要复杂的分布式应用。这也是近几年来在Java世界里，许多人提倡“轻量级”、“no-EJB”的原因。
事实上，嵌入式工作流引擎经过一定的扩展也能够处理跨系统的流程交互：
在上图中，新的嵌入式工作流引擎通过附加工具能够为外部业务接口（不管是RIM/JMS/Web Service）自动生成适配器（Adapter）供引擎使用，另外引擎会对外提供远程WAPI（包括客户端适配器）。具备了远程交互能力的嵌入式引擎仍然可以作为组件在主要的业务应用中使用，从而使得大部分业务逻辑和引擎之间的交互为本地调用，不会造成性能的损失。
国际著名工作流专家Michael zur Muehlen 在其 “Workflow-based Process Controlling”一书中谈到：“在上个世纪80-90年代，大部分工作流应用采用第一种应用方式（独立）。现在，对于包含复杂流程的应用系统，许多软件提供商重新定位和设计它们的工作流产品，使其成为应用系统的构件模块（即嵌入式）”。你的看法呢？