Doing Ajax the SCA Way

興趣盎然的閱讀著 tempo 所作的投影片「AJAX 的 client/server 溝通機制探究」，裡面提到了「如果你流落荒島, 但是只能帶一個 AJAX Framework, 建議你帶 DWR」。這句話引起我對 DWR 極大的興趣。
其 實我們公司內部已經採用 Echo2 開發產品 (而且用的很高興)。Echo2 最大的優點是可讓我們完全擺脫 HTML、Javascript 編輯時擾人的細節，完 完全全以乾淨的 Java 程式碼開發出極為動態的 Ajax 應用程式，但相對的它的缺點是會耗費大量的 Session 資源。因此如果想要開發 Community Style 的網站時，就不適合採用 Echo2 了。所以一直以來，我對較為傾向於 stateless, 單純 RPC 導向的 ajax framework 還是保持一定的注意。
看著 DWR 的範例程式碼，讓我有種似曾相識的感覺。我突然回想起，先前在 JavaTwo 中我所介紹的 Tuscany SCA 也有提供 Ajax Remoting 的功能。再回頭去翻翻 Tuscany SCA 所提供的 ajax client 端範例程式碼，嗯！它的風格一樣也是簡潔明瞭。

以 Tuscany 設計 Ajax 的 Server 端服務
直接以 Tuscany 的範例做說明，假設我們在 Server 端有個類別如下：

public interface HelloWorldService {
    public String getGreetings(String name);
}

@Service(HelloWorldService.class)
public class HelloWorldServiceComponentImpl implements HelloWorldService {
    public String getGreetings(String name) {
        return "jsonrpcHello " + name;
    }
}

為了要讓這個類別變成 Client 端 JSON-RPC 可以呼叫的服務，我們在 sca.module 中定義其 entryPoint 及 component wire：

   
       
       
        HelloWorldServiceComponent/HelloWorldService
   

   
       
   
  

在 Client 端使用 Ajax 服務

最後，我們在 client 端就可以使用 Tuscany 所提供的 "SCA 物件"，簡單的使用 server 上的服務操作：

:

:

:

:

嗯嗯... 這裡似乎隱約就可嗅到 SCA 所強調的 unified programming model。即使使用 javascript 來呼叫 service，它的用法幾乎與標準的 Java client 沒有多大差異。

在 Ajax client 呼叫 Web Services
另 外，SCA 還有一項特長，就是可以「把別人家的 Web Services 包裝起來變成自家的元件」。這在 Ajax 手法下特別有用，因為受限於 security issues，Ajax 無法由 client 端向不同的網站發出 ajax request。透過 SCA「把別人家的 Web Services 包裝起來變成自家的元件」的特長，我們可以在 sca.module 中集成不同網站的 web services，然後用 entryPoint 匯出成可在 client 端以 JSON-RPC 呼叫的服務。 有興趣的朋友，可以參考 Tuscany 所附的 scahelloworldjsclient 範例。

一點提醒

到這裡，有朋友心動，想用 SCA 來寫 Ajax 了嗎？哎~~ 還是提醒心動的朋友，出了事情要想辦法自己解決，因為網路上很少人談到這樣的作法。而且肯定的，至少在目前為止，在網頁元素的 binding 上，SCA 所提供的支援應該較為單調。至少我還不知道，是否有內建的 function call，只要一個指令，就可以把 service 傳回 string array binding 到 html 的 select 元素上。當然自己寫也不會太難就是了！

一個問題
最後，有一個問題我納悶很久了，很想問問 tempo：既然流落荒島，那為什麼還要帶一本 Ajax 的書呢？那時候我可能會帶「與食人族共舞」或「24 小時學會獨木舟造船術」。嗯…「螃蟹的 24 種吃法」也不錯，如果有的話。

從 Separation of Concerns 談 AOP 與 SOA

AOP (Aspect-oriented Programming) 強調的是面向分割 (separation of concern)，並且試圖由程式語言 (compiler)、框架 (framework) 或執行期 (runtime) 層次對橫切物件功能的服務考量 (crosscutting concerns) 提供支援。

AOP 本身是開發應用程式框架的有力工具，透過 AOP 的手法，可以輕易解決傳統 OOP 窒礙難行的問題。例如充斥在整個系統中的橫切服務--包括日誌、交易、安全的議題，都可透過 AOP 的支援而輕易實作出來。

不過 AOP 也引入一些問題，例如透過 AOP 手法建築的系統，其元件間的互動關係較難以理解及追蹤，因此個人認為 AOP 適用於開發 application framework 的底層，但卻並不適合拿它直接來開發應用系統。

 而個人對於 SOA 所謂的 Concerns 則有二種看法：

• Business Concerns: 如何達到 (business) services independency
• 如 同 AOP 中之 crosscutting concern：這在 SOA 中給它負予了一個可怖的稱謂，叫 Enterprise Concerns，其實也不過就是 log, monitor, access rights 這些非使用者功能導向的服務需求。不過 SOA 不在程式語言、編譯器或框架(framework)上解決此議題，而在架構層級解決

SOA 之所以也能達到 separation of concerns 的訴求，完全是因為它將服務的兩端抽象化，並將呼叫訊息化。在 client 與 service 之間，可以加入許多的 proxy, router, interceptor 這樣的東東，因此可以在兩造之間加入許多的 QoS(Quality of Services, 即上述的 Enterprise Concerns)。

這樣一來，這些 QoS 就可獨立出來個別設計，再於佈署時期或執行時期動態的設定，也就達到 separation of concerns 的訴求。從這個面向來說，SOA 達到了最為動態的 AOP。不過，相對的 SOA 之切點的設定便無法如傳統 AOP 的作法 (在程式語言上下功夫) 那樣的精密了。