程式碼高𠅙

2006/08/23

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 種吃法」也不錯,如果有的話。

2006/08/22

從 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 的作法 (在程式語言上下功夫) 那樣的精密了。

2006/07/16

從 Inversion of Control 談 SOA 與 IoC

SOA 是 IoC 的自然演化或延伸, IoC 是 SOA 的開路先鋒

  1. IoC 強調的是依賴注入,控制權反轉。在控制權反轉這事上,SOA 與 IoC 所扮演的角色相同,都是希望元件開發者所開發出來的元件,具有 "Don't call us, we'll call you" - the Hollywood Principle 的特質。然而 IoC 相形之下,著重於元件開發層次,它強調個別元件如何實作,才能達到這項訴求 (例如: type 1 IoC: interface injection, type 2 IoC: setter injection, type 3 IoC: constructor injection)。而 SOA 相形之下,則著重於系統及整體架構。SOA 提供了在系統架構層次,如何達到控制權反轉這類機制的思維。
  2. 關 於依賴注入,SOA 較之 IoC 有更高一層的訴求,即是希望達到 "沒有依賴",或是最低限度依賴的程式。IoC 導向的系統元件,可以達成兩個元件之間,僅相依於兩者間的特定介面。在這種情況下,只要這一介面關係存在,就能替換其中各別元件的實作。而 SOA 則希望能做到,讓系統中的每個元件,儘量使用同一組介面或協定,而不是依賴於其中某些元件的特定介面。如果整個系統都使用同一組介面或協定,代表整個系統 中的任意元件,都可以任意組合。為達到這樣的訴求,系統元件介面便需傾向於使用粗粒度 (coarse-grained) 的介面。
  3. 由於粗粒度的介面無法提供如細粒度 (fine-grained) 介面那樣豐富的語意,因此只好轉由介面參數身上著手,這也就是為何 SOA 強調使用文件導向的參數(亦即參數本身為一含括豐富語意的文件)
  4. 沒 有 IoC,就做不到 SOA:試想,若你的系統架構設計沒有辦法做到控制權反轉及依賴注入,又如何在系統上線後,指定元件之間的參引關係,或是將許多元件編織 (waving) 起來,成為一個作業流程呢。所以有人說,SOA 的觀念或想法並不是用來取代現有的軟體設計觀念,而是在面對模組重用或系統整合時,所需 "額外"、"附加" 考量的思維。

2006/04/26

新命運觀--運數關係、因果論,以及個體組成分子中的環境鏡像

之前曾寫過一篇文章,叫只有運數,沒有定數。那時點出一個方向:如果我們可以找出影響命運的因素,並取得一筆數量可觀的母群體,那麼透過資料探勘或相關的研究方法,要找出命運的模式,是極有可能的。
影響命運的因素,目前我所想到的,大概可分三個方向:
  1. 環境因素:這是一種機械論或系統論–給定不同個體,讓他們處在相同的結構中,會產生相同的行為(出自第五項修練:系統思考)。像是教育、家庭、朋友、國家、時代,甚至生日、八字、風水等,都可歸類到環境因素。其影響人的能力、品性、職涯與生活,至為明顯。
  2. 遺傳因素:此即基因論。像是有些文獻或書籍就直指犯罪及同性戀之傾向,跟基因有密切相關。甚至有些書籍更指出,其實基因不只影響個體的命運,也會影響整個物種及族群的命運。
  3. 個體因素:這是自由意識論。認為人是具有自由意識的個體,能夠自己控制其行為,追求想要的目標,進行決定自己的命運。大凡成功學(像是思考致富聖經書系、羊皮卷書系等)以及某些新紀元 (New Age) 思想體系,都強調意志的作用,足以改變命運,甚至昇華生命。
— *** —
命運與因果論
回 頭看看以上三類因素,其實也就代表了個體由外 (環境) 到內 (基因) 的組合。雖說是分成三類,可是這三類因素確也互相影響。以基因與環境為例,一物種的基因,實際上乃是物種在演化過程中,與環境互動下,最佳化的結果。也就 是說,其實基因裡面,已經存有一份歷史環境的鏡像。而個體的自由意識呢?雖在 New Age 的知識體系裡面,有所謂的大意志 (先天下而生的意識),但反應到現實世界,意識本身也是環境與基因作用下的產物。可見,以上三類因素,實際上是在因果論的模型下運行。
— *** —
接下來的步驟,就是針對這些因素,找到可供衡量的變數。也就是,找到一套方法,把以上的因素量化。同樣的,我們也可以把命運的結果轉成一組變數(像是事業、情感、精神),加以量化。進而找出(因數)與(果數)之間的各種關係、模式。
至此,我們可以看到,解決問題的方法已經出現。麻煩的卻是,究竟要取哪些變數當(因數)、哪些當(果數)。又,即使已決定變數,那麼量化的方式又如何,取得有無困難,這些才是讓人頭疼的地方。
— *** —
個體組成分子中的環境鏡像
為 何生辰八字與住家風水影響一個人的命運,這牽扯到個體組成分子中的環境鏡像。是這樣的,當你打從娘胎受精逐漸成形,在細胞分裂與成長的過 程中,個體的組成成分即不斷受到外在環境的影響。想像在雲層中的水氣,一旦凝聚成水滴,這顆水滴就映照著包含它的三千大千世界,這顆水滴自此就有了相的改 變。隨著環境變異的增強,水滴可能產生形態的改變、甚至是本質的改變。
同樣的,那些成長分裂中的細胞,也受到成形過程中的時空因素所影響,像鏡子或錄音機一樣,反映出其間的時間因素。傳統命學或西洋占星術之所以能有幾分準確,的確是因為它們都掌握了時間的週期性。而這週期性,足以影響個體成分之相態與質性。