幾種體系架構(gòu)與開發(fā)工具的組成

幾種體系架構(gòu)與開發(fā)工具的組成三層體系架構(gòu)WebServer/AppServer開發(fā)工具核心技術(shù)備注J2EEWebsphere(IBM)Jbuilder9.0WSAD5.0Eclipse(Java)免費(fèi)WebLogic(BEA)Jarguas(SYBASE)PB9.0+PJ非主流技術(shù).NETWindowsServer2003(WebServer+AppServer)Asp.NET北京瑞得公司、杭州創(chuàng)業(yè)公司采用.NETStudioBorlandC++;DelphiCorbaDephi非主流技術(shù)衛(wèi)寧公司采用項(xiàng)目上體系架構(gòu)與開發(fā)工具的選擇序號方案優(yōu)勢缺點(diǎn)備注第一種Websphere(IBM)+Eclipse單CPU價(jià)格：30-50萬(估計(jì))跨平臺技術(shù)，易移植和多平臺產(chǎn)品集成技術(shù)方案比較完整開發(fā)工具免費(fèi)技術(shù)比較復(fù)雜Websphere價(jià)格比較高（如果采用Bea也比較高）如果技術(shù)人員對IBM的技術(shù)比較熟悉可采用此方案，但Websphere的價(jià)格問題需要斟酌與解決第二種.NET(Asp.Net)50用戶價(jià)格：5萬以下（winserver2003版）技術(shù)簡潔，開發(fā)簡單價(jià)格上也有優(yōu)勢（.Net是內(nèi)嵌在Winserver2003中）只能在Windows平臺上使用因?yàn)榭紤]該項(xiàng)目需要集成的項(xiàng)目不多，沒有跨平臺的需要，再加上技術(shù)簡單，容易掌握，如果人員比較熟悉微軟的技術(shù)，建議采用此方案可以參考看如下幾篇文章：J2EE與.NET的比較毫無疑問，程序員，軟件開發(fā)商，企業(yè)IT經(jīng)理一直都在密切的關(guān)注著J2EE和.NET的發(fā)展，但是選擇一個(gè)在性能，價(jià)格，時(shí)間上滿足他們需求的平臺卻并不是一件簡單的事情。本文試圖在技術(shù)上做一個(gè)簡單的比較，希望對于他們做選擇時(shí)有所幫助。一.技術(shù)概觀在表現(xiàn)形式上，J2EE是一組規(guī)范，而.NET更象是一組產(chǎn)品。但它們的目的都是為了企業(yè)應(yīng)用提供分布式的，高可靠性的解決方案.它們在架構(gòu)上有著很多的相似之處，下表是一個(gè)簡單對照:J2EE.NET

通信協(xié)議RemoteMethodInvocationoverInternetInterOrbProtocol(RMI/IIOP)，XML

編程語言JavaC#，VB.NET，COBOL

運(yùn)行時(shí)環(huán)境JavaVirtualMachine(JVM)CommonLanguageRuntime(CLR)

胖客戶端JavaSwingWindowsForms

目錄服務(wù)JavaNamingandDirectoryInterface(JNDI)ActiveDirectoryServicesInterface(ADSI)

數(shù)據(jù)訪問JavaDatabaseConnection(JDBC)，JavaConnectorsADO.NET

異步消息處理JavaMessageService(JMS)MicrosoftMessageQueue

表示層技術(shù)Servlets，JavaServerPage(JSP)ASP.NET

中間層組件模型EJB，JavaBeanCOM+，COM

安全訪問JAASCOM+Security

CallContext

事物處理JavaTransactionServer(JTS)MicrosoftDistributedTransactionCoordinator(MS-DTC)

開發(fā)工具WebGainVisualCafé

BorlandJbuilder

IBMVisualAge等

(第三方提供，規(guī)范本身沒有定義)VisualStudio.NET

J2EE平臺的構(gòu)成EJB-J2EE中間層，完成商業(yè)邏輯；JAAS-J2EE處理認(rèn)證和授權(quán)的API;JavaConnectors-J2EE用于連接異種數(shù)據(jù)源的API，對上層來講是透明的;JSP，JavaServlets-J2EE的表示層技術(shù)，用于生成用戶界面;JavaVirtualMachine-Java語言運(yùn)行環(huán)境；JDBC-J2EE數(shù)據(jù)庫訪問；JMS-J2EE的異步消息隊(duì)列；JNDI-J2EE的名字查找API，獨(dú)立于目錄服務(wù)器；JTS-J2EE用于處理交易的API；RMI/IIOP-J2EE的分布式對象的通訊API，提供了和CORBA交互的能力。.NET平臺構(gòu)成.NETFramework-.NET應(yīng)用運(yùn)行的基礎(chǔ)；IL(IntermediaryLanguage)-所有的.NET語言首先被編譯成該中間語言，然后在CLR中運(yùn)行；SOAP-用于服務(wù)訪問的工業(yè)標(biāo)準(zhǔn)；DCOM-組件間通信協(xié)議；MS-DTC-用來在.NET平臺上使用兩階段提交協(xié)議來處理分布式交易；CLR-.NET應(yīng)用的運(yùn)行時(shí)環(huán)境；COM+-.NET的中間層模型，用于構(gòu)建商務(wù)邏輯；ADO.NET-.NET對數(shù)據(jù)訪問的API。此外.NET平臺還包括其他一些產(chǎn)品象ApplicationCenterServer，BizTalkServer，NLBS(NetworkLoadBalancingService)，CommerceServer，EnterpriseServers，HIS(HostIntegrationServer)，ISAS(InternetSecurityandAccelerationServer)用來提供象防火墻，安全訪問，B2B交易，負(fù)載平衡等服務(wù).J2EE規(guī)范本身沒有定義這些服務(wù)，但可通過選擇第三方產(chǎn)品來滿足類似的要求。二.技術(shù)比較1.一vs多一種語言vs多種語言，一個(gè)平臺vs多個(gè)平臺.這似乎是大家最喜于津津樂道的話題，也似乎是所有問題的焦點(diǎn)。兩種平臺主流的開發(fā)語言Java和C#在架構(gòu)上有著驚人的相似：虛擬機(jī)技術(shù)，基于沙箱的安全模型，分層的命名空間，垃圾回收等。所以從第一眼看上去，C#簡直就是Java的克隆。但微軟并不這樣認(rèn)為，微軟的說明是：“它集成了C++，Java，Modula2，C和Smalltalk等多種語言的精華，對它們共同的核心思想象深度面向?qū)ο?deepobject-orientation)，對象簡化(object-simplification)等都一一做了參考。”一方面，C#的大多數(shù)關(guān)鍵字來源于C++，使它在書寫上有別于Java。但另一方面，C#的嚴(yán)格的類型轉(zhuǎn)換等概念卻明顯來自于Java(當(dāng)然，它的原始類型的定義更嚴(yán)格，并且據(jù)微軟聲稱沒有影響到效率.)，使其在內(nèi)涵上有克隆之嫌.但即是Java，其有些特性也和Smalltalk頗有淵源.所以評價(jià)一種開發(fā)語言的優(yōu)劣不僅是看其外在的表現(xiàn)形式，更重要的是其實(shí)實(shí)在在的功效.作為一種新語言，C#加入了基于XML的標(biāo)記，可以被編譯器用來直接生成文檔，C#的另一個(gè)特點(diǎn):一站式軟件(one-stop-shoppingsoftware)強(qiáng)調(diào)了自解釋(self-describing)的編碼方式，即頭文件，IDL(InterfaceDefinitionLanguage)，GUID和其他復(fù)雜的接口無需再被引用.也即是C#，VB.NET等代碼片斷可以任意的被加入到其他語言中.這無疑在多種語言混合編程的模式中是一次飛躍，但是，其難維護(hù)性也是不言而喻的。微軟的.NET的平臺提供了象C#，VB.NET，COBOL等多種開發(fā)語言，C#是新的，而其他的每一種語言都是在原有的基礎(chǔ)上改造而來.這是微軟煞費(fèi)苦心并且也是不得以的要為習(xí)慣于這些語言的程序員鋪一條便捷之路.但是，這些語言的改造與其說是整容到不如說是一次開膛破肚的大手術(shù).首先是觀念變了，Basic，Cobol等語言先天的缺少面向?qū)ο蟮膬?nèi)涵，現(xiàn)在卻變成了面向?qū)ο蟮恼Z言，這就不是要求其傳統(tǒng)的程序員僅僅熟悉一些額外的關(guān)鍵字那么簡單的問題了.基于面向?qū)ο蟮能浖治鲈O(shè)計(jì)開發(fā)測試是完全不同于基于傳統(tǒng)過程性語言的質(zhì)變，所以這一過程的轉(zhuǎn)變對傳統(tǒng)程序員來講也是一個(gè)痛苦和漫長的過程.在傳統(tǒng)程序員面前，微軟看似提供了豐富多采的解決方法，但對于實(shí)際問題而言，卻怕是有些力不從心.所以一個(gè)簡單的辦法是:直接使用C#.對于獨(dú)立軟件開發(fā)商來講，其轉(zhuǎn)換成本不容忽視.其次，在一個(gè)軟件項(xiàng)目中使用多種語言，開發(fā)商必須同時(shí)擁有多種語言專家和多個(gè)獨(dú)立的難以互相支援的開發(fā)小組，無疑的，這也使其軟件的維護(hù)的成本已非線性的曲線增長.多樣性是雙韌劍，實(shí)施時(shí)需仔細(xì)斟酌.跨平臺是J2EE的最大賣點(diǎn)，也是至今為止還絆住微軟的柵欄.當(dāng)開發(fā)商完成了符合J2EE規(guī)范的軟件時(shí)，其客戶可以依據(jù)其喜好和實(shí)力來選擇不同應(yīng)用服務(wù)器.從基于opensource的免費(fèi)軟件到高端滿足B2B需求的商業(yè)套件來搭建自己的平臺.但是由于J2EE的規(guī)范還不完善，各個(gè)J2EE服務(wù)器的提供商為了使其提供其各自理解的完整的功能，不得不添加一些額外的特性.這就使得使用了這些特別功能的應(yīng)用軟件，綁定到了特定的應(yīng)用服務(wù)器上.隨著J2EE規(guī)范的發(fā)展，這種差別會逐漸減小.微軟的跨平臺解決方案是Webservices，它解決的是異種平臺上不同應(yīng)用之間的連通性問題.從技術(shù)角度講，它除了以XML為介質(zhì)之外沒有什么新意.但它的重要意義在于:它是微軟這樣一個(gè)重量級選手所推出的，前景不容小視.構(gòu)造和使用Webservices的過程較為簡單:服務(wù)提供者用他所選擇的語言構(gòu)造服務(wù);服務(wù)提供者用WSDL(theWebServicesDescriptionLanguage)來定義該服務(wù);服務(wù)提供者在UDDI(UniversalDescription，Discovery，andIntegration)中注冊該服務(wù);使用者的應(yīng)用程序從UDDI中查找已注冊服務(wù);使用者的應(yīng)用程序通過SOAP(theSimpleObjectAccessProtocol)來調(diào)用服務(wù).(SOAP使用HTTP來傳遞基于XML為表現(xiàn)形式的參數(shù))正如我們所討論的:Webservices解決的是異構(gòu)平臺上服務(wù)連通性的問題，但在現(xiàn)實(shí)中所更迫切需要的是如何在異構(gòu)的平臺上構(gòu)造具有可擴(kuò)展性，高可靠性，高可用性，故障冗余，錯誤恢復(fù)能力的企業(yè)應(yīng)用.缺少這一點(diǎn)，從結(jié)構(gòu)上講，.NET平臺還遠(yuǎn)未完善.2.中間層基于組件的軟件開發(fā)技術(shù)可以在較高的級別上實(shí)現(xiàn)軟件復(fù)用，加快企業(yè)軟件開發(fā)的進(jìn)程.在J2EE構(gòu)架中，JavaBean和EJB(EnterpriseJavaBeans)被用來完成事物邏輯.其中EJB和JavaBean有著類似的模型，但它被用來創(chuàng)建分布式的企業(yè)應(yīng)用.它定義服務(wù)器端組件的模型，具有以下一些特性:生存期模型；訪問模型；安全模型；事物處理模型；會話處理模型；數(shù)據(jù)封裝模型；部署模型根據(jù)這些模型，簡單的編碼就可完成復(fù)雜的功能。在微軟的.NET平臺中，舊的COM和COM+的組件模型被新的組件模型所代替。增加了象基于沙箱的安全模型和垃圾回收等功能.并且實(shí)現(xiàn)了多重接口繼承，擴(kuò)展的元數(shù)據(jù)和新的代理模型等.舊有的COM和COM+組件也可被映射到新的運(yùn)行環(huán)境中。綜上所述，兩眾架構(gòu)在基于組件的中間層的設(shè)計(jì)上各有千秋，對于創(chuàng)建分布式的，復(fù)雜的，高效的，高可靠性的的應(yīng)用程序都有著足夠的能力。3.表示層兩種架構(gòu)都同時(shí)支持胖客戶端和瘦客戶端.即C/S模式和B/S模式.對于C/S模式，J2EE提供了替代JavaAWT的JavaSwing，同時(shí)作為可視化組件的JavaBean也可用來構(gòu)造系統(tǒng)。對于B/S結(jié)構(gòu)的表示層，J2EE使用servlet，JSP(JavaServerPage)，HMTL，WML，XML等工具來實(shí)現(xiàn)。微軟的胖客戶端技術(shù)則由WindowsForms代替了MFC.它們起的作用相同，在結(jié)構(gòu)上WindowsForms被插入到.NET的運(yùn)行時(shí)框架(runtimeframework)和組件模型(componentmodel)中.在瘦客戶模型中，ASP.NET代替了舊有的ASP和HMTL，WML，XML作為表示層。在ASP.NET中，C#，VB.NET等語言的代碼片斷可被自由引用.ASP.NET頁面被首先轉(zhuǎn)換成中介語言(IntermediaryLanguage)，然后再被中介語言及時(shí)編譯器(just-in-timeILcompiler)編譯，最后運(yùn)行于公共語言運(yùn)行環(huán)境中，并且ASP.NET提供了頁面的緩沖，所以，其運(yùn)行速度要遠(yuǎn)遠(yuǎn)快于ASP。大體上，兩種架構(gòu)所使用的表示層的技術(shù)非常類似，雖在細(xì)節(jié)上各有所長，但總體功能當(dāng)在伯仲之間。4.數(shù)據(jù)訪問J2EE和.Net已不同的形式支持?jǐn)?shù)據(jù)的訪問。JDBC和ADO一樣和所連接的數(shù)據(jù)庫無關(guān)，并且通過連接，命令語句和結(jié)果集來對數(shù)據(jù)進(jìn)行操作.所以屬于中間層次的API.更高一級的數(shù)據(jù)封裝和數(shù)據(jù)管理是通過實(shí)體EJB(entityEJB)來完成的.基于容器管理的實(shí)體EJB使開發(fā)更快捷，管理更方便.事實(shí)上，由于實(shí)體EJB的load()和store()方法的同步機(jī)制，將大大緩解因并發(fā)而使數(shù)據(jù)庫產(chǎn)生的瓶頸.也可以采用不屬于J2EE規(guī)范的第三方數(shù)據(jù)訪問工具，象WebGain的TopLink。而微軟的.NET的數(shù)據(jù)訪問工具則由基于XML的ADO.NET代替了基于COM組件的ADO.任何以XML為輸出的數(shù)據(jù)源都可以作為ADO.NET的數(shù)據(jù)源.相應(yīng)的結(jié)果集升級為數(shù)據(jù)集(DataSets)，命令語句則升級為數(shù)據(jù)集命令(DataSetCommands).從形式來看，微軟的ADO.NET更新潮和時(shí)髦一些，基于XML的特性使其可以處理極其豐富的數(shù)據(jù)源，并且，因其構(gòu)架在HTTP協(xié)議之上，易于穿透防火墻，使溝通更為便利.但由于XML本身的基于標(biāo)記的特性，很明顯限制了在有超大數(shù)據(jù)量和有網(wǎng)絡(luò)瓶頸的應(yīng)用中的使用.而J2EE的數(shù)據(jù)訪問規(guī)則則顯得略有單薄，但同時(shí)卻更簡單，更有效.并且通過對應(yīng)用程序有效的層次的設(shè)計(jì)，對于數(shù)據(jù)庫和基于XML的數(shù)據(jù)源的訪問，也是可以無縫的整合的。三.整體評價(jià)在微軟還沒有足以和Java平臺相對抗的產(chǎn)品的時(shí)候，微軟所樂于做是大聲的宣傳:"w