SOA——中小系统的不能承受之重
最近开发了一套工作流系统，当然，相对比较简单，对于复杂的自动机没有实现。开发完之后对SOA有了更深入的理解。
工作流机制是SOA的灵魂，下面咱就谈谈这个灵魂。
完整的工作流系统包含三个部分：
第一，工作流本身的数据模型以及控制流程实例流转的引擎；
第二，与业务数据密切相关的工作流边界，负责关联业务数据和工作流；
第三，工作流的流程管理子系统，最理想的是可视化编辑。
目前，开源的工作流引擎有osworkflow,jbpm,shark等，这些工作流都符合工作流联盟的规范。但是要让他们符合你的需求比较难。最重要的原因是，你的系统里层级和架构设计，比如DAO的方式等规范，与他们对工作流本身数据模型管理的方式出入比较大。osworkflow里有几种可选的DAO方式，JDBC支持，hibernate支持，hibernate+spring也支持。但是整合方式未必和你的系统规范吻合。
除了在数据模型操作上有出入外，在流程管理上也未必符合你的要求。流程管理的最高境界就是让客户按需求自己去配置业务流程。而从osworkflow等提供的方式来看，客户还必须得精通xml等技术，客户还不把我们这些人宰了？因此，用他们的东西，一定程度上可以解放工作量，灵活修改流程配置，但是要求是提前跟客户沟通好有哪些具体流程，万一流程有变，还得程序员自己去修改，做不到让客户来可视化的自己拖放流程。不过IBM的dominao等做的不错，流程设计还是挺牛的。
如果工作流引擎有了，程序员要做的就是开发将业务和工作流关联起来的边界程序。别以为你有个工作流放那了，你就轻松了。引擎不知道业务数据要被如何计算，以及不知道你什么用例下才触发工作流。而且对于角色权限控制也不知道你是怎么规定的。边界程序就是要做这些事。
有几个概念容易混淆：工作流，控制流，业务流。
工作流是可以被取代的：在业务模型上多加几个控制状态的字段就可以了。
使用工作流虽然很好，但是要付出代价的：开发成本高，程序运行成本高，维护成本也高。
如果你的业务流程设计时可以用控制流，那就尽量用状态字段取代工作流吧，毕竟SOA不是用来杀鸡的刀
。
写于在公司开发完一套工作流系统后。
---------------------------------------------
SOA的一个中心思想就是使得企业应用摆脱面向技术的解决方案的束缚，轻松应对企业商业服务变化、发展的需要
工作流和业务流程实际上是一回事情。SOA中用工作流引擎做集成，和基于工作流的开发类不类似，关键看粒度。当然，开发工作流引擎和使用工作流引擎，那肯定是两回事情。
可能有些人比较关注异构的问题，这个是webservice技术要解决的，如果你说这个技术就是soa，那就大错特错，还不如说cobar就是SOA呢。
OO和JAVA以及是设计模式三者的关系你理解吗？
SOA和webservice和工作流三者的关系也就好理解了哈。
引用一句话说：“WebServices是SOA的基础资源；工作流用于调用WebServices，构成了SOA的大脑和灵魂”。
如果工作流没有和组织机构结合起来，那算不得上一个完整的工作流，至少在很多方面会受到限制。举个例子，A请假，要A的上级审批，A的上级，就是组织机构里的东东。A的上级看到的数据，可能与A不同（可能有些字段A的上级看不到，有些字段不能被修改），这就是权限的问题。所以，工作流必须要和组织机构（当然，组织机构包括了权限）无缝的结合在一起。而数据流，则是组织系统各个模块的，这样才能形成一个系统。
问个简单的问题：什么是工作流？ 43 楼 shuidrinking 2007-12-24 jasonhsu 写道工作流本身和SOA没有什么直接的关系，工作流引擎可以实现为一个或若干个service，当然也可以实现为其它的依赖实现方式，仅此而已。
这是什么话呀，感觉你连工作流都不了解，谈什么SOA 44 楼 zrweng 2007-12-24 shuidrinking 写道jasonhsu 写道工作流本身和SOA没有什么直接的关系，工作流引擎可以实现为一个或若干个service，当然也可以实现为其它的依赖实现方式，仅此而已。
这是什么话呀，感觉你连工作流都不了解，谈什么SOA
真可笑，呵呵 45 楼 rEloaD_cn 2007-12-28 shuidrinking 写道jasonhsu 写道工作流本身和SOA没有什么直接的关系，工作流引擎可以实现为一个或若干个service，当然也可以实现为其它的依赖实现方式，仅此而已。
这是什么话呀，感觉你连工作流都不了解，谈什么SOA
从一开始大家就很含蓄的指出了你的错误，有问题大家一起讨论嘛 46 楼 jzcjy 2008-08-22 仅仅从业务上看工作流和业务流程是对应的，从技术上来看SOA不仅仅是这点东西！ 47 楼 czx566 2008-10-03 soa的业务流程更多的提法是:process
而楼主所提到的工作流是：workflow
这两个在单词语义上面就是有区别的。
至于process 在soa当中的地位问题
我举一个具体应用soa的案例:
在客户的需求中，需要将域中所有的系统所有的操作 实时归纳到一个统一的日志系统中。这样在这个soa应用中，我们仅仅需要将监听的系统所作的操作信息转存到日志数据库中。这个仅仅需要esb。而根本没有出现process,更没有workflow。
48 楼 thesecondbull 2008-11-30 看了一点，偶不懂啥是soa，但是面向服务应该和工作流扯不上啥关系吧，他们就不像一个层次上的事情，假设lz的那个假设是正确的，那如果系统里有workflow他就叫soa？笑话 49 楼 fjlyxx 2008-12-09 明白一个概念，SOA的工作流程的目的是更高层次的协同工作（比如部门间，不同行业间）。不要被EOS和一些书本给影响了。如果SOA拿去开发一个紧密联系的流程那么和EOS有什么不同。工作流是一个具体的业务流程，SOA是的流程更多是个桥梁作用。A B C三个点A同时要B C和协同工作这个才是SOA的流程。B C对SOA来说都是服务，所以SOA流程内只有简单的一个控制逻辑。
ESB是一个调度中心 不是铁轨，ESB提供流程的内核服务。一个SOA平台没有可能做到具体化一个具体业务，它只能协调业务服务的工作。
太多打着SOA的旗号卖工作流的人了。SOA的目的就是协同工作和信息共享，不是业务处理。业务的处理是服务关心的。 50 楼 hongsoft 2008-12-09 严重反对楼主这样的把SOA和工作流关联起来的行为。
从技术实现上看，我理解的SOA包括如下内容：
1）首先要有service的实现和封装。就是通过某个方式，用技术的方法把服务封装出来。（比较好的是 webservice+sca)
2）其次要有service的管理。可能是通过简单的表结构来做一个服务表，可能是用service registry来做一个注册中心，可能是ESB。
3）再其次要实现service的编排。这个可能是一个BPM产品来实现。
BPM产品和工作流的区别在哪里？这个涉及到SOA的本质。
请看http://hongsoft.iteye.com/blog/288992
（BA使用BPM工具，在一个集成的环境中来建模和部署可执行的业务流程）
楼主的工作流的技术和场景，严重违反了这个标准：
1）没有让BA参与进来
2）没有一个集成的环境
3）工具不能产生可执行的业务流程
