用于判断是否选用ESB的检查清单
- 你是否在集成至少3个应用/服务?如果你只需要在2个应用之间进行通信,使用点对点集成会更简单。
- 你是否真的需要在未来插入更多的应用?尽量避免架构中有多余之物。更好的方式是保持简单,然后在需要时再重新构架。
- 你需要使用的通信协议类型是否多于1种?要是你只使用HTTP/Web服务或只使用JMS,那么你就无法从Mule提供的跨协议消息传递和转换中得到任何好处。
- 你是否需要消息路由功能,如分裂(forking)和聚合(aggregating)消息流,或基于内容的路由?许多应用并不需要这样的功能。
- 你是否需要发布服务供其他应用消费?这非常适合用Mule,因为它提供了一个健壮和可伸缩的服务容器,但是在Erik的用例中,他们所需要的只是一个来自他们前端Struts应用的HTTP客户端。
- 你是否有超过10个的应用要集成?避免大爆炸式的项目,考虑把这种项目分割成更小的块。首先把你的架构在3到4个系统中进行试验,在它对其他系统产生影响前把所有问题都搞定。
- 你是否真的需要ESB的伸缩性?应用的伸缩性需求非常容易被过度构架。Mule对伸缩性的支持使它成为了“内建”伸缩性的流行选择。但是,这要付出代价,因为你给架构中增加了一种新技术。
- 你 是否确切地理解了架构的目标?厂商往往把ESB描述成一个盒子,有许多应用环绕在其周围。实际上,这并不是它的工作方式。围绕集成点、协议、数据格式、 IT基础设施、安全等一开始有大量细节需要了解。从小做起有助于控制问题的范围,使莫名其妙的问题降至最少。在你了解你的架构并适当地划定范围之前,你都 无法真正判断ESB是否对你合适。
- 通常来说,总要验证产品解决方案是否符合你的需要。不要选择ESB或其他任何技术,仅仅因为:
- 让你的简历好看
- 虽然今天我不需要这些特性,但是将来有一天我可能会用到它们
- 我和销售们的老大一起渡过了一个相当不错的高尔夫周末