愛德華日誌

興趣盎然的閱讀著 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 種吃法」也不錯，如果有的話。

與其說這是一篇對 2006 年的預測，不如說這份清單是我看到，目前正在發生的事情。不過既使不是預測，其中也充滿了個人觀點，也許你會有不同的看法，歡迎交流囉!

關於應用系統的整合與開發

SOA, SOA, SOA... 今年炒熱一整年的 SOA(服務導向架構)，明年還會繼續，而其相關的應用與資源 - ESB, JBI, SCA(Service Component Architecture), SDO(Service Data Objects)...，於2006年會更加成熟，而且實際的應用於產業中。會有許多產品宣告它是 SOA Enabled。

相較於 SOA 的炒作的熱絡與實質應用的成功，MDA(Model Driven Architecture)會遭遇理論與實質應用上的挑戰。為什麼這裡我會將 MDA 與 SOA 這兩個看似不相關的東西擺在一起，簡而言之，是他們對於所要解決的問題，有高度的相似性。只是採用的作法完全不同，這可以是另一個故事。

流程與方法學在政府及顧問公司的推波助瀾下更受重視

PMP, Project+, CMMI… 簡而言之，既然對大家都有好處(個人可以獲得專業上的認證，顧問公司及教育訓練機構可以賺到錢，公司可以改善組織流程，進入所謂的贏者圈)，這麼好的 Business Story, 還會有誰來反對? 除了錢的問題…

Ajax Application向傳統網頁應用程式進軍，有些桌面應用程式也改以類 Ajax 技術實作

今年 (2005年) 可說是 Ajax Application 大放異彩的一年，一些網路服務應用先趨已經為了 Ajax Application 作了良好的示範。而在 2006 年，將會有更多軟體開發工具、套件實質支援 Ajax。另外一些傳統的Web 應用程式，像是 CMS(內容管理系統)、Portal(以及其上的 portlet)，Report Querier … 也都會有 Ajax 應用出現。甚至一些原本的桌面應用，像是專業的資料分析、探勘程式，也都可能出現"類 Ajax"版本。

專門為 Firefox 設計的網站應用程式

以前在瀏覽網站時，常會發現某些網站是 for IE only，相信在今後也會有 for Firefox only 的網站。與過去for XXX瀏覽器網站最大的不同點是，這些for Firefox only的網站，會充份利用Firefox 所提供的Extension, XUL, Canvas功能，將網站與瀏覽器無縫整合在一起，使整個網站的瀏覽體驗，更像是在使用桌面應用程式。

VoIP 持繼發熱

網路電話持續加溫，傳統電話業務會因此而停止成長。Skype 加入NetMeeting的功能，eBay 將透過 Skype 的NetMeeting功能提供線上影音即時拍賣。

Eclipse 仍為開放工具平台的實質標準

雖然 NetBeans 越做越好，在穩定度與易用度上甚且超越 Eclipse，但仍然無法力挽狂瀾。其中一個很大的原因是，Eclipse 已成為開放工具平台的實質標準。你可以在 Eclipse 上找到 PHP, Python, Perl, C/C++… 等其他語言的 IDE plugins，這是 NetBeans 無法追趕得上的。

軟體開發廠商生存更加困難

因為有越來越多各式各樣的套裝軟體出現，代表著有越來越多的"大眾化需求"被滿足。未來新興的軟體公司，極可能會面臨沒有應用程式可寫的壓力。因為你能想到的應用程式，都被別人開發完成了。

一般軟體廠商，面對這種情勢，有三件事可以做

1. 要以專案模式，朝客製化方向前進
2. 把握特殊領域應用，開發利基市場
3. 尋找過人的創意，解決市場尚未被滿足的需求，或創造出市場需求。 有創意的廠商能迅速脫穎而出。

軟體服務化，成為廠商延伸市場觸角的法寶

接續前面所提的 Ajax Application 中的推想，有許多傳統上應該是執行於個人電腦上的桌面應用程式，會在技術成熟，以及"商業策略"的因素下轉而Web化。將傳統桌面軟體 Web化，除了可以延伸市場觸角外，還可以支援許多傳統上難以達到的商業策略。諸如提供客戶 live experience, 改變軟體計價方式，迅速收集客戶回應等。

接續前面「軟體開發廠商生存更加困難」的話題，即使傳統軟體廠商想朝向軟體服務化方向走，前方的道路依然充滿困難… 因為這方面做的最好的，依舊是現有優勢者： Google, Yahoo!及微軟三家公司霸占著大多數的線上服務市場；而IBM, Oracle 等老大哥也是策略創新的高手。想冒出頭來的新興廠商，只能在不到 10% 的市場機會中尋找生存的空隙。

Drupal 成為最受歡迎的 CMS/Protal 系統

Drupal是一套以 PHP 開發、模組化、架構簡易，功能卻強大的內容管理架站系統。在Java開發者的眼中，這樣的系統不但不物件導向（完全用callback 方法實作），甚至還不夠格稱上 3-tier system（因為 drupal 事實上就是 web-tier + DB），它的DB存取還不用DAO、Model Object的觀念呢…，可怎樣，功能就是很強，就是可以加入無限擴充的模組，要氣死物件導向派的高手了。

不可諱言的，我自然也是Java社群的一員。初次觀看drupal程式碼時，還是覺得PHP實在不是優美的語言，drupal 程式碼中更夾雜著SQL與HTML（附帶一提，drupal可能已是PHP 內容管理系統裡面程式碼寫的最優雅的了。以PHP的標準，如果說 Mambo 是金玉其外，那 drupal 則是文質彬彬）。

無論如何，在Mambo分家，而Nuke、Xoops在分支眾多的情況下，Drupal已然成為 PHP CMS 中開發社群凝聚力最強的一支隊伍。相信在2006年會有更多開發人員為 drupal 建立外掛模組，使drupal成為 Apache+MySQL+PHP 上實質的的應用軟體開發、整合平台。

OpenOffice 會吸收更多的死忠支持者，就如有一群人死忠支持 Firefox 一樣

更多政府機構會實質採用 OpenOffice, 更多學校會採用 OpenOffice 授課。

微軟會成為智慧型手機、PDA、家庭數位娛樂電器的實質贏家

這已是事實，不用多說。

應用程式繼續朝向精簡型架構設計，EJB 3.0 叫好不叫座

(雖然Jini大力推EJB 3.0)

這是一個最重視物件導向的年代，也是最不重視物件導向的年代。舉例來說吧，現在的Java應用程式框架，強調要支持POJO的觀念，可是事實上，MVC卻大行其道，MVC是物件導向嗎？有人打圓場，說這叫separation of concerns。再以前面的 drupal 實作為例，callback不算物件導向吧！可是它卻是標準的 IoC (Inversion of Control)，符合 Hollywood principle -"Don't call me, I will call you"。

"物件導向不再無限上綱"。這句話一出，怕是要引起不小的爭論了。讓我簡單的說吧! 在未來的應用系統開發，你所強調的是架構，是服務，是功能，是流程。而物件，則是堆砌這一切的基本單元。也就是說，你只有在構築"程式的基本單元"時，才會採用物件導向的思維模式。當你往上堆砌系統，或一開始即採用架構導向系統開發方法(Architecture Oriented System Development)時，比較適當的思維模式，是將系統看作一部"機器"，你考慮的應當是系統各部元件之間的連結，彼此間如何互動，最後才是各部元件各自的角色與職責。

這與傳統的物件導向方法的差異是，這樣的方法是由整個系統，由整體到部份，由外往內，由多數到單一，再由單一推進至物件裡面。而不是一開始就著重在各個功能物件上。甚至在各功能物件之間尚未完成定義前，就必須先設計整個系統的訊息交換機制。要深入探討，這又是另一個故事，就此打住。

最近這一年來，與 Rich Client 相關的技術字眼層出不窮，像是 Rich Internet Application(RIA)、Smart Client、Ajax 等等。一切的一切，似乎召告企業運算的戰場，正朝著 Flash、Javascript + XML、PHP，或是微軟的 Smart Client 的方向前進。而 Java 呢? 倒像是躲在角落的灰姑娘了。

但事情的進展，總開始於不顯眼的地方。我們部門最近將一個傳統的 Client/Server socket 程式作適度的更改：Socket 伺服器改成 Tomcat (或任何的 J2EE Web Container) HTTP 伺服器，Socket 連線改成 HTTP Object Stream。而 Client 端自動更新機制改成 Java Web Start。

結果呢? 我們創造了一個不折不扣的 Java 版 Smart Client。引用自「Smart client有多Smart？」Smart client 有下列特色：

* 使用區域端的資源：這裡指的包含硬體與軟體的資源，可能是利用區域端的CPU計算能力、記憶體，將生產力軟體連接至企業營運系統，或是所連接的裝置，如PDA、電話、RFID接收器…等。

* 連接：Smart client應用程式通常是大型分散式系統的一部分。例如，應用程式可能跟一系列的Web services溝通，不僅可以維護程式，也能提供部署與更新服務。

* 離線的能力：由於可善用區域資源，此類應用程式可讓使用者在缺乏網路連線或是不穩定的狀況下仍可運作。不論是出差需求或是移動工作者，利用桌上型電腦、筆記型電腦或PDA，都能在離線時持續運作，而當連線時，也可智慧的自動擷取或更新資料。

* 智慧型安裝與更新：這是與傳統Rich client最大的差別。以.NET framework為例，系統管理者便可透過檔案複製、下載，或是利用HTTP部署應用程式，同時可以保持自動更新版本的能力。

* 用戶端裝置的彈性：隨著數位裝置的蓬勃發展，不論是手機、PDA、遊戲機、車用電腦等，新的技術平台也將提供其支援Smart client應用程式架構的能力。

我們的 Swing 程式，的確是使用區域端的資源，進行一些計算與操作。而由於 Client 與 Server 俱使用 Java 開發，兩者間採用 Object Stream 溝通訊息的方式，比 Web Service 方便太多。至於離線的能力，傳統的 Swing 程式，本來就可以獨立於 Server、Browser 而存在。智慧型安裝與更新，那更是 Java Web Start 的強項。至於用戶端裝置的彈性，先不談跨裝置吧，我們的產品至少是跨作業平台的。

近來在 java.net Weblogs 上看到 J2SE 6.0 Mustang 的更新特性，以及 J2EE 將對 Ajax 提供的支援，Sun 在 JVM 改良上所下的用心(如 MVM)…在在令我繼續燃燒著對 Java 的熱情。希望 Java 越來越好!

順帶提一點：其實我對微軟所宣稱的 "ASP.NET Server Control" 可達到 "用戶端裝置的彈性" 是持保留態度的。設計過手機或 WAP 程式的人都知道，除非你的頁面極其簡單，否則是不太可能把同一組 ASP.NET 網頁，透過不同的 XSLT 或其他方式轉換，同時顯示在電腦螢幕及手機螢幕上。簡而言之，不同的使用介面，操作設計與邏輯完全不同，這不是只轉換顯示方式就能解決的問題。

RIA - Rich Internet Application 一詞在最近在電腦網路、軟體產業竄紅。有多紅呢? 紅到上了 e 天下雜誌網站的封面故事 --《2005年7種哈燒新科技》。RIA 簡而言之，就是一種同時擁有瀏覽器的輕巧，與傳統應用程式豐富操作性的網路程式。

傳統上，當我們在使用網頁應用程式，像是 web mail 時，每點一個連結，畫面就自伺服器上更新(refresh)一次，以便顯示不同的資料。這與桌面應用程式並不相同，以收信軟體為例，在收件夾中點選不同的郵件並不會造成整個收信軟體的 refresh，會更新的只有信件內容顯示區。

摒除使用性較低，反應較慢這兩缺點之外，網頁應用程式卻有著傳統應用程式所難以達到的優點：免安裝(只需要瀏覽器)、永遠是最新版(只要更新伺服器上的應用程式就行了)、無遠弗屆的存取能力，以及(通常)較易於開發。RIA 就是擷取網頁應用程式與桌面應用程式兩者之長的產物。

目前在網路上，中文資料蒐集最豐富的網站當是阿修的部落格 » RIA，裡面介紹了各式各樣的 RIA 應用程式。如果想對 RIA 的原理及開發環境有所理解，則可參考 Overview - Rich Internet Applications。若是想隨時追蹤 RIA 的發展現況，那還有一個專門提供 RIA 資訊的入口網站: RichClients.org。

從以上的訊息來源可以歸納出，目前 RIA 所採用的 Client 端展示技術，似乎是以 Flash 最受歡迎。而採用 Flash 的 RIA 架構中，又以 Laszlo 及 Macromedia Flex 開發社群最堅強。究竟 Flash 的 RIA 技術可以給網頁應用程式帶來怎樣的豐富性呢，不妨連上它們的 demo 網站看看-- Laszlo demo, Flex demo。

如果你是 HTML 或 XML 基本教義派的支持者，打死也不肯用 Flash，那採用 DHTML 的 RIA client 也是有的。其中整個 Framework 比較完善的有 Isomorphics、DomAPI - DHTML Platform，以及 Bindows。如果你連上這些網站，並執行 demo 程式，你必定會訝異於原來 DHTML 可以做到這等地步。

最後，我又要為 Mozilla 抱不平了。Mozilla 的展示技術 - XUL，可以說是最早的 RIA 技術之一 (甚至有一個網站 Open XUL Alliance 專門提供各種 XUL 專案的資訊)，可是卻在這一波 RIA 的浪潮中被冷落在一旁。我敢保證，現今的許多 RIA 技術，乃至微軟的 InfoPath、 XAML (XML Application Markup Language) 等，都必定在某些程度受到 XUL、Mozilla 的啟發。前思後想，Mozilla 在 RIA 較少人提及只有一個原因，Mozilla 的 XUL 並不是跨瀏覽器的標準，而前面所提的 Flash 及 DHTML 卻可以達到跨瀏覽器的要求。為此，我若是 Mozilla 瀏覽器的開發者，便會開發一個 XUL 的 activeX 元件，讓 IE 可以使用，問題就解決了。