在前面兩篇文章中,我們了解了中間件的基本概念和中間件的主要技術分類,在這篇文章中我們了解下基于中間件的主流技術平臺。
現有的基于中間件的主流技術平臺1般典型的利用是為3層/多層結構的散布式軟件系統提供各種開發支持,由于3層結構的散布式軟件的核心為中間層,因此支持主要集中在對中間層開發的支持上,目前應當最廣泛的技術平臺有3類:
基于 OMG(ObjectManagement Group,對象管理組織)CORBA規范
基于 Sun JEE(JavaEnterprise Edition,Java 企業版)規范
基于Microsoft的Distributed interNet Applications (DNA) 2000規范、
CORBA規范是OMG組織基于眾多開放系統平臺廠商提交的散布對象互操作內容的基礎上制定的公共對象要求代理體系規范,用于開發和配置散布式利用的服務器端中間件模型的規范,讓散布式利用程序中的遠程對象可以相互通訊,獨立于系統平臺和開發語言。
CORBA所基于的概念框架是對象管理體系結構(Object Management Architecture,OMA) ,OMA 描寫了1個基于 CORBA的利用系統的基本結構與構成系統的構件的特性。
OMA的核心基礎設施是象要求代理(ObjectRequest Broker,ORB),
,CORBA規范規定了ORB的標準體系結構。ORB 負責完成查找要求的對象實現、讓對象實現準備好接收要求、傳遞構成要求的數據等完成遠程調用時底層通訊任務所需的全部機制
CORBA CCM(CORBAComponentModel)技術,是在支持POA的CORBA規范(版本2.3以后)基礎上,結合EJB當前規范的基礎上發展起來的。CORBA構件模型,是OMG組織制定的1個用于開發和配置散布式利用的服務器端中間件模型規范
CORBA的目標是支持多個層次的可互操作性,CORBA 規范經過量次改進與發展才到達這1目標。CORBA支持在可互操作性主要包括以下幾個層次:
1、不同平臺(如操作系統)與語言之間的可互操作性:這是初期的 CORBA版本強調解決的主要問題,解決方法包括制定IDL標準和IDL到程序設計語言的映照。這使得使用同1供應商的 ORB 產品開發的客戶程序與服務程序之間可以交互, 但使用不同供應商的ORB產品開發的客戶程序與服務程序則未必是可互操作的。
2、不同廠商 ORB 產品之間的可互操作性:CORBA 2.0 版引入了GIOP 和 IIOP,從而實現了不同供應商的 ORB 產品之間的可互操作性,所有供應商的 ORB產品如果與 CORBA 2.0 兼容則彼此之間可互操作。
3、不同體系結構之間的可互操作性:更完善的可互操作性還應包括不同體系結構之間的可互操作, 例如1個CORBA對象可通過協議橋接操作1個DCOM對象,OMG通過引入ESIOP來解決這1問題。 但ESIOP只能解決CORBA與特定體系結構 (如DCOM)之間的互操作,其實不能通過1套 ESIOP解決所有的問題。
關于CORBA的特點是大而全,互操作性和開放性非常好。CORBA的缺點是龐大而復雜,并且技術和標準的更新相對較慢,COBRA規范從1.0升級到2.0所花的時間非常短,而再往上的版本的發布就相對10分緩慢了。在具體的利用中使用不是很多。
為了推動基于Java的服務器端利用開發,Sun因而在1999年底推出了Java2技術及相干的J2EE規范,J2EE的目標是:提供平臺無關的、可移植的、支持并發訪問和安全的,完全基于Java的開發服務器端中間件的標準。
在J2EE中,Sun給出了完全的基于Java語言開發面向企業散布利用規范,其中,在散布式互操作協議上,J2EE同時支持RMI和IIOP,而在服務器端散布式利用的構造情勢,則包括了JavaServlet、JSP(Java Server Page)、EJB等多種情勢,以支持不同的業務需求,而且Java利用程序具有"Writeonce,run anywhere"的特性,使得J2EE技術在發布計算領域得到了快速發展。
J2EE簡化了構件可伸縮的、其于構件服務器端利用的復雜度,雖然微軟的DNA也1樣,但最大的區分是微軟的DNA是1個產品,J2EE不是1系列產品,而是1個規范和標準,不同的廠家可以實現自己的符合J2EE規范的產品,J2EE規范,是眾多廠家參與制定的,它不為Sun所獨有,而且其支持跨平臺的開發,目前許多大的散布計算平臺廠商都公然支持與J2EE兼容技術。
J2EE的優點是,服務器市場的主流還是大型機和UNIX平臺,這意味著以Java開發構件,能夠做到"Writeonce,run anywhere",開發的利用可以配置到包括Windows平臺在內的任何服務器端環境中去。
EJB是Sun推出的基于Java的服務器端構件規范J2EE的1部份,自從J2EE推出以后,得到了廣泛的發展,已成為利用服務器真個標準技術。Sun的EJB技術是在JavaBean本地構件基礎上,發展的面向服務器端散布利用構件技術。EJB技術的推出,使得用Java基于構件方法開發服務器端散布式利用成為可能。
從企業利用多層結構的角度,EJB是業務邏輯層的中間件技術,與JavaBeans不同,它提供了事務處理的能力,自從3層結構提出以后,中間層,也就是業務邏輯層,是處理事務的核心,從數據存儲層分離,取代了存儲層的大部份地位。
從散布式計算的角度,EJB像CORBA1樣,提供了散布式技術的基礎。提供了對象之間的通訊手段。
從Internet技術利用的角度,EJB和Servlet,JSP1起成為新1代利用服務器的技術標準,EJB中的Bean可以分為會話Bean和實體Bean,前者保護會話,后者處理事務,現在Servlet負責與客戶端通訊,訪問EJB,并把結果通過JSP產生頁面傳回客戶端。
MicrosoftDNA 2000(Distributed interNetApplications)是Microsoft在推出Windows2000系列操作系統平臺基礎上,在擴大了散布計算模型,和改造BackOffice系列服務器端散布計算產品后發布的新的散布計算體系結構和規范。
在服務器端,DNA2000提供了ASP、COM、Cluster等的利用支持。目前,DNA2000在技術結構上有著巨大的優越性。1方面,由于Microsoft是操作系統平臺廠商,因此DNA2000技術得到了底層操作系統平臺的強大支持;另外一方面,由于Microsoft的操作系統平臺利用廣泛,支持該系統平臺的利用開發廠商數目眾多,因此在實際利用中,DNA2000得到了眾多利用開發商的采取和支持。
DNA2000融會了現今最早進的散布計算理論和思想,如事務處理、可伸縮性、異步消息隊列、集群等內容。DNA使得開發可以基于Microsoft平臺的服務器構件利用,其中,如數據庫事務服務、異步通訊服務和安全服務等,都由底層的散布對象系統提供。
但是它的不足是依賴于Microsoft的操作系統平臺,因此在其它開發系統平臺(如Unix、Linux)上不能發揮作用。
DNA構件有COM(Component Object Model)/DCOM/COM+構件。
以Microsoft為首的DCOM/COM/COM+陣營,從DDE,OLE到ActiveX等,提供了中間件開發的基礎,如VC,VB,Delphi等都支持DCOM,包括OLEDB在內新的數據庫存取技術,隨著Windows2000的發布,Microsoft的DCOM/COM/COM+技術,在DNA2000散布計算結構基礎上,展現了1個全新的散布構件利用模型。
首先,DCOM/COM/COM+的構件依然采取普通的COM(ComponentObjectModel)模型。COM最初作為Microsoft桌面系統的構件技術,主要為本地的OLE利用服務,但是隨著Microsoft服務器操作系統NT和DCOM的發布,COM通過底層的遠程支持使得構件技術延伸到了散布利用領域。DCOM/COM/COM+更將其擴充為面向服務器端散布利用的業務邏輯中間件。通過COM+的相干服務設施,如負載均衡、內存數據庫、對象池、構件管理與配置等等,DCOM/COM/COM+將COM、DCOM、MTS的功能有機地統1在1起,構成了1個概念、功能強的構件利用體系結構。而且,DNA2000是單1廠家提供的散布對象構件模型,開發者使用的是同1廠家提供的系列開發工具,這比組合多家開發工具更有吸引力。
針對上述的各種散布計算平臺技術,都出現了相似且具有可比性的散布式構件,即CORBACCM(CORBA Component Model)技術、SUN的EJB(Enterprise JavaBean)技術和DNA2000中的COM/DCOM/COM+技術。
我們從集成性、可用性、可擴大性進行比較之前,先了解下這3個特性。
集成性主要反應在基礎平臺對利用程序互操作能力的支持上。它要求散布在不同機器平臺和操作系統上、采取不同的語言或開發工具生成的各類商業利用必須能集成在1起,構成1個統1的企業計算框架。這1集成框架必須建立在網絡的基礎之上,并且具有對遺留利用的集成能力;
可用性要求所采取的軟件構件技術必須是成熟的技術,相應的產品也必須是成熟的產品,在相當重要的企業利用中能夠穩定、安全、可靠地運行。另外,由于數據庫在企業計算中扮演側重要角色,軟件構件技術應能與數據庫技術緊密集成;
可擴大性,集成框架必須是可擴大的,能夠調和不同的設計模式和實現策略,可以根據企業計算的需求進行裁剪,并能迅速反應市場的變化和技術的發展趨勢。通過保證當前利用的可重用性,最大程度地保護企業的投資。
下表從集成性,可用性,可擴大性3個方面,給出了上述3種主流散布計算平臺的比較結果。
表格
|
CORBA(CCM) |
Ejb |
DCOM |
集成性
|
|
|
|
跨語言性能 |
好 |
差(限于java) |
好 |
跨平臺性能 |
好 |
好 |
差(限于windows) |
網絡通訊 |
好 |
好 |
1般 |
公共服務構件 |
好 |
好 |
1般 |
可用性
|
|
|
|
事務處理 |
好 |
1般 |
1般 |
消息服務 |
1般 |
1般 |
1般 |
安全服務 |
好 |
好 |
1般 |
目錄服務 |
好 |
1般 |
1般 |
容錯性 |
1般 |
1般 |
1般 |
軟件開發商支持度 |
1般 |
好 |
好 |
產品成熟性 |
1般 |
1般 |
好 |
可擴大性 |
好 |
好 |
1般 |
雖然這3種平臺由于其構成的歷史背景和商業背景有所不同,各自有自己的側重和特點,其實在它們之間也有很大的相通性和互補性。目前許多平臺都能實現EJB構件和CORBA構件的互操作。同EJB和CORBA之間相互之間方便的互操作性相比,DOCM和CORBA之間的互操作性要相對復雜些,由于商業利益的緣由,在EJB和DCOM之間基本沒有提供互操作方法。
關于中間件的知識這篇文章就介紹到這里,下篇文章我們繼續中間件的知識。