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架构实施的正确路线。

评论

21 楼 hongsoft 2008-12-11  

EOS6.0现在没有做BPEL的实现。

BPS6.1中将支持BPEL。

20 楼 fjlyxx 2008-12-10  

可以这样理解吗？EOS也是BPEL的一种实现。只是执行过程中参与的接口不一样。

19 楼 hongsoft 2008-12-10  

我对公司以前的版本了解也不多。
我进来就做 EOS6.0的架构师，做了两年，6.0与以前版本变化比较大，基本是重写的；现在做BPS6.1的架构师，做BPEL和B4P方面的东西。

我说的话并不代表公司观点，呵呵，只是纯技术交流。

18 楼 fjlyxx 2008-12-10  

你是普元的阿，听过你们公司EOS的培训。说实话你们用XML作为数据总线，把XML分为数据区域和控制区域确实是一个很明智的选择。这点我很认同，但是我觉得有点大才小用，如果把这个技术应用到ESB引擎中那么也许会更能发挥它本应该有的魅力。
我今天无心说EOS。有时候提供越多的功能，想囊括越多，反而会失去更多的作用空间。

17 楼 hongsoft 2008-12-10  

fjlyxx 写道

我觉得学习SOA如果单纯的看书是没有啥用的。在SOA中 你没想到的问题太多了，本来SOA就是一个模糊的概念，可以说是异步的又可以说是同步的，可以说是分布式的又可以说不是，SOA是啥？一句话，啥都不是，啥都是。当然你可以用你看到的定义去反驳我。

EOS做个工作流他自己说也是SOA，好像我们也没有办法反驳他。仁者见仁的事情。

不过话说回来，SOA的目标还是很明确的。协同工作，信息共享。就这两点而言如果我之做信息共享那么我完全可以把SOA做成ETL，如果我把业务组建（请注意这里的业务组建的定义是不通过网络就可以访问的功能模块）当成服务那么 我做个工作流也是SOA。

所有，工作流，ETL，SOA三种东西在功能上本来就很难说清楚。

但是，我个人不认为ETL和工作流是SOA平台。
我的感受是
第一，SOA一定要有协同工作的能力，当然这种协同工作的颗粒度不是像工作流一样。

第2，SOA的服务调用绝对不是像工作流引擎调用业务节点一样。（虽然你可以把这个业务节点发布成一个SOA服务）

如果把工作流的业务节点提高一个层次那么工作流也许就是一个SOA平台了。我是靠服务颗粒去判断的。

就这两点个人想法，交流下对SOA的认识。

公司现在有两个产品：一个是EOS，SOA中间件，编程模型采用 SCA/SDO；另外一个是BPS，BPM中间件，编程模型采用BPEL+B4P。

16 楼 hongsoft 2008-12-10  

fjlyxx 写道

我觉得学习SOA如果单纯的看书是没有啥用的。在SOA中 你没想到的问题太多了，本来SOA就是一个模糊的概念，可以说是异步的又可以说是同步的，可以说是分布式的又可以说不是，SOA是啥？一句话，啥都不是，啥都是。当然你可以用你看到的定义去反驳我。

EOS做个工作流他自己说也是SOA，好像我们也没有办法反驳他。仁者见仁的事情。

不过话说回来，SOA的目标还是很明确的。协同工作，信息共享。就这两点而言如果我之做信息共享那么我完全可以把SOA做成ETL，如果我把业务组建（请注意这里的业务组建的定义是不通过网络就可以访问的功能模块）当成服务那么 我做个工作流也是SOA。

所有，工作流，ETL，SOA三种东西在功能上本来就很难说清楚。

但是，我个人不认为ETL和工作流是SOA平台。
我的感受是
第一，SOA一定要有协同工作的能力，当然这种协同工作的颗粒度不是像工作流一样。

第2，SOA的服务调用绝对不是像工作流引擎调用业务节点一样。（虽然你可以把这个业务节点发布成一个SOA服务）

如果把工作流的业务节点提高一个层次那么工作流也许就是一个SOA平台了。我是靠服务颗粒去判断的。

就这两点个人想法，交流下对SOA的认识。

SOA是一种做架构的范式，这个范式的核心目标是做到业务敏捷，核心思路是通过服务的方式。
满足上面三个条件的，是SOA。

15 楼 hongsoft 2008-12-10  

fjlyxx 写道

学习SOA前我个人觉得不要现着急看技术方面的东西，先看看SOA能干什么。想想如果要你去做会碰见什么问题。思想最重要技术其次。 推荐先看世界是扁平的

呵呵，是的。
《世界是平的》我是06年看的，还写过 blog，呵呵。

14 楼 ronghao 2008-12-10  

如果大家一定要把SOA往IT实现上靠的话，那SOA就是在忽悠。

13 楼 fjlyxx 2008-12-10  

学习SOA前我个人觉得不要现着急看技术方面的东西，先看看SOA能干什么。想想如果要你去做会碰见什么问题。思想最重要技术其次。 推荐先看世界是扁平的

12 楼 fjlyxx 2008-12-10  

我觉得学习SOA如果单纯的看书是没有啥用的。在SOA中 你没想到的问题太多了，本来SOA就是一个模糊的概念，可以说是异步的又可以说是同步的，可以说是分布式的又可以说不是，SOA是啥？一句话，啥都不是，啥都是。当然你可以用你看到的定义去反驳我。

EOS做个工作流他自己说也是SOA，好像我们也没有办法反驳他。仁者见仁的事情。

不过话说回来，SOA的目标还是很明确的。协同工作，信息共享。就这两点而言如果我之做信息共享那么我完全可以把SOA做成ETL，如果我把业务组建（请注意这里的业务组建的定义是不通过网络就可以访问的功能模块）当成服务那么 我做个工作流也是SOA。

所有，工作流，ETL，SOA三种东西在功能上本来就很难说清楚。

但是，我个人不认为ETL和工作流是SOA平台。
我的感受是
第一，SOA一定要有协同工作的能力，当然这种协同工作的颗粒度不是像工作流一样。

第2，SOA的服务调用绝对不是像工作流引擎调用业务节点一样。（虽然你可以把这个业务节点发布成一个SOA服务）

如果把工作流的业务节点提高一个层次那么工作流也许就是一个SOA平台了。我是靠服务颗粒去判断的。

就这两点个人想法，交流下对SOA的认识。

11 楼 hongsoft 2008-12-10  

huidian 写道

hongsoft 写道

BA就是  业务分析人员的意思，也可指 业务分析专家。 我见过 国内很多公司 有这个职位的。 国外就更普遍。

能否加您联系方式，本人刚毕业，现在在一家以工作流为核心产品的公司工作，但似乎公司的研发核心人员大部分离职了，所以急切想找一位像您一样的前辈来指点迷津,万分感谢.
我QQ 14463141
  邮箱 [e-mail]
万分感谢!

呵呵，自己多学习吧。通过网络不好交流太多的东西的。

如果在上海可以通过聚会的形式沟通。

10 楼 hongsoft 2008-12-10  

对于目前很多企业来说，第一，第二，第三阶段这样并存的企业很多~~


是的，你说的这一点我很认同。


第2阶段并不是 点到点的模式，而是 多个 轻量级ESB 共同管理的方式。
呵呵，画个图比较好说清楚点，可惜我没有时间（现在在做BPEL和B4P的研发工作）。


也许我这样说可能更容易明白：
我们不需要 重量级ESB，只需要轻量级ESB。

多轻量级ESB共存；或者可能是  服务管理表 与 轻量级ESB共存 。 

9 楼 czx566 2008-12-10  

hongsoft 写道

回czx566，其实我认为 第2阶段是 正确使用ESB的前提：

服务总线其实分为两大类，一是ESB企业服务总线如IBM的产品；二是服务总线如Aqualogic Service Bus。一般的服务总线都有如数据转换、协议转换、消息路由等等通用功能，而ESB还多了负载均衡、安全策略、服务监控、团队开发支持等特性。

1） 应用级不需要服务总线（最好是没有ESB，否则带来项目复杂性）
2） 部门级（领域级）需要服务总线，但是不需要ESB （如果客户已经买了ESB，一定要用，也可以初步使用；如果没有买ESB，则不需要ESB，可以考虑买EOS的简单ESB实现版本）
3） 企业级： 需要ESB。但是这个级别的项目我们很难争取到，市场上也不一定存在。

我理解你说的部门级，也就是传统的EAI解决方案： 点到点解决模式~

这种点到点的模式 如果系统比较少还好，如果多了，那么头就大了。

所以在我们有ESB这种资源的前提下，我觉得点到点的模式可以不考虑了~~

所以我说第二阶段感觉没有必要。

    而目前的情况来说，据我个人所知，如果一旦一个企业决定上SOA，一定先上ESB~~~
让ESB先去兼容原有的应用系统，如果领导一看效果不错，才有可能将后续的系统开发加上必须符合SOA架构的系统要求，所以对于目前很多企业来说，第一，第二，第三阶段这样并存的企业很多~~

8 楼 hongsoft 2008-12-10  

“现实中，企业往往先从第3级开始的，只有当你的esb并入了大多数系统后，企业才有可能在后续新开发的系统加上第一级的要求！ ”

我明白你说的现状，它的产生有两个原因：
1）  IBM等公司 已经 卖了太多的ESB（一般是通过SOA来卖的），企业感觉不用也是浪费
2） 新开发的系统，应该天然的 支持 对外暴露 服务的接口，不应该留给以后的系统集成。    （这个就是我的blog说的 开发即集成的概念之一）


当然，在你说的情况之下（企业已经有ESB了），那当然也可以把它用上。
只是我个人认为 ESB实在不是个 好东西，而多个服务总线才是我们的需要。

7 楼 huidian 2008-12-10  

hongsoft 写道

BA就是  业务分析人员的意思，也可指 业务分析专家。 我见过 国内很多公司 有这个职位的。 国外就更普遍。

能否加您联系方式，本人刚毕业，现在在一家以工作流为核心产品的公司工作，但似乎公司的研发核心人员大部分离职了，所以急切想找一位像您一样的前辈来指点迷津,万分感谢.
我QQ 14463141
  邮箱 [e-mail]
万分感谢!

6 楼 hongsoft 2008-12-10  

呵呵。上面是  我个人 对 EOS  对 服务总线的归纳，并不代表 公司的观点。

我想大家的项目，最大也就是 对企业某个领域（比如5个CRM系统）的 业务的 管理，
这样的情况下，对服务的调用 只需要 调用到   服务总线中的服务，并不需要ESB。

如果CRM要调用 计费系统的 服务怎么办？
那就需要用  服务总线，把  计费领域的  服务管理起来，对外（CRM)提供调用。


注意：这里是  多个服务总线，但是并不是ESB。

5 楼 hongsoft 2008-12-10  

回czx566，其实我认为 第2阶段是 正确使用ESB的前提：

服务总线其实分为两大类，一是ESB企业服务总线如IBM的产品；二是服务总线如Aqualogic Service Bus。一般的服务总线都有如数据转换、协议转换、消息路由等等通用功能，而ESB还多了负载均衡、安全策略、服务监控、团队开发支持等特性。

1） 应用级不需要服务总线（最好是没有ESB，否则带来项目复杂性）
2） 部门级（领域级）需要服务总线，但是不需要ESB （如果客户已经买了ESB，一定要用，也可以初步使用；如果没有买ESB，则不需要ESB，可以考虑买EOS的简单ESB实现版本）
3） 企业级： 需要ESB。但是这个级别的项目我们很难争取到，市场上也不一定存在。

4 楼 hongsoft 2008-12-10  

BA就是  业务分析人员的意思，也可指 业务分析专家。

我见过 国内很多公司 有这个职位的。

国外就更普遍。

3 楼 elam 2008-12-09  

czx566 写道

对了，问一句，BA是个啥

Busyness Analyser
?

2 楼 czx566 2008-12-09  

对了，问一句，BA是个啥