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