面向服務的框架

  Service-Oriented Framework

1       框架

在這里，框架是指特定領域應用框架。

在歷史上，創建的很多框架，會造成一種強約束，太多需要去遵循的條條框框。而我認為，一個可用的框架，對于框架的使用者而言，應該減少遵循的法則，極少數的限制應該是符合最佳實踐或者是設計模式。

框架應該是一個松散的結構，這個結構定義了一個抽象的運行時狀態。它表示一組資源的操作契約。

由于這個框架是特定領域的應用框架，因此，它的結構中存在必要的基礎設施，就好像一個房子它如果是住宅，那必然要有廚房基礎設施，比如燃氣管道，排煙通道，上下水，等等。

我在這里希望討論的特定領域是企業信息系統。

然而，框架僅提供基礎設施接口，而非實現，就好比燃氣管道可以輸送液化氣，也可以輸送天然氣，水管可以輸送純凈水，自來水，冷熱水。這并不重要。

框架對于應用開發者而言，僅需要關注業務領域知識，然而幾乎所有的新技術，新標準，新框架，新平臺出來時都是如此承諾的，但是這幾乎很難兌現。這是個兩難問題，既不能太具體，也不能太抽象。

因此，我接著會談到服務分層。

一個框架并不能兌現所有承諾，那就使用子領域框架來完成。子領域框架更加貼近某類應用，比如CRM，或者是Blog。而具體的項目，則基于子領域框架構建，架構師負責將領域概念轉為軟件模型，我傾向于這是一個對象模型，因為在描述業務領域方面，其使得從業務概念到軟件模型的轉換更自然（可以在討論DDD時再詳說）。

其實，我使用過一些復雜的應用框架，比如Oracle Application Framework，它對于企業信息系統抽象的很好，可惜的是由于歷史原因，技術比較落后，使得其非常的笨拙，但是很多方面是值得借鑒的。

拋開技術本身，一個能夠為大家所用的框架，也應該有豐富的文檔，已經解決典型問題的豐富的案例庫。

2       服務分層與服務分類

服務按照在應用中所處的不同位置和面對的不同方面應該分出不同層次，可以包括：

1 基礎設施服務層，例如分布式緩存，安全，并發，UI，命名服務，事務，日志（審計）

2 應用服務層，例如郵件，工作流，搜索引擎，目錄，BI展現引擎，消息

3 領域（業務）服務層，例如會議室，部門列表，地址名錄，員工檔案

從服務的分類來看，存在一種傳統意義上的Web Service服務，和另外一種傳統意義上的Mashup服務，或者是現在流行的App。

關于UI服務，我是受到了Google的Code PlayGround，Adobe Flex Samples庫，以及Dojo可以通過放在AOL上的鏈接進行調用的啟發，何必每個項目都要去選擇控件呢。另外我也受到Oracle Application Framework的啟示，圖片之類的資源也可以公用。此時可能有人會想到面向資源的架構。

再來談談并發服務，我是希望能夠像安全，事務一樣，利用AOP來透明的實現并發，這或許比較其他方面更難，多線程甚至是多進程的處理和協作模型雖然看起來是清晰的，但是通過配置來使得開發者受益需要進一步思考，我最近閱讀了很多相關資料，包括特定領域應用框架：行業的框架體驗，Java編程思想里的線程一章，Effective Java的線程部分，以及IBM上的一些文章，還有一些學術論文，JBoss的手冊，這是個不近不遠的目標。

然后說說搜索引擎，我認為對于具體項目而言，搜索就像使用Google做站內搜索一樣簡單，建庫也只是簡單幾個URL搞定的事兒。

最后說說員工檔案，這樣的服務應該提供有價值的統一服務，這個概念可能那些做數據庫的會想到主數據庫MDB。

3       分離服務與服務組件

3.1     服務只是一種契約

服務僅僅是一種契約，我提供什么資源，你給我提供什么服務，我會得到什么，當發生意外，會怎么樣。

一般服務都會有個名字服務來進行注冊，比如JNDI，UDDI之類的，也就是告訴我服務在哪。

一定要將服務和服務組件分離開，服務組件是用來提供服務的。

周末家里的抽水馬桶堵了，于是打電話給12580說明情況，她幫我轉接了一個家政服務的電話，然后我說明了我的情況，對方就說派一個人來修。

其實我并不關心服務來自于哪，由誰來提供。

我會遇到問題時就給12580打電話，比如最近的銀行，去某個地方怎么走之類的，我只需要記得這個號碼就可以了，然后表明我需要什么服務。

3.2     只依賴真正的標準

如果上一節我還說得不夠清楚的話，那么我再明確的表述一下我的意思，就是提出服務時，不要談及SOAP Web Service，還是Message Service，或是RESTful Web Service，或者是Corba。

我看了Corba的承諾，SOAP Web Service的設想，后來又出來RESTful web service，之后ROA有了兩個意思，一個是Resource-Oriented Architecture和RESTful SOA。我還開發過SCA（Service Component Architecture）的程序，使用過Active MQ，Spring HTTPInvoke。

經歷了這些覺得除了HTTP協議，XML（現在可以提及JSON了）之外的神馬都是浮云。

3.3     不同的外套

在瀏覽視頻網站進行分享時我受到一個啟示，就是點擊分享時，它會生成三種格式供你分享之用，分別是用于IM分享的本頁的鏈接，一種是HTML代碼<embed src=，一種是Flash鏈接。

其實服務也可以這樣，同一個服務，可以生成不同的接口，比如用于Spring程序直接調用的Spring HTTPInvoke服務，或者是SOAP Web Service，或者是RMI，這些都需要生成一些樁代碼?；蛘呤怯糜贘S調用的Javascript片段，或者是一般的RESTful Web Service。就像視頻分享網站一樣，你只需點擊一個按鈕即可。

服務就像披上了不同的外套一樣，可以出席各種場合了。

3.4     微引擎

這需要實現一個微引擎來做這件，其實這個結構非常簡單，而且可以有擴展性?？梢院芎唵蔚睦米止澊a生成（對于Spring HTTPInvoke，或RMI），或者是XML生成（SOAP，或用于RESTful）。

服務組件本身可以一個jar包，然后微引擎將其轉為web service，或者是通過URLConnection遠程加載jar包（或者是用一個框架輔助這件事，比如OSGI）。一個服務組件本來可能就是一個Web服務（這里稍微在概念上不太嚴謹，服務組件在這里應該稱為服務契約的實現或具體提供者），那么引擎會將其轉為需要的接口服務。

生成的代碼可以緩存起來，就像JSP的機制一樣。

3.5     服務中心

建立服務中心很重要，它可以發布，管理，搜索，轉換（換外套）服務。并且還可以預覽和測試服務。

服務中心的意義在于使得其能夠成為穩固的IT資產。

4       分布式服務，而非分布式對象

Martin Fowler的分布式對象第一法則提到不要分布你的對象。但是其支持分布式服務。

因此千萬不要在這里搞神馬分布式對象。

5       面向服務的框架

在過去的開發經歷中，我比較熟悉并自然的劃分為多個層次，比如展現層，領域層，數據訪問層等。在開發大型項目時，不同子系統的調用還有專門的Import和Export的Façade層。這使得系統會被豎著切若干刀。

后來在項目中使用了AOP，來進一步分離關注點，于是橫著又對系統切了若干刀，所謂橫切面。

這時系統變成了一個網格。

5.1     敏捷開發框架

我之前寫過一篇帖子談論利用CoC來快速構建應用的框架，我現在的想法更近了一步，就是加入分層次的Service，在線的UI組件庫，利用內容管理工具整合RESTful web service（其表現為JS App）或者是Mashup。

結合持續集成，自動構建工具，就可以創造一個隨需應變的面向服務的框架了。

5.2     企業服務總線

受到計算機硬件的啟示，企業服務總線由若干標準的接口（比如PCI，內存）和消息路由器組成。

5.3     服務組合

服務是可以組合起來形成更大的服務的。SCA標準支持SOAP Web Service，EJB的集成，我之前寫了一篇論文Research on e-Commerce Application Architecture Based on the Integration of Workflow and Agile Service，介紹了RESTful Web Service和Workflow的結合，并且介紹了RESTful的服務組合。這類似于將SCA，BPEL的工作轉移到REST上。

6       架構師團隊

[一個小組]是一些擁有各種技術的人的集合，他們之間有共同需要完成的目標，并且之間相互負責任。

架構師團隊的成員應該是類似于一個類繼承體系，基類是對系統架構的共同的技能，能夠為一個產品定義架構。然后每個子類代表一個或幾個方面專長或對其負責的架構師。

在這個團隊中，所有的成員一起為構建系統的架構做出決策，尤其是那些最重要的系統。而每個人會負責產品涉及的某一個領域，比如RIA，工作流，分布式，并發，遠程訪問等。

在系統設計方面，架構師主要負責針對領域問題設計出軟件模型。因此需要對領域具有深刻的理解，同時精通于領域模型和軟件結構的設計。

領域這個詞的概念很寬廣，可以指具體的業務領域，比如招聘，培訓，財務，也可以指技術領域，比如緩存，分布式等。

本文提及的框架由架構師團隊設計并完成核心模塊，而具體服務由分管架構師負責。

另外為特定業務領域創建構建模式，并利用之前提到的以服務形式提供的工具集，由一個架構師總領整個設計并對業務總體建模（保持概念完整性），分管架構師解決對應技術領域問題。

7       結束語

本文立足于服務計算的歷史和自己的相關經驗，意在總結與拓展。

基于某個致力于統一服務計算的規范來實現系統集成，服務應用都是沒有生命力的，即使SOAP Web Service這種基于HTTP協議（雖然可以用于FTP等協議，但是實際應用不多見）和XML的服務協議，依然在使用時讓大家感覺很難受。因此才有了Big Web Service這樣戲謔的名稱。

寫到最后感覺怎么跟學術論文是的。