我來講講實務面
原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. 特定軟體對硬體要求高，使用場景特殊(例，安全需求)，因此無法輕易
: 放上雲端
: 以上是我自己的淺見，不知各位有什麼經驗與想法呢？