我們在生產環境中有多個版本的Web服務（包括REST和SOAP），並且每個版本的編號都越來越大。Web服務版本控制：是ESB矯枉過正？
在版本之間，可能會對請求和響應進行較小的更改（通常是添加新字段）。
如果我們要退休舊版本，我們如何繼續爲舊版本提供服務？
可能的解決方案的一個方面涉及創建「虛擬端點」，以將對先前版本的請求路由到相同服務的新版本。因此，/ v1/customer/1的請求映射到/ v2/customer/1。我們正在使用Mashery，通過它可以很容易地完成。
我們還希望將轉換規則應用於請求和響應，以生成符合舊合同的XML和JSON響應。
總而言之，我們需要將路由和轉換規則應用於所有傳入消息和響應。 ESB是否過分矯枉過正？我們的標準並不完全符合http://blogs.mulesoft.org/to-esb-or-not-to-esb/中列出的標準。有一個更簡單的解決方案來解決這個問題嗎？一個不需要修改我們的代碼來實現請求和響應的版本控制？
如果刀具適合...
如果你正在尋找它要給滿足您的版本控制和改造需求，然後繼續使用它的ESB。
你不想要的是「哦，這裏是我們的ESB在爲我們的一個Web服務傾聽我們的一個端點」。這簡直是瘋了。
對我來說，ESB很適合你的需求。你不必檢查所有的框。事實上，你需要覈對的唯一一個框是「這個工具是值得的資源和時間來學習，利用，支持和部署在我們的環境與我們更舒適的東西」工作箱。
因爲像ESB這樣的軟件存在的一個問題是它們可能帶有很多東西，因此很多文檔對於平臺中的新手來說很難做到，並且選擇合適的東西，以及如何配置它。
我會抓住一個ESB並做一個飛行員，然後做一些性能測試。如果你不會在飛行員身上耗費大量時間，而且它看起來似乎運作良好，然後隨它一起滾動。
有一些像IBM這樣的公司專門爲您的用例構建軟件。他們基本上有一個服務註冊服務器。服務註冊表充當您所有服務的別名。更重要的是，大多數服務註冊表服務器都有一個工作流程，人們可以使用該工作流程來提升，降級，日落，版本，並通知服務的用戶某些事情已發生變化。大多數人稱之爲工作流...治理。
謝謝。這個答案使我能夠實現服務註冊的開源ESB。 Apache Synapse帶有一個與我上面描述的完全一致的例子。正如另一個人所建議的那樣，我可以用它來做一個飛行員。 – 2011-04-16 13:48:26
嘗試UltraESB [http://adroitlogic.org]，其中顯示了許多關於如何執行路由和轉換的示例。您還可以使用基準測試http://esbperformance.org加載測試任何ESB，以瞭解它們在路由，轉換等方面的表現有多快。它是一個小的（〜35MB）ESB，不需要更改代碼或具有陡峭的學習曲線 - 在編寫時你的路由規則是一些Java行，甚至是Javascript，Ruby，Groovy等 - 無論你知道哪種JSR 223腳本語言。
對於這個解決方案，ESB可能是矯枉過正的。儘管我們可能會棄用舊版本，並且有新版本，但仍會嘗試使用舊版本服務的客戶端程序會發生什麼情況。
如果我們在新版本的服務中更改了請求/響應格式，那麼嘗試發送舊請求格式並期望舊響應格式的客戶端將會失敗。所以我們不能也不應該將舊的服務版本突然離線，但是將其逐步淘汰。爲此，我們需要並行運行新舊服務，至少需要一段時間。
因此，引入ESB並不能解決問題。當我們真正退休的舊服務，經過一段時間，允許客戶使用舊的遷移到新的，然後我們可以重新指引舊的URL到新的。但是，我們不需要ESB來做到這一點，因爲像httpd mod_proxy或nginx這樣的簡單解決方案可以完成這項工作。
ESB對於在客戶端和實際端點之間添加消息中介的增值功能非常有用。因此，無論在哪裏有so many performing ESBs，都應該保持它適合這種情況的簡單而智能的解決方案。
我喜歡做飛行員的想法。如果運行太困難，那麼我可以排除使用該特定框架。應該有足夠輕量級來支持我們的用例，但不會阻礙。 – 2011-04-16 13:49:19