Eclipse Virgo 的首個里程碑版本 (2.1.0.M01) 現已在 Eclipse 公共許可證 下 可供下載。它包含一個應用伺服器，稱為 Virgo Web Server，以及一個獨立的核心。

此里程碑版本的目標是讓 dm Server 2.0.x 使用者能夠相對輕鬆地遷移到此版本，並擁有同樣穩定的環境。SpringSource 為 Virgo 提供商業支援，我們鼓勵所有 dm Server 使用者遷移到 Virgo。與使用者的主要溝通渠道現在是 Virgo 論壇。還有一個 Virgo 開發者郵件列表和每週一次的 Virgo 社群電話會議……

Juergen Hoeller 宣佈 Spring 3.0.3 現已釋出。此小版本解決了 100 多個小問題，並與一些最近的第三方釋出保持同步。

下載 | 文件 | Javadoc API | 變更日誌 | JIRA

請注意，我們不再提供依賴下載。與 Spring 一起使用的第三方庫的推薦獲取方式是 Maven/Ivy；您也可以下載您選擇的第三方分發版本並從中獲取 jar 包。請注意，除非您想這樣做，否則沒有理由升級第三方庫：最簡單的解決方案是繼續使用您熟悉和信任的版本。

不要忘記 Spring 使用者可以在社群論壇提問，並在JIRA中報告問題。

經過幾周的最佳化和社群反饋，Spring Framework 3.0.3 現已釋出。此版本修復了針對 Spring 3.0.2 報告的 100 多個小問題，尤其是在 JSP 標籤庫和 Portlet 會話處理方面，以及 ConversionService 的細節。同樣，此版本也與最近的第三方釋出保持同步：OpenJPA 2.0 final、Hibernate 3.5.2 和 JBoss 6.0.0 M3，所有這些現在都與 Spring 3 完全相容。

請注意，與此同時，所有主要的永續性提供程式都發布了支援 JPA 2.0 的 GA 版本，甚至…

更新 我修改了第一段，以澄清 RabbitMQ 和 JMS 之間的關係。

RabbitMQ 是一款輕量級、可靠、可擴充套件且可移植的訊息代理。但與許多 Java 開發者熟悉的訊息代理不同，它不基於 JMS。相反，您的應用程式透過一種平臺中立的線級協議與之通訊：高階訊息佇列協議 (AMQP)。幸運的是，已經有一個 Java 客戶端庫，並且 SpringSource 正在努力實現一流的 Spring 和 Grails 整合——所以不用擔心需要進行底層操作來使用 RabbitMQ。您甚至可以找到公開 JMS 介面的 AMQP 客戶端庫。但是 AMQP 在操作上與 JMS 足夠不同，這可能會給習慣於 JMS 模型的 Java 開發者帶來麻煩。

為了簡化過渡，我將在本文中探討支撐 AMQP 的基本概念以及三種常見的使用場景。到最後，您應該能夠很好地理解如何配置 RabbitMQ 並透過 Spring 和 Grails 提供的 API 使用它。

交換器、佇列和繫結

就像任何訊息系統一樣，AMQP 是一種處理釋出者和消費者的訊息協議。釋出者生成訊息，消費者接收並處理它們。訊息代理（例如 RabbitMQ）的工作是確保來自發布者的訊息傳送到正確的消費者。為此，代理使用兩個關鍵元件：交換器和佇列。下圖展示了它們如何將釋出者連線到消費者

正如您所見，設定非常簡單。釋出者將訊息傳送到命名交換器，消費者從佇列中拉取訊息（或根據配置，佇列將訊息推送到消費者）。當然，首先必須建立連線，那麼釋出者和消費者如何發現彼此呢？透過交換器的名稱。通常，釋出者或消費者會建立一個具有指定名稱的交換器，然後將該名稱公開。公開方式取決於具體情況，例如可以將其寫在公共 API 文件中或傳送給已知客戶端。

訊息如何從交換器路由到佇列？好問題。首先，佇列必須附加到指定的交換器。通常，消費者會建立一個佇列並同時將其附加到交換器。其次，交換器收到的訊息必須與佇列匹配——這個過程稱為“繫結”。

要理解繫結，理解 AMQP 訊息的結構很有幫助

訊息的 header 和 properties 基本上是鍵值對。它們的區別在於 header 由 AMQP 規範定義，而 properties 可以包含任意的、特定於應用程式的資訊。實際的訊息內容只是一系列位元組，所以如果您想在訊息中傳遞文字，那麼應該標準化一種編碼。UTF-8 是一個不錯的選擇。如果需要，您可以在訊息 header 中指定內容型別和編碼，但這顯然不是很常見。

這與繫結有什麼關係？其中一個標準 header 稱為routing-key經紀人就是用它來將訊息與佇列匹配的。每個佇列都指定一個“繫結鍵”，如果該鍵與routing-keyheader，佇列就會收到訊息。

交換器型別的概念使事情稍微複雜化。AMQP 規範定義了以下四種類型

交換器型別	行為
Direct (直連)	繫結鍵必須與路由鍵完全匹配——不支援萬用字元。
Topic (主題)	與 Direct 相同，但在繫結鍵中允許使用萬用字元。'#' 匹配零個或多個點分隔的單詞，而 '*' 匹配恰好一個此類單詞。
Fanout (扇出)	路由鍵和繫結鍵被忽略——所有釋出的訊息都發送到所有繫結的佇列。
Headers (頭部)

更新 我修正了關於萬用字元的資訊，萬用字元是基於點分隔的單詞或術語工作的。

例如，假設釋出者向一個名為“Stocks”的主題交換器傳送一條路由鍵為“NYSE”的訊息。如果消費者建立一個附加到“Stocks”的佇列，其繫結鍵為“#”、“*”或“NYSE”，那麼該消費者將收到該訊息，因為這三個繫結鍵都匹配“NYSE”。然而，如果訊息釋出到一個 direct 交換器，那麼如果繫結鍵是“#”或“*”，消費者將不會收到訊息，因為這些字元被視為字面量，而不是萬用字元。有趣的是，儘管路由鍵沒有點，“#.#”也會匹配“NYSE”。

現在考慮一條路由鍵為“NYSE.TECH.MSFT”的訊息。考慮到訊息將傳送到一個主題交換器，哪些繫結鍵會匹配它？

繫結鍵	匹配？
NYSE.TECH.MSFT	是
#	是
NYSE.#	是
*.*	否
NYSE.*	否
NYSE.TECH.*	是
NYSE.*.MSFT	是

基本上就是這樣。每個佇列支援多個消費者以及每個交換器支援多個佇列提供了靈活性。事實上，單個佇列甚至可以繫結到多個交換器。現在讓我們看看其中的一些場景。

RPC (遠端過程呼叫)

AMQP 代理可以充當客戶端和服務之間的 RPC 機制。一般的設定如下，使用一個 direct 交換器

一般流程如下

1. 客戶端向佇列傳送訊息，指定：(a) 與服務匹配的路由鍵；(b) 用於接收響應的佇列名稱。
2. 交換器將訊息傳遞到服務的佇列（本例中是“ops_q”）。
3. 佇列將訊息推送到服務，服務處理完後將響應訊息發回交換器，指定與回覆佇列匹配的 routing_key。
4. 客戶端從回覆佇列中獲取響應訊息。

從客戶端的角度來看，呼叫可以是阻塞的或非阻塞的。然而，執行其中哪種方式的難易程度取決於所使用的客戶端庫。

RPC 場景的關鍵是確保客戶端和服務對於初始請求使用相同的交換器，並且客戶端知道路由鍵應指定什麼。

至於回覆佇列，它通常由客戶端建立，然後客戶端填充reply_toheader。此外，儘管回覆可以使用與請求不同的交換器，但更常見的是對請求和回覆使用相同的交換器。

Pub(lish)/Sub(scribe) (釋出/訂閱)

JMS 有主題佇列的概念，它確保釋出者的訊息傳送到所有訂閱者。您可以透過將多個佇列繫結到交換器，輕鬆在 AMQP 中實現相同的行為，如下所示

更好的是，佇列可以透過繫結鍵過濾接收哪些訊息。如果消費者想接收所有訊息，它可以指定繫結鍵為“#”——即“匹配任意數量單詞”的萬用字元。對於普通開發者來說，有點令人困惑的是，“*”匹配零個或一個（點分隔的）單詞，正如前面提到的。

工作分發

想象您的應用程式有一堆需要執行的任務。使用 AMQP，您可以連線多個消費者，使得每個任務僅由其中一個消費者處理。釋出者不關心哪個消費者完成了工作，只關心工作被完成。這就是工作分發。

配置它非常簡單，如下圖所示

因此，您有一個繫結到交換器的佇列，並且有多個消費者共享該佇列。這種設定保證無論有多少消費者，給定的訊息只會被一個消費者處理。

這些是 AMQP 代理的三種主要使用模式。雖然我分別描述了它們，但通常會結合使用。例如，您可以在 RPC 模式下擁有多個服務共享同一個佇列（工作分發）。如何配置交換器和佇列完全取決於您，現在您應該對如何為您的場景找到合適的設定有足夠的瞭解。

如果您想深入瞭解 AMQP，請查閱規範本身，特別是關於總體架構的部分。要開始使用 RabbitMQ，只需訪問其網站。

在 SpringSource 的 Groovy & Grails 培訓課程中，我們強調 Grails 站在巨人的肩膀上。其中一個巨人就是 Spring。沒有它，Grails 根本不可能開發得如此之快。它可能也不會有如此的靈活性，無法輕鬆與企業 Java 系統整合。只需看看可用的外掛數量：許多都基於支援 Spring 的 Java 庫。

在這篇文章中，我想首先探討 Grails 如何使用 Spring，然後介紹您可以訪問其原生強大功能和靈活性的各種方式。

Spring 的孩子

您可能不知道，但是當您建立一個 Grails 應用程式時，您也在建立一個 Spring MVC 應用程式。在底層，Grails 建立了 Spring MVC 的一個變體DispatcherServlet並配置了一系列 bean 來完成繁重的工作。當然，這意味著您的應用程式底層有一個 Spring 上下文——正如您稍後將看到的，您可以訪問它。

這裡有一些…

親愛的 Spring 社群，

Spring Web Flow 2.1.0 的首個釋出候選版本現已可供下載。

下載 | 變更日誌 | 文件

在此版本中，Web Flow 文件已根據所有可用更改進行了更新。請參閱文件中的“Spring Web Flow 新特性”部分以獲得良好的概覽。

Rossen Stoyanchev Spring Web 團隊

現在，大多數人可能都聽說過 Google I/O 上關於 Spring, Roo, STS 和 GWT 的公告。Ben 和 Rod 最近在他們各自的部落格帖子中介紹了這一點。如果您錯過了主題演講，我強烈建議您在 YouTube 上觀看錄影以瞭解詳情（相關部分從錄影的 1:09:00 開始）。

今天，我想提供一些詳細的步驟和說明，介紹如何使用 Roo 和 STS 建立您的第一個 GWT 應用程式。

安裝

在我們啟動 Roo shell 並開始輸入命令之前，我們需要下載並安裝所有先決條件。儘管有很多…

Grails 是一個非常出色的框架，可以快速輕鬆地開發 Web 應用程式。您還可以訪問大量外掛，這些外掛提供功能或使與其他系統的整合變得簡單方便。這些都很好，但在這篇文章中，我想談談當您的應用程式增長，您開始淹沒在控制器、領域類和其他檔案的海洋中時會發生什麼。

關注點分離

軟體架構中最有用的模式之一稱為關注點分離。其思想是將與特定特性或關注點相關的一切分組到一個單一的、自包含的單元中。該單元中的程式碼不應承擔任何其他職責。例如，Web 服務中的業務邏輯應該在一個類中，而 SOAP 訊息的處理應該在另一個類中：業務邏輯和 SOAP 處理是兩個不同的關注點。

這種模式的真正優點在於您可以將這些單元聚合到更粗粒度的關注點中，從而最終在多個級別上使用該模式。例如，假設上面提到的 Web 服務…

此版本修復了一些錯誤，釋出說明可從JIRA獲取。此版本可從 SpringSource.org 的專案頁面下載。

• 核心啟動硬超時限制已增加，以允許 dm Server 在較慢的機器上執行。
• 記錄了 OSGi web 容器中的一個限制，不支援 Tomcat 的 <context> 元素。
• 修復了 ServiceScoper 類，使其關閉所有輸入流。
• 增加了支援以容忍 File.list 偶爾返回 null，這表現為 pickup 目錄偶爾似乎無故清空自己。
• 現在使用 @Configurable 與 ServerOsgiBundleXmlWebApplicationContext 一起工作正常。

該專案正作為 Virgo 捐贈給 Eclipse 基金會。我們計劃在適當時候釋出一個 Virgo 的基線版本，它在功能上將等同於 dm Server 2.0。請參閱 Virgo 的網站瞭解更多資訊。除了 dm Server，SpringSource 將為 Virgo 提供商業支援。