【讨论】什么是ESB

我的使用后的理解就是：1.一个类似路由的转发器。2.可以统一管理webservice

说实话，大企业里动辄十几个系统，但基本都是每个系统都是属于自己的部门，除非有个高高手，能熟悉所有部门的流程，这时候集成或许有点意义，但是，正如你所说的，大企业嘛，基本这样的高高手还没有出现过。

我们公司的系统何止上百个，但是能和自己的部门扯上关系，无非3-4个，这3-4个系统只要提供自己的webservice接口就好了，而新的业务，无非也就是调用这些接口中的若干个而已，何必需要一个ESB，真扯上ESB，就有点脱裤子放屁。
上面有位哥们提到DSB，部门里那几个系统其实需要几份接口文档就足够了，加一个DSB系统徒然增加部门的预算而已。


温柔一刀同学提到想想“每个单体电脑两两通讯实现的代价”，我个人觉得这是个没有困难制造困难也要上的命题。错误在于将信息理解为发散的，但是事实上，在任何一个企业里，信息都是如此，越往底层，消息越具体，越往上层，消息越抽象，所以部门是信息的天然屏障，在部门内部，消息越具体越庞杂，在部门与部门之间，消息则趋向抽象和简洁。因为发散的无休止地两两通讯是不存在的。



ESB是建立在一个企业似乎总有人站在很高的高度来统领全局的假设上，但真的统领全局的人，大概只需要看报表，而不需要关心什么ESB

大叔只是站在企业内部部门之间看问题。好吧，我就来个具体应用场景吧：
目前酒店行业的信息化还是很低很不规范的，众多的渠道和供应商就是具体的消息发送或接收端点，如果一个渠道要跟其他的N个供应商通讯，那就要向N个地址发送N个不同协议的消息，如果仅仅是一对多，这样也是可以的，问题是每个端点都有这种需求，就是多对多，如果两两通讯，什么代价？是不是可以想象成没有网络时要实现单体电脑两两通讯。这时候ESB的意义是不是就有了？理想情况是每个端点只需要接到总线上，其他的就不用操心了。

ESB这玩意最大的优点应该是在大型项目构建中，系统与系统间的关系由网状结构转换成了星型结构，由此，衍生出很多优点：服务的高复用、消息的可适配、可扩展、缓存、监控等，还是很有吸引力
但真正在项目中的落地实施，存在一定困难的：
1。本来是你和我直接交流的，突然多了个第三者，谁来管理？管理成本等。。
2。正如前面有为大拿说的，项目中必须有一个大大拿的角色对被ESB的各大系统非常熟悉，才能实施的很好，真正大型项目中要出这么个角色还是很难的，涉及到不同的业务、不同的厂商。
目前国内真正用到ESB的项目应该还是很少的，我了解到的电信、移动的项目有使用的，但也就做做消息的转化，都是被IBM ESB了，用了才发现SB了。
总的来说，这玩意还是不要太在意的好。多花点时间做好自己的工作才是王道--

n个不同协议的端点挂到ESB上，需要实现相同的业务接口吗？ 如果不需要，查询如何被自动翻译给n个端点？如果需要，那我完全可以强制n个端点，必须实现同样的webservice接口

ESB让我第一个联想起来的，就是Windows的注册表，服务无非就是COM组件，有了注册表，Windows复用COM组件超级方便，C也因为有了注册表，Windows也很脆弱。。注册表一损坏，Windows就完蛋

是啊，你说的这个查询中心怎么实现呢？是不是需要分支聚合（Splitter Aggregator），路由（router），过滤（filter），消息格式转换（transformer），公共消息通信传输，还需要用到file，db，jms，ws等资源和服务。这不基本上正是一个ESB的实现么？

ms 真正起作用的，还是web service吧，至于其他的都不是必须的，或者说，关键还不如推进行业标准呢？

挂到ESB上的端点是要实现相同的业务接口的，但是做不到强制各个端点都实现这个接口。强势渠道和强势供应商有自己的接口，所以只能变相的实现强制接口，也就是在不能强制别人实现自己接口的情况下，在中间加一个消息转换器，实现端点到总线协议的转换。

web service只能实现基本的通讯，但是要做的事情远不止通讯。行业标准在金融业等成熟的行业已经实现了，但是在旅游业还很乱，我们也想也正在试图推行标准，对于没有自己接口的端点，相对比较容易让别人实现自己的标准，对于已经有成熟接口的端点，要完成大统，路还很长。