对分布式工作流引擎的困惑?-

工作流机的执行分为集中式和分布式两种，对于分布式的工作流机，其分布式的调度算法是关键所在。
例如：一个process有以下几个Activity ： Activity1－Activity2－Activity3－Activity4－Activity5 ，Workflow Engine A部署在Server A， Workflow Engine B 部署在Server B上，其中Activity1、Activity2、Activity3由Workflow Engine A负责执行，而Activity4、Activity5由Workflow Engine B负责执行，那么这种调度是在建模的时候静态的指定？还是设计一种算法进行动态调度呢？如果是静态指定，那么建模者，必须知道所有流程的所有活动的分布情况，这几乎是不可想象。但是如果是动态调度，那么调度算法应该怎么设计呢？而由这个问题我又想到了集群，集群和分布式的工作流机不同的是，一个流程的实例还是有一个Workflow Engine 去执行，但是大量客户对工作流机的请求可以由集群去动态的调度，从而实现了对大业务量访问的一个负载均衡，那么此时还有必要去研究工作流机的分布式执行么？工作流机的分布式执行的优点又在哪里呢？

到底分布式的工作流机要解决的问题是什么？我觉得分布式工作流机要解决的根本问题不是性能问题，性能问题可以通过cluster解决，分布式工作流机要解决的还是一个分布式的问题，也就是解决分布式应用的协作问题，举个列子：对于一个大型的企业（或者是跨国公司）它有销售部、研发部、客户支持部，三个部门都分布在不同的城市（甚至是不同的国家），而有一个业务流程需要这三个部门协作完成，那么此时怎么办？三个部门的相关资源都在自己的部门，这时我们是不可能能通过集中式的工作流机来完成，所以只能是通过分布式的工作流机来完成，所以我想到的是，通过消息中间件和EJB2.0来实现工作流机的分布式。

关于分布式工作流引擎的文章，于是查阅了一些已有产品和相关论文的实现方式，主要有以下几种实现：一、基于COBRA的分布式引擎；二、基于事件的分布式引擎，这方面的代表是EvE（EVent Engine）－ an Event-Driven Distributed Workflow Execution Engine；三、基于webservice的分布式引擎；结合自己公司现在的工作流引擎的实现，于是想到了，基于EJB2.0（SB、EB、MDB）和名称空间服务（NameSpace Service）来实现引擎的分布式协作。工作流管理系统的分布式分为三层：工作流建模的分布式、工作流引擎的分布式、工作流定义的分布式（即流程定义采用分布式存储）。对于现在的大型企业级应用主要关注的是工作流引擎的分布式，也就是对于一个非常复杂的业务流程，有多个Server去共同完成，例如，在典型的电子政务应用中，拟稿、科长审核由engine A 执行，处长核稿、会签由engine B执行。