最近，我們釋出了用於 Spring Roo 的 Flex Addon 的第一個里程碑版本，作為 Spring BlazeDS Integration 1.5.0.M1 分發版的一部分。此外掛旨在將 Spring Roo 的生產力和可用性優勢帶到使用 Flex 開發基於 Spring 的 RIA。下面的 15 分鐘截圖影片（分為兩部分）是對該外掛及其功能的快速介紹。觀看我們如何透過少量命令從安裝外掛到完全功能的由 Spring 支援的 Flex 應用程式。
第一部分介紹了外掛的初始下載和安裝，以及使用 SpringSource Tool Suite 中的 Spring Roo 整合進行 Spring Flex 專案的初始設定。
第二部分演示了使用“flex remoting”命令生成和更新由 Spring 和 Hibernate 支援的 Flex UI 腳手架。
Virgo 2.1.0.M02-incubator 現已可供下載。除了完成“入門指南”外，此里程碑顯著縮短了啟動時間 - 在某些系統上甚至高達5倍。
這應該進一步激勵dm Server使用者遷移到Virgo：Virgo是未來開發的 codebase，擁有更寬鬆的許可，現在提供更快的啟動速度。
我們測量了Virgo Web伺服器在熱啟動（即不帶-clean）時的執行時間，並將里程碑M02與M01進行了比較。
在四核Intel Xeon 2.66 GHz機器上，啟動時間從68秒減少到12秒，減少了……
在本系列的 第 1 部分 中，我向您介紹了一些與使用 GORM 持久化領域例項相關的細微差別。這次，我將重點關注關係處理，特別是：hasMany還是belongsTo.
GORM 提供了幾個基本的元素來定義域類之間的關係，但它們足以滿足大多數需求。當我在 Grails 上進行培訓課程時，每次都令我驚訝的是，講解關係只需要如此少的幻燈片。正如您所能想象的，這種明顯的簡單性確實隱藏了一些微妙的行為，可能會讓粗心大意的人陷入困境。讓我們從最基本的開始……
緊隨 STS 在 Eclipse 3.6 和 Gemini Web 里程碑釋出的訊息之後，我很高興地宣佈 Gemini Blueprint 的第一個里程碑版本已可供 下載。作為 Gemini 專案的一部分，Blueprint 構建在 Spring Dynamic Modules v2 程式碼庫之上，是 OSGi 4.2 Blueprint 規範的參考實現。除了反映 遷移 到 Eclipse Foundation 的更改外，1.0.0.M1 程式碼庫已升級到最新的 Spring 框架版本。Gemini Blueprint 在 Apache 許可證和 Eclipse 公共 許可證下雙重許可。
雖然將現有的 Spring DM 應用程式遷移到 Gemini Blueprint 應該很簡單，但一份 指南…
Eclipse Gemini Web 的第一個里程碑 (1.1.0.M01) 現已可供下載，採用Eclipse公共許可證和Apache許可證2.0雙重許可。
SpringSource開發了OSGi Web容器的參考實現，然後將程式碼貢獻給Eclipse，作為Gemini的Web子專案。Gemini的目標是提供Java EE技術的模組化實現。Gemini Web提供servlet和JSP技術。
Gemini Web執行在Equinox OSGi框架上並嵌入Tomcat。它還整合到Eclipse Virgo Web伺服器中。
你是 Grails 新手嗎？或者你是否遇到了第一個 GORM 的“怪癖”？如果是這樣，那麼你一定要閱讀這個關於 GORM 陷阱的系列文章。這些文章不僅會揭示那些常常讓人們困惑的小特性，還會解釋 GORM 為什麼會表現出這些行為。
希望您已經知道，GORM 是 Grails 自帶的資料庫訪問庫。它基於可能是最流行的 Java ORM：Hibernate。正如您所能想象的，Hibernate 是一個強大而靈活的庫，它為 GORM 帶來了巨大的好處。但使用它是有代價的：許多…
Eclipse Virgo 的第一個里程碑 (2.1.0.M01) 現已在Eclipse公共許可證下可供下載。它包含一個應用程式伺服器，稱為Virgo Web Server，以及一個獨立的核心。
這個里程碑的目標是讓dm Server 2.0.x 使用者能夠相對無痛地遷移到它，並擁有同樣穩定的環境。SpringSource為Virgo提供商業支援，我們鼓勵所有dm Server使用者遷移到Virgo。與使用者的主要溝通渠道現在是Virgo論壇。還有一個Virgo開發者郵件列表和每週一次的Virgo社群電話會議…
經過幾周的精細調整和社群反饋，Spring Framework 3.0.3 現已釋出。此版本修復了 Spring 3.0.2 中報告的一百多個小問題，特別是在 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訊息的結構很有幫助。
訊息的頭和屬性本質上是鍵值對。它們之間的區別在於，頭由AMQP規範定義，而屬性可以包含任意的、特定於應用程式的資訊。實際的訊息內容只是一個位元組序列，所以如果您想在訊息中傳遞文字，應該統一使用一種編碼。UTF-8是一個不錯的選擇。如果您願意，可以在訊息頭中指定內容型別和編碼，但這似乎並不特別常見。
這與繫結有什麼關係？一個標準頭稱為routing-key，代理就是利用它來匹配訊息到佇列。每個佇列都指定一個“繫結鍵”，如果該鍵與routing-key頭的值匹配，則該佇列將接收到訊息。
交換器型別的概念使情況稍微複雜化。AMQP規範定義了以下四種類型：
| 交換器型別 | 行為 |
|---|---|
| Direct | 繫結鍵必須與路由鍵完全匹配，不支援萬用字元。 |
| Topic | 與Direct相同，但允許在繫結鍵中使用萬用字元。'#'匹配零個或多個點分隔的單詞，'*'匹配恰好一個這樣的單詞。 |
| Fanout | 路由鍵和繫結鍵被忽略——所有釋出的訊息都會發送到所有繫結的佇列。 |
| Headers |
更新 我修正了關於萬用字元的資訊，它們基於點分隔的單詞或術語。
例如，假設一個釋出者向名為“Stocks”的主題交換器傳送一個路由鍵為“NYSE”的訊息。如果一個消費者建立了一個附加到“Stocks”的佇列，並且其繫結鍵為“#”、“*”或“NYSE”，那麼該消費者將收到該訊息，因為所有這三個繫結鍵都匹配“NYSE”。然而，如果訊息釋出到一個直連交換器，並且繫結鍵是“#”或“*”，那麼消費者將不會收到訊息，因為這些字元被視為字面量，而不是萬用字元。有趣的是，“#.#”也會匹配“NYSE”，儘管路由鍵中沒有點。
現在考慮一個路由鍵為“NYSE.TECH.MSFT”的訊息。給定訊息將傳送到一個主題交換器，哪些繫結鍵會匹配它？
| 繫結鍵 | 匹配？ |
|---|---|
| NYSE.TECH.MSFT | 是 |
| # | 是 |
| NYSE.# | 是 |
| *.* | 否 |
| NYSE.* | 否 |
| NYSE.TECH.* | 是 |
| NYSE.*.MSFT | 是 |
基本上就這麼簡單。透過支援每個佇列的多個消費者和每個交換器的多個佇列來提供靈活性。事實上，一個佇列甚至可以繫結到多個交換器。現在讓我們看看其中的一些場景。
AMQP代理可以充當客戶端和服務之間的RPC機制。一般的設定如下，使用直連交換器。
一般的流程如下：
從客戶端的角度來看，呼叫可以是阻塞的或非阻塞的。但是，實現哪種方式的容易程度取決於所使用的客戶端庫。
RPC場景的關鍵是確保客戶端和服務使用相同的交換器進行初始請求，並且客戶端知道要為路由鍵指定什麼。
至於回覆佇列，它通常由客戶端建立，然後客戶端會適當地填充reply_to頭。此外，雖然您可以使用與請求不同的交換器來處理回覆，但更常見的是為請求和回覆使用同一個交換器。
JMS具有主題佇列的概念，可以確保釋出者的訊息傳送給所有訂閱者。在AMQP中，您可以透過將多個佇列繫結到一個交換器來輕鬆實現相同的行為，如下所示：
更妙的是，佇列可以透過繫結鍵過濾它們接收的訊息。如果一個消費者想要接收所有訊息，它可以指定繫結鍵為“#”——正如前面提到的“匹配任意數量的單詞”萬用字元。對於普通開發人員來說，有點令人困惑的是，“*”匹配零個或一個（點分隔的）單詞。
想象一下您的應用程式有一堆需要執行的任務。透過AMQP，您可以連線多個消費者，使每個任務僅傳送給其中一個消費者。釋出者不在乎哪個消費者完成了工作，只在乎工作是否完成。這就是工作分配。
配置起來非常簡單，如本圖所示：
所以您有一個佇列繫結到交換器，有多個消費者共享這個佇列。這種設定可以保證即使有多個消費者，也只有一個消費者會處理給定的訊息。
以上是AMQP代理的三個主要使用模式。儘管我分別描述了它們，但將它們組合起來的情況也很常見。例如，在RPC模式中，您可以讓多個服務共享同一個佇列（工作分配）。最終由您來決定如何配置交換器和佇列，現在您應該已經有了足夠的理解，可以為您的具體情況找出合適的設定。
如果您想深入瞭解AMQP，請檢視規範本身，特別是“General Architecture”（通用架構）部分。要開始使用RabbitMQ，只需訪問其網站。
