Java平臺已經逐漸發展為一個成熟可靠的企業應用平臺，成熟的應用平臺的一個標志則是它能夠帶動大量的衍生技術以及可以與其他技術集成的選 項。本文將詳細講述怎樣用Grails這項傳統JEE應用開發的衍生技術，結合另一項完全不同但卻可以在Java中使用的Flex技術來開發JEE。這兩 個平臺都能大幅度提高開發效率。兩者相結合則在為J2EE應用創建富客戶端的同時不影響整體的開發效率。

　　Grails的前身是一個在 JVM中運行的web應用，它使用Groovy以及其它幾個著名的框架，比如Spring和Hibernate。為了實現快速應用開發，它極為依賴 “Convention over Configuration”原則。Groovy擁有很多動態的特性，在定義組件間共同行為方面，功能非常強大。Grails采用plug-in構架，因 此很容易把它與其他框架集成，而且也很容易在應用間復用各自的功能。

　　Flex是個RIA開發套件，由它創建的SWF應用只能在 FlashPlayer下應用。這是Adobe（前身為MacroMedia）的一個新型 Flash開發套件。除了擁有豐富的widget和把各種widget粘合在一起的強大的語言之外，它還能提供一些高端通信解決方案，分布式應用程序的開 發因此變得相當容易。它使用兩種語法：MXML和ActionScript。MXML創建在XML語法之上，專門用來定義通用組件的用戶接口；而 ActionScript則用來定義組件之間的動態交互。

　　Grails和Flex的集成——難題所在

　　要把Grails和Flex這兩個建立在完全不同基礎上的框架結合起來，首先會遇到諸多通信方面的問題：

　　一個框架中的組件如何才能在另一個框架中找到正確的通信對象？

 從本質上來說，Grails實際是運行在服務器的JVM上的一個web應用框架。Flex則是擁有客戶端和（瘦）服務器組件的RIA平臺，服務器組件以web應用的方式部署。因此，這兩個框架之間的集成實際上在web應用容器內進行。

　　用戶在Flex UI發起的通信必須通過Grails組件來調用業務邏輯。那么，Flex UI組件該如何找到正確的Grails組件呢？

　　框架間如何解析彼此的數據？

　　Flex采用ActionScript來描述數據，而Grails則采用Java和Groovy對象。Flex UI向服務器發送的ActionScript對象應該被轉述為應用程序能夠理解的數據結構。這該如何實現？

　　某個用戶的修改該如何與該應用程序的其他用戶交互？

　　這是多用戶應用程序普遍存在的問題，但同時運用兩個不同的框架使得問題更加復雜。難點在于Grails應用程序，用戶通過Flex UI來啟動這個應用，但如何通過Flex UI與其他用戶通信，讓他們知道該用戶的這一動作呢？

　　在接下來的三個部分中，我們詳細討論上文提到的三個問題，尋找采用Grails和Flex的解決方案。

　　集成——尋找消息接收對象

　　一個框架中的組件如何才能在另一個框架中找到正確的通信對象呢？

　　具體到Grails和Flex的話，這個問題其實就是在問Flex組件怎樣才能找到正確的Grails組件，進而發送請求數據，或者以用戶的名義執行一些操作。為了更好的理解解決這個難點的方法，我們首先來了解一下Flex的通信子系統。

　　Flex中的客戶——服務器通信

　 　Flex的通信子系統可以分為客戶和服務器兩個部分?？蛻舨糠职四切┰试S應用程序發送或者接受消息的組件，比如RemoteObject和 Consumer組件。這些組件與服務器部分特定的“服務”對象相關聯，比如RemotingService和MessagingService。客戶組 件及其相關聯的服務器組件的結合能夠支持典型的通信模式。比方說結合Consumer、Producers和MessagingService，應用軟件 就能夠使用Publish-Subscribe機制來通信。

　　客戶和服務器件的通信通過信道（Channel）來完成。信道的實現方式并不唯一，所有信道中最重要的是AMFChannel和 RTMPChannel。 AMFChannel建立在HTTP基礎上，也就是說建立在請求－回復的構架上。它可以和MessagingService同時使用，從而支持 Publish-Subscribe構架。這種結合下，信道定期從發布中讀取新的消息，生成請求。RTMPChannel在這樣的配置下效率更高，它能夠 在TCP/IP的基礎上支持客戶與服務器間的連接。這樣一來，客戶與服務器之間能夠立即發送或接受消息。遺憾的是，Adobe免費開源的Flex實現—— BlazeDS不包含這樣的RTMPChannel實現。

　　Flex中最重要的通信基礎設施是Destinations。 Destination是通信信道的服務器端終點。一個服務提供一個 Destination，而客戶組件則通過這個Destination與這個服務相關聯。關聯的客戶組件可以向Destination發送和讀取消息。 Destinations可以由Factories創建。

　　Grails暴露的遠程接口：服務

　　如何把Flex復雜的 通信設施和Grails結合起來呢？Grails能夠識別幾類對象：域對象、控制器、視圖和服務。Grails中的每個服務都是通過外部通信信道——比如 HTTP——展示某些功能或者服務的一個對象。而在Flex中，每個服務則與一個Destination相對應。

　　這恰恰就是針對 Grails的flex-plugin所提供的解決方案。Grails中所有注明向Flex展示的服務都將在Flex框架中以Destination的形 式注冊。Grails通過一個特定的 Factory把注明的服務添加到Flex中特別配置的RemotingService。這個特定的Factory會在Grails使用的Spring上 下文中定位到對應的服務。所有這些配置都可以在services-config.xml中找到，flex-plugin會為Grails將這個文件復制到 正確的地方。

class UserService {
static expose = ['flex-remoting']
def List all() {
User.createCriteria().listDistinct {}
}
def Object get(id) {
User.get(id);
}
def List update(User entity) throws BindException {
entity.merge();
if (entity.errors.hasErrors()) {
throw new BindException(entity.errors);
}
all();
}
def List remove(User entity) {
entity.delete();
all();
}
}

　 　這段配置將UserService展示給flex客戶。下面這段MXML代碼則是對前面這段配置的應用。RemoteObject的 destination是userService，這個userService正是Grails中目標對象提供的服務名。服務對象的所有方法這下都可以作 為遠程操作調用。ActionScript可以將這些操作像一般的方法那樣調用，而方法調用的結果或錯誤也可以當作一般的ActionScript事件來 處理。

...
<mx:RemoteObject id="service" destination="userService">
<mx:operation name="all" result="setList(event.message.body)"/>
<mx:operation name="get" result="setSelected(event.message.body)"/>
<mx:operation name="update"/>
<mx:operation name="remove"/>
</mx:RemoteObject>
...結論

　　flex-plugin為Grails提供的針對集成的解決方案非常漂亮，易于使用而且幾乎是自動化的。在Convention-over-Configuration概念下，Destinations動態添加到Flex配置的時候使用命名規范。

　　數據轉換

　　框架間如何互相轉換對方的數據（本文中就是Java和ActionScript對象轉換的問題）？

　　這個問題的關鍵之處在于兩框架相交接的地方。Flex包含Java（web服務器）和ActionScript（客戶端）兩個組件。因此，Grails和Flex之間的邊界就在web服務器，而這個服務器在兩個框架內實際上都是Java應用。

　　Flex的Java組件只關注于與Flex客戶間的通信。基于ActionScript對象的AMF協議就用于這樣的數據通信。服務器內部的 Java代碼將數據轉換成ActionScript對象，這些對象在信道上實現系列化。Flex支持Java的基本類型，也支持其標準復雜類型（比如 Date或者 Collection類型）。由于ActionScript是門動態語言，因此它也支持隨機對象結構。Java對象域會轉換成ActionScript對 象的動態屬性。但把這些非類型ActionScript對象轉換成Groovy域對象的過程則沒那么直接，它會默認生成一個Map，將屬性以key- Value對的形式存儲到這個Map中。

　　Flex創建與Groovy域對象擁有同樣屬性的ActionScript類，通過注解將兩者互相關聯起來，這樣一來，數據轉換更加方便。下面的這個例子就是這樣一對關聯的Groovy-ActionScript。

注 解“RemoteClass”將ActionScript類鏈接到由alias屬性指明的Java(或Groovy)類。alias這個屬性應該包含完整 的類名。Grails中的領域類通常都添加到默認的類包。Grails類中的所有屬性都會復制到ActionScript類。這些屬性的名字都應當完全一 樣。Grails會為所有需要“id”和“version”的領域對象動態添加這兩個屬性，領域對象因此可以在與客戶端交互的時候保留這兩個信息。
結論
Flex 提供的與Java（或Groovy）間數據轉換的解決方案會導致很多重復的代碼。每個領域類都會被定義兩次，一次用Groovy（或Java）定義，另一 次用ActionScript。但是這樣一來，可以添加一些客戶端特定代碼，比如說那些單單用ActionScript編寫的控制對象顯示的代碼。這也推 動編輯器同時提供兩種代碼的自動完成功能。至于用于配置的注解則非常簡便。
多用戶
應用程序如何將某個用戶所作的修改通知到其他用戶？
對于一個能同時支持多用戶的應用程序來說，將某個用戶對共享數據所做的修改通知到其他用戶著實是個挑戰。對于其他用戶來說，這個過程可以看作是有服務器發起的通信。
單個中央結點（通常指服務器）向很多接收點（通常指客戶）發起通信的時候，發布－注冊（publish-subscribe）就非常實用。客戶在服務器上注冊之后，服務器上任何相關消息的發布，他們都會收到通知。
由于Grails可以使用Java，自然就可以用到JMS。JMS是應用程序間通信的Java標準，它支持publish-subscribe技術，而且應用程序也可以通過適配器來集成JMS。
Grails中的JMS配置
在眾多標準中，有一個特別針對Grails的jms-plugin，它添加了很多有用的方法可以用來向JMS目的地對象、向所有的控制器和服務類發送消息。在上一章中提到的UserService就可以運用這些方法在數據發生變化時通過JMS向所有的用戶發送更新消息。
class UserService {
...
def List update(User entity) throws　BindException {
entity.merge(flush:true );
if　(entity.errors.hasErrors()) {
throw new BindException(entity.errors)
}
sendUpdate();
all();
}
def List remove(User entity) {
entity.delete(flush:true );
sendUpdate();
all();
}
private def void sendUpdate() {
try　{
sendPubSubJMSMessage("tpc",all(),[type:"User"]);
} catch (Exception e) {
log.error("Sending updates failed.", e);
}
}
}

　 　服務可以決定什么時候發送什么樣的消息。無論用戶什么時候更新或刪除數據，都會發送一條包含了完整的數據列表的消息。這條消息會發送到特定話題，也就是 這里的“tpc”。任何注冊了這個話題的用戶都將接收到新數據。列表中的對象類型（本例中也就是“User”）作為元數據添加到消息中，接收對象因此在服 務器上注冊的時候特別指明他們所關注的數據類型。

　　為了讓Grails應用也能夠采用JMS，每個JMS都需要實現provider。 Apache有個免費的開源實現，只需簡單配置就能在Grails應用程序中使用。你所需要做的是把ApacheMQ類庫添加到Grails應用的lib 文件夾下，再將下列代碼段復制到connection factory所使用的conf/spring文件夾下的resources.xml中。

...
<bean id="connectionFactory"
class="org.apache.activemq.pool.PooledConnectionFactory"
destroy-method="stop">
<property name="connectionFactory">
<bean class="org.apache.activemq.ActiveMQConnectionFactory">
<property name="brokerURL" value="vm://localhost"/>
</bean>
</property>
</bean>
...在Flex中接收JMS消息

　 　目前的Flex配置僅僅包含一個RemotingService，依靠它來支持request-response類型的用戶與UserService間 交互。這個服務由flex-plugin向Grails中添加。除此之外，我們還需要一個MessagingService來支持publish- subscribe類型的交互。

...
<service id="message-service" class="flex.messaging.services.MessageService" messageTypes="flex.messaging.messages.AsyncMessage">
<adapters>
<adapter-definition id="jms" class="flex.messaging.services.messaging.adapters.JMSAdapter" default="true"/>　　　 </adapters>　　　　<destination id="tpc">
<properties>
<jms>
<message-type>javax.jms.ObjectMessage</message-type>
<connection-factory>ConnectionFactory</connection-factory>
<destination-jndi-name>tpc</destination-jndi-name>
<delivery-mode>NON_PERSISTENT</delivery-mode>
<message-priority>DEFAULT_PRIORITY</message-priority>
<acknowledge-mode>AUTO_ACKNOWLEDGE</acknowledge-mode>
<transacted-sessions>false</transacted-sessions>
<initial-context-environment>
<property>
<name>Context.PROVIDER_URL</name>
<value>vm://localhost</value>
</property>
<property>
<name>Context.INITIAL_CONTEXT_FACTORY</name>
<value>org.apache.activemq.jndi.ActiveMQInitialContextFactory</value>
</property>
<property>
<name>topic.tpc</name>
<value>tpc</value>
</property>
</initial-context-environment>
</jms>
</properties>
</destination>
</service>
...

　 　在services-config.xml文件中，我們需要添加下列這段包含了一個新的MessagingService和JMSAdapter的代碼 段。添加的這個適配器將服務中的destination鏈接到JMS資源。這個服務中還包含一個destination的配置，flex代碼中的用戶可以 通過注冊獲得這個destination的數據更新。Destination中含有很多JMS特定的配置。大部分都是常用的JMS屬性。initial- context-environment中的“topic.tpc”屬性是個可定制的ActiveMQ屬性，這個屬性將在上下文中注冊一個JNDI名為 “tpc”的話題。

...
<mx:Consumer destination="tpc" selector="type = 'User'"
message="setList(event.message.body)"/>
...

　 　Flex客戶端代碼非常簡單。消息根據選擇器（selector）被發送到特定的destination，而Consumer組件因此接受到所對應的 destination中的消息。在這個例子中，我們通過篩選器指定Consumer所關注的消息是元數據“type”屬性值為“User”的內容。無論 消息是何時收到的，消息的內容，也就是User-objects列表會被置為可顯示的內部列表。消息內容的處理和RemoteObject上“all”處 理的返回值完全一樣。

　　結論

　　Grails和Flex中將數據變化傳遞給多用戶的解決方案完全可以通過標準組件來實現。涉及到的組件數量很多，配置和實現因此相當復雜。如果配置正確的話，這個解決方案使用起來就非常方便。

　　合并解決方案

　　回顧前三章提出的解決方案，你會發現還可以把他們合并起來得到一個更為通用的解決方案來實現Flex/Grails應用程序客戶與服務器間的關于領域狀態信息的通信。本章節中，我們要討論的就是這樣一個更為通用的解決方案。

　　泛化服務器端代碼

　　問題1和3的解決方案所需要的服務器端的代碼可以合并到同一個Groovy服務中。我們將把它指明為針對User領域類的服務。通過Groovy這樣一門動態語言，要把這樣一個服務泛化到面向所有領域類的操作非常容易。

import org.codehaus.groovy.grails.commons.ApplicationHolder
class CrudService {
static expose = ['flex-remoting']
def List all(String domainType) {
clazz(domainType).createCriteria().listDistinct {}
}
def Object get(String domainType, id) {
clazz(domainType).get(id)
}
def List update(String domainType, Object entity)
throws BindException {
entity.merge(deepValidate:false, flush:true)
if (entity.errors.hasErrors()) {
throw new BindException(entity.errors)
}
sendUpdate(domainType);
all(domainType);
}
def List remove(String domainType, Object entity) {
entity.delete(flush:true);
sendUpdate(domainType);
all(domainType);
}
private def Class clazz(className) {
return ApplicationHolder.application.getClassForName(className);
}
private def void sendUpdate(String domainType) {
try {
sendPubSubJMSMessage("tpc", all(domainType), [type:domainType]);
} catch (Exception e) {
log.error("Sending updates failed.", e);
}
}
}

　 　要實現這個目的的關鍵在于讓客戶來決定返回的領域類型。出于這個目的，我們需要為所有服務引入一個參數，通過這個參數為服務器鑒定各個領域類型。很明 顯，對于這個參數來說，領域類型的類名是無非是最好的選擇。為所有領域對象提供C(reate)R(etrieve)U(pdate)D(elete)操 作的服務被稱為CrudService。

　　一旦有任何數據更改，CrudService都會向JMS話題發送更新消息。這個更新消息包含了應用程序所知道的完整的領域對象列表。為了讓用戶來決定這是否是自己心儀的更新內容，領域類型的類名將以元數據方式添加到消息中。

　　客戶端代碼

 解決方案1和3中的客戶端ActionScript代碼也可以綜合到同一個類中。這個類的實例可以用來管理客戶端某個特定領域類型的所有實例集。

public class DomainInstancesManager
{
private var domainType : String;
public function EntityManager(domainType : String, destination : String) {
this.domainType = domainType;
initializeRemoteObject();
initializeConsumer(destination);
}
private var　_list : ArrayCollection = new ArrayCollection();
public function get list () : ArrayCollection {
return _list;
}
private function setList(list : *) : void {
_list.removeAll();
for each (var o : * in list) {
_list.addItem(o);
}
}
internal static function defaultFault(error : FaultEvent) : void {
Alert.show("Error while communicating with server: " + error.fault.faultString);
}
...
}

　 　實現客戶端的ActionScript基本上包含兩個組件：簡化request-response對話的RemoteObject和用于 producer-subscriber對話的Consumer組件。上一章節中，這些對象通過MXML代碼實現初始化，但他們也可以通過 ActionScript來創建。上面這段代碼段顯示的是這兩個組件共同使用的結構：包含了實例和錯誤處理的列表。包含實例的列表根據任何一個通信組件發 送的消息而更新。

　...
private var consumer : Consumer;
private function initializeConsumer(destination : String) : void {
this.consumer = new Consumer();
this.consumer.destination = destination;
this.consumer.selector = "type ='" + domainType + "'";
this.consumer.addEventListener(MessageEvent.MESSAGE, setListFromMessage);
this.consumer.subscribe();
}
private function setListFromMessage(e : MessageEvent) : void {
setList(e.message.body);
}
...

　 　這里這段代碼顯示的是Consumer如何通過ActionScript來構建，這段代碼用來接收服務器端發送的消息。Consumer的 selector屬性僅僅用來接收那些包括了元數據中所指明的領域類型的消息。無論什么時候接收到這樣的消息，event handler都會被調用，并且列表也會得到更新。

　　接下來這段代碼段將RemoteObject設置為request-response型通信的一個結點。所有必要的操作都作為操作屬性而添加到RemoteObject上，客戶因而很容易調用這些操作。

...
private var service : RemoteObject;
private var getOperation : Operation = new Operation();
public function initializeRemoteObject() {
this.service = new RemoteObject("crudService");
var operations:Object = new　Object();
operations["all"] =　new　Operation();
operations["all"].addEventListener(ResultEvent.RESULT, setListFromInvocation);
operations["get"] = getOperation
operations["remove"] = new　Operation()
operations["remove"].addEventListener(ResultEvent.RESULT, setListFromInvocation);
operations["update"] = new　Operation()
operations["update"].addEventListener(ResultEvent.RESULT, setListFromInvocation);
this .service.operations = operations;
this .service.addEventListener(FaultEvent.FAULT, defaultFault);
// Get the instances from the server.
this.service.all(domainType);
}
public function get(id : *, callback : Function) : void {
var future: AsyncToken = getOperation.send(domainType, id);
future.addResponder(new CallbackResponder(callback));
}
public function update(entity : Object) : void {
service.update(domainType, entity);
}
public function remove(entity : Object) : void {
service.remove(domainType, entity);
}
private function setListFromInvocation(e : ResultEvent) : void {
setList(e.message.body);
}
...

　 　大部分方法都將任務委派到服務的其中一個操作。所有這些操作都不會阻塞其它操作，同時它們都是異步操作。服務的返回值無論什么時候都會由注冊的事件處理 器（eventhandler，本例中為setListFromInvocation）來處理，這個處理器同時還會更新列表。由于返回值在很多地方都會用 到，“getOperation”就顯得有點特別。CallbackResponder只有注冊了調用才能得到該調用的返回值。答復方也將調用一個 Function來處理剛接收到的消息的內容。

import　mx.rpc.IResponder;
import　mx.rpc.events.ResultEvent;
public　class CallbackResponder implements　IResponder {
private　var callback : Function;
function CallbackResponder(callback : Function) {
this .callback = callback;
}
public　function result(data : Object) : void　{
callback(ResultEvent(data).message.body);
}
public　function fault(info : Object) : void　{
DomainInstancesManager.defaultFault(info);
}
}使用通用的類包

　 　怎樣使用這個通用的類包呢？我們來看一個例子，這個例子中我們要實現的是在第二個解決方案中提到的管理User對象的實例。下面這段MXML代碼定義了 一個PopUpDialog，這個PopUpDialog可以用來編輯系統中Users的詳細信息。這個對話框的外觀就如左圖所示。實例變量 “manager”為User領域類型初始為一個DomainInstanceManager實例。界面中包含了所有捆綁到這個manager的list 屬性的用戶的列表。它顯示了用戶的displayName值。

<mx:TitleWindow xmlns:mx="//www.adobe.com/2006/mxml" xmlns:users="users.*" title="User Manager">
<mx:Script>
<![CDATA[
import crud.DomainInstancesManager;
import mx.managers.PopUpManager;
[Bindable]
private var　manager : DomainInstancesManager = new DomainInstancesManager("User", "tpc");
private function resetForm() : void {
selectedUser = new User();
secondPasswordInput.text = "";
}
private function　setSelected(o : Object) : void
{
selectedUser = User(o);
secondPasswordInput.text = selectedUser.password;
}
]]>
</mx:Script>
<users:User id="selectedUser"
displayName="{displayNameInput.text}"
username="{usernameInput.text}"
password="{passwordInput.text}"/>
<mx:List height="100%" width="200" dataProvider="{manager.list}" labelField="displayName"
itemClick="manager.get(User(event.currentTarget.selectedItem).id, setSelected)"/>
<mx:VBox height="100%" horizontalAlign="right">
<mx:Form>
<mx:FormItem label="Display Name">
<mx:TextInput id="displayNameInput" text="{selectedUser.displayName}"/>
</mx:FormItem>
<mx:FormItem label="User Name">
<mx:TextInput id="usernameInput" text="{selectedUser.username}"/>
</mx:FormItem>
<mx:FormItem label="Password">
<mx:TextInput id="passwordInput" text="{selectedUser.password}" displayAsPassword="true"/>
</mx:FormItem>
<mx:FormItem label="Password">
<mx:TextInput id="secondPasswordInput" text="" displayAsPassword="true"/>
</mx:FormItem>
</mx:Form>
<mx:HBox width="100%">
<mx:Button label="New User" click="{resetForm()}"/>
<mx:Button label="Update User" click="{manager.update(selectedUser);resetForm()}"/>
<mx:Button label="Remove User" click="{manager.remove(selectedUser);resetForm()}"/>
</mx:HBox>
<mx:Button label="Close" click="PopUpManager.removePopUp(this)"/>
</mx:VBox>
</mx:TitleWindow>

　 　一旦點擊列表中的數據項，你就可以從服務端讀取對應的user對象的數據，這些數據存儲在界面的“ selectedUser”中。這個屬性在MXML中定義，因此很容易用來與表單中的域綁定。 “selectedUser”屬性的屬性和表單中的input域是雙向綁定，所以“selectedUser”屬性值的改變（由服務器端的事件引發的修 改）會影響到input域，而input域的值的改變（由用戶輸入值所引發的修改）也會影響到“selectedUser”屬性值。界面上的按鈕是鏈接到 manager的方法，這個方法的參數就是“selectedUser”屬性值。方法調用的結果會影響到manager維護的表單，也會影響到界面上顯示 的列表內容，因為這兩者也是互相綁定的。

　　注意事項

　　需要注意的是，在使用這個通用類庫的時候，你需要在客戶端維護一個包含了系統所識別的某個特定類型的所有對象的列 表。有些你所期望使用的引用數據和數據本身可能會在實例的數量上有一定的限制，這沒什么問題。另外還有一些數據你可能不是必須的，甚至不可能維護一個完整 的列表，這時候你可以在這個完整的表單的子集上采用同樣的原理。

　　有趣的是，無論客戶何時修改數據（無論是保存、更新或是刪除領域對 象），他都會得到一個包含了新的列表的回復。他還會接收到一個消息表明其他用戶也都收到了更新的列表。因此，用戶會因為自己的每個修改而收到兩條更新消 息。第一條（針對他請求的回復）可以被丟棄，但這條消息會添加到系統中，因為直接回復常常比通過JMS發送消息更費時間。

　　另外一個值得 提及的是，由于消息中包含的更新（本例中就是完整的列表）來自于不同的信道，這個模型中可能存在并發問題。消息有可能被延遲，用戶可能在收到一個更新消息 之后再收到收到上一個更新的消息。這也意味著用戶看到的是失去實效的數據。解決這個問題的一個方法是在消息中添加一個序列號，然后在每次接收消息的時候通 過檢驗這個序列號來查看這條信息是否是最新的。

　　結論

　　通用的類包以易于使用的形式包含了前面幾章中討論的解決方案。

　　本文中提到的解決方案能夠為開發使用Flex和Grails的JEE應用程序提供堅固的基礎。采用這個工具箱的JEE開發人員的開發將可以更快、更敏捷，也許更重要的是開發將變得更有趣！

　　關于作者

 Maarten Winkels是具有五年Java和JEE開發經驗的軟件開發工程師和咨詢師。他最近從荷蘭搬遷到印度，宣傳Xebia所提供的分布式敏捷開發過程。 Xebia是一家專于Java技術、海外Agile項目、Agile咨詢和培訓、IT構架和審核的公司。