SOA与工作流、ESB的关系

看了http://www.iteye.com/topic/148856?page=5，因为严重反对楼主这样的把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）没有一个集成的环境 ，工具不能产生可执行的业务流程

 

我理解如果结合大家的ESB方面的疑问，可以这样定位SOA三个阶段：

1.       应用级：大多数客户的状况，客户的预算是先实施一个应用。这级的目标是：SOBA应用按SOA的范式来调用外界的服务，而且SOBA应用内的服务可以很容易地融合到以后的SOA整体架构中。这个级别不需要ESB。

2.       部门级：客户只对业务流程进行了局部研究，业务集成范围限于部门内（或者限于某个业务领域内）。这个级别需要一个服务管理库，但是还是不需要ESB（企业服务总线）。

3.       企业级：这个级别需要ESB和企业业务库。 

如果企业在有限的集成服务范围内，盲目地投资实现非常高级的SOA架构，将造成很大的成本负担，IT投资过大，需求不可控制，取得的业务优势会得不偿失。而根据未来要求，分步实施、稳步推进是SOA架构实施的正确路线。