我来讲讲实务面
原PO可以先用看看Open Source ActiveMQ当做middleware
http://activemq.apache.org/
毕竟用IBM MQ或Tibco RV都不是一般小公司付得起
原PO如果理解松散耦合的概念，应该也认同"针对interface定义"
所以要定义spec，虽然说没有规定什么格式，但用XML好处还蛮多的
每个XML定义一个功能，也就是message，这些message透过middleware
在新旧系统之间传送
新旧系统需要针对端口增加adapter功能，主要就是处理interface的转换
这当中可能会有一些business model要做细部处理
例如A系统把message丢到B系统传送一份询价单，丢到C系统确认库存
A系统要等到B、C回传结果message才能做后续处理
另外因为采用了middleware，各系统间的通讯由middleware管理
就不用各系统互相建立连线，降低了管理上的难度
管理上就要确保middleware不要挂点
当然如果连一个messsage也不漏失、具有failover、load balancing与跨router
功能，IBM MQ或Tibco RV或许是更好的选择
※ 引述《fayhong (恰似飞鸿踏雪泥)》之铭言：
: 最近碰到客户对 ESB (Enterprise Service Bus) 这种架构情有独钟，
: 不知道诸位 300W 年薪的大师们，对这个产品在导入时有什么经验，
: 可以分享给我涨姿势一下吗？
: 文有点短，好，我先说我的想法。
: 首先，我没有使用 ESB 的经验，所以不能说好或坏，所幸我走过 Java
: 的黄金岁月，却没有使用过 ESB，不知这是好还是不好。
: 然而，在 legacy 系统较多的企业环境里，需要 ESB 做一个抽象层整合，
: 好让旧系统间盘根错节的串接关系可以进行解耦，增加后续系统的维护度
: 以及未来新系统的建置弹性。
: 以上，是我对 ESB 的使用场景的想法，必须存在在几个前提之下得以发挥：
: 1. 有很多 legacy 系统与封闭架构的套装软件
: 2. 系统间相依性复杂，缺乏清楚明确分界，内部关系与资料串接紊乱
: 3. 公司对于私有云缺乏管理能力，故需再买一套套装软件来管理其他的套
: 装软件，而不是叫大家都上私有云
: 4. 特定软件对硬件要求高，使用场景特殊(例，安全需求)，因此无法轻易
: 放上云端
: 以上是我自己的浅见，不知各位有什么经验与想法呢？