SOA——中小系统的不能承受之重

    最近开发了一套工作流系统，当然，相对比较简单，对于复杂的自动机没有实现。开发完之后对SOA有了更深入的理解。

    工作流机制是SOA的灵魂，下面咱就谈谈这个灵魂。

    完整的工作流系统包含三个部分：

    第一，工作流本身的数据模型以及控制流程实例流转的引擎；
    第二，与业务数据密切相关的工作流边界，负责关联业务数据和工作流；
    第三，工作流的流程管理子系统，最理想的是可视化编辑。

    目前，开源的工作流引擎有osworkflow,jbpm,shark等，这些工作流都符合工作流联盟的规范。但是要让他们符合你的需求比较难。最重要的原因是，你的系统里层级和架构设计，比如DAO的方式等规范，与他们对工作流本身数据模型管理的方式出入比较大。osworkflow里有几种可选的DAO方式，JDBC支持，hibernate支持，hibernate+spring也支持。但是整合方式未必和你的系统规范吻合。
    除了在数据模型操作上有出入外，在流程管理上也未必符合你的要求。流程管理的最高境界就是让客户按需求自己去配置业务流程。而从osworkflow等提供的方式来看，客户还必须得精通xml等技术，客户还不把我们这些人宰了？因此，用他们的东西，一定程度上可以解放工作量，灵活修改流程配置，但是要求是提前跟客户沟通好有哪些具体流程，万一流程有变，还得程序员自己去修改，做不到让客户来可视化的自己拖放流程。不过IBM的dominao等做的不错，流程设计还是挺牛的。
    如果工作流引擎有了，程序员要做的就是开发将业务和工作流关联起来的边界程序。别以为你有个工作流放那了，你就轻松了。引擎不知道业务数据要被如何计算，以及不知道你什么用例下才触发工作流。而且对于角色权限控制也不知道你是怎么规定的。边界程序就是要做这些事。
   
    有几个概念容易混淆：工作流，控制流，业务流。

    工作流是可以被取代的：在业务模型上多加几个控制状态的字段就可以了。
    使用工作流虽然很好，但是要付出代价的：开发成本高，程序运行成本高，维护成本也高。

    如果你的业务流程设计时可以用控制流，那就尽量用状态字段取代工作流吧，毕竟SOA不是用来杀鸡的刀

。
                                                             写于在公司开发完一套工作流系统后。

一路看来，现在有一个问题在我脑间回荡。 工作流和业务逻辑是一个什么关系？ 工作流和SOA应该没有直接关系吧。 感觉现在大家讨论工作流就是应用一些工作流框架实现你自己定义的工作流业务逻辑。而SOA是站在系统构架角度上，完成各种服务之间的交互工作。

工作流本身和SOA没有什么直接的关系，工作流引擎可以实现为一个或若干个service，当然也可以实现为其它的依赖实现方式，仅此而已。

这是什么话呀，感觉你连工作流都不了解，谈什么SOA

这是什么话呀，感觉你连工作流都不了解，谈什么SOA