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

雲中的訊息演進

隨著組織越來越多地在雲環境中構建和部署應用程式，支援這種新模型的基礎設施也在不斷發展。需要一種新型的輕量級、可靠、可擴充套件和可移植的訊息系統，以支援將使用者請求路由到適當的資源，無論它們位於何處。RabbitMQ在該領域處於領先地位，並在雲訊息方面展現了顯著創新。

RabbitMQ之所以非常適合雲，主要有三個原因

• 開放性：RabbitMQ是開源的，擁有一個開放和活躍的社群，並且基於開放標準。開放性將是成功的雲平臺的關鍵因素，因為如果雲最終只是另一種供應商鎖定，那麼它將失去很多吸引力。
• 靈活的可擴充套件性：RabbitMQ能夠以多種不同方式進行擴充套件，不僅包括技術上的橫向擴充套件，還包括跨服務擴充套件的聯合訊息傳遞，直至地理分散式擴充套件。
• 基於協議：RabbitMQ是一個基於協議而非API的訊息系統。這意味著訊息客戶端不依賴於供應商安裝的庫，這增加了應用程式的可移植性，並允許來自各種不同平臺的客戶端訊息傳遞。這種方法還允許RabbitMQ支援多種協議，從而增加了它在雲等異構環境中的實用性。

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

這對你意味著什麼？

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

我們熱愛並致力於各種語言和平臺（超越 Java）的多樣性，開發者正是透過它們使用 Rabbit。訊息傳遞技術的部分價值在於其跨平臺的能力。

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

這種 Spring 整合將包含兩個要素

• 與 Spring 的 JMS 支援類似的低層整合。這將包括一個 RabbitTemplate，它提供簡單的傳送和接收操作，並委託給 MessageConverter 以支援 POJO 訊息模型。除了模板之外，我們還將透過 MessageListenerContainer 和 MessageListenerAdapter 提供“訊息驅動 POJO”的支援，它們與 Spring 的 JMS 支援中的同名元件非常相似。當然，我們還將管理低層資源以及事務。所有這些都將適用於 Java 和 .NET，我們正在設計高階 AMQP 層，以便它將來可以支援多種實現。
• Spring Integration 支援。這將包括通道介面卡，用於將 Spring Integration 訊息通道連線到傳送端的 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 之上。開發者可以使用宣告式、配置驅動的方法來解決整合問題，例如轉換、路由、拆分和聚合，同時保持與基於 POJO 的業務邏輯的清晰分離，業務邏輯可以輕鬆地獨立測試。Spring Integration 的訊息通道抽象提供了程序內和程序間訊息傳遞之間的一致性。它還將應用程式程式碼與任何特定的傳輸或協議解耦。這與 Spring 的一般哲學非常吻合，即可移植性不應要求程式碼更改，技術選擇不應導致鎖定。透過將 RabbitMQ 新增到傳輸選項中，開發者將擁有更多選擇，並且能夠立即在 RabbitMQ 和任何其他受支援的傳輸之間建立橋樑。

我寫這篇部落格有點晚了。新聞界、部落格圈和 Twitter（它一直是一個熱門話題）已經對 SpringSource/Rabbit 議論紛紛。（這提醒我：最近我在 Twitter 上比在我的部落格上活躍得多，我鼓勵您在springrod關注我。）

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