計(jì)算機(jī)外文翻譯-文獻(xiàn)綜述(J2EE)

計(jì)算機(jī)外文翻譯-文獻(xiàn)綜述(J2EE)黃河科技學(xué)院畢業(yè)設(shè)計(jì)(文獻(xiàn)翻譯)外文翻譯，網(wǎng)上搜索所得基于J2EE在分布式環(huán)境下的底層結(jié)構(gòu)的自動(dòng)動(dòng)態(tài)配置的應(yīng)用AnatolyAkkerman,AlexanderTotok,andVijayKaramcheti摘要：為了實(shí)現(xiàn)廣域網(wǎng)中符合工業(yè)標(biāo)準(zhǔn)基于組件的應(yīng)用程序中動(dòng)態(tài)的可適應(yīng)性，我們需要一種框架來(lái)在這樣的環(huán)境里自動(dòng)化地配置J2EE應(yīng)用程序。這種需要對(duì)于哪怕在單一的應(yīng)用程序服務(wù)器上嘗試部署J2EE應(yīng)用的人來(lái)說(shuō)也顯而易見(jiàn)，這種任務(wù)設(shè)計(jì)到大量的系統(tǒng)服務(wù)和應(yīng)用組件的配置。關(guān)鍵詞：j2ee；動(dòng)態(tài)配置；分布式；組件；1前言近幾年，我們已經(jīng)看到基于組件的企業(yè)應(yīng)用開(kāi)發(fā)的顯著增加。這種應(yīng)用程序通常被部署在公司的內(nèi)部網(wǎng)或者是因特網(wǎng)上，以高事務(wù)容量，大量的用戶和覆蓋范圍廣的訪問(wèn)為特征，它通常會(huì)被部署在中央?yún)^(qū)域，采用服務(wù)器集群來(lái)均衡負(fù)載從而支持用戶下載。但是這種平均負(fù)荷的方法被證明只對(duì)減少應(yīng)用轉(zhuǎn)發(fā)的用戶可以察覺(jué)的反應(yīng)時(shí)間有效，而對(duì)于減少網(wǎng)絡(luò)方面的延遲作用不大，垂直分割（例如…運(yùn)行網(wǎng)絡(luò)層和事務(wù)層在不同的虛擬機(jī)）被用于錯(cuò)誤分離和均衡負(fù)荷，但是它是不符合實(shí)際的由于遠(yuǎn)程調(diào)運(yùn)的大量使用顯著地增加了運(yùn)行時(shí)時(shí)間。最近的著作已經(jīng)表明在廣域網(wǎng)中利用垂直負(fù)荷而不引起前面所述的超時(shí)問(wèn)題的可行性。那非研究的主要結(jié)論可以概括如下：(1)應(yīng)用合適的應(yīng)用程序，在廣域網(wǎng)中的垂直負(fù)荷可以察覺(jué)的延遲。(2)廣域垂直層需要復(fù)制應(yīng)用層組件而且需要維持和原組件間的一致性。(3)新加的復(fù)制組件可以被動(dòng)態(tài)配置以滿足新的需要。(4)事實(shí)上，不同的復(fù)制組件可能會(huì)根據(jù)應(yīng)用不同的方式實(shí)現(xiàn)相組件。(5)新的請(qǐng)求路徑可以復(fù)用先前的組件配置路徑。目的地，像對(duì)話和隊(duì)列，是由消息服務(wù)執(zhí)行所提供的資源。數(shù)據(jù)源是提供給應(yīng)用服務(wù)器的為事務(wù)組件進(jìn)入到企業(yè)信息服務(wù)層提供數(shù)據(jù)接口，通常由被應(yīng)用服務(wù)器管理的JDBC連接池實(shí)例化。一個(gè)J2EE編程者明確編寫的項(xiàng)目只有EJB和Web組件。這些用戶編寫的組件彼此交互而且系統(tǒng)服務(wù)可以是明顯的也可以是隱含的。例如，EJB開(kāi)發(fā)者可以選擇明確的事務(wù)區(qū)分方式，這種方式意味著開(kāi)發(fā)者假設(shè)通過(guò)定義良好接口的事務(wù)經(jīng)理服務(wù)平臺(tái)來(lái)書(shū)寫明確的程序交互?；蛘?，開(kāi)發(fā)者也可選擇容器管理事務(wù)區(qū)分的方式。這樣由于組件的事務(wù)行為通過(guò)他的描述者來(lái)定義而且全部用EJB容器來(lái)處理，因此作為一個(gè)隱式獨(dú)立的EJB提供潛在的事務(wù)管理服務(wù)。2.3組件間的鏈接2.3.1遠(yuǎn)程交互J2EE僅定義了三種可以在不同應(yīng)用服務(wù)器間傳遞的基本組件間連接類型。在這三種情況下，通信通過(guò)特定的Java對(duì)象來(lái)完成。(1)遠(yuǎn)程EJB調(diào)用：同步的EJB調(diào)用通過(guò)主EJB對(duì)象和EJB對(duì)象接口來(lái)實(shí)現(xiàn)。(2)Java連結(jié)器的外部連接：同步消息接收，同步和異步消息發(fā)送，用連接工廠和連接接口進(jìn)行數(shù)據(jù)庫(kù)查詢。(3)Java連接器的內(nèi)部連接：異步消息傳遞進(jìn)入消息驅(qū)動(dòng)Bean只能使用ActivationSpec對(duì)象。在前兩個(gè)實(shí)例中，應(yīng)用組件的開(kāi)發(fā)者不僅書(shū)寫執(zhí)行在組件的運(yùn)行時(shí)JNDI環(huán)境中的對(duì)象目錄代碼，而且書(shū)寫發(fā)布方法調(diào)用，與遠(yuǎn)程的組件相互發(fā)送和接受消息。組件的運(yùn)行時(shí)JNDI環(huán)境為每一個(gè)組件部署所創(chuàng)建。環(huán)境中的綁定在組件部署時(shí)由部署者進(jìn)行初始化。這些綁定被假設(shè)為是靜態(tài)的，因?yàn)橐?guī)格中沒(méi)有提供任何的容器和組件間協(xié)議去提示綁定發(fā)生了變化。在Java連接器的內(nèi)部通信情景下，ActivationSpec對(duì)象查詢以及所有的相應(yīng)的M容器隱式的完成。雖然查詢的協(xié)議還沒(méi)有被標(biāo)準(zhǔn)化，但是假設(shè)一個(gè)基于JMX或者JNDI的查詢是合理的。假設(shè)潛在的應(yīng)用服務(wù)器提供了所有的設(shè)備去控制部署過(guò)程的每一步，那么在兩個(gè)J2EE組件間確立一個(gè)連接需要涉及：(1)部署目標(biāo)組件類。(2)創(chuàng)建一個(gè)特定的Java對(duì)象用作目標(biāo)組件代理。(3)用組件的命名服務(wù)去綁定目標(biāo)。(4)啟動(dòng)目標(biāo)組件。(5)部署指定的組件類。(6)在主機(jī)的命名服務(wù)中，創(chuàng)建和進(jìn)行指定組件的運(yùn)行環(huán)境。(7)啟動(dòng)指定的組件。然而，沒(méi)有一個(gè)現(xiàn)代的應(yīng)用服務(wù)器允許詳細(xì)的控制所有組件類型的部署過(guò)程除了在它們的部署解釋器中的有限的選擇。因此我們的架構(gòu)將使用簡(jiǎn)化的途徑，它所依賴的特征在現(xiàn)在的大多數(shù)的應(yīng)用服務(wù)器上都可以得到。(1)動(dòng)態(tài)部署消息目的和數(shù)據(jù)源的能力。(2)創(chuàng)建和綁定特定的JNDI目標(biāo)去訪問(wèn)消息目的和數(shù)據(jù)源的能力。(3)把初始綁定的EJB對(duì)象到EJB部署組件的能力。(4)用在參考組件運(yùn)行環(huán)境中的JNDI指引去指出綁定的參考EJB的能力。在只有相同的應(yīng)用服務(wù)器的架構(gòu)中，上面的功能對(duì)通過(guò)簡(jiǎn)單的部署控制解釋器方式來(lái)控件間的連接已經(jīng)足夠了。然而，在不同應(yīng)用服務(wù)器的環(huán)境下，由于跨服務(wù)器的類下載問(wèn)題，這種簡(jiǎn)單的控制解釋器的方式是不夠的。2.3.2本地交互一些組件間的交互可以發(fā)生在同一地點(diǎn)的相同應(yīng)用服務(wù)器虛擬機(jī)的組件間，有時(shí)候甚至可以發(fā)生在只有相同容器的組件間。在Web層，這種交互的例子是servlet到servlet的請(qǐng)求轉(zhuǎn)發(fā)。在EJB層，這種交互的例子是CMP實(shí)體關(guān)系和通過(guò)EJB本地接口的調(diào)用。這種本地部署所關(guān)心的不是在分布式架構(gòu)中去表現(xiàn)而是去增強(qiáng)一致性。因此，這種架構(gòu)把所有的本地的組件請(qǐng)求當(dāng)作一個(gè)單一的組件加以對(duì)待。2.4部署J2EE應(yīng)用程序和系統(tǒng)服務(wù)2.4.1部署應(yīng)用程序組件部署和拆卸標(biāo)準(zhǔn)的J2EE組件還沒(méi)有統(tǒng)一的標(biāo)準(zhǔn)，因此每個(gè)應(yīng)用服務(wù)的提供商對(duì)組件的部署和拆卸提供了單獨(dú)的功能于J2EE規(guī)范中沒(méi)有定義標(biāo)準(zhǔn)組件的包，包的格式和包內(nèi)的基于xml部署解釋器的位置，因此這種包對(duì)于沒(méi)有所屬權(quán)變化的應(yīng)用服務(wù)器不需要部署。具體變化的例子有：(1)支持或者取代標(biāo)準(zhǔn)所有者解釋器的新的所有者解釋器的產(chǎn)生。(2)具體服務(wù)應(yīng)用程序類的代碼的更替。為了著手構(gòu)建一個(gè)能夠部署不可網(wǎng)絡(luò)的動(dòng)態(tài)的分布式的架構(gòu)，我們提出了一種普遍的部署單元即一個(gè)簡(jiǎn)單的基于xml部署的解釋器或者是一組類似的綁定到文檔中的解釋器。文檔可能包含用于執(zhí)行組件的Java類或者任何其它的所需組件。相應(yīng)地，部署解釋器也可以簡(jiǎn)單地用URL來(lái)索引代碼。我們假設(shè)這種動(dòng)態(tài)的部署和拆卸服務(wù)存在于所有的兼容的J2EE服務(wù)器上而且在不理解類重載相關(guān)問(wèn)題時(shí)一個(gè)健壯的類重載結(jié)結(jié)構(gòu)的應(yīng)用服務(wù)器就能夠重復(fù)的部署生命周期。大多數(shù)現(xiàn)代的應(yīng)用服務(wù)器都提供這樣的功能。2.4.2部署系統(tǒng)組件對(duì)應(yīng)用組件來(lái)說(shuō)，J2EE規(guī)范只是少了在部署和拆卸時(shí)的明確定義，而對(duì)系統(tǒng)服務(wù)來(lái)說(shuō)，在這方面做的更糟。對(duì)系統(tǒng)服務(wù)來(lái)說(shuō)不僅沒(méi)有具體的定義一個(gè)標(biāo)準(zhǔn)化的部署，實(shí)際上，這個(gè)規(guī)格甚至連沒(méi)有強(qiáng)調(diào)在生命周期屬性方面的要求，更不用手強(qiáng)調(diào)依賴也潛在的系統(tǒng)服務(wù)的應(yīng)用組件的明確規(guī)范了取而代之的是它定義了部署者的角色，這個(gè)角色負(fù)責(zé)確保像組件的本性和系統(tǒng)的解釋器所暗示的那樣，所需的服務(wù)是基于應(yīng)用組件對(duì)系統(tǒng)服務(wù)依賴性的基礎(chǔ)之上。例如，假如有一個(gè)事務(wù)容器要至少用一種方法去開(kāi)始一個(gè)新的事務(wù)，那么一個(gè)帶有這樣的事務(wù)容器的EJB就需要在應(yīng)用層表示事務(wù)管理服務(wù)。與之相似的是，一個(gè)消息驅(qū)動(dòng)的bean，也隱式需要一種運(yùn)行在網(wǎng)絡(luò)上消息服務(wù)實(shí)例。它為MDB管理消息目的以及基于查詢的Java連接器通過(guò)它的管理服務(wù)層去提供這種消息服務(wù)?？紤]到應(yīng)用層可能通常只用到了應(yīng)用服務(wù)器所提供的服務(wù)的一個(gè)子集，根據(jù)應(yīng)用層的需要允許遞增的配置服務(wù)的組件應(yīng)用服務(wù)器允許更高效的利用多種資源。包括，開(kāi)源的應(yīng)用服務(wù)器，JBoss和OnAS在內(nèi)，已經(jīng)有多種J2EE應(yīng)用服務(wù)器已經(jīng)全部或者部分的實(shí)現(xiàn)了組件化。我們感覺(jué)到通過(guò)動(dòng)態(tài)的部署和拆卸系統(tǒng)服務(wù)，動(dòng)態(tài)的配置應(yīng)用服務(wù)器對(duì)動(dòng)態(tài)分布的部署J2EE應(yīng)用程序是一種十分重要的構(gòu)建資源有效型框架的方法。因此我們提倡并將把用JBoss應(yīng)用服務(wù)器設(shè)計(jì)的微內(nèi)核的應(yīng)用服務(wù)器用作一個(gè)模型。在該模型中，一個(gè)微型的服務(wù)包括了系統(tǒng)調(diào)用總線，一個(gè)穩(wěn)健的類下載子系統(tǒng)，一些命名子系統(tǒng)和一個(gè)動(dòng)態(tài)配置子系統(tǒng)。所有其它的服務(wù)是熱部署并且通過(guò)一個(gè)普通的調(diào)用總線來(lái)進(jìn)行通信。例如，JBoss利用Java管理擴(kuò)展服務(wù)器來(lái)實(shí)現(xiàn)基本的命名和調(diào)用功能。除此之外，JBoss實(shí)現(xiàn)了一個(gè)先進(jìn)的類下載子系統(tǒng)和部署服務(wù)。所有其它的JBoss是動(dòng)態(tài)配置的，并外在的表現(xiàn)為具有良好機(jī)制和生命周期的JMXMBeans.這樣的一種應(yīng)用服務(wù)器根據(jù)系統(tǒng)服務(wù)外在利用應(yīng)用組件去設(shè)計(jì)相關(guān)功能，并且只有需要的系統(tǒng)服務(wù)才會(huì)得到合理配置和部署！參考文獻(xiàn)[1]MattBishop.ComputerSecurity:ArtandScience.NewYork,2002[2]MattBishop.VulnerabilitiesAnalysis.ProceedingsoftheSecondInternationalSymposiumonRecentAdvancesinIntrusionDetection.LosAngeles2006[3]Balasubramaniyan.ArchitectureforIntrusionDetectionusingAutonomousAgents[M].DepartmentofComputerSciences,PurdueUniversity,1998.

InfrastructureforAutomaticDynamicDeploymentOfJ2EEApplicationinDistributedEnvironmentsAnatolyAkkerman,AlexanderTotok,andVijayKaramchetiAbstract:inordertoachievesuchdynamicadaptation,weneedaninfrastructureforautomatingJ2EEapplicationdeploymentinsuchanenvironment.ThisneedisquiteevidenttoanyonewhohasevertrieddeployingaJ2EEapplicationevenonasingleapplicationserver,whichisataskthatinvolvesagreatdealofconfigurationofboththesystemservicesandapplicationcomponents.Keywords:j2ee;component;Distributed;DynamicDeployment;1IntroductionInrecentyears,wehaveseenasignificantgrowthincomponent-basedenterpriseapplicationdevelopment.TheseapplicationsaretypicallydeployedoncompanyIntranetsorontheInternetandarecharacterizedbyhightransactionvolume,largenumbersofusersandwideareaaccess.Traditionallytheyaredeployedinacentrallocation,usingserverclusteringwithloadbalancing(horizontalpartitioning)tosustainuserload.However,horizontalpartitioninghasbeenshownveryefficientonlyinreducingapplication-relatedoverheadsofuser-perceivedresponsetimes,withouthavingmucheffectonnetwork-inducedlatencies.Verticalpartitioning(e.g.,runningwebtierandbusinesstierinseparateVMs)hasbeenusedforfaultisolationandloadbalancingbutitissometimesimpracticalduetosignificantrun-timeoverheads(evenifonewouldkeepthetiersonafastlocal-areanetwork)relatedtoheavyuseofremoteinvocations.Recentwork[14]inthecontextofJ2EEcomponentbasedapplicationshasshownviabilityofverticalpartitioninginwide-areanetworkswithoutincurringtheaforementionedoverheads.Thekeyconclusionsfromthatstudycanbesummarizedasfollows:?Usingproperlydesignedapplications,verticaldistributionacrosswide-areanetworksimprovesuser-perceivedlatencies.?Wide-areaverticallayeringrequiresreplicationofapplicationcomponentsandmaintainingconsistencybetweenreplicas.?Additionalreplicasmaybedeployeddynamicallytohandlenewrequests.?Differentreplicasmay,infact,bedifferentimplementationsofthesamecomponentbasedonusage(read-only,read-write).?Newrequestpathsmayreusecomponentsfrompreviouslydeployedpaths.Applyingintelligentmonitoring[6]andAIplanning[2,12]techniquesinconjunctionwiththeconclusionsofthatstudy,weseeapotentialfordynamicadaptationinindustry-standardJ2EEcomponent-basedapplicationsinwideareanetworksThroughdeploymentofadditionalapplicationcomponentsdynamicallybasedonactivemonitoring.However,inordertoachievesuchdynamicadaptation,weneedaninfrastructureforautomatingJ2EEapplicationdeploymentinsuchanenvironment.ThisneedisquiteevidenttoanyonewhohasevertrieddeployingaJ2EEapplicationevenonasingleapplicationserver,whichisataskthatinvolvesagreatdealofconfigurationofboththesystemservicesandapplicationcomponents.ForexampleonehastosetupJDBCdatasources,messagingdestinationsandotherresourceadaptersbeforeapplicationcomponentscanbeconfiguredanddeployed.Inawideareadeploymentthatspansmultipleservernodes,thisprovesevenmorecomplex,sincemoresystemservicesthatfacilitateinter-nodecommunicationsneedtobeconfiguredandstartedandavarietyofconfigurationdata,likeIPaddresses,portnumbers,JNDInamesandothershavetobeconsistentlymaintainedinvariousconfigurationfilesonmultiplenodes.Thisdistributeddeploymentinfrastructuremustbeableto:?addressinter-componentconnectivityspecificationanddefineitseffectsoncomponentconfigurationanddeployment,?addressapplicationcomponentdependenciesonapplicationserverservices,theirconfigurationanddeployment,?providesimplebutexpressiveabstractionstocontroladaptationthroughdynamicdeploymentandundeploymentofcomponents,?enablereuseofservicesandcomponentstomaintainefficientuseofnetworknodes’resources,?providethesefacilitieswithoutincurringsignificantadditionaldesigneffortonbehalfofapplicationprogrammers.InthispaperweproposetheinfrastructureforautomaticdynamicdeploymentofJ2EEapplications,whichaddressesalloftheaforementionedissues.Theinfrastructuredefinesarchitecturedescriptionlanguages(ADL)forcomponentandlinkdescriptionandassembly.TheComponentDescriptionLanguageisusedtodescribeapplicationcomponentsandlinks.Itprovidesclearseparationofapplicationcomponentsfromsystemcomponents.Aflexibletypesystemisusedtodefinecompatibilityofcomponentportsandlinks.Adeclarationandexpressionlanguageforconfigurablecomponentpropertiesallowsforspecificationofinter-componentdependenciesandpropagationofpropertiesbetweencomponents.TheComponent(Replica)AssemblyLanguageallowsforassemblyofreplicasofpreviouslydefinedcomponentsintoapplicationpathsbyConnectingappropriateportsvialinkreplicasandspecifyingthemappingofthesecomponentreplicasontotargetapplicationservernodes.TheComponentConfigurationProcessevaluatesanapplicationpath’scorrectness,identifiesthedependenciesofapplicationcomponentsonsystemcomponents,andconfigurescomponentreplicasfordeployment.Anattemptismadetomatchandreuseanypreviouslydeployedreplicasinthenewpathbasedontheirconfigurations.WeimplementtheinfrastructureasapartoftheJBossopensourceJavaapplicationserver[11]andtestitonseveralSampleJ2EEapplications–JavaPetstore[23],Rubies[20]andTPC-W-NYU[32].TheinfrastructureimplementationutilizestheJBoss’sextendablemicro-kernelarchitecture,basedontheJMX[27]specification.ComponentizedarchitectureofJBossallowsincrementalservicedeploymentsdependingontheneedsofdeployedapplications.Webelievethatdynamicreconfigurationofapplicationserversthroughdynamicdeploymentandundeploymentofsystemservicesisessentialtobuildingaresource-efficientframeworkfordynamicdistributeddeploymentofJ2EEapplications.Therestofthepaperisorganizedasfollows.Section2providesnecessarybackgroundforunderstandingthespecificsoftheJ2EEcomponenttechnologywhicharerelevanttothisstudy.Section3givesageneraldescriptionoftheinfrastructurearchitecture,whilesection4goesdeeperindescribingparticularlyimportantandinterestinginternalmechanismsoftheinfrastructure.Section5describestheimplementationoftheframework,andrelatedworkisdiscussedinsection6.2J2EEBackground2.1IntroductionComponentframeworks.Acomponentframeworkisamiddlewaresystemthatsupportsapplicationsconsistingofcomponentsconformingtocertainstandards.Applicationcomponentsare“plugged”intothecomponentframework,whichestablishestheirenvironmentalconditionsandregulatestheinteractionsbetweenthem.Thisisusuallydonethroughcontainers,componentholders,whichalsoprovidecommonlyrequiredsupportfornaming,security,transactions,andpersistence.Componentframeworksprovideanintegratedenvironmentforcomponentexecution,asaresultsignificantlyreducetheeffort.ittakestodesign,implement,deploy,andmaintainapplications.CurrentdayindustrycomponentframeworkstandardsarerepresentedbyObjectManagementGroup’sCORBAComponentModel[18],SunMicrosystems’Java2PlatformEnterpriseEdition(J2EE)[25]andMicrosoft’s.NET[17],withJ2EEbeingcurrentlythemostpopularandwidelyusedcomponentframeworkintheenterprisearena.J2EE.Java2PlatformEnterpriseEdition(J2EE)[25]isacomprehensivestandardfordevelopingmulti-tierenterpriseJavaapplications.TheJ2EEspecificationamongotherthingsdefinesthefollowing:?Componentprogrammingmodel,?Componentcontractswiththehostingserver,?Servicesthattheplatformprovidestothesecomponents,?Varioushumanroles,?Compatibilitytestsuitesandcompliancetestingprocedures.Amongthelistofservicesthatacompliantapplicationservermustprovidearemessaging,transactions,namingandothersthatcanbeusedbytheapplicationcomponents.ApplicationdevelopedusingJ2EEadheretotheclassical3-Tierarchitectures–PresentationTier,BusinessTier,andEnterpriseInformationSystem(EIS)Tier(seeFig.1).J2EEcomponentsbelongingtoeachtieraredevelopedadheringtotheSpecificJ2EEstandards.1.PresentationorWebtier.Thistierisactuallysubdividedintoclientandserversides.Theclientsidehostsawebbrowser,appletsandJavaapplicationsthatcommunicatewiththeserversideofpresentationtierorthebusinesstier.TheserversidehostsJavaServletcomponents[30],JavaServerPages(JSPs)[29]andstaticwebcontent.Thesecomponentsareresponsibleforpresentingbusinessdatatotheendusers.ThedataitselfistypicallyacquiredfromthebusinesstierandsometimesdirectlyfromtheEnterpriseInformationSystemtier.TheserversideofthepresentationtieristypicallyaccessedthroughHTTP(S)protocol.2.BusinessorEJBtier.ThistierconsistsofEnterpriseJavaBeans(EJBs)[24]thatmodelthebusinesslogicoftheenterpriseapplication.Thesecomponentsprovidepersistencemechanismsandtransactionalsupport.ThecomponentsintheEJBtierareinvokedthroughremoteinvocations(RMI),in-JVMinvocationsorasynchronousmessagedelivery,dependingonthetypeofEJBcomponent.TheEJBspecificationdefinesseveraltypesofcomponents.Theydifferininvocationstyle(synchronousvs.asynchronous,localvs.remote)andstatefulness:completelystateless(e.g.,Message-DrivenBean),statefulnon-persistent(e.g.,StatefulSessionBean),statefulpersistent(e.g.,EntityBean).SynchronouslyinvocableEJBcomponentsexposethemselvesthroughaspecialfactoryproxyobject(anEJBHomeobject,whichisspecifictoagivenEJB),whichistypicallyboundinJNDIbythedeployeroftheEJB.TheEJBHomeobjectallowscreationorlocationofanEJBObject,whichisaproxytoaparticularinstanceofanEJB1.3.EnterpriseInformationSystem(EIS)orDatatier.Thistierreferstotheenterpriseinformationsystems,likerelationaldatabases,ERPsystems,messagingsystemsandthelike.BusinessandpresentationtiercomponentcommunicatewiththistierwiththehelpofresourceadaptersasdefinedbytheJavaConnectorArchitecture[26].TheJ2EEprogrammingmodelhasbeenconceivedasadistributedprogrammingmodelwhereapplicationcomponentswouldruninJ2EEserversandcommunicatewitheachother.Aftertheinitialintroductionandfirstserverimplementations,thetechnology,mostnotably,theEJBtechnologyhasseensomeasignificantshiftawayfrompurelydistributedcomputingmodeltowardslocalinteractions2.Therewereverylegitimateperformance-relatedreasonsbehindthisshift,howevertheDistributedfeaturesarestillavailable.TheJ2EEspecificationhasseenseveralrevisions,thelateststablebeingversion1.3,whileversion1.4isgoingthroughlastreviewphases3.Weshallfocusourattentionontheformer,whileactuallylearningfromthelatter.CompliantcommercialJ2EEimplementationsarewidelyavailablefromBEASystems[4],IBM[9],Oracle[21]andothervendors.Severalopensourceimplementations,includingJBoss[11]andJOnAS[19]claimcompatibilityaswell.ARecentadditiontothelistisanewApacheprojectGeronimo[1].2.2J2EEComponentProgrammingModelBeforewedescribebasicJ2EEcomponents,let’sfirstaddresstheissueofdefiningwhatacomponentisasoftwarecomponentisaunitofcompositionwithcontractuallyspecifiedinterfacesandexplicitcontextdependenciesonly.Asoftwarecomponentcanbedeployedindependentlyandissubjecttocompositionbythirdparties[31].AccordingtothisdefinitionthefollowingentitieswhichmakeupatypicalJ2EEapplicationwouldbeconsideredapplicationcomponents(someexceptionsgivenbelow):?EJBs(session,entity,message-driven),?Webcomponents(servlets,JSPs),?messagingdestinations,?Datasources,EJBandWebcomponentsaredeployedintotheircorrespondingcontainersprovidedbytheapplicationservervendor.Theyhavewell-definedcontractswiththeircontainersthatgovernlifecycle,threading,persistenceandotherconcerns.BothWebandEJBcomponentsuseJNDIlookupstolocateresourcesorotherEJBcomponentstheywanttocommunicatewith.TheJNDIcontextinwhichtheselookupsareperformedismaintainedseparatelyforeachcomponentbyitscontainer.Bindingsmessagingdestinations,suchastopicsandqueues,areresourcesprovidedbyamessagingserviceimplementation.Datasourcesareresourcesprovidedbytheapplicationserverfordataaccessbybusinesscomponentsintotheenterpriseinformationservices(data)tier,andmostcommonlyareexemplifiedbyJDBCconnectionpoolsmanagedbytheapplicationServer.AJ2EEprogrammerexplicitlyprogramsonlyEJBsandWebcomponents.Thesecustom-writtencomponentsinteractwitheachotherandsystemservicesbothimplicitlyandexplicitly.Forexample,anEJBdevelopermaychooseexplicittransactiondemarcation(i.e.,Bean-ManagedTransactions)whichmeansthatthedeveloperassumestheburdenofwritingexplicitprogrammaticinteractionwiththeplatform’sTransactionManagerServicethroughwell-definedinterfaces.Alternatively,thedevelopermaychooseContainer-Managedtransactiondemarcation,wheretransactionalbehaviorofacomponentisdefinedthroughitsdescriptorsandhandledcompletelybytheEJBcontainer,thusactingasanimplicitdependencyoftheEJBontheunderlyingTransactionManagerservice.2.3LinksBetweenComponents2.3.1RemoteInteractionsJ2EEdefinesonlythreebasicinter-componentconnectiontypesthatcancrossapplicationserverboundaries,inallthreecases;communicationisaccomplishedthroughspecialJavaobjects.?RemoteEJBinvocation:synchronousEJBinvocationsthroughEJBHomeandEJBObjectinterfaces.?JavaConnectoroutboundconnection:synchronousmessagereceipt,synchronousandasynchronousmessagesending,DatabasequeryusingConnectionFactoryandConnectioninterfaces.?JavaConnectorinboundconnection:asynchronousmessagedeliveryintoMessage-DrivenBeans(MDBs)only,utilizingActivationSpecobjects.Inthefirsttwocases,anapplicationcomponentdeveloperwritesthecodethatperformslookupoftheseobjectsinthecomponent’srun-timeJNDIcontextaswellascodethatissuesmethodinvocationsorsendsandreceivesmessagestoandfromtheremotecomponent.Thecomponent’srun-timeJNDIcontextiscreatedforeachdeploymentofthecomponent.Bindingsinthecontextareinitializedatcomponentdeploymenttimebythedeployed(usuallybymeansofcomponent’sdeploymentdescriptors).Thesebindingsareassumedtobestatic,sincethespecificationdoesnotprovideanycontractbetweenthecontainerandthecomponenttoinformofanybindingchangesInthecaseofJavaConnectorinboundcommunication,ActivationSpecobjectlookupandallsubsequentinteractionswithitaredoneimplicitlybytheMDBcontainer.Theprotocolforlookuphasnotbeenstandardized,thoughitisreasonabletoassumeaJMX-orJNDI-basedlookupassumingtheunderlyingapplicationserverprovidesfacilitiestocontroleachstepofdeploymentprocess,establishmentofalinkbetweenJ2EEcomponentswouldinvolve:?Deploymentoftargetcomponentclasses(optionalforsomecomponents,likedestinations),?CreationofaspecialJavaobjecttobeusedasatargetcomponent’sproxy,?Bindingofthisobjectwithcomponent’shostnamingservice(JNDIorJMX),?Startofthetargetcomponent,?Deploymentofreferencingcomponentclasses,?Creationandpopulationofreferencingcomponent’srun-timecontextinitshostnamingservice,?startofthereferencingcomponent.However,noneofmodernapplicationserversallowdetailedcontrolofthedeploymentprocessforallcomponenttypesbeyondwhatispossiblebylimitedoptionsintheirdeploymentdescriptors4.Thereforeourinfrastructurewilluseasimplifiedapproachthatreliesonfeaturescurrentlyavailableonmostapplicationservers:?Abilitytodeploymessagingdestinationsanddatasourcesdynamically,?AbilitytocreateandbindintoJNDIspecialobjectstoaccessmessagingdestinationsanddatasources,?AbilitytospecifyinitialbindingofEJBHomeobjectsuponEJBcomponentdeployment,?AbilitytospecifyaJNDIreference5inthereferencingcomponent’srun-timecontexttopointtotheEJBHomebindingofthereferencedEJBcomponent.Inourinfrastructurewhichislimitedtohomogeneousapplicationservers,theseoptionsaresufficienttocontrolintercomponentlinksthroughsimpledeploymentdescriptormanipulation.However,incontextofheterogeneousapplicationservers,simpleJNDIreferencesandthussimpledescriptormanipulationareinsufficientduetocross-application-serverClassloadingissues.2.3.2LocalInteractionsSomeinteractionsbetweencomponentscanoccuronlybetweencomponentsco-locatedinthesameapplicationserverJVMandsometimesonlyinthesamecontainer.IntheWebtier,examplesofsuchinteractionsareservlet-to-servletrequestforwarding.IntheEJBtier,suchinteractionsareCMPEntityrelationsandinvocationsviaEJBlocalinterfaces.Suchlocaldeploymentconcernsneednotbeexposedatthelevelofadistributeddeploymentinfrastructureotherthantoensurecollocation.Therefore,theinfrastructuretreatsallcomponentsrequiringcollocationasasinglecomponent.2.4DeploymentofJ2EEApplicationsandSystemServices2.4.1DeploymentofApplicationComponentsDeploymentandundeploymentofstandardJ2EEcomponentshasnotyetbeenstandardized(seeJSR88[10]forstandardizationeffort6).Therefore,eachapplicationservervendorprovidesproprietaryfacilitiesforcomponentdeploymentandundeployment.AndwhiletheJ2EEspecificationdoesdefinepac