ESB，形式上实现了有必要么？

公司最近要在以前的框架上加上一个mule——我更倾向认为它只是个开源的jms框架，所谓要搞产品ESB化。

 

听我这写字的情绪，大家就知道

   1.我对SOA、ESB也只停留在感念阶段，不太懂。

   2.我认为公司在做无用功。

 

先说说我们老板想要的效果

   服务器A（一个功能模块的service层和EJB层）

   服务器B（一个功能模块的service层和EJB层）

 

   服务器X，作为EBS中间服务器，主要用于调度，比如服务器C上一个控制层的类要调用业务1后显示页面给客户，业务1需要调用服务器A上的服务类aa，  服务器B上的bb，那么C就请求服务器X，X然后找aa和bb，执行后返回给C（可以是异步的，做个本地缓存队列或者）。

 

总之类似的一个东东吧，我说几点批一下。

 

1.现在应用都不建议采用分布的系统，本来需求不大，数据处理都要求不很高，一个集中服务器就够用了，为什么搞得这么复杂，局域网延迟都占主要的了。

 

2.本来UI几乎都是html，你搞一个所谓系统总线，请求都是一样地来自http，而且请求格式都一致，这跟一个web container的linstener有什么区别？

 

3.公司以前的系统本来比较旧，重用性低，更谈不上组件化，冗余代码（类似的编码）很多，弄出来这个效果，对客户来说功能一样，而且多了研发学习成本，多了分布式的不稳定性，也许可能满足以后一个手机客户端的需求，这么做还不如重构下以前的系统，使之架构更好。

 

 

好了，暂时批完了，大伙接着批，

批我，或批我公司都成

你这种场景我觉得没有太多必要，除非你们公司有更深远的考虑

你这种情况 MQ+EJB 完全可以解决你的问题  不过这种场景ESB也是有用的  最起码脚本清晰  但是还是感觉小题大做了  感觉服务的颗粒度把握的有点问题

如果只是2个应用通过ESB进行集成则没有必要，反而增加复杂性。多个应用之间可以考虑使用ESB，它提供了通信协议转换，数据格式转换功能，能降低多应用集成的复杂性。在ESB基础上可以使用BPM来实现多系统间服务的编排。