SOA没在忽悠

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

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

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

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

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

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

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

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

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

评论

83 楼 oth 2009-02-24  

jackyrong 写道

另外，SCA, SDO, BPEL, ESB 等这一堆东西都是 IBM 带头定义的，目的自然只是为了他们的产品增加一点所谓的技术含量。可是你真的见过这些东西成功部署的案例吗？就连楼上的楼上的楼上不也是曾经被 IBM 那套东西差点折腾死的人吗？


带不带头定义谁不重要，关键是已经是事实标准。还有，BPEL,ESB的成功案例太多了，单国内普元
的案例就很多，可以去相关主页查看，很多大银行大企业也有很多用了的案例，楼主你不能就凭你
的想象就说没成功的案例。


归根到底，那就是楼主的PHPRPC应该继续搞下去，但应该务实些，低调些，没必要把时间花
在SOA的整个领域，也没必要花时间去说其他技术的不好，凡是存在肯定有其道理的，
踏踏实实把产品搞成熟

andot 写道

jackyrong 写道

我觉得PHPRPC不错，值得鼓励，但发明者把PHPRPC所实现的功能就
等同与SOA,这就太狭隘了，SOA还包括SCA,SDO,BPEL,ESB等很多方面
PHPRPC跟HESSIAN解决的只是从另外一个角度去方便了不同种语言的
相互沟通而已,仅此而已,因此PHPRPC的发展应该更专一些,不应该去做的
更大,把自己造成三投六臂那样

我从来没有说过 PHPRPC 就是 SOA。我只说，有了它利用它可以更容易的构建 SOA，你觉得我这样说有错吗？

另外，SCA, SDO, BPEL, ESB 等这一堆东西都是 IBM 带头定义的，目的自然只是为了他们的产品增加一点所谓的技术含量。可是你真的见过这些东西成功部署的案例吗？就连楼上的楼上的楼上不也是曾经被 IBM 那套东西差点折腾死的人吗？

你可以认为 PHPRPC 跟 HESSIAN 解决的是同一个问题，但 PHPRPC 对脚本、移动设备、服务器和普通客户端都提供比 Hessian 要好的支持，而且对目前来说进行系统集成的最迫切的需要不也就是这个吗？至于 IBM 定义的那一套概念 PHPRPC 压根也没打算去做。我不认为连基本问题都解决不好的 IBM 的那些东西会成为拯救企业的法宝。更何况事实也证明了这一点。

对外宣传的网页,也能相信?
当然要相信,只不过对外宣传的网页不会明说,他们的it系统能够帮助企业适应中国国情,
我这里所说的"国情",是造假帐之类的国情.对付和适应审计方面的国情.
so,其他的系统也要跟着适应.

82 楼 andot 2009-02-24  

Devin.Chenzx 写道

andot 写道

四个字就可以最灵活解决以上所有问题：编程实现。

如果按照你的答案，那么什么架构呀，系统都是垃圾

因为我们都可以编程实现。。。。。


首先PHPRPC的确是个不错的东西

但是完全没必要靠打嘴仗来宣传自己东西~

不是两个层面的东西，本来就不应该拿来比较~

那你能告诉我，使用了 ESB 之后是否你说的那些问题就都不需要编程就能实现了吗？事实是，你仍然要编程，只不过是本来可以用从你熟悉的语言来做的事，变成了要用你不熟悉的语言来做的事，无谓的增加了学习成本，增加了投入成本，跟皇帝的新装没什么区别。

81 楼 oth 2009-02-24  

andot 写道

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

其实应该翻译为:
咦~傻逼！

80 楼 oth 2009-02-24  

Devin.Chenzx 写道

andot 写道

四个字就可以最灵活解决以上所有问题：编程实现。

如果按照你的答案，那么什么架构呀，系统都是垃圾

因为我们都可以编程实现。。。。。


首先PHPRPC的确是个不错的东西

但是完全没必要靠打嘴仗来宣传自己东西~

不是两个层面的东西，本来就不应该拿来比较~

切莫恶意揣测,架构,系统也是编程实现的.
但除了你,没人说是垃圾,


正常技术切磋,只要不是恶意揣测和抬杠我不觉得是嘴仗.

79 楼 oth 2009-02-24  

jackyrong 写道

Devin.Chenzx 写道

andot 写道

四个字就可以最灵活解决以上所有问题：编程实现。

如果按照你的答案，那么什么架构呀，系统都是垃圾

因为我们都可以编程实现。。。。。


首先PHPRPC的确是个不错的东西

但是完全没必要靠打嘴仗来宣传自己东西~

不是两个层面的东西，本来就不应该拿来比较~

赞成，国内的开源界还是应该踏实点，取长补短，不自卑的同时也不要自大，那才是发展之路

phprpc的代码就是踏实这两个字的体现.

写代码就要像个男人.

78 楼 jackyrong 2009-02-24  

Devin.Chenzx 写道

andot 写道

四个字就可以最灵活解决以上所有问题：编程实现。

如果按照你的答案，那么什么架构呀，系统都是垃圾

因为我们都可以编程实现。。。。。


首先PHPRPC的确是个不错的东西

但是完全没必要靠打嘴仗来宣传自己东西~

不是两个层面的东西，本来就不应该拿来比较~

赞成，国内的开源界还是应该踏实点，取长补短，不自卑的同时也不要自大，那才是发展之路

77 楼 Devin.Chenzx 2009-02-24  

andot 写道

四个字就可以最灵活解决以上所有问题：编程实现。

如果按照你的答案，那么什么架构呀，系统都是垃圾

因为我们都可以编程实现。。。。。


首先PHPRPC的确是个不错的东西

但是完全没必要靠打嘴仗来宣传自己东西~

不是两个层面的东西，本来就不应该拿来比较~

76 楼 fjlyxx 2009-02-24  

jackyrong 写道

另外，SCA, SDO, BPEL, ESB 等这一堆东西都是 IBM 带头定义的，目的自然只是为了他们的产品增加一点所谓的技术含量。可是你真的见过这些东西成功部署的案例吗？就连楼上的楼上的楼上不也是曾经被 IBM 那套东西差点折腾死的人吗？


带不带头定义谁不重要，关键是已经是事实标准。还有，BPEL,ESB的成功案例太多了，单国内普元
的案例就很多，可以去相关主页查看，很多大银行大企业也有很多用了的案例，楼主你不能就凭你
的想象就说没成功的案例。


归根到底，那就是楼主的PHPRPC应该继续搞下去，但应该务实些，低调些，没必要把时间花
在SOA的整个领域，也没必要花时间去说其他技术的不好，凡是存在肯定有其道理的，
踏踏实实把产品搞成熟

IBM也未必在忽悠,只是自己还没有投入成本去学习.毕竟IBM做成产品式的东西需要考虑的行业特性比较多.

75 楼 jackyrong 2009-02-24  

另外，SCA, SDO, BPEL, ESB 等这一堆东西都是 IBM 带头定义的，目的自然只是为了他们的产品增加一点所谓的技术含量。可是你真的见过这些东西成功部署的案例吗？就连楼上的楼上的楼上不也是曾经被 IBM 那套东西差点折腾死的人吗？


带不带头定义谁不重要，关键是已经是事实标准。还有，BPEL,ESB的成功案例太多了，单国内普元
的案例就很多，可以去相关主页查看，很多大银行大企业也有很多用了的案例，楼主你不能就凭你
的想象就说没成功的案例。


归根到底，那就是楼主的PHPRPC应该继续搞下去，但应该务实些，低调些，没必要把时间花
在SOA的整个领域，也没必要花时间去说其他技术的不好，凡是存在肯定有其道理的，
踏踏实实把产品搞成熟

andot 写道

jackyrong 写道

我觉得PHPRPC不错，值得鼓励，但发明者把PHPRPC所实现的功能就
等同与SOA,这就太狭隘了，SOA还包括SCA,SDO,BPEL,ESB等很多方面
PHPRPC跟HESSIAN解决的只是从另外一个角度去方便了不同种语言的
相互沟通而已,仅此而已,因此PHPRPC的发展应该更专一些,不应该去做的
更大,把自己造成三投六臂那样

我从来没有说过 PHPRPC 就是 SOA。我只说，有了它利用它可以更容易的构建 SOA，你觉得我这样说有错吗？

另外，SCA, SDO, BPEL, ESB 等这一堆东西都是 IBM 带头定义的，目的自然只是为了他们的产品增加一点所谓的技术含量。可是你真的见过这些东西成功部署的案例吗？就连楼上的楼上的楼上不也是曾经被 IBM 那套东西差点折腾死的人吗？

你可以认为 PHPRPC 跟 HESSIAN 解决的是同一个问题，但 PHPRPC 对脚本、移动设备、服务器和普通客户端都提供比 Hessian 要好的支持，而且对目前来说进行系统集成的最迫切的需要不也就是这个吗？至于 IBM 定义的那一套概念 PHPRPC 压根也没打算去做。我不认为连基本问题都解决不好的 IBM 的那些东西会成为拯救企业的法宝。更何况事实也证明了这一点。

74 楼 andot 2009-02-24  

四个字就可以最灵活解决以上所有问题：编程实现。

73 楼 dualface 2009-02-24  

PHPRPC 只是一种 PRC 协议，以及该协议的实现品。和楼上所说的不是一个层次的东西。

ESB 也只是一种架构模式，具体到实现，你可以根据实际情况选择底层的技术和协议。比如消息传递，使用 PHPRPC 未尝不可。

至于消息传递的可靠性等问题，都可以通过设计来解决。当然如果确实有上 ESB 的需求，选择 IBM 成熟的产品和技术未免不是省时省力的解决方案。

最后说到消息定制和持久化，和底层的传输协议完全没有关系。

72 楼 Devin.Chenzx 2009-02-24  

虽然我也讨厌IBM

但是PHPRPC  请问

你怎么解决 ESB 中面临 消息聚合 和 分发 这种模式？

你怎么解决 消息传递的可靠性

你怎么解决 消息定制和消息的持久化？

71 楼 andot 2009-02-23  

jackyrong 写道

我觉得PHPRPC不错，值得鼓励，但发明者把PHPRPC所实现的功能就
等同与SOA,这就太狭隘了，SOA还包括SCA,SDO,BPEL,ESB等很多方面
PHPRPC跟HESSIAN解决的只是从另外一个角度去方便了不同种语言的
相互沟通而已,仅此而已,因此PHPRPC的发展应该更专一些,不应该去做的
更大,把自己造成三投六臂那样

我从来没有说过 PHPRPC 就是 SOA。我只说，有了它利用它可以更容易的构建 SOA，你觉得我这样说有错吗？

另外，SCA, SDO, BPEL, ESB 等这一堆东西都是 IBM 带头定义的，目的自然只是为了他们的产品增加一点所谓的技术含量。可是你真的见过这些东西成功部署的案例吗？就连楼上的楼上的楼上不也是曾经被 IBM 那套东西差点折腾死的人吗？

你可以认为 PHPRPC 跟 HESSIAN 解决的是同一个问题，但 PHPRPC 对脚本、移动设备、服务器和普通客户端都提供比 Hessian 要好的支持，而且对目前来说进行系统集成的最迫切的需要不也就是这个吗？至于 IBM 定义的那一套概念 PHPRPC 压根也没打算去做。我不认为连基本问题都解决不好的 IBM 的那些东西会成为拯救企业的法宝。更何况事实也证明了这一点。

70 楼 jackyrong 2009-02-23  

我觉得PHPRPC不错，值得鼓励，但发明者把PHPRPC所实现的功能就
等同与SOA,这就太狭隘了，SOA还包括SCA,SDO,BPEL,ESB等很多方面
PHPRPC跟HESSIAN解决的只是从另外一个角度去方便了不同种语言的
相互沟通而已,仅此而已,因此PHPRPC的发展应该更专一些,不应该去做的
更大,把自己造成三投六臂那样

69 楼 fjlyxx 2009-02-23  

呵呵 ,还是我们好 完全自主开发,全都有专利. 没有用第三方的平台.

68 楼 andot 2009-02-23  

bonny 写道

楼上两位大哥，继续双簧吧，祝福你们生意发财。我闪还不行么。

我还以为你这么声嘶力竭的为 IBM 的方案摇旗呐喊是因为真的觉得他们的东西好用，用起来很享受呢，看了你的 Blog

http://bonny.iteye.com/blog/260374

之后发现，你不也同样是一个被它折磨过的人吗？难道是自己受的苦不够，还想拉别人一起上贼船不成？

67 楼 bonny 2009-02-23  

楼上两位大哥，继续双簧吧，祝福你们生意发财。我闪还不行么。

66 楼 oth 2009-02-23  

很多公司,不愿购进更加先进的计算机,运行虚拟设备,

而是耗费更多人力去作什么转换,人比机器贵多乐呢.

减少裁员,估计是为了稳定和谐把.

65 楼 andot 2009-02-23  

bonny 写道

andot 写道

我明白你的意思，你说的那些第二个层面的转换其实是业务层数据的转换，而不是通讯协议的转换。业务层的数据转换交由业务层来做就是了，为何非要一个ESB把业务层转换和通讯层转换放到一起做呢？

分成两部分来做，效率更高，逻辑也更清楚，不是吗？

我前面的帖子说过ESB的作用至少包含了
1，协议转换
2，语义转换

1，是可插拔的。并且协议转换是必须的，因为前后端业务系统需要。通讯层是独立的，在IBM message broker消息流里面表现的是输出输入节点。
2，语义转换。ESB的语义转换层也是独立的（在IBM message broker是消息流处理节点，处理方式可以选择ESQL或者自己写JAVA程序处理）。

谁告诉你说ESB把两个放在一起做了？

我说的一起就是一个工具的意思。

协议转换我就不说了，统一的通讯方式是不需要转换的。

语义转换这里你没发现更搞笑的事情吗？“处理方式可以选择ESQL或者自己写JAVA程序处理”，既然还要自己写程序完成，我还需要这个ESB做什么？那不就是皇帝新装吗？本来就是什么都没有，不过是想把人限制在了一个 ESQL 和 Java 平台上而已。我如果要整合的两个系统一个 PHP 的，一个 ASP 的，我还要再加个 ESQL 或 Java 程序才能转换，这不是舍近求远吗？在可以进行语义转换的情况下，用任何一个语言都可以完成，PHP 也好，ASP 也好，无非就是将数据统一，相互理解嘛，何必多加一层 ESQL 或 Java 呢？

64 楼 bonny 2009-02-23  

andot 写道

oth 写道

谁能定义协议转换是必须的

把这个前提放这里,还有啥好说的.逻辑阿逻辑.

协议转换是必须的是由 IBM 定义的。所以所有被 IBM 洗脑的人都这么认为。

你无敌了。我服了。您请继续洗