愛德華日誌

興趣盎然的閱讀著 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：

<module ... name="sampleHelloworldJSONRPC">

    <entryPoint name="HelloWorldService">
        <interface.java interface="...HelloWorldService"/>
        <jsonrpc:binding.jsonrpc/>
        <reference>HelloWorldServiceComponent/HelloWorldService</reference>
    </entryPoint>

    <component name="HelloWorldServiceComponent">
        <implementation.java class="....HelloWorldServiceComponentImpl"/>
    </component>
    
</module>

在 Client 端使用 Ajax 服務

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

:
<script type="text/javascript" xsrc="SCA/scripts/sca.js" mce_src="SCA/scripts/sca.js"></script>
:
<script language="JavaScript">
   function getGreeting() {
      var name = document.getElementById("name").value;
      var result = SCA.HelloWorldService.getGreetings(name);
      document.getElementById('greeting').innerHTML=result;
   }
</script>
:
<div id='greeting'></div>
:

嗯嗯... 這裡似乎隱約就可嗅到 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 種吃法」也不錯，如果有的話。

這是我在 JavaTwo 2006 上的講題。選定 SOA (Service-Oriented Architecture, 服務導向架構) 為主題，一方面是因為自己感興趣，另一方面也是因為 Browser 希望能在 JavaTwo 中多增加一點 JavaEE 的場次，尤其是與 SOA 或 JBI 有關的。

考量 SOA 在台灣的發展，多是由資訊大廠所推動，這導致兩個現象：1. 其目標聽眾，大抵為企業資訊決策高階主管；2. 以資訊大廠之產品作為 SOA 應用之主軸。考量 JavaTwo 之與會者，多為系統開發人員，是捲起袖子來幹的一群人，因此我將捨棄 SOA 之業務觀點，直接從系統之架構與設計出發。

由於 SOA 強調的是模組、系統間的組裝與互動，這跟物件導向所著重的，對物件行為進行精密的控制，在出發點上有些不同，這也導致在設計原則上的差異。例如，物件導向強調物件應具有屬性與行為，但是 SOA 裡面，則強調資料與服務實作的分離。

而在設計上，由於 SOA 從架構出發，其中當然就涵括了不少設計樣式，像是 Bridge、Adapter、DAO、Registry 等。透過研究 SOA，我們亦可從中觀察到這些樣式間如何彼此合作，完成更大的服務體系。

在實務上，目前 SOA 的解決方案基本上可分為兩種型式，一種是透過 Bridge/Adapter 轉接，另一種則試圖像 DCOM 一樣，定義一套共通的分散式通信協定。前者以 ESB/JBI 為代表，而後者則為 SCA/SDO。

由於 ESB 之實作通常提供了許多連接到異質資訊系統的配接器，加上它通常會配合一套 Service Registry，因此它挺適合用於統整企業內分離的資訊系統。而 SCA (Service Component Architecture) 則因統一並簡化了分散式系統的開發方式，因此相當適合用於客製化專案或商業產品的開發，另外，SCA 也很適合作為兩個企業間或兩套系統間的溝通方式。我希望能為這兩種方案各提供一個例子。

看來要講的內容有點多，我得多加注意時間的掌控才行。