愛德華日誌

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

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

終於結束今年 JavaTwo 的演講。也許是這年頭 SOA 正火熱，也許是因為 jini 大在他部落格的推薦，也許是 Browser 在 session key note 的引言，今天來場的聽眾我個人覺得是滿多的。

這次演講時間上的控制大致上還可以，這要感謝 Browser (Mike) 之前幫我做 rehearsal，在他指點下，原本不知如何取捨的繁雜內容才得到比較好的安排。美中不足的地方是，SCA 後半段的 demo 顯的有點零亂…

如果有人是衝著這次的標題 "SOA 之原則、設計與實務" 而前來，那我要對這些學員說聲抱歉，限於時間的關係，我沒法在原則、形而上之類的題材著墨太深。事實上整場演講，我想帶給學員的就是目前在 java 業界 SOA 兩大主流：JBI+ESB 及 SCA+SDO 的實務作法。希望到場的學員多少有吸收到我想表達的訊息。

此次演講中 demo 的範例程式及投影片請按此下載。壓縮檔解壓縮後包含 readme.txt，說明範例程式的安裝及執行方式。如果各位在測試上還有什麼問題，就留言討論吧！

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

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

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

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

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 那一大套。