ESB就是又一个EJB

我听过不止一个愤青说过，SOA就是一个EJB，下场是一样的。

 

我不同意他们的这个说法，但是我其实明白他们想说什么：ESB就是又一个EJB，这个我倒是非常同意的。

 

首先我说说为什么我不同意“SOA就是一个EJB”：

SOA包括什么内容？我的观点请见http://hongsoft.iteye.com/blog/289341

1）服务的实现和封装（webservice/sca)

2）服务的管理 （服务管理库、服务总线，但是不是ESB）

3）服务的编排（BPM）

很明显，SOA不是下一个EJB。

 

但是，我认为ESB就是下一个EJB。

很明白，他们都做了些什么事情？

一般的服务总线都有如数据转换、协议转换、消息路由等等通用功能，（很黄很暴力）

而ESB还多了负载均衡、安全策略、服务监控、团队开发支持等特性。（和EJB的这些特性一样，基本就是废物）

 

我认为，我们的负载均衡、安全策略、团队开发支持 根本就不需要由这些产品来支持，我们开发人员有自己的办法来搞定他们。

所以，ESB就是又一个EJB。

评论

45 楼 SINCE1978 2015-03-05  

不同意，事实上SOA里目前能够落地的只有ESB，服务注册和流程编排都是最虚的部分，无以落地。因为脱离了SOA，ESB仍有其价值所在。而流程编排，要产生价值必须得实施得应用，这些更多是一个管理难题，至于服务注册，UDDI规范已死。

44 楼 neo_q 2008-12-11  

我个人其实蛮喜欢BEA的aqualogic，一直在用它。
如果谈到ESB是否需要上，坦率地说从SOA assessment来看，它依赖于企业本身的SOA maturity，我前面说过，ESB is not kernel，但是当你的SOA成熟度到了一定程度的时候，ESB自然顺理成章。大家可以自己研究一下SOA的成熟度的问题，相信会对SOA的实施有些体会和帮助。

43 楼 hongsoft 2008-12-11  

不知道为什么，我知道的案例，如果是买的IBM的ESB，都是用的  WMB。
这个应该是旧产品改造的“ESB”。

而 websphere ESB，好像我还没有看到过一个case。这个好像是新开发的，真正符合SOA思想和目标的 ESB产品，有人见过用这个ESB的吗？

我估计这个才是 服务总线的真正市场所在。
参与竞争的有 wesb,aqualogicSB, 说不定 我们公司也会做这个级别的 服务总线产品。

42 楼 cyberblue 2008-12-11  

如果只是业务逻辑复杂，负载大，但服务架构不复杂，完全没有使用ESB的必要，一个简单的workflow引擎就可以了。

如果架构复杂，而且负载量大，才有可能要使用ESB，这样可以把复杂的逻辑挡在业务单元里。

对于使用频度几乎不用考虑，因为牵扯的架构比较复杂，而且负载量大的业务几乎不可能直接暴露在外面。

41 楼 hongsoft 2008-12-11  

呵呵。也许大家的理解都是对的，我最新得到的信息如下：

IBM ESB
> 有三款产品：WESB、WMB、Datapower 


1)WESB更注重在企业内、部门内的交互，主要以服
务的方式集成各个应用   （就是我说的重点，我推荐大家做opensource的朝这个方向努力）
2)WMB更注重消息的可靠性、路由，更多协议，以及大数据量
处理  
3)DataPower更注重安全性与性能


我反对用后面两个，因为没有必要。

40 楼 peterkong 2008-12-11  

一般的服务总线都有如数据转换、协议转换、消息路由等等通用功能。
其实，早在EII、EIA时就已经包含“数据转换、协议转换、消息路由”，SOA我个人认为最突出的地方就是面向架构设计的概念，并且ESB就好像是AJAX，都是利用原来的老技术通过新的组合和新的想法衍生出来，至于ESB是不是EJB现在还不好说的

39 楼 neo_q 2008-12-11  

楼主，你太执着于这个E了，我个人觉得既然大家都提倡是希望轻量级的solution，OK，老板，我们都喜欢，但是问题是我们无法回避的是，现实中很多问题你是无法用轻量级来解决的。
就说ESB，如果真的我们着眼于这个E，那确实会很限制我们的思维，但是我个人的观点是看你怎么使用，你可以以轻量级的方式来使用ESB啊，但是也可以执着地一定要集中在E上面，也没有错吧。
其实ESB对于我来讲，它不像BPM，BPEL之类有明确的规范，各个厂商都是只有concept，对于没有规范的东西，我倒是觉得自由度很大的，我们爱怎样怎样。
见山是山，见水是水。

38 楼 cyberblue 2008-12-11  

hongsoft 写道

解决方案还是要靠我们程序员喜欢的方式：简单，直接，轻量。

一个程序员是这样，一队程序员呢？好几个公司的好几队程序员呢？难道每个团队都要把其他团队的文档都看一遍不成？

37 楼 hongsoft 2008-12-11  

呵呵，springhill 把这个问题理解太简单了。

我们退一步看看SOA，它强调异构拥抱异构，并且在ESB上着力强调了 “复用”和“松耦合”。
你想过没有，SOA的松耦合是怎么来的？是加了一层ESB。ESB本身的松耦合怎么做？对不起，目前的SOA方法论没有提这个事情，ESB厂商也没有提这个事情。

问题的产生还是是因为 ESB的重量级特性，带来了巨大的复杂性，已及要求 白衣归纳的“运行中心化”。

但是，运行中心化已经被证明是不可能的事情，SOA本身就是为了要解决这个问题。这不是自相矛盾吗？


所以，不是你说的 不需要就不用的问题，就好象我只想用javaBean，但是你让我用EJB的方式去用javaBean，可能吗？


解决方案还是要靠我们程序员喜欢的方式：简单，直接，轻量。
别总拿“企业”级的东西糊弄我们。

36 楼 hover1215 2008-12-11  

不用咬文嚼字了，

任何产品都有核心功能，和边缘功能。

soa 的核心就是 eai+bpm

还有其他的好多你说的那些边缘性质的功能，你没用，不见得别人不用。

每个企业的it 环境是各种各样，纷繁复杂的，有先进有落后的。

总有适用的时候。

如果，esb 是ejb。

就 好像说 大海无非就是一滴水 一样。

35 楼 springhill 2008-12-11  

不需要可以不用嘛，ESB给了你这种灵活性，有能力的团队都是这么干的，拿出来说事儿，很有趣？

34 楼 fjlyxx 2008-12-11  

[quote="neo_q负载均衡在小型应用上当然是很少的，但是在大型的企业应用上有负载均衡是绝对可以带来明显的性能提升的。
安全策略，当然你可以说你可以在别的地方来做策略管理，我不知道你对策略管理是怎么理解的，难道你直接加在service上？在ESB里面加上策略管理明显是可以灵活地插拔。
对于ESB还有一个重要的功能，在一个大型的企业中存在各种service但是这些service的实现方式肯定是有很大差异的，因为语言或者规范的差异，会导致彼此的调用或者编排不是设计中那么高的兼容性，而ESB的一个功能就是可以消除这种差异性，在真实的大型SOA项目中是绝对好用的 feature，君不见，oracle以前的ESB产品就是一堆adapter吗？

君不见，oracle以前的ESB产品就是一堆adapter吗？ 现在的产品也是一堆adapter，这个是没办法的。如果SOA是在一张白纸上架构起来的可以没有这个麻烦，适配器也有它的好处，在SOA中我们不叫这个东西为适配器（有点难听） 叫服务接入点

33 楼 hongsoft 2008-12-11  

呵呵，一起回复一下 cyberblue 和 neo_q ：

1）不用EJB，不表示不用javaBean；不用ESB，不表示不用 serviceBus。
cyberblue：serviceBus的路由管理、数据转换、协议转换 中的任何一个，都不是你说的“手写”可以完成的。
同样回复neo_q：content based routing当然是需要，这个是 serviceBus的功能特性，不是 我说的ESB的。
2）ESB的lb是对 服务总线的 lb，我举的三个例子中任何一个都没有用对servicebus的lb。
3）服务的策略是 配置级的内容，你不可能每开发一个服务，都要去ESB上面配置一把吧？  我说的产品是指 非ESB的产品，就是我说的 SOA中的另外两个组成： 服务的封装 和 BPM的实现时，进行配置。ServiceBus需要做对服务的策略的 监控和统计。

32 楼 neo_q 2008-12-11  

neo_q 写道

hongsoft 写道

呵呵，我真的没有见过 哪个企业 用到了
ESB的  负载均衡、安全策略、团队开发 功能？能否说说让我学习一下/

当然，没有 服务管理特性，就不是SOA。这个我是同意的。

晕，你没见过并非代表没有用或者不存在！
quote]

先说说我大概了解的ESB的产品使用情况：
1）js银行的ESB的总体结构是：  总行一个ESB，分行各一个ESB，部分支行还买了ESB。
   采用的是“联合ESB”架构。其使用方式和EAI并无本质区别。
本质没有区别应该是说你站在特别高的一个高度来看待这个问题的时候是这样子，但是你稍微往下面细节一下，ESB和传统的EAI差异其实是很大的，功能点和侧重完全是不一样的。
2）jt银行的ESB上面管理了 极少的服务（一个表+一个web应用就可以搞定的事情）
不在多寡而在如何管理，我举个最简单的功能，content based routing，一般的ESB都提供了这个功能，但是你自己要实现一下，你觉得这仅仅是重复发明轮子的事吗？不管从技术还是cost这都不是一个数量级的问题
3）ah电信的几个系统本来运行很正常的，买了ESB后，经常down机.....不走ESB就又正常了，但是问题就是发现不了
这只能说缺少专业人士的support，非战之罪，难道我们要因噎废食吗？你用什么不出问题？搞搞DB2估计还有一堆性能问题，难道你就不用数据库了吗？
不要受大厂商的HY，自己明白自己需要什么。
这倒是实话，厂商绝对有夸大之嫌，也不是说所有的项目都要上ESB才是一个SOA，至少在我的眼里，ESB is not SOA kernel,但是它确实提供了很多很好用的功能，让你在实际的项目中省了很多事，少了很多麻烦，这也是支持它活下去的原因。

31 楼 cyberblue 2008-12-11  

<div class='quote_title'>hongsoft 写道</div>
<div class='quote_div'>
<p>而ESB还多了负载均衡、安全策略、服务监控、团队开发支持等特性。（和EJB的这些特性一样，基本就是废物）</p>
</div>
<p> </p>
<p>那就都手写吧</p>
<p> </p>

30 楼 neo_q 2008-12-11  

hongsoft 写道

[quote="neo_q负载均衡在小型应用上当然是很少的，但是在大型的企业应用上有负载均衡是绝对可以带来明显的性能提升的。
安全策略，当然你可以说你可以在别的地方来做策略管理，我不知道你对策略管理是怎么理解的，难道你直接加在service上？在ESB里面加上策略管理明显是可以灵活地插拔。
对于ESB还有一个重要的功能，在一个大型的企业中存在各种service但是这些service的实现方式肯定是有很大差异的，因为语言或者规范的差异，会导致彼此的调用或者编排不是设计中那么高的兼容性，而ESB的一个功能就是可以消除这种差异性，在真实的大型SOA项目中是绝对好用的feature，君不见，oracle以前的ESB产品就是一堆adapter吗？

下面从技术的角度来讨论：

1）ESB或者服务总线并不是在 “大型或者 小型应用”上用的，SOA考虑的是 分布式系统，强调的是多个应用，可能是跨领域的。
2） “大型的企业应用上有负载均衡”：  这个与ESB无关。
3）“在大型的企业应用上有负载均衡是绝对可以带来明显的性能提升的。”负载均衡怎么可能提升性能呢？别开玩笑了。
4）策略当然是加在服务上的。我们有个客户强烈要求我们做到这点，呵呵。你看看现在的产品（包括开源的），策略都是在服务上的。（当然，endpoint可以统一配置一个策略）
5）我理解的策略就是ws-policy，没有感觉到有其他的需求。
6）ESB里面的策略管理，灵活地插拔什么？
7)你说的语言或者规范的差异，就是我说的 “数据转换，协议转换”。这个是需要的。

我认为我们需要的是 轻量级的服务管理功能，而不是把以前的EAI产品或者MQ改造的“新”的ESB.

1）ESB或者服务总线并不是在 “大型或者 小型应用”上用的，SOA考虑的是 分布式系统，强调的是多个应用，可能是跨领域的。
晕倒，我有在那句话里面说到这个观点吗？
3）“在大型的企业应用上有负载均衡是绝对可以带来明显的性能提升的。”负载均衡怎么可能提升性能呢？别开玩笑了。
负载均衡不是提升了单个应用的性能？我这个是开玩笑吗？
4）策略加在服务上，oh，my god。策略是经常变化不稳定的东东，而我们希望是服务相对不变和稳定不然谈何复用，将变化的和不变的分离，这是最基本的设计思想，难道你没有考虑吗？一个良好的设计是必须考虑封装变化，并且统一管理，OK？你说的产品支持策略管理在服务上，你所指的产品是指什么产品，是service specification  stack的实现产品还是service的管理产品，在不同的产品上实现了policy的支持，效果和目的是完全不同的。
5）我理解的策略就是ws-policy，没有感觉到有其他的需求
你可以简单地理解为ws-policy，可需要管理的策略如果不是集中控制，而是分布到各个服务上，你觉得哪个好？
6）ESB里面的策略管理，灵活地插拔什么？
当然是你可以任意地修改针对某个service的policy，如果将policy加在service本身上能这么灵活吗？
7)你说的语言或者规范的差异，就是我说的 “数据转换，协议转换”。这个是需要的。
消除差异，我很欣慰你我在这点上的共识

29 楼 hongsoft 2008-12-11  

这个贴子  http://hongsoft.iteye.com/admin/blogs/289341
被javaEye管理中心 hidden了。好像还扣了我30分。

呵呵，可能是怀疑我做广告？或者是 其他的什么？

看来要研究一下版规。


新编辑：我看了看，决定把与公司有关的内容和讨论去掉。

最新编辑：算了。好像编辑不了了。

28 楼 hongsoft 2008-12-11  

管理中心化，运行去中心化。

白衣这个总结很不错。

27 楼 fjlyxx 2008-12-11  

江南白衣 写道

本质上，SOA是管理中心化，运行去中心化的东东，而ESB又恰恰是一个运行中心化的东东，所以我一直对ESB的应用范围有保留意见，以为只适合战术级的使用，而不赞成那种跨层级跨部门的战略级使用。

我不认为SOA是管理中心化 ESB也是中心化的观点。实际中没办法做到，业务上是理想技术上难。SOA ESB的模型如果是中心化管理那么会搞的很复杂。

26 楼 江南白衣 2008-12-11  

本质上，SOA是管理中心化，运行去中心化的东东，而ESB又恰恰是一个运行中心化的东东，所以我一直对ESB的应用范围有保留意见，以为只适合战术级的使用，而不赞成那种跨层级跨部门的战略级使用。