SOA没在忽悠

个人觉得数据整合,应用协同发展的步骤分为以下几步.
第一:数据库整合
第二:应用整合
第三:暴露服务整合,请求模式
第四:SOA

这四个步骤都有这么几个要素.
第一:应用方
第二:数据提供方
第三:业务需求

说SOA是忽悠的也可以理解,因为这四个步骤都可以实现SOA的目标.可是如果从业务扩展和变更的角度去考虑就会发现不同.

一个简单的例子,本来A,B,C三个部门有一个应用(比方是公司的三个不同部门) 因为政策变化公司需要把这个三个部门整合成一个部门,这样完全可以把进行数据库整合然后重新开发应用(第一种),或者把三个部门的应用进行整合(第二种)等...
这样的整合在功能实现上是一样的. 好的又过了一段时间,公司业务发展的需要又要把这个整合后的部门分为两个部门,这时候你依旧可以和以前那样进行整合. 这样就不难看出为了适应变化投入的成本.

下面我说说 第三和第四种整合模式

第三:暴露服务整合,请求模式这种整合已经是准SOA模式了只是它把业务的流程积压在应用方,服务提供方提供服务的细节对应用方是透明的.这种整合的缺点是在业务变化的时候 还需要比较大面积的修改原来应用的逻辑.
第四:SOA,其实它把简单的服务调用流程和数据库整合规则逻辑加在了SB上,服务对应用是不透明的.应用只需要知道有这个服务就可以了,这种模式在业务变化的情况下也许只是简单的修改流程脚本而已.

所以SOA有它自己独特的领域,并不能说SOA在忽悠,如果业务变更不大,业务流程不复杂那么完全可以不用SOA去做.

SOA在理论上是要解决数据孤岛的问题,但是它在本质上确实要解决协调工作的问题.快速应答客户需求只是这种模式带来的好处而已.

我不否认SOA是一大堆适配器,在没有平台规范的情况下这种情况是难免的.君不见JAVA世界里面还一大堆接口.你能说接口就不是一个适配器吗?
SOA在发展,就请不要再否认SOA的意义,容忍SOA在发展过程中犯的小错误,存在即合理.垃圾只是发错地方的财富而已.

评论

3 楼 andot 2009-02-20  

SOA 没有在忽悠，是现有用于实现 SOA 的技术在忽悠，庞大复杂低效（还要在原本就很低效的各个协议之间转来转去），且仅面向 Java（虽然口号是语言无关，可是在对其它语言的支持上基本上都是空白一片）。其实，要构建 SOA 系统，根本不需要那些复杂的东西，只要有 PHPRPC 这样的高效易用且语言支持广泛的技术就足够了，其它的都是在扯淡。ESB 是啥？翻译成中文其实就是：哦，傻逼！

2 楼 fjlyxx 2009-02-20  

没这么强大,SOA的流程和工作流又有一定的区别.
打个比方吧,比如你申请一块土地盖房子可能需要 A B C三个部门审批, OK 这时候 你开发一套系统 把A B C三个部门给联系在一起了. 如果哪天政策变化  国家把B C合并成D 或者不需要C审批了 那么 你就需要改原来的系统   成本太大  如果有SOA平台 你就可以简单的修改流程脚本了   业务变化频繁 需求不确定 需要协调工作的系统比较适合SOA

SOA的流程的颗粒度不一样.  一般来说 在 SOA平台中对于流程 只需要提供简单的 逻辑(与或非) 和 简单的数学计算 就可以了. 逻辑服务是为了控制流程走向,数学计算就是为内部的运作提供一些方便.

1 楼 darkjune 2009-02-16  

SOA是在暴露的服务基础上进行工作流的流转么?