愛德華日誌

OSGi 起源於1999 年三月，是由一些家用閘道器相關產業廠商所組合而成的組織，目前約有八十餘家廠商加入。包括了 IBM、Sun、BMW、Motorola、Nortel、Nokia、 Philips、Panasonic、Sony、Toshiba、Echelon 等。目前最新的標準是OSGi Specification 3.0。

當初制定OSGi 標準的最主要的目的，是要為遠端的服務提供者 (Service Provider) 與本地端的設備 (Device) 之間提供完整的點對點服務傳送解決方案。因此，OSGi 定義了一個開放性的平台，使得遠端軟體服務供應商所提供的應用程式 及加值服務，能視使用者需求，隨時下載至靠近用戶的閘道器 (Gateway) 上，並且自動安裝執行，而這裡所指的閘道器通常是連接家庭網路(Home Network)、辦公室網路 (Office Network) 與廣域網路間的一個裝置，如機上盒 (Set-top Box;STB)、ADSL數據機、纜線數據機 (Cable Modem)、住宅區閘道器 (Residential Gateway)等。透過這個開放性的平台，不同廠商所開發出的服務軟體及設備都能互相溝通及搭配使用。

在 OSGi 網站上的 FAQ 中，指出 OSGi 應用方向包括：

• Services in the Home:
• • Communication
  • Information/entertainment
  • Safety and security monitoring
  • Energy management and metering
  • Appliance diagnostics and servicing
  • Telemedicine and healthcare monitoring
• Services in the Car:
• • Navigation
  • Emergency assistance
  • Mobile commerce
  • Information/entertainment
  • Vehicle diagnostics
  • Location-based services

Again, we see java succeeded in J2ME. We can see many big-name companies in the OSGi member name list which include many companies come from many industries.

最近 OSGi 在軟體業最為人雀躍的發展，莫過於 Eclpise Java IDE 支援 OSGi 標準。這是一個有趣的現象，本來是設計給其他產業的運用，卻在軟體業也有不凡的表現。這也讓我想起 Java 的發展歷史，本來也是為了 embedded 系統而設計，卻意外的在 internet 竄起的年代獲得各方的矚目，更在 enterprise application 中立於不敗之地...

JMX 與 OSGi 在功能上的許多重疊之處，在國外已經有人討論過 (例如 Eclipse Embeds OSGi Based MicroKernel 及 JMX vs. OSGi - The New Flavor of the Eclipse Runtime)。不過我認為重點是：

1. JMX 本來設計的用途就只為了管理，我們不該把他拿來 (over use) 作為開發應用程式的元件 (那是 EJB 或 JavaBeans 該做的事)。但 OSGi 卻可以!
2. JMX 多數用於 server 系統中，而 OSGi 卻不限於所開發的應用程式。你可以用它開發 embedded 系統、desktop 程式，甚至是 server 程式。

OSGi 不但提供了與 JMX 相似的容器管理能力，甚至它本身就是一套精密的 Framework。OSGi 採用Micro-Kernel 的架構，可以提供無限延伸的功能。OSGi 的 Bundles 線上更新功能、以及應用程式之微量記憶體執行能力，都是開發應用程式的利基。

OSGi 與 J2EE 在設計上，我覺得完全是兩種思維模式：J2EE 的思維是 build on large scale，OSGi 的思維是 build on dynamic scale。OSGi 以小搏大...

OSGi Resources:

• Welcome to the OSGi Alliance - OSGi official web site
• alphaWorks : OptimalGrid
• ServiceBinder - Automatic service dependency management in OSGi
• IBM Service Management Framework - IBM Software
• Oxygen project homepage
• Oscar - An OSGi framework implementation
• Knopflerfish OSGi

註:

目前我看到與 OSGi 有關的 JSR 為：

• JSR 8: Open Services Gateway Specification (OSGi)
• JSR 232: Mobile Operational Management

這是我在 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 也很適合作為兩個企業間或兩套系統間的溝通方式。我希望能為這兩種方案各提供一個例子。

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

在這 Web 2.0 的時代，現今的 Java Web Framework 也與過去第一代的 Java Web Framework 有些不同，先列出我所關注的幾個：

Spring Framework

• Spring Framework - http://static.springframework.org/
  
  輕量級的 Java 應用程式容器，同時支援 Rich Client、Web及 Java EE 應用系統之開發。
  
  
• Spring Web MVC Framework - http://static.springframework.org/spring/docs/2.0.x/refer...
  
  Spring Web MVC 是一簡單易用的 web MVC 套件，可讓開發人員把 View, Controller 及 Model 分離，開發出容易維護的 Web 程式碼。由於其 View 端採用 pluggable 方式設計，可搭配 JSP, Struts 或 JSF 展示框架使用。
  
  由於 Struts 架構因限制特定用途且開發動能不足，目前已呈老化之趨勢，開發新專案時，不建議採用。對過去只採用 JSP 的系統來說，採用 Spring Web MVC + JSP 將是最可行而簡易的升級方案。
  
  
• 中文版的 Spring Framework 教材 - http://caterpillar.onlyfun.net/Gossip/SpringGossip/Spring...
  
  良葛格寫的，其中對 Spring Framework 有深入淺出的介紹。若對 Spring Framework 不熟悉，建議先看這裡的介紹，大致上看完後對基本的應用就足夠了。若有不足處，可再參考官方參考手冊(http: //static.springframework.org/spring/docs/2.0.x/reference/)。
  
  
• Spring Web Flow - http://opensource.atlassian.com/confluence/spring/display...
  
  Spring Web Flow 讓開發人員定義一組態設定檔，透過定義 page 及 action 的 binding，完成 page flow 的定義。令人興奮的是，在 Spring IDE(http://springide.org/project/wiki/SpringideFeatures) 中，提供對 Spring Web Flow 的支援，讓開發人員可以透過視覺化的方式(http://springide.org/project/wiki/WebFlowEditor)， 來定義 網頁流程。

• Echo2 - http://www.nextapp.com/platform/echo2/echo/
  
  支援 Ajax 最徹底的 Web Framework，其特色是 Echo2 將網頁元素完全物件化，透過它所開發出來的網頁程式，不用寫到一行 HTML, javascript 程式碼。如果開發者對 Swing 熟悉，那麼開發 Echo2 程式將會輕而易舉。想要了解 Echo2 所開發出來的程式風格，可參考其 demo(http://www.nextapp.com/platform/echo2/echo/demo/)。 看過 Echo2 令人印象深刻的展示程式後，會覺得其他 Web Framework 的展示程式是那麼軟弱無力。
  
  另外，我發現 Echo2 的社群也是非常活躍，像是其 forum(http://forum.nextapp.com/forum/) 或 wiki(http://wiki.nextapp.com/echowiki/) 裡，可以找到不錯的參考資源。而 EndPointNG (http://wiki.nextapp.com/echowiki/EchoPointNG) 則提供了許多額外的元件，像是 Tree, TreeTable, PageableTable 等。
  
  在應用上，把所有 web 元素通通轉換成 Java 資源放在 session 裡面，對於使用者眾多的應用程式將非常不利(但若是像我們公司這類程式由於非訴諸一般 end user，則無所謂)。
  

• Google Web Toolkit - http://code.google.com/webtoolkit/
  
  Google 所出品的 Java Ajax Web Framework。其實說它是 Java Web Framework 有些不對，因為它在開發的過程中，採用與 Echo2 類似的 Approach，是以 Java 物件來代表/處理 Web 元素。但是真正佈署前，必須將這些 Java 物件 compile 成 HTML 及 Javascript，再佈署這些轉譯後的 web 資源。因此這些資源極有可能佈署至一般的 web server 內(如 Apache)，而不需要特定的 Java web container(如 tomcat)。
  
  由於 GWT 已經實際應用於 Google 的產品線(如 Gmail、Google Calendar 等)由於 Google 的Ajax 技術已經過實際應用，因此可以確認的是它的效能不成問題。另外由於它的展現層與邏輯層完全分離，兩者之間採用 jscon 或 RPC 的方式進行呼叫，因此 server 端完全免除 UI 的 loading，只要專注於 service 的邏輯即可。再加上它可透過 JavaScript Native Interface (JSNI) 來整合既有 javascript 撰寫的網頁元件，對於 third-party 的元件，將較容易整合與移植。結論是：GWT 是一適用於高負載，運用彈性靈活的 web framework。

• Wicket - http://wicket.sourceforge.net/
  
  Wicket 是 web 應用程式中，將 Java 程式與 HTML 源碼切割的最乾淨的一套 web framework。與 JSP 一樣，Wicket 將 view 端的 UI 定義在 HTML 中，但與 JSP 不同的是，它並不是採用 <%%> 這類特殊的 tag 來夾注 server 端的邏輯，而是利用 XML namespace 的方式，在一般的 html tag 中加注 Wicket id 來達到 server 端邏輯連結的效果。
  
  Wicket 與 Echo2 一樣，將所有的 UI 元素都轉換成 Java 物件存在 session 裡，對於流量大的應用程式非常不適用。實際試用 Wicket 之後，發現在使用既有元件的情況下，要完成相同的工作，它所需的程式碼要比 Echo2 來的多。且由於 Echo2 是所謂 "一頁式" 的 web 應用程式，而 Wicket 可支援多個頁面，因此它在 URL 連結及 session 的處理上更為複雜。所得到的益處是，Wicket 同時支援 Ajax 與 refresh based 的 web 應用程式開發，且支援 bookmarkable URL。
  
  另外，由於 Wicket 使用 HTML 作為網頁元素樣版，因此可以在美工人員與程式設計師之間作良好的分工。而既有的 javascript 在整合上，也會較 Echo2 來的簡易。
  

接下來，我想透過分析以上幾個 frameworks，檢視應用程式框架發展、轉變背後所隱含的意義：

支持輕量級開發

所謂輕量級開發，可以由幾個角度來檢視，一個是元件模型，UI 與 Server 端的邏輯是否容易連結。另一是在開發應用程式的過程中，是否需要採用特殊的工具，如特殊的 GUI Builder 或 configure file editor。最後，則是其執行環境是否單純，或是需要特定的 web 容器。

在第一點上，個人認為 Wicket 及 Echo2 皆有良好的表現。因為它們所採用的方式，是直接撰寫視覺元件的 action listener，與 Swing 的作法一致。而 Spring Web Framework 則承襲第一代 web framework，採用 dispatcher/handler 的作法，在觀念是 request/response 模式。至於 GWT，由於 client 端邏輯純粹由 javascript 負責，它所提供的 javascript 包含 RPC 呼叫程式，用來呼叫 server 端的應用程式邏輯。而 GWT 的 server 端邏輯，是一種特殊型式的 servlet。因此，如果系統中後端邏輯複雜多變，需要多個 server 端元件時，採用 GWT 預計就要維持很多個 servlet，可能會令人相當頭疼。

第二點，應用程式之開發環境，在 GWT, Wicket 及 Echo2 中，都是直接以既有的 Java IDE 即可開發，至於 Spring Web Framework 在這一點上，因為其 View 端採 plugable 設計，基本上是獨立的。不過其 config file，個人認為若有合適的 editor，會較容易使用。最仰賴 GUI builder 的，我想是 JSF，不過也不排除有存在樂於 hand coding JSF tags 的天才。

最後是運行環境，這方面的贏家是 GWT，因為它在運行時甚是不需要 server 環境。至於 Spring、Wicket 及 Echo2 等，則需要(只要)一搬的 java web container, 加上 framework 特有函式庫即可。 

另外，這裡我並未強調元件模型是否為 POJO，因為繫結視覺元素與後端邏輯，本身就是 glue code。你只能看它是否夠不夠簡易，而無需用 model layer 的標準來要求，

支援新一代的動態網頁技術

Wicket、Echo2 及 GWT 都支援所謂的 Ajax 技術。在使用上，Echo2 的方式相當靈活，因為它讓你可以動態的在 clinet 端加入與移除視覺元件。Wicket 在使用上感覺就有些限制，因為它要求 Web UI 元件與後端的處理元件，需存在一對一的對應。

對於標準的支持

這一項有些含糊，因為每個 framework 所重視的標準不一。像是 GWT 重視的是平台的獨立性，而 Spring 重視的是支援既存的各種 framework，達到中立性。Wicket 重視的是 HTML 語法的相容性，而 Echo2 重視的則是瀏覽器的相容性，以及 Swing 風格的設計思路。不過總而言之，新一代的 web framework 在這個面向已進步許多。

視覺元件與程式邏輯更明確的分割

這可分為「看起來是」與「實際上是」，像是 Wicket 就做到看起來是。有趣的是，Echo2 是看起來不是，但實際上卻是。至於 GWT 嗎，由於它的 server 端的邏輯是另外寫成 service，而 client 端的視覺元素在開發時也是以 java 撰寫。兩者採用一致的方式，不過卻必須分開撰寫，可以說它是實際上是，至於看起來是不是，就見仁見智了。

2006/05/03 使用 Eclipse Web Standard Tools 開發 Web Service

一直想要找一個方法，可以讓我直接將 JavaBean 轉換成 Web Service，而不需要太大的 coding effort。之前試過 SpringFramework 對 Web Service 的支援，基本上它也是要你自己去編一大堆的組態檔，好像也沒輕鬆到哪去。而 JAX-RPC 2.0 則是借用 JDK 5.0 對 Annotation 的支援，用起來跟 .NET web service 的寫法很像。但我仍在思考，是否存一種更乾淨的作法，可以不用 Annotation…

今天心想我已經為 Eclipse 裝上 Web Standard Tools，何不就試試它的 web service 開發能力呢。一試之下驚為天人，怎麼可以這麼好用。基本上它為 server 端的 web service 的開發提供兩種支援：

1. 給定一個 Java 類別，它可以為你產生合適的 WSDL 檔
2. 給定一個 WSDL 端點，它為你產生 Java 樣版
   

然後包含 web.xml、server-config.wsdd 的產生或修改、它都幫你做到好。其實它還有許多好用的功能，像是直接在 WSDL 上新增方法，甚至 refactor WSDL 等，絕對值得一試。

Eclipse WST 的WSDL 圖形編輯器

想了解更多 Eclipse WST 如何開發 web service，可參考：Developing Web Services Eclipse Web Tools Project

Web Service 測試小技巧

寫起來免得自己忘記。如果你有個 web service 叫 HelloMath，其中有個 method 為 add(int a, int b)，你可以不用寫程式，直接瀏覽 http://some.url.to/services/HelloMath?method=add&a=1&b=2 進行測試。

這個方法在以 Axis 為服務套件的 web service 上行得通。.NET 預設也有類似用法。至於其他的 web service 套件，就請自行測試了。

----***----

2004/02/10 Java Web Service 簡介

談到對於 Web Service 的支援，多數專家會認定 .NET 平台比 Java 好。個人認為就易用性而言，這可能是真的(只是可能)；不過若就支援的標準來說，Java 肯定是贏家。

這個領域的重要成員包括：

• 來自 Sun 的 Java Web Services Developer Pack (Java WSDP)，含括以下幾個套件:
  
  • JavaServer Pages Standard Tag Library (JSTL)
    
  • Java WSDP Registry Server
    
  • Web Application Deployment Tool
    
  • Ant
    
  • Tomcat
    
• 另外一個要角則是來自 Apache 的 Axis(Apache eXtensible Interaction System，據說是 IBM donate 的)。Axis 有許多特異功能。例如只要把一般的 Java Class 的副檔名由 .java 改為 .jws，就可以立刻變身為 web service，可作為獨立的 web server 等
  

其他專案

The Simple Messaging Framework: "The Simple Messaging Framework provides an elegant way to create robust and flexible Web services. It is based on the document-style Web services paradigm that uses the full power of XML Schema. This approach enables you to expose arbitrarily complex business objects and services with ease."

在 Java Application Server 上使用 PHP

Caucho 在 Resin Application Serer 上加入對 PHP 的支援。其實在過去，Caucho Resin 就以其 JavaScript in JSP 的功能聞名。相關討論：

• TheServerSide: Caucho Resin adds PHP
• digg: 6 times faster PHP interpreter by Resin creators

我的第一個想法是，如果相容性做的好，那現有由 PHP 所實作的所有 CMS 在往後都可以很容易的 porting 到 servlet platform 上，也就不用擔心 JAVA 沒有好的 CMS 實作了。

Java 被 Scripting Language 取代?

還在擔心 Java 被 Scripting language 取代嗎? Java 其實是兩個層次上的東西，一個是 Java 語言本身，一個是與整個 JVM 有關的執行環境。目前可用於 JVM 上的平台的 Scripting 語言包括可以參考 "List of Java scripting languages"，另外，在 "Programming Languages for the Java Virtual Machine" 可以找到所有可以執行於 Java 平台的語言。

與此相關的 JSR 包括：

• JSR 223: Scripting for the JavaTM Platform
• JSR 241: The Groovy Programming Language
• JSR 274: The BeanShell Scripting Language

相信 jvm 在 sun 的努力下，終有一天會變成良好的 scripting 語言共通平台。

程式語言競技場

有人說 Java 比 C 還快? PHP 及 Python 熟強? 何不上「程式語言競技場」較量較是。你可以比較一下：

• C++ vs. Java -- 就效能上，當然是 C++ 強。但別忘了考慮平台、函式庫、跨系統整合上的支援，仍是 Java 的強項
• Python vs. PHP -- 還是 Python 強
• Java vs. Python -- Script 語言再怎麼強，在效能上還是沒搞頭
• D vs. C++ -- 效能上 D 語言小勝，不過由 Code Lines 可看出 D 語言更為簡潔
• D vs. Java -- "吃人夠夠"，Java 被 D 語言海扁。如果你的程式是要寫給自己玩的，可以拿 D 試試。

你用的語言過時了?

最後，大家要關心的，還是你所使用或學習的語言，是不是符合市場的趨勢，這裡有幾個連結，供大家參考：

• Programming Language Usage Graph
• Programming Language Popularity
• TIOBE Programming Community Index for January 2006

與其說這是一篇對 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)時，比較適當的思維模式，是將系統看作一部"機器"，你考慮的應當是系統各部元件之間的連結，彼此間如何互動，最後才是各部元件各自的角色與職責。

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

前一陣子為了要實作一個資料流程的編輯器，在網路上尋找了一些相關的應用程式。以下是我所找到的相關資源：

Joone - http://www.jooneworld.com/docs/guiEditor.html

• 這是一個 Neural Network 的程式，裡面的 Neural Net 也可以編流程

• 這是一個 EAI 的應用程式，裡面有一個 FlowEditor

• 這是一套 Open source 的 Java 資料探勘工具，裡面有一個 KnowledgeFlow Editor

• 裡面的 KBeansShell 可以拿 JavaBeans 來當作流程元件，還有與 JavaBeans 有關的 design patterns 可參考
• 另一個 AGILShell 也是個不錯的東西，以 JavaBeans 來作為 Agent System 的流程元件

另外，也可以參考一下 The Bean Builder - https://bean-builder.dev.java.net/。這個東西很有趣，示範如何透過 JavaBeans 在執行期組裝新元件，組裝好的元件可以透過 JavaBeans long term persistence api 存成一個 XML 檔。當然這個檔案之後可以再透過 long term persistence api 重建，與應用程式整合在一起。

Mule

這是我在這方面找到的第一個 open source Java solution。它的主要特性摘錄如下：

• J2EE 1.4 Enterprise Service Bus (ESB) and Messaging broker
• Pluggable connectivity such as Jms (1.0.2b and 1.1), vm (embedded), jdbc, tcp, udp, multicast, http, servlet, smtp, pop3, file, xmpp.
• Support for asynchronous, synchronous and request-response event processing over any transport.
• Web Services using Axis or Glue.
• Flexible deploment [Topologies] including Client/Server, Peer-to-Peer, ESB and Enterprise Service Network.
• Declarative and Programmatic transaction support including XA support.
• End-to-End support for routing, transport and transformation of events.
• Spring framework Integration. Can be used as the ESB container and Mule can be easily embedded into Spring applications.
• Highly scalable enterprise server using the SEDA processing model.
• REST API to provide technology agnostic and language neutral web based access to Mule Events
• Powerful event routing based on patterns in the popular EIP book.
• Dynamic, declarative, content-based and rule-based routing options.
• Non-Intrusive approach. Any object can be managed by the ESB container.
• Powerful Application Integration framework
• Fully extensible development model

Mule 除了本身具有 SOA/ESB 的功能外，我們也可以拿它來當作傳統 Client/Server 系統中的通訊平台。它可以拿來當成獨立的 server，又可 embedded 在 web application 中，真是一魚多吃。

在 TheServerSide.com 有人問到 mule 與 openadapter 的比較， 基本上 mule 是一個開放式的分散式架構，它支援不同系統間的流程整合(即是它的 end point 不只一個)。而 openadapter 則是一個資料流程管理機制，它的流程是發生在同一個 service instance 之內的。在應用上，或可採 mule 主外，openadapter 主內。

我對 Mule 的疑問：

• 由於它用來處理 UMO(Unify Meessage Object) 的元件都要用組態檔來設定，如果系統中使用了很多 UMO Component，那不就相當麻煩
• 如何把上述的很多的元件，同時讓它們可以處理 http 及 tcp connector 進來的 request? 我當然知道可以一個一個分別設定給 http 及 tcp 的 end-points...
• 雖然 Mule 可與 Spring 合併使用，但是 Mule 有自己的組態檔 - 又要學習另一套組態設定語法。
• Mule 提供了很具 "彈性" 的 service routing path，雖然功能強大，但也容易造成元件開發模型不一致。而且要是發生錯誤，恐怕不好追蹤。
• 測試 Mule SystemStreamConnector，當 promptMessage 屬性設為中文時，會有顯示的問題，
• 另外將 config 檔用 UTF-8 格式存檔，SAX parser 會有 complain

ServiceMix

架構及 service routing path 上是比 Mule 簡單的多，且預設就是要與 Spring 配合使用，還符合 JBI(JSR 208)規範，看起來是不錯。其主要特性如下：

ServiceMix is lightweight and easily embeddable, has integrated Spring support can be ran as a standalone ESB provider, as a service within an ESB or within a J2EE application server.

ServiceMix currently has bindings for:

• HTTP
• JMS
• SAAJ (and so Apache Axis)
• WSIF
• ActiveSOAP
• Mule
• JSR223
• Groovy

ServiceMix also provides a simple to use Client API for working with JBI components and services.

In addition ServiceMix provides an implementation of WS Notification

有趣的，是 ServiceMix 與 Mule 同樣 Hosting 在 http:/www.codehaus.org/。

xBus

在 xBus 的網站上並沒有看到 SOA 或 ESB 的字眼，它把自己定義成 EAI 的 solution。就功能性來講似乎是 mule 的子集，整合性來講似乎也不如 mule。但相對的也較簡單。其特性如下：

• Published under an Open Source License similar to the Apache License.
• Platform-independent by implementation in Java 1.4
• Different operating modes:
• • As a standalone background service
  • Manually started single operation or triggered by a scheduler
  • Running inside a servlet engine
  • Integrated into other Java applications
• Two communication modes are supported:
• • Request/Acknoledgement
  • Request/Response
• High flexibility and simple extensibility achieved by a consistent layer architecture and a plugin mechanism
• Powerful transformation engine using standardized XML technology
• High number of configuration options
• Flexible addressing of sources and destinations
• Journaling of all data streams possible
• Future-proof by the implementation of standardized APIs

S-integrator

同樣的 S-integrator 也沒有宣稱自己是個 SOA/ESB 的 solution。在它的網站上是這麼寫的：

.. A service-oriented integration server that hosts Service Stores which authorize, monitor, manage and run services while making them available through web services, HTTP and other protocols. Included listeners and inbound adapters support address banning, content filtering and a virus detection filter. Included outbound adapters integrate databases, mainframes (APPC), web servers, FTP, mail and other technologies. Administration is performed using a web browser or cell phone that accesses the embedded web server. Service Flows provide process automation and hot deployment is supported. S-integrator is single-source, small footprint and only requires JRE 1.2 and a database with JDBC driver.

它的特點：

• 簡單的程式設計模型，整個系統小於 1MB
• 裡面還包括一個小的 embedded web server，真厲害
• 由於它有自己特定的目錄結構，預計將不利於與其它應用程式(尤其是 application server 整合)
• 糟糕的是，它的 agent service 還直接寫成 Thread，當 embedded 在某些系統裡面時可不允許這樣玩
• 是想說它或許可以與 OSGi 整合，以解決 OSGi 在跨 service instance 呼叫方式的不足
• 適合拿來作為一個 mini-server 的 kernel

Spring Remoting

Spring Remoting 當然也沒宣稱自己是 SOA/ESB 的 solution，但就像 Spring Framework 在其它方面的表現一樣，它的 remoting 功能，也是令人眼睛為之一亮。它可以讓你的程式在極少量的改寫之下，就具有跨系統的整合能力。

Spring Remoting 同時支援 RMI、HTTP remoting 及 Web Service。我想要加上 JMS 及 FTP 等整合也不是難事。如果要連接的兩個系統都是用 Java 開發的，實在想不出什麼理由一定要走 ESB 那一大套。

Spring Framework 具有動態產生 proxy 的功能，也就是，給定一個類別或介面，它可以在執行期，產生此類別或介面的代理物件。這樣做的好處是，我們可以透過代理物件，在呼叫原始物件方法的前後動些手腳：像是權限檢查、日誌、效能檢測、訊息過濾... 乃至我要在這裡介紹的，透過代理物件來存取遠端的物件實體。用途相當多樣化。

傳統的 Client/Server 設計，常會與底層的傳輸協定產生緊密的耦合。例如傳統的 RMI，要採用 RMI 傳輸協定的 Client/Server 系統，其遠端介面必須 extends RMI 的 Remote 介面，而這就產生了系統與協定的耦合。但仔細回想，這樣的耦合卻是不必要的。怎麼說呢？

概念上，我們可以把 Client 跟 Server 兩端看成是河的兩岸。當 Client 端的某一物件要呼叫 Server 端的另一物件時，就像是河的一端派了個特使要過河傳達訊息。而 Client 端與 Server 端的傳輸協定，就像是兩者間的各種運輸管道。例如水泥橋、吊橋，或是般隻。事實上，河的兩岸可以是個獨立的個體，特使要過河，他可以走水泥橋、吊橋，或是搭乘般隻。從這個角度來思考，實在沒有必要把 Client/Server 架構跟底層的傳輸協定綁在一塊。

Spring 在遠端呼叫上，支援多種協定，包括傳統的 RMI、能穿越防火牆的 HTTP Object Stream，以及跨系統的 Web Service。由於 proxy 物件是動態產生的，並不需要事先編譯，因此甚至能做到動態變更底層的傳輸協定 (也就是解了系統與傳輸協定的耦合)，而不用變更一行的程式碼。究竟 Spring 是怎麼辦到的呢？

答案很簡單，其實說穿了就是嚴格區分物件的角色(有沒有注意到這裡也有 AOP 的影子)。執行商業邏輯的物件，就不該管如何將其服務開放出來(這也就是讓 Business service 去 extends RMI Remote 介面不好的原因)。在 Spring 裡面，把 export service 的動作，交給 ServiceExporter 來處理。今天你想讓 AccountService 經由 RMI 呼叫，那就把它交由 RmiServiceExporter export 吧！若是想讓它經由 HTTP 呼叫，那就交由 HttpInvokerServiceExporter export 吧！其他的協定亦然。從 Server 端的角度來講，經由不同的 exporter，就可以支援各式各樣的呼叫介面了。

反觀 Client 端，也可能會面對採用不同傳輸協定的 Server。這時 Client 端見人說人話，見鬼說鬼話的能力就很重要了。在 Spring 裡面，提供了許多的 ProxyFactoryBean。採用不同的 ProxyFactoryBean，就能讓你連到不同協定的 Server，而不用改寫一行 Client 端程式。

詳細的範例，我就不在此列舉了，有興趣的請移駕前往 Spring 使用手冊第 17 章：Remoting and web services using Spring。