Spring Roo 使用心得

最近開始看了一些Spring Roo 1.1, 也試著使用在新的project裡. 用了之後覺得他的確建構web app的好幫手. 當然也有人不喜歡Roo, 不過某些他不喜歡的原因, 在1.1版的Roo已經不存在了.

我喜歡他的原因在於,

1. 建立了良好的程式範本. 從後端的Entity, 到前端的Jspx. Roo都幫我們建立清晰的結構可讓programmer遵循.
2. AspectJ 的大量使用. 剛開始接觸 AOP的人,可能都會需要一段時間的適應. 一但上手, 最會覺得AOP方便好用. Roo大量使用AOP在 Entity和Controller上. 另外值得一提的是 Roo在Entity的 AOP 同時讓 GWT的 RequestFactorye功能顯得更直覺.
3. 快速開發. 這一點, 我想是所有人對Roo的第一印象.
4. 技術整合. Roo將一些新的技術/觀念整合放在一起, 如 Spring 3, JSR 303(Bean Validation), REST…等. 以下是我比較有在用的, 詳細的清單可到官方網站上看

• JPA
• Tiles
• AspectJ
• Dojo
• GWT
• Hibernate
• JSR 303 Bean Valiation
• REST
• Spring Security
• Maven

Lingo, 讓JMS來做RPC

這一篇是一年多前在另一個blog中寫的
========================
Java programmer講到RPC(Romote Procedure Call), 多半會想到 RMI,
用RMI, 可以讓我們很容易的呼叫遠端的 mothod.

但是, RMI 有一些缺點, 其中每一個method都要 throw RemoteException, 不過最近我都用Spring framework, 他已經讓我們處理掉了這個麻煩…

另外一個RMI的缺點, 也就市本篇文章的重點, 就是method的呼叫者與被呼叫者的關係太緊密了,
也就是說, client必須指定我所要呼叫的server是在網路的哪一個位址…

JMS,則提供了一個方式,讓client (producer)送出message, 但不指定誰來收這一個message,
這種 loosely coupling 的方式, 讓我們的程式更有彈性, 但是用JMS來做RPC還是有一些麻煩的地方

* procedure送出的是message而不是 呼叫method
* 基本上 JMS是 asynchronous, 也就是說 proceudre送出message後, message還沒被處理, procedure就繼續執行下去.這與我們一般RMI 的用法不一樣.

然而Lingo 幫我們解決了這兩個問題, 透過Lingo, 我們可以讓client直接呼叫server的method (而不是發送message, 在server這端 也不用去接受message), 但是並不指定是哪一個server幫我們處理這一個method call. 這對multiple server和load-balance很有幫助.

Lingo的範例, 可以看下面這個網址, 相當簡單明瞭

http://lingo.codehaus.org/Example

附帶一提的是, lingo不但可以用 synchronous呼叫method, 另外也可以用synchronous呼叫method.

好用吧…..