敏捷開發和ESB

Question

我正致力於將我們的企業技術範式轉變爲敏捷開發。 這是一個艱難的過程，但我們幾乎在那裏！ :)

我們有數據庫管理的舊系統（曾經是Access，現在移植到.NET和MS SQL），我們正在爲我們的未來願景開發一個框架。我們希望儘可能地遷移到網絡上。但我們希望將現有系統與「即將到來」的系統整合在一起。我們不會重疊任務和功能。

我的願景是將我們用戶的所有聯繫信息移動到不同的數據庫，將這些「配置文件」鏈接回MS SQL以獲取其歷史記錄和會計信息。我們會將所有會計系統保留在桌面應用程序上，但是我們要添加的功能更多，這將極大地依賴於網絡，尤其是Ruby on Rails。

我想問題是：爲什麼ESBs？有沒有辦法在不使用複雜ESB系統的情況下創建SOA？整個想法是給K.I.S.S.無論如何。是否可以通過允許桌面/ Web /移動設備成爲接口的方式創建SOA，並保持業務邏輯的功能（當然，某些功能必須在界面上實現，但要保持最低限度）。 ESB甚至適合敏捷哲學嗎？我閱讀和研究的越多，我越少認爲！ ：/

感謝您的投入！如果您需要我澄清，請提出幾個問題，我會盡我所能做到！ :)

Answer 1

一旦框架/基礎架構就位，ESB就很適合敏捷。你會發現你可以創建一個新的系統，並與舊系統並行運行一段時間，並逐漸關閉系統的舊部分，直到只剩下新系統，沒有人會知道區別

基本的SOA只是定義服務而不是應用程序; ESB管理頻道中的服務以隱藏端點，使得升級和替換更加「敏捷」

Answer 2

整個遷移是讓我進入ESB的原因......但是ESB的整個想法似乎很難解決一個涉及大約30,000個配置文件的問題！我們正處於一些指數增長的邊緣（幾百萬個配置文件），並且可能從一條新路徑開始將是最好的。將位於MySQL DB上的條目與存儲在MS SQL DB上的數據鏈接起來有多容易？我並不想明確地重複輸入，但是可能比「整個」ESB更敏捷......我明白，使用ESB的SOA在升級和替換方面可以非常靈活，但它會是過度殺傷？ :)

Answer 3

我已經學會很快回避術語「ESB」走爲ITIS非常超載，意味着不同的事情不同的人（有時不同的事情，同一個人:-)）

關鍵是自然而然地問自己你究竟需要什麼。

將數據庫包裝爲服務可能是一個明智的選擇，尤其是如果您有多個客戶端用於此數據;你將不得不花費大量的時間來思考你的合同和範圍，但敏捷可以在這裏有很大的幫助。

現在的問題是如何調用這些服務，我認爲您需要權衡客戶端和服務更改的可能性以及您的系統將如何發展。

服務總線有助於屏蔽來自其客戶端的服務（可以是其他服務），並且此「屏蔽」可以中繼到位置，協議，格式，代碼等。 某些形式的服務總線也維護行程（需要調用什麼，什麼時候調用），但我通常不喜歡這個想法。

所以 - 你需要先問自己一個問題，我想，是你有什麼需要，開始用了多少了前期投資，你希望做（可以證明）

例如，如果最初，您對更多的點對點方法感到滿意，您的客戶可以直接致電該服務;在稍後階段，隨着服務的發展，您可以引入「中間人」來斡旋請求和響應（是的 - 如果您願意，您可以稱它爲ESB）。

或者，您可以從一個基本的「中間人」開始，這樣客戶端就不會直接調用服務，而只需要開始使用功能，並根據需求擴展功能;它可能最初是一個簡單的轉發機器。

理想情況下，您將建立在具有許多內置功能的產品之上;如果這不是一個非常具體的答案 - 但我想我的主要觀點是，「ESB」不必爲了是一個矯枉過正的問題，它只是歸結於你在第一天想要擁有的東西，而敏捷（和SOA）通過允許你漸漸發展而不是像任何大爆炸一樣幫助你。

（如果高於一切完全是胡說八道或者只是有點不清楚這是由於缺乏一個新的是在家裏生的睡眠！道歉:-)）