2006年11月10日

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

SCA

?????? 服務構件架構 (Service Component Architecture) 是一套規范，它描述了采用面向服務的體系結構來搭建應用和系統時的模型。 SCA 擴展并完善了以前實現服務的方法，并且 SCA 構建在開放的標準之上，

例如： Web Service

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

?

OSGi

?????? OSGi 是什么， OSGi 是一種服務運行平臺。通過實現能夠提供服務的符合 OSGi 規范的組件，用戶可以將其組件發布到 OSGi 運行平臺，供用戶和其他組件使用。 OSGi 組件提供的服務具有兩個層面的含義：系統層面，即一個組件為其他組件提供服務，這些服務體現為 Java 接口的實現；業務層面，即一個組件為外部系統或用戶提供某種業務服務實現。

?

從概念看我們可以很快發現他們的相同點和不同點。

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

模塊：

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

?

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

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

?

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

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

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

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

???????? 歡迎大家一起討論 OSGi 和 SCA 技術。

  2006年5月31日

這幾天總算有點時間，可以看看手頭的書了。

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

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

?

所謂的主旋律，個人理解就是一種審美觀點，就像大家看到漂亮的 MM 一樣，為什么 MM 這么漂亮，因為他符合人們對漂亮的機電看法
—— 國色天香 傾城傾國 沉魚落雁 閉月羞花 如花似玉 花容月貌 美若天仙 艷如桃李。。。反正就是美。

從設計模式角度說明主旋律，就是設計中常常遵守的幾點原則——可維護性，可擴展性，可復用性，要面向接口去設計，等等。

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

2??????? 簡單

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

這種情況還出現在我們當初在做一個業務系統的時的框架選擇上，當時我們為了框架能夠承受更大的負載度，而考慮使用 EJB 的多層開發（幸運的是沒有用實體 Bean ），這使我們的開發量整整增加的一倍，還在不考慮測試的情況下。項目結束了上線使用，用戶根本沒有當初設想的并發量，我們當時真的還考慮了 Rod 所說的是否能夠在客戶端支持 Swing 程序，幸虧后來被否定了。有時候我們在設計中總是追尋完美，為了設計而設計，這種做法正如 Rod 所說的是不科學的。

簡單才是美，因為簡單出現了 POJO 對象，因為簡單出現了 Hibernater ，因為簡單出現了 Annotation ，因為簡單出現了 EJB3.0 。因為簡單才是 java 的開源社區如火如荼，人聲鼎沸。

?

2??????? 高產

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

去年在開發一個項目的時候，因為我們是和其他部門一起合作開發，在項目開始的調研當中，我們極力推薦使用我們的 JBrain 元數據框架，而另為一個部門卻強調使用 JSF 所建立的框架（ JSF 剛出來，而且那個部門的人員還沒有太多的理解 JSF 的深刻含義，他們覺得 JSF 非常好，非常的完美），最后因為我們的框架是黑盒的，客戶不想把他們的項目綁死在我們的框架上，所以最后決定使用 JSF 來設計框架（不說開發一個企業級框架所需要的時間），這里我不是說 JSF 不好，我研究過 JSF ，覺得他的設計哲學真的很好，尤其他的組件樹和生命周期設計的非常完美，尤其他的 Render 機制，真的就是我們以前在使用 jsp Tag 的時候一直想要又沒有的功能（我們框架中的顯示模型有很多思想是從他的組件數概念而來的），但是如果用 jsf 開發企業級程序，而且是在國內這種客戶要求非常苛刻的情況下是非常不足的。因為我們的 JSF 框架是在 Apache 的 MyFace 基礎上開發的，實際上后來他的標簽我們沒有用多少，大部分都是我們自己在他的基礎上重新開發的。后來框架設計出來了，生產率太低，完成一個工作需要做很多很多的事，我實在看不下去了，看著我周邊的同事一邊又一邊的嘆氣（而且項目結束前幾乎是天天加班到 9 點），根據我們原有框架的元數據原理，寫了一個 JSF 框架的代碼生成機，這才把生產率稍微提上了一點。

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

?

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

  2006年5月10日

在現在的應用系統中幾乎都能看到xml和database的身影,與這兩個東西正交的是OO.

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

?

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

比較有名的框架有:

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

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

+ JAXB 是JAVAEE中的對于xml和OO對象Binding定制的新的規范(標準阿!);

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

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

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

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

?

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

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

不斷整理中。。。

  2005年6月25日

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

       JBrain框架的設計的初期目的就是要提供一個基本的企業級運行環境，就好比JVM一樣。而下一期開發的目標就是在JBrain框架的這一個運行環境的基礎上，開發一套建模語言，而JBrain框架就是這種模型語言的運行環境。

       我們為了這個目標都在研究MDA，個人覺得MDA的思想是 “ Perfection”，但是實現他談何容易，我們研究它只是研究它的思想，通過這種思想，能夠給我們以啟發。
   

  2005年6月16日

   再一次的看設計模式的時候，感覺自己對設計模式，有了一個進一步的理解（自我感覺的J）.

       在數學計算中我們要求AàB點的最短路徑，可能從A點到B點有很多種走法，但是追求完美的我們（尤其是程序員），總是希望找到一條最短的路徑。設計模式也是相同，在設計中我們想要找到設計中的最短路徑，也就是設計的永恒之道（就是設計模式中常說的無名的質），說白了，就是如何設計才能使系統更容易擴張，更靈活，更穩定。模式追求的是一種最佳的解決方案，在這個方案的指導下，我們能夠跟好的去實現我們所想要實現的東西。

       數學計算的時候有一定的法則，軟件設計的時候也是有一定的法則的，而這些法則，都是在追求軟件設計的守恒定律時形成的——什么開/閉原則，面向接口原則，依賴倒置原則等等，但是軟件設計中的原則也是可變的，而且是時刻發展的，要不然就不會出現，今天的spring非?；鸬膱雒妫?/SPAN>Ioc原則。

       數學計算是通過許多的公式推倒出結果的，但是我們求解的時候，會出現這種情況，C結果，是通過A和B兩個公式推導出來的，模式也是一樣，有一些較小的模式，而這些較小的模式是一些較大的模式的基礎。

       在理解模式的時候我們可以從對象的生命周期來理解。

       對象產生的時候需要描述對象的屬性，它的存在形式，創建模式就是用來描述這個的；而這個對象存在就會和其他對象發生聯系，就會和其他對象發生作用，如何描述他們之間的聯系和作用就是結構模式要做的事了；前面這些都是靜態的，對象的存在，不可能永遠靜止不動的，它會根據自己的需要，完成一些動作，語言中還有動詞，名詞，形容詞之分呢！模式就跟語言一樣需要有動詞來描述對象，行為模式就是用來描述對象的行動的；

       設計模式，實際就是一種設計中的語言，很多的最基本的模式，就是組成這種語言的基礎，我們在理解模式的時候不能只是背模式，而應該靈活的運用他們，讓他們有機的結合在一起，形成一個生動的句子。這個就好比我們學英語，不是光背一些單詞，就能寫出一篇好文章的，還需要我們有語感，理解了以后才能寫出來。

       這個只是我對模式的一點點個人的理解，不代表所有人的觀點！：）