这周要开始做平台的接口设计了，最近自己一直在看工作流引擎这块，就提一下自己关于这块的一些简单想法，给下面的设计提供一些思路，欢迎大家共同探讨。
目前工作流引擎技术的倾向是JBPM，当然，任何一项技术的运用都有两方面的问题，一个就是技术本身的能力局限，这个就需要运用的人去采用其他技术或者某些巧妙地处理，解决技术本身的能力瓶颈。另一个就是使用技术的人能否掌握这项技术并应用于实际的开发。
JBPM当然存在问题，它对于各种中国式的流程并不能很好的支持，比如回退，跳转之类，对于历史轨迹的记录也不是特别的关注，这些就需要去拓展实现，这个就是我们平台实际开发时考虑的技术实现细节，现阶段暂时不用考虑。另一方面从目前的定位来看，将来一定会有外部的虚拟人员去开发业务组件，那么他们在开发的时候，我们是否需要去让平台以外的开发人员了解或者说是掌握工作流技术。这就要从JBPM的分类来讨论下，根据工作流产品在运行时刻与业务应用系统的关系，可以将国内市场上的工作流软件产品分为嵌入式和独立运行两大类。
嵌入式就是说JBPM作为一个jar包附加到项目上，不能独立运行，与业务层的交互方式上，采用直接提供本地API的方式。独立式本身就是一个应用，以远程调用方式提供API。独立运行工作流引擎能够和多个业务系统打交道，嵌入式工作流不能直接和宿主系统以外的系统交互。因此只有独立运行工作流引擎支持分布式应用，和支持通过业务流程做企业应用集成（EAI）。联系到我们的平台，如果业务组件中附加JBPM的jar包，那就是嵌入式工作流，要求开发人员掌握JBPM的api和使用方式，对开发人员要求较高，同时相当于把工作流引擎放到业务组件中。如果业务组件中不附加JBPM的jar包，而是采取远程调用的方式，那就是独立式，要求开发人员提供相应的业务接口，掌握web service相关技术。但是独立运行工作流引擎必须自己实现多线程同步、网路通讯处理、资源池等服务端技术，因此实现的成本高、技术复杂，对于平台的开发部署来说，难度加大，不知道有没有中间件或者现成的框架支持。
因为技术选型直接关系到下一阶段对外开放的接口方法，所以这里特别让我迷惑，不知道该何去何从，希望大家拍砖。
