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