ESB就是又一个EJB

[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.

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

晕，你没见过并非代表没有用或者不存在！
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,但是它确实提供了很多很好用的功能，让你在实际的项目中省了很多事，少了很多麻烦，这也是支持它活下去的原因。

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