我很高興地宣佈，VMware 旗下的 SpringSource 部門已收購 Rabbit Technologies Ltd.，該公司是流行的開源雲訊息傳遞技術 RabbitMQ 背後的公司。此次收購將增強我們的中介軟體產品組合，並加速我們的雲計劃。

雲中的訊息傳遞演進

隨著組織越來越多地在雲環境中構建和部署應用程式，支援這種新模型的 Infrastructure 正在不斷發展。需要一種新型的輕量級、可靠、可伸縮和可移植的訊息傳遞系統，以支援將使用者請求路由到適當的資源，無論它們位於何處。RabbitMQ 是該領域的領導者，並在雲訊息傳遞方面展示了重要的創新。

RabbitMQ 非常適合雲環境，主要有三個原因

• 開放：RabbitMQ 是開源的，擁有開放且活躍的社群，並基於開放標準。開放性將是成功構建雲平臺的關鍵因素，因為如果結果只是另一種形式的廠商鎖定，那麼遷移到雲端將失去很多吸引力。
• 靈活的可伸縮性：RabbitMQ 能夠以多種不同方式進行伸縮，不僅包括技術性的橫向伸縮，還包括跨服務伸縮的聯合訊息傳遞，直至跨地域的多樣化伸縮。
• 基於協議：RabbitMQ 是一個基於協議而非基於 API 的訊息傳遞系統。這意味著訊息客戶端不依賴於廠商安裝的庫，這提高了應用程式的可移植性，並允許客戶端從各種不同的平臺傳送和接收訊息。這種方法還使 RabbitMQ 能夠支援多種協議，從而提高了它在雲等異構環境中的實用性。

事實上，Rabbit 在雲場景下的適用性已透過雲服務提供商和構建私有云的組織（例如 NASA Nebula）的採用得到了實踐驗證。

這對您意味著什麼？

如果您是 RabbitMQ 社群的成員，這是個好訊息，也是對您技術選擇的進一步重要肯定。RabbitMQ 將繼續保持開源，並以與以前相同的方式分發。社群可以期待對這項傑出技術投入更多資源，這將顯著改進開源版本。RabbitMQ 社群還可以期待獲得 SpringSource 對其其他開源社群（如 Spring、Grails、Groovy 和基於 Apache 的技術）提供的同樣的奉獻和支援。

我們熱愛並致力於開發者使用 Rabbit 的多樣化語言和平臺（不僅限於 Java）。訊息傳遞技術的部分價值在於其跨平臺能力。

正如您可以預期的那樣，我們將為 Spring 社群構建一種特別引人注目的體驗。直接使用 Spring 或透過 Grails 使用 Spring 的企業開發者可以期待 RabbitMQ 作為訊息傳遞系統的出色整合。這將為開發者提供更多靈活性和選擇來構建他們的應用程式，同時確保他們開發的應用程式可以更輕鬆地從開發者桌面遷移到虛擬或物理資料中心，再到雲端。

這種 Spring 整合將包含兩個方面

• 類似於 Spring JMS 支援的低階整合。這將包括一個 RabbitTemplate，它提供簡單的傳送和接收操作，並委託給 MessageConverter 以支援 POJO 訊息傳遞模型。除了模板之外，我們還透過 MessageListenerContainer 和 MessageListenerAdapter 提供對“訊息驅動 POJO”的支援，它們與 Spring JMS 支援中的對應項非常相似。當然，我們將管理低階資源以及事務。所有這些都將適用於 Java 和 .NET，並且我們正在設計高階 AMQP 層，以便將來可以支援多種實現。
• Spring Integration 支援。這將包括通道介面卡（Channel Adapters），用於將 Spring Integration 訊息通道（Message Channels）連線到傳送端的 AMQP 交換機（Exchanges）和接收端的 AMQP 佇列（Queues）。雖然這些介面卡建立在上述低階支援的基礎上，但它們進一步抽象了程式設計模型，以便終端使用者可以在純 POJO 服務層之上依賴 Spring Integration 配置。

後者尤為重要。Spring Integration 是最令人興奮的 Spring 專案之一，它提供了 Spring POJO 程式設計模型自然地擴充套件，以處理企業整合模式。我們看到社群和客戶對 Spring Integration 的興趣日益高漲，並正在大幅增加對其開發的投資。正如 Spring 依賴注入提供了一種抽象，避免了使用 JNDI 等低階 API 的需求，簡化了應用程式程式碼並將其與部署問題解耦一樣，我相信許多（如果不是大多數）非同步模式最好在更概念化的層面表達，就像 Spring Integration 那樣，而不是直接使用訊息傳遞 API 和協議。

Spring Integration 允許開發者利用同步和非同步訊息傳遞，而無需實現監聽器介面或編寫依賴於模板的程式碼。它支援 企業整合模式 (Hohpe/Woolf)，直接構建在 Spring Framework 之上。開發者可以使用宣告式、配置驅動的方法來處理整合問題，例如轉換 (Transformation)、路由 (Routing)、拆分 (Splitting) 和聚合 (Aggregation)，同時與易於獨立測試的基於 POJO 的業務邏輯保持清晰的分離。Spring Integration 的 Message Channel 抽象提供了程序內和程序間訊息傳遞之間的一致性。它還將應用程式程式碼與任何特定的傳輸或協議解耦。這與 Spring 的總體理念非常吻合，即可移植性不應需要修改程式碼，技術選擇不應導致鎖定。透過將 RabbitMQ 新增到傳輸選項中，開發者將擁有更多選擇，並能夠立即在 RabbitMQ 和任何其他支援的傳輸之間建立橋樑。

這篇部落格我有點晚了。媒體、部落格圈和推特（RabbitMQ 是熱門話題）已經對 SpringSource/Rabbit 議論紛紛。（這讓我想起：我最近在推特上比在部落格上活躍得多，我鼓勵大家在 springrod 關注我。）

然而，請允許我率先歡迎 RabbitMQ 社群加入 SpringSource 大家庭，並鼓勵 SpringSource 社群瞭解如何開始使用 RabbitMQ。