张瀚文的空间

我们一直在努力....

嵌入式还是分布式

标签: 工作流 JBPM

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

 


    评分: 请先登录再投票,同一篇博客一月只能投票一次!
    无人投票

相关博客:


评论

张瀚文 2011-1-10 15:53:31   回复
自己顶个,我们的平台应该还是用独立式的工作流,但我找了半天也没有个独立式的例子或者相关的文章,把jbpm当成一个应用部署简单,问题是怎么用web service或者其他手段调用这个引擎呢。
谭明智 2011-1-10 21:02:06   回复
工作流引擎相对于平台来说应该是嵌入式的,平台里应该继承工作流引擎和工作流的管理,而相对于业务组件来说,工作流又是一个独立的系统,流程和ESB结合,来整合服务。大体应该是这个样子。
张瀚文 2011-1-11 10:24:01   回复
@谭明智 说:我有个想法,是不是可以这样,我们提供一个网页版的工作流设计器,然后开发人员用我们的设计器开发流程,设计的xml和流程数据表保存在服务端,每个业务组件看到的流程或者说可能编辑的流程不一样,所以还要提供一个流程控制台,去做流程的权限管理。

发表评论

关注此文的人们还关注