終極SOA技術

當前似乎人人都愿意談論SOA以及它如何解決大部分(如果不是全部)的架構問題。而在本文中我不打算討論創建SOA的優點。我想談的是什么技術能最大程度地幫助我們創建面向服務架構。似乎大多數支持SOA的人都一直在討論使用web services來實現。讓我們現實一些。web services是一項不錯的技術，但是還遠遠達不到它關于創建跨web的無縫集成的承諾。用Jave創建的web services常常無法訪問.NET客戶機，反之亦然(參閱Web Services Interoperability和Web services programming tips and tricks: Improve interoperability between J2EE technology and .NET)。即使最后成功地進行跨平臺web services通信，還是會面對很多問題，比如版本控制、安全性，以及難以表示XML中的復雜數據結構。如果web services都不能解決SOA的實現問題，還有哪種技術能解決?

終極SOA技術的特征

如果讓我來開發一項技術，以協助構建健壯的面向服務架構，我認為它必須具備一些特征。具體來說，是以下特征:

對處理網絡故障的強力支持——網絡隨時都可能出現故障。我希望該技術能包含這一點，并提供抽象的概念和具體的工具以恰當地處理網絡故障。

安全性——關于這一點已經說得夠多了。

表示復雜概念/交換復雜的數據結構的能力——我不想因為技術不支持而無法提供某種服務。

跨平臺的兼容性——我不想因.NET或傳統的客戶機不能使用構建于Jave基礎上的SOA而煩惱。

易用性——鑒于新框架、新技術和新方法的不斷涌現，誰有時間糾纏于一項難以使用的技術?

現在我可以斷言，有一項現有的技術符合80%的要求:Jini。雖然Jini這個主題值得更深入的研究，而不僅僅是了解我在這里強加給您的內容，但還是讓我解釋一下為什么我認為Jini符合那些要求(其中的大部分!)。

在我看來，Jini為解決網絡故障問題提供了終極支持。由諸如租用(leasing)和自動服務發現之類的功能可以看出，Jini技術不僅意識到連接網絡的不確定性，而且還提供了處理該問題的概念和工具。

Davis項目是為解決Jini中棘手的安全性問題創建的，它已經被并入了2.0版本。支持安全性的構建與所使用的安全傳輸協議相結合，形成一個完美的安全性解決方案。

Jini使用的都是可移動代碼。因為我是在創建Jini服務，而不僅僅受限于交換數據。是的，我知道RPC(遠程過程調用)被認為已經過時了。XML才是大勢所趨。但無論如何，就我個人而言，我從不曾看好它，但那又是另外一個話題了……

跨平臺的兼容性體現在幾個方面。的確，Java是“一次編寫，到處運行”的(不是嗎?)，但是我們希望非Java的客戶機也能使用支持SOA的Jini。例如，讓支持Corba的客戶機能夠連接到Jini。要獲得關于連接到Jini的非Java客戶機的更多信息，請參考與Jim Waldo的對話。

您可能已經注意到，我將易用性放到了最后。這是Jini的不足之處。遺憾的是，構建復雜的Jini服務仍然很麻煩(需要有黑巫術、獻祭的羊和神秘的儀式，非一般人能為)。這令人沮喪。

行動呼吁

我堅信Jini具有成為支持健壯的面向服務架構創建的技術的潛力，前面我只是試圖吊起您對Jini的胃口，現在我要催促您從百忙之中抽出一點點時間來了解更多有關Jini的知識。在Jini.org上有一個繁榮的社區，Sun的官方Jini站點上也有很棒的信息。當然，您要問了，如果我所言屬實，為什么Jini沒有成為一項主流技術?為什么并非大家都在談論Jini?好吧，回到Jini技術的致命缺點:易用性。不是開玩笑，Jini很難，這限制了它的廣泛使用。如果某個大公司(例如:Sun、BEA或者IBM)能認識到Jini的力量并構造一個Jini服務器，我相信很快人人都在創建Jini服務。想想看，如果使用當前的語言特性，只能使用某些類似 @Jini-Service的方式來注釋方法，就如同一些框架允許創建web服務一樣，那為什么不利用Jini來構建SOA?問題在于創建框架(即Jini服務器)并非一項平常的任務。社區已經開始使用像Rio之類的項目來應對這項挑戰，但仍然有許多工作要做。因此我將以一個對前面提及的大公司的挑戰結尾:突破條條框框的限制，認識到使用Jini創建SOA的潛力，然后致力于創建Jini服務器，使開發人員在該平臺上能夠輕松地使用一兩個注釋來創建和部署Jini服務。嘿，如果你們不做的話，JBoss大概會做的……

(責任編輯：銘銘)