服務框架，這個名詞已經出現了很多年了，很早以前系統的架構就希望是以基于服務框架的方式來搭建的，turbine、phoenix、avalon等都是朝著實現服務框架的目標而去，如今的SCA，也可以說就是為了提供一個可用的服務框架，服務框架在系統中到底承擔什么角色呢，為什么它會顯得那么重要呢，如果要實現一個服務框架，不太可能從最底層做起，那么我們又需要怎么樣去選擇呢？
服務本身是個挺形象的名詞，在系統設計中我們非常強調輸入和輸出，服務呢，可以說是更形象的去強調了這一點，每個模塊都會對外提供一定的功能，而這些對外提供的功能我們就可以作為服務了，細到模塊內，我們也會發現模塊內各個類其實也是以服務的方式來交互的，在這樣的情況下，服務框架自然就成了整個系統的核心基礎框架，那么服務框架能幫我們來提供哪些功能呢，如果我們要實現一個服務框架，有哪些要素是需要考慮的呢，歡迎大家拍磚，多多交流！
1、如何注冊服務
怎么樣注冊出服務這東西呢，:)，這是我們在做考評時的第一要素了，最理想的莫過于通過xml將一個pojo描述為服務了，或者是java annotation的方式了。
另外個可以附加考評的點就是在注冊服務時是否支持部署到指定的服務中心，類似websphere的遠程部署。
2、如何調用服務
如何調用服務，這個可以說是考評中很重要的一個因素，而且也是比較復雜的考評點。
從調用的方式上來講，服務的調用需要考評的有是否支持injection方式和顯式調用方式、本地調用和遠程調用的區別、同步調用和異步調用的區別、lazy式的調用還是固定的引用調用，從考評的期望上來講，我們當然是希望injection和顯式調用都支持，本地調用和遠程調用、同步調用和異步調用能透明式的配置，lazy式的調用是指注入或調用的服務只有在切實調用到相應的方法時才會獲取到真實的服務對象，而固定的引用調用時指當調用服務時即獲取到真實的服務實例對象，lazy式的調用和固定引用調用的支持對于集群應用場景會產生很大的影響。
調用服務同時涵蓋了查找服務的概念，在查找服務方面考評的點就是是否支持按需查找服務、查找多個服務，由于同樣的服務在系統中可能存在多個不同的實現，按需查找服務的意義就在于可以準確的指定所需的服務，這對于需要按規則準確查找服務的應用場景而言是很重要的；查找多個(0..n)服務呢，對于需要調用可用的所有服務的應用場景很重要，這個功能對于當調用的服務不是必須的時候也是非常重要的，例如引用了日志服務，但即使當日志服務不可用的時候也需要不影響當前類的功能的應用場景。
在調用服務上還需要考慮調用服務的安全性，例如認證、權限控制等。
在調用服務上還需考慮此框架中的服務是否可以很容易的被第三方進行調用，例如在spring中調用、在其他的語言中調用等，呵呵，是不是有點SCA的感覺。
3、如何測試服務
服務的測試無疑也是考評的重要點之一，要知道當年webwork能在MVC框架領域爭得一席地位和其action更好的支持了單元測試有很大的關系，所以服務框架在此方面支持的怎么樣也是需要考評的要素之一。
4、服務的生命周期
由于服務的生命周期是由服務框架來控制的，因此服務的生命周期是如何轉換的這也是我們在考察服務框架時需要知道的。
另外一個考評點就是如果服務的生命周期發生轉變時，引用此服務的類是否能得到通知等，當然，如果是lazy式的調用的話，完全不存在這問題。
5、服務的管理和維護
這個對于服務框架而言應該是比較基礎的功能，包括的有提供服務列表，在服務列表中應該有服務的名稱、所屬的服務中心、服務的狀態、服務的處理日志以及服務訪問的壓力記錄等等。
服務的管理就包括了服務的安裝、升級、啟動、停止和卸載。
6、服務的組裝
服務的組裝的概念是指可以靈活的將多個服務組裝為一條鏈，然后鏈式的調用，這個呢是附加的考評要素了。
7、服務的出錯處理
需考評當位于此服務框架下的服務處理出錯時會造成什么現象，最理想的結果自然是服務的調用停止，并記錄相關的日志，另外的服務對此情況做出糾錯處理，有點像erlang的容錯思想，:)，最基本的一點就是不能影響到服務框架和其他服務的正常運轉。
8、服務事件的廣播和訂閱
允許服務在處理時能對外廣播事件，同時也可訂閱事件，以觸發某些動作，這里可以附加考評的就是是否支持多種靈活的服務觸發方式，例如定時的觸發等。
其他可考評的要素還有服務框架對于AOP的支持、是否可建立服務庫，就像bundle repository一樣，:)
當然，目前開源界應該說是沒有此類框架的直接存在的，但我們可以基于Equinox、Newton等已存在的類似框架來實現一個這樣的標準的服務框架，考評時就可以根據這些點去判斷基于哪個已有的框架是較好的選擇了。