這段時間看了不少的文章都是關(guān)于 SCA 與 OSGi 之間比較的。且不論他們之間到底有沒有關(guān)系，我們來看看他們的定義

SCA

?????? 服務(wù)構(gòu)件架構(gòu) (Service Component Architecture) 是一套規(guī)范，它描述了采用面向服務(wù)的體系結(jié)構(gòu)來搭建應(yīng)用和系統(tǒng)時的模型。 SCA 擴(kuò)展并完善了以前實(shí)現(xiàn)服務(wù)的方法，并且 SCA 構(gòu)建在開放的標(biāo)準(zhǔn)之上，

例如： Web Service

服務(wù)構(gòu)件架構(gòu) SCA （ Service Component Architecture ）為建設(shè)基于面向服務(wù)的體系結(jié)構(gòu)的應(yīng)用和系統(tǒng)提供了一種編程模型。這基于一種觀點(diǎn)，即業(yè)務(wù)功能以一系列服務(wù)的形式被對外提供出來，然后它們被組合在一起去實(shí)現(xiàn)滿足特定業(yè)務(wù)需求的解決方案。這些復(fù)合的應(yīng)用，可以包含專門為此應(yīng)用程序創(chuàng)建的新服務(wù)，也可以包含來自已有的系統(tǒng)和應(yīng)用程序的業(yè)務(wù)功能，重復(fù)利用就像其中的一部分一樣。 SCA 即為組合服務(wù)提供了模型，也為服務(wù)構(gòu)件的創(chuàng)建，包括在 SCA 組裝中重用已有應(yīng)用系統(tǒng)的功能提供了模型。

?

OSGi

?????? OSGi 是什么， OSGi 是一種服務(wù)運(yùn)行平臺。通過實(shí)現(xiàn)能夠提供服務(wù)的符合 OSGi 規(guī)范的組件，用戶可以將其組件發(fā)布到 OSGi 運(yùn)行平臺，供用戶和其他組件使用。 OSGi 組件提供的服務(wù)具有兩個層面的含義：系統(tǒng)層面，即一個組件為其他組件提供服務(wù)，這些服務(wù)體現(xiàn)為 Java 接口的實(shí)現(xiàn)；業(yè)務(wù)層面，即一個組件為外部系統(tǒng)或用戶提供某種業(yè)務(wù)服務(wù)實(shí)現(xiàn)。

?

從概念看我們可以很快發(fā)現(xiàn)他們的相同點(diǎn)和不同點(diǎn)。

???????? 他們都是一種組件模型，而且是面向服務(wù)的編成模型，都對服務(wù)組件模型作了相應(yīng)的定義。在兩種模型中都有“模塊”，“組件”，“服務(wù)”這 3 種共同的概念。我們分別從這三種感念來看看他們之間的差別

模塊：

???????? 可能 OSGi 對于模塊的概念定義的更完善一點(diǎn)，支持模塊的動態(tài)更新和依賴，而 SCA 對于模塊的概念中沒有涉及動態(tài)更新的概念 ( 實(shí)際如果把 SCA 中的模塊映射到 JEE 中的 EAR 塊就可以做到了 ) ，對于模塊間依賴關(guān)系的定義也沒有 OSGi 中 Export/import 定義的完美，對于一個包的引用，要存在 2 個不同的副本，至少 WPS （ IBM 中 SCA 的實(shí)現(xiàn)）中是這樣。所以說模塊的定義 OSGi 要比 SCA 要完善，實(shí)際上這樣是兩種模型出發(fā)點(diǎn)是完全不同的， OSGi 設(shè)計之初主要是面向網(wǎng)絡(luò)設(shè)備的，最后被 Eclipse 所采用才為大家所知的，而 SCA 從一開始就是面向企業(yè)級應(yīng)用的，所以這方面沒有 OSGi 定義的完善。模塊的定義 OSGi 是在 MANIFEST.MF 文件中通過元數(shù)據(jù)定義的，而 SCA 是在 sca.module 文件中定義的 xml 格式。從這點(diǎn)上我們就可以看出來， OSGi 只能是在 java 平臺上（他的規(guī)范中說明也是只適合 java 平臺的，規(guī)范的 0layer 定義了它的最小 runtime ），而 SCA 是一種跨平臺的規(guī)范，它不依賴于平臺，你可以是 Java 環(huán)境也可以 C++ 環(huán)境。

?

???????? 對于組件的概念，個人感覺 OSGi 是在 DS （ OSGI R4 的 Declarative Services ）出來以后才有了比較定性的定義，而 SCA 從一開始就非常強(qiáng)調(diào)組件的定義，對于 SCA 組件可以是一個 webservice ，一個 java 對象，一個有限狀態(tài)機(jī)中的規(guī)則對象，也可以是一個 BPEL 流程對象，還可以一個人工干預(yù)的工作流對象，更可以是許多組件的組合對象，這一點(diǎn) OSGi 組件是做不到，也不要想 OSGi 能夠做到，因?yàn)樗麄兊脑O(shè)計出發(fā)點(diǎn)根本是不同的，不要把企業(yè)級應(yīng)用的東西強(qiáng)加到 OSGi 中來，在 OSGi 中的組件可以發(fā)布 / 查找服務(wù)， SCA 也可以這么做，對于服務(wù)的引用， OSGi 只能是在 single JVM 中，不要怪 OSGi 要知道他當(dāng)初設(shè)計的目標(biāo)就是網(wǎng)絡(luò)設(shè)備，不用考慮企業(yè)級應(yīng)用中的分布式，服務(wù)質(zhì)量什么的。但是組件概念上 SCA 有一點(diǎn)還是弱于 OSGi ， OSGi 對服務(wù)的引用可以做到動態(tài)更新，一個服務(wù)改變了，它可以動態(tài)的或者是靜態(tài)的更新應(yīng)用它服務(wù)的組件對象，這一點(diǎn)在網(wǎng)絡(luò)設(shè)備中是非常重要的，但是在 SCA 這種企業(yè)級應(yīng)用中到底需不許多要我們還需要考慮，畢竟如果我們是面向接口編成，而不用關(guān)心細(xì)節(jié)是什么，你的服務(wù)再怎么更新，只要我們的接口不變就不會用什么問題。

???????? 而服務(wù)，最大的差別可能就是 OSGi 是在 single JVM 內(nèi)的所以對于服務(wù)的引用永遠(yuǎn)都是直接的內(nèi)存引用吧，而 SCA 在服務(wù)的引用上附加了 Binding 的概念也就多了一個協(xié)議的選擇層，很象 jmx 中 distributed layer ， SCA 對于服務(wù)的 Export/Import 都需要 Binding 一個具體的實(shí)現(xiàn)，你的服務(wù)可以通過 WebService 來發(fā)布，也可以通過 RMI ， JMS 等等來發(fā)布。這一點(diǎn)是 SCA 的設(shè)計出發(fā)點(diǎn)來決定的（面向企業(yè)級的應(yīng)用開發(fā)）。對于服務(wù)的調(diào)用，不僅僅是必須在環(huán)境內(nèi)的調(diào)用，也可以在環(huán)境外進(jìn)行調(diào)用，比如你在一個 JSP 頁面想要調(diào)用 SCAExport 出來的服務(wù)，你就可以通過 SCA 提供的 Tools 直接調(diào)用， OSGi 是不支持環(huán)境外調(diào)用的。

?

???????? 從以上來看 OSGi 和 SCA 除了基于同樣的設(shè)計方法，其他的不具什么可以比較性，因?yàn)樗麄冊O(shè)計的根本意圖上是不同的，一個是用在單一個的 JVM 中的面向網(wǎng)絡(luò)設(shè)備或者像 Eclipse 這種應(yīng)用，不需要考慮服務(wù)質(zhì)量，服務(wù)的可靠性，分布式，等等。而 SCA 從誕生之初就為了解決 SOA 應(yīng)用中的規(guī)范性，而且與他同級別的還有 SDO 來定義服務(wù)的數(shù)據(jù)對象，這一點(diǎn)也是 OSGi 中沒有定義的。

???????? 有人會說 OSGi 最近正在定義在企業(yè)級應(yīng)用的規(guī)范（ EEG ）， Eclipse 的 RSP 也在做相應(yīng)的努力。但是如果是在 SCA 之外另開辟出一個新的模型空間，個人覺得不太可能，畢竟 SCA 是 IBM ， BEA ， Oracle ， Sap 這些廠商在認(rèn)識到許多現(xiàn)有技術(shù)的不足之后總結(jié)出來的設(shè)計模型，是這些廠商經(jīng)驗(yàn)的積累，就像 OSGi 是 OSGi 組織在網(wǎng)絡(luò)設(shè)備應(yīng)用中的積累的一樣，這兩種技術(shù)只能出現(xiàn)互補(bǔ)性，再說 SCA 模型的定義充分體現(xiàn)的軟件界一貫的規(guī)則“重用”，不管是 IBM 的 WPS ，還是 Apache 的 Tuscany 都是以現(xiàn)有平臺為出發(fā)點(diǎn)設(shè)計的，是把 SCA 這種模型與現(xiàn)實(shí)技術(shù)做一定的映射，例如，如何實(shí)現(xiàn)異步調(diào)用就可以以借助 JEE 環(huán)境中的消息或者 Corba 中消息機(jī)制。

???????? 真希望看到 OSGi 的 EEG 組織和 SCA 規(guī)范定制組織合作的場景。這樣不僅可以讓組件服務(wù)思想得到升華，還能為企業(yè)級開發(fā)開辟一個新的天地。

???????? 以上觀點(diǎn)純屬個人感觸，不代表任何特別的言論，其實(shí)最近正打算吧原有的平臺遷移到 OSGi 平臺上，在研究過程中發(fā)現(xiàn)了許多有趣的地方。

???????? 歡迎大家一起討論 OSGi 和 SCA 技術(shù)。

這幾天總算有點(diǎn)時間，可以看看手頭的書了。

手頭一直有本書從買來就沒有翻一下——《 expert one-on-one J2EE Development without EJB 》，這幾天沒事翻了一下。覺得大師就是大師一上來就把我們的苦衷說的清清楚楚，還是實(shí)踐出真理阿。

最讓我記憶猶新的是這幾句話：

?

?????? 檢驗(yàn)一個體系結(jié)構(gòu)是否合理，判斷一種實(shí)現(xiàn)選擇是否合適，都要看他是否符合這一主旋律。 ?????? 主旋律是： 2??????? 簡單 2??????? 高產(chǎn) 2??????? 面向?qū)ο鬄楸?/span> 2??????? 業(yè)務(wù)需求至上 2??????? 重視檢驗(yàn)過程 2??????? 重視可測試性

所謂的主旋律，個人理解就是一種審美觀點(diǎn)，就像大家看到漂亮的 MM 一樣，為什么 MM 這么漂亮，因?yàn)樗先藗儗ζ恋臋C(jī)電看法
—— 國色天香 傾城傾國 沉魚落雁 閉月羞花 如花似玉 花容月貌 美若天仙 艷如桃李。。。反正就是美。

從設(shè)計模式角度說明主旋律，就是設(shè)計中常常遵守的幾點(diǎn)原則——可維護(hù)性，可擴(kuò)展性，可復(fù)用性，要面向接口去設(shè)計，等等。

以上這些都是從理論角度出發(fā)考慮的，而 Rod Johnson 是從實(shí)踐的角度來考慮問題，大學(xué)學(xué)了點(diǎn)哲學(xué)原理都運(yùn)用在這里了。以前在設(shè)計第一個框架的時候沒有太多的考慮到程序員的實(shí)用型，只是為了設(shè)計而設(shè)計，最后把框架設(shè)計的及其復(fù)雜，最后的結(jié)果只有進(jìn)行重新設(shè)計，進(jìn)行框架的重構(gòu)。而在設(shè)計中遇到的問題很多是 Rod 在書中描述的場景，真是深有感觸阿。

2??????? 簡單

設(shè)計中常常應(yīng)該遵守 2/8 原則，系統(tǒng)中 80% 是最長用的，應(yīng)該以這 80% 為重點(diǎn)去設(shè)計，如果只是為了設(shè)計中的完美而過多地考慮其他的 20% 就會陷入復(fù)雜的漩渦。就拿我們現(xiàn)在設(shè)計的 JBrain （我們的框架代號）框架中的元數(shù)據(jù)系統(tǒng)來說把，本來是為了對系統(tǒng)中的所有元素的一個建模過程，涉及到顯示模型建模，業(yè)務(wù)模型建模，數(shù)據(jù)模型建模，工作流模型建模，（這個就好比在基礎(chǔ)框架基礎(chǔ)上又抽象出一層），我們在建模中就是考慮到那 80% 常見的情況，對模型系統(tǒng)進(jìn)行設(shè)計，但是每一個業(yè)務(wù)都會涉及到報表系統(tǒng)，這就是那 20% 的情況，如果我們再花精力去研究報表系統(tǒng)的建模，就會把自己帶入無比復(fù)雜的深淵中，所以我們決定用這 80% 的模型建模來描述這 20% 的報表建模，這樣問題就簡單多了，對于報表的設(shè)計來說，雖然有點(diǎn)麻煩，但是我們的設(shè)計可以適應(yīng)大多數(shù)的情況。實(shí)際只要我們作一些輔助的工具就可以簡化報表模型的建模，這是我們在框架開發(fā)的后期發(fā)現(xiàn)的，經(jīng)過實(shí)踐證明我們當(dāng)初的想法是真確的。

這種情況還出現(xiàn)在我們當(dāng)初在做一個業(yè)務(wù)系統(tǒng)的時的框架選擇上，當(dāng)時我們?yōu)榱丝蚣苣軌虺惺芨蟮呢?fù)載度，而考慮使用 EJB 的多層開發(fā)（幸運(yùn)的是沒有用實(shí)體 Bean ），這使我們的開發(fā)量整整增加的一倍，還在不考慮測試的情況下。項(xiàng)目結(jié)束了上線使用，用戶根本沒有當(dāng)初設(shè)想的并發(fā)量，我們當(dāng)時真的還考慮了 Rod 所說的是否能夠在客戶端支持 Swing 程序，幸虧后來被否定了。有時候我們在設(shè)計中總是追尋完美，為了設(shè)計而設(shè)計，這種做法正如 Rod 所說的是不科學(xué)的。

簡單才是美，因?yàn)楹唵纬霈F(xiàn)了 POJO 對象，因?yàn)楹唵纬霈F(xiàn)了 Hibernater ，因?yàn)楹唵纬霈F(xiàn)了 Annotation ，因?yàn)楹唵纬霈F(xiàn)了 EJB3.0 。因?yàn)楹唵尾攀?/span> java 的開源社區(qū)如火如荼，人聲鼎沸。

?

2??????? 高產(chǎn)

有時候，設(shè)計者注重的是設(shè)計，這也是我們設(shè)計中常常存在的一種習(xí)慣，程序員總是追求完美，追求 perfect ，而一個企業(yè)在完成項(xiàng)目中要的是生成率，要的是質(zhì)量，一個功能用那種完美的框架需要 2 周的時間才能開發(fā)完，而使用簡單的框架只需要 3 天的時間就可以完成了，你說我們應(yīng)該使用那種框架。

去年在開發(fā)一個項(xiàng)目的時候，因?yàn)槲覀兪呛推渌块T一起合作開發(fā)，在項(xiàng)目開始的調(diào)研當(dāng)中，我們極力推薦使用我們的 JBrain 元數(shù)據(jù)框架，而另為一個部門卻強(qiáng)調(diào)使用 JSF 所建立的框架（ JSF 剛出來，而且那個部門的人員還沒有太多的理解 JSF 的深刻含義，他們覺得 JSF 非常好，非常的完美），最后因?yàn)槲覀兊目蚣苁呛诤械模蛻舨幌氚阉麄兊捻?xiàng)目綁死在我們的框架上，所以最后決定使用 JSF 來設(shè)計框架（不說開發(fā)一個企業(yè)級框架所需要的時間），這里我不是說 JSF 不好，我研究過 JSF ，覺得他的設(shè)計哲學(xué)真的很好，尤其他的組件樹和生命周期設(shè)計的非常完美，尤其他的 Render 機(jī)制，真的就是我們以前在使用 jsp Tag 的時候一直想要又沒有的功能（我們框架中的顯示模型有很多思想是從他的組件數(shù)概念而來的），但是如果用 jsf 開發(fā)企業(yè)級程序，而且是在國內(nèi)這種客戶要求非常苛刻的情況下是非常不足的。因?yàn)槲覀兊?/span> JSF 框架是在 Apache 的 MyFace 基礎(chǔ)上開發(fā)的，實(shí)際上后來他的標(biāo)簽我們沒有用多少，大部分都是我們自己在他的基礎(chǔ)上重新開發(fā)的。后來框架設(shè)計出來了，生產(chǎn)率太低，完成一個工作需要做很多很多的事，我實(shí)在看不下去了，看著我周邊的同事一邊又一邊的嘆氣（而且項(xiàng)目結(jié)束前幾乎是天天加班到 9 點(diǎn)），根據(jù)我們原有框架的元數(shù)據(jù)原理，寫了一個 JSF 框架的代碼生成機(jī)，這才把生產(chǎn)率稍微提上了一點(diǎn)。

實(shí)際有時候我們設(shè)計框架的時候不必要考慮過多，一定要從開發(fā)和實(shí)用的角度去考慮，多考慮一下程序員的工作方式。

?

?????? 今天就寫到這里，可能是和 Rod 的 Without EJB 中的想法產(chǎn)生了共鳴才有了這么多費(fèi)話，其他的感觸將在后續(xù)的隨筆中寫到。寫這篇文章也是為了提醒自己開發(fā)的時候一定要從實(shí)際出發(fā)，一切的靈感都是來源于實(shí)踐的。

?

在現(xiàn)在的應(yīng)用系統(tǒng)中幾乎都能看到xml和database的身影,與這兩個東西正交的是OO.

• XML <==> OO 影射的東西有很多,一般都是使用marshaller架構(gòu).

?

(這里不說用于xml解析的dom和sax模型,只是說xml與pojo的影射關(guān)系:)其實(shí)再怎么影射也是通過dom或者sax接口的實(shí)現(xiàn)進(jìn)行解析的,還是通過新的javaSE規(guī)范Streaming API for XML (StAX), xml和OO的影射只不過進(jìn)行了抽象封裝,把xml到pojo之間的解析部分透明化了,我們這里實(shí)際說的其實(shí)是JavaEE5.0中一個新的規(guī)范Java Architecture for XML Binding (JAXB))

比較有名的框架有:

+ castor 比較有名的一個O/X影射框架,可以根據(jù)xsd生成解析框架.(個人比較喜歡使用她)

+ apache 的xmlbean和Commons-Digester(不知道為什么會存在兩個同樣領(lǐng)域的東西,可能是digester相對來說比較簡單,因而它被許多的apache的開源項(xiàng)目使用);

+ JAXB 是JAVAEE中的對于xml和OO對象Binding定制的新的規(guī)范(標(biāo)準(zhǔn)阿!);

實(shí)際要研究xml和OO的影射框架,大家不妨看看現(xiàn)有的web service框架就會了解很多了,建議看Codehaus的 XFire 他是一個比較輕量級的WS框架,AXIS2也不錯.

我了解的XML Binding框架就這么多,如果誰知道更好用的可以告訴我,相您請教.

• 對于O/R mapping 就不用太說了,大家了解的可能都比我多,個人只用過一下幾個:

+ hibernate ,ibatis ,jdo ,castor jdo(期待EJB3.0種的Persistence規(guī)范JPA)對于這幾種框架的介紹就不說明了,google一下會出來無數(shù).

?

?這里不是想討論兩種技術(shù),而是想聽大家對XML到database的影射有什么更好的辦法,因?yàn)镺/X,O/R都有很好的框架了,是否有X/R的好的框架.

這里我只知道castor 中對從xml到database有一定的支持,但支持的還是不夠,hibernate3.0種好象對xml到database進(jìn)行了支持,但是也是一些簡單的支持.

不斷整理中。。。

   這幾天在研究框架架高層次的抽象問題，還有框架的一些集成問題，可能要沒時間維護(hù)Blog；框架的初期版本已經(jīng)開發(fā)完畢了，在幾次初期的使用中，反映還是不錯的，真是高興。但是還有很多不足的地方，下一階段對框架的開發(fā)，主要就是在調(diào)試和測試方面。

       JBrain框架的設(shè)計的初期目的就是要提供一個基本的企業(yè)級運(yùn)行環(huán)境，就好比JVM一樣。而下一期開發(fā)的目標(biāo)就是在JBrain框架的這一個運(yùn)行環(huán)境的基礎(chǔ)上，開發(fā)一套建模語言，而JBrain框架就是這種模型語言的運(yùn)行環(huán)境。

       我們?yōu)榱诉@個目標(biāo)都在研究MDA，個人覺得MDA的思想是 “ Perfection”，但是實(shí)現(xiàn)他談何容易，我們研究它只是研究它的思想，通過這種思想，能夠給我們以啟發(fā)。