SCA、SOA與OSGi概念淺析

基於組件的編程一直是軟件業簡化編程和提升效率和質量的一個重要方法，可是每每對於不一樣語言咱們有不一樣的組件模型，從而須要不一樣的調用方式。SCA的目的是使用戶在構建企業應用時有一個再也不直接面對具體的技術細節的層次，而是經過服務組件的方式來構建應用。這種方式也使得客戶的企業應用具備良好的分層架構，可以很好的分離應用的業務邏輯和IT邏輯，不但易於應用的構建，也易於應用的更改和部署。

SCA全稱Service Component Architecture，即服務組件框架。服務組件體系結構 (SCA) 是一個規範，它描述用於使用 SOA 構建應用程序和系統的模型。它可簡化使用 SOA 進行的應用程序開發和實現工做。它由BEA、IBM、Oracle等知名中間件廠商聯合制定的一套符合SOA思想的規範。

SCA是一個可執行的模型，用於將不一樣的 服務集成到一個業務解決方案。它簡化了實現業務服務的組件編程模型，這些組件可使用不一樣編程語言實現,對於企業應用，SCA還提供了關鍵的一些基礎設施，像安全性、事務、可靠調用等，這對於企業應用的開發而言就變得很方便了。SCA確實能夠成爲企業應用開發的利器SCA確實能夠成爲企業應用開發的利器。SCA是第一項承諾提供一個組合模型以啓用服務網絡並支持構建下一代面向服務應用程序的技術。 SCA在2005年11月，發佈了0.9版本的規範，其中包括了組裝模型規範，Java/C++客戶端以及其實現規範。2006年4月，整個SCA規範有了很大的改進，推出了對應的0.95版本。2007年3月，OSOA聯盟宣佈了SCA和SDO規範中關鍵部分的完成，發佈了SCA 1.0和SDO 2.1，並將其正式提交給OASIS，經過其開放式標準過程進行推進。

SCA規範中着重解決了現有企業應用之間的相互調用和企業應用如何以面向服務的思想來創建和部署。可是對於構件容器的實現方面的規定則有些不足，僅僅是站在使用者的角度描述了客戶端API的規格。

SCA可以讓你專心於分析業務邏輯，而不須要過多的去擔憂系統架構。SCA簡化了全部開發者的使用體驗

SCA能夠將已有的程序、代碼、服務添加上元數據，從而能夠被其餘的服務引用或調用。獨立於程序代碼的元數據描述信息，能夠方便的描述已有的代碼，而不須對已有代碼作修改。

服務組件框架(SCA)提供了一套可構建基於面向服務的應用系統的編程模型。它的核心概念是服務及其相關實現。服務由接口定義，而接口包含一組操做。服務實現能夠引用其餘服務，稱爲引用。服務能夠有一個或多個屬性，這些屬性是能夠在外部配置的數據值。

SCA與SOA

既然SCA是爲基於SOA思想的系統而制定的開發、部署規範，它首先必然是具有了SOA的一系列的優勢，象跨語言、分佈式、以服務的思想構建系統等。SCA對於組件中的服務的調用提供了異步調用的支持，在異步調用的支持上SCA的考慮也較爲全面，象JMS方式的、RMI方式的等等。

使用SOA構建業務解決方案主要的優點之一就在於其能按照業務需求的變化和革新快速組裝新的解決方案。解決方案組裝的關鍵是包含現有的應用和功能的能力，而不是什麼都從頭開始。的確，只有儘量地複用現有的功能，才能完成快速開發的目標。

SCA一種是使用SOA的業務解決方案的編程模型。SCA提供了這麼一個特性，使得將已存在的功能組裝成新的解決方案儘量的簡單。該文檔檢驗了這些特性中的一些。

SCA提供了實現面向服務的架構(SOA)的一個編程模型。

面向服務的架構已經在軟件開發領域存在不少年了。可是當一些組織試圖去定義最佳的實現和管理技能的時候，爲一個特定組織開發一個SOA的細節倒是難以捉摸的。

SCA規範是爲了企業應用集成而制定，OSGI規範的初衷則是爲移動設備計算而制定的。因爲兩者的出發點不同，致使了兩個規範的側重點不同。SCA規範如今的版本是0.95，相對OSGI規範的4.0版本還顯得多少有些稚嫩。

服務組件

服務組件是SCA中的基本組成元素和基本構建單位，也是咱們具體實現業務邏輯的地方。咱們能夠把它當作是構建咱們應用的積木。咱們能夠很是容易地把傳統的POJO，無狀態會話BEAN等包裝成SCA中的服務組件。 SCA服務組件的主要接口規範是基於WSDL(Web Service Description Language)的，另外爲了給Java編程人員提供一個比較直接的接口，SCA的部分服務組件也提供了Java接口。所以，使用服務組件的客戶端能夠選擇使用WSDL接口或Java接口。

服務模塊

服務模塊(簡稱模塊)由一個或多個具備內在業務聯繫的服務組件構成。把多少服務組件放在一個模塊中，或者把哪些服務組件放在一塊兒主要取決於業務需求和部署上靈活性的要求。模塊是SCA中的運行單位，由於一個SCA模塊背後對應的是一個J2EE的企業應用項目。這裏之因此說是"背後"，緣由是咱們在開發工具WID(WebSphere Integration Developer V6.0)中，經過業務集成透視圖看到都是SCA級別的元素。可是當你切換到J2EE透視圖你就會發現這些SCA元素與實際J2EE元素之間的對應關係。所以，在WID中構建一個模塊就至關於構建一個項目。另外，因爲模塊是一個獨立部署的單元，這給應用的部署帶來很大的靈活性。好比，只要保持模塊接口不變，咱們很容易經過從新部署新的模塊而替換原有的業務邏輯，而不影響應用的其它部分。

因爲一個模塊中每每會包含多個服務組件，那咱們如何來構建這些服務組件之間的相互調用關係呢?在WID工具中，咱們只要簡單地經過接口與引用之間的連線，就能夠指定它們之間的調用關係而不須要寫一行代碼。另外，咱們能夠在這些連線上面設定須要的QoS要求，好比事務，安全等。

SCA和SDO/OSGi

SCA和SDO規範能幫助企業更便捷地建立新的以及改造現有的IT資產，使之可複用、易整合，以知足不斷變化的業務需求。這些規範提供了統一服務的途徑，大大下降了在應用開發過程當中，因程序設計語言與部署平臺的不一樣而產生的複雜性。SCA和SDO規範都是用於簡化業務邏輯和業務數據呈現的新興技術。早期用戶已經開始實行這些規範並從中得到了價值。

SCA和SDO的出現，給SOA來了點實際的。SCA(Service Component Architecture)其實就是將過去EJB的成果繼續下去，基於Component的複用，同時吸取了IOC的思想，Component之間的組裝是經過SCA框架來實現的，可是很重要的一點，他沒有走EJB的老路，而是學習spring的輕量級框架，再也不爲開發者做的面面俱到，其實，特別對於中國的程序員來講，不須要太多的框架去限制他們，只須要給他們一個能夠訂製的靈活的框架便可，他們的手藝都不錯，同時也能夠在這個訂製的階段學到不少，這也是爲何開源項目吸引那麼多高手的緣由，由於參與和創造才能給程序員一種自我實現的快感。SCA的Component和OSGI的Bundle同樣實際上是對Java封裝的一種貫徹，它有須要Import的服務引用，須要Export的服務，很重要一點就是它對於Component，service,reference的實現都沒有做限制，這類對象只須要有個接口定義和實現描述便可，當前規範中支持的接口定義能夠是java接口也能夠是wsdl文件(最終也是轉換成爲java接口)，實現的話那麼更加普遍java,webservice,rmi,jms,腳本語言等等，同時提供了擴展接口，因此只要你想的到，就能夠實現的了。而後多個Component組裝成爲一個Composite(對於業務開發來講，也就是一個業務的Model)。

SCA支持遠程調用其餘組件的服務，而這點正是OSGi的一個巨大的缺點，也是EEG如今正在努力作的;SCA對於遠程調用其餘組件的服務支持象Webservice、JMS、JCA、RMI、CORBA等等方式的調用。

SCA和OSGI之間的優缺點是能夠互相彌補的。SCA和OSGI的優劣，但其實做爲這兩個規範面向的解決問題都是不一樣的，SCA是SOA的一個實現，SOA是解決分佈式服務的互通問題，而OSGI是針對單機服務的動態綁定義及組裝，所以二者不存在着可比性，可是在我看來，二者卻有着很好的互補性，在平臺的現有狀況下，用SCA來實現服務框架，同時經過OSGI來實現組件裝配，這無疑是很好的一件事情，一樣有個開源項目也正在作這件事。

SCA 方法的優點包括：

簡化業務組件開發

簡化做爲服務網絡構建的業務解決方案的組裝和部署

提升可移植性、可重用性和靈活性

經過屏蔽底層技術變動來保護業務邏輯資產

提升可測試性

SCA容許在很寬的implementation types(實現類型)中選擇任何一種實現，例如象Java、BPEL或者C++等都是implementation types(實現類型)，每一種類型都描述一個明確的實現技術。這些技術不只能夠是一種語言，象Java，還能夠是特殊的框架或者運行環境，象Java技術中的Spring框架和J2EE技術中的EJB環境。

目前，SCA提供了Spring、EJB、JavaScript、Groovy、Ruby、BPEL等的實現技術，能夠將已有的程序實現加入到SCA系統中，爲SCA提供具體的功能實現。也能夠根據實際須要，經過SCA提供的擴展機制，將新的技術增長到SCA系統中。