计算机外文翻译文献综述J2EEWord文档下载推荐.doc

计算机外文翻译文献综述J2EEWord文档下载推荐.doc

《计算机外文翻译文献综述J2EEWord文档下载推荐.doc》由会员分享，可在线阅读，更多相关《计算机外文翻译文献综述J2EEWord文档下载推荐.doc（17页珍藏版）》请在冰点文库上搜索。

（5）新的请求路径可以复用先前的组件配置路径。

应用智能监视和人工智能规划方法再结合那个研究得出的结论，我们看到通过动态布置基于动态监视的额外的应用组件，在广域网中符合工业标准基于组件的应用程序中动态的可适应性是可以实现的。

然而，为了实现这种动态可适性，我们需要一种框架来在这样的环境里自动化地配置J2EE应用程序。

这种需要对于哪怕在单一的应用程序服务器上尝试布置J2EE应用的人来说也显而易见，这种任务设计到大量的系统服务和应用组件的配置。

例如你必须在配置和部署应用组件前先建立JDBC数据源，设立消息目的地和资源适配器。

在需要跨越多个节点服务器的广域网配置中，这将更加复杂，因为更多的便利内部节点通信的系统服务需要配置和启动，而且多种配置数据比如IP地址，端口号，JNDI名字和其他的数据在多个节点的配置文件中必须维持一致性。

这种分布式配置框架必须满足：

（1）声明内部组件一致性规范和定义它对组件配置部署的影响。

（2）声明应用程序组件对应用服务器，以及它们的配置和部署的依赖性。

（3）提供简单但可表达的抽象方法去控制通过部署和拆卸组件获得的适用性。

（4）能够复用服务和组件从而高效的利用网路节点资源。

（5）提供上述便利而不会增加应用程序员的设计负担。

在本论文中，我们提出自动动态部署J2EE应用程序的框架涉及了上面的所有问题，这种框架为组件定义了结构描述语言，链接说明和集合。

这种组件说明语言用来描述应用程序组件和链接，它使得应用组件与系统组件中清晰的分开。

一种灵活的系统类型用来定义组件接口和端口的兼容性。

一种为配置组件属性而开发的定义和表述语言允许内部组件间独立的规范和组件间属性的继承。

组件集合语言允许先前定义的复制的组件通过连接合适的端口集合到应用路径，连接时通过链接复制对象和具体把这些复制组件映射到目标应用服务器节点。

组件配置过程评估了应用程序路径的正确性，确认在系统组件上的应用组件的独立性和完成复制组件的部署。

根据这些配置使先前部署的复制组件在新的路径中得以匹配和复用的努力正在做出。

我们把这种架构作为JBoss开源java应用服务器的一部分加以实现，在几个J2EE样本程序比如JavaPetStore,，RUB和TPC_W_NYU中进行测试。

这种架构实现利用了JBoss的可扩展的微内核结构，基于JMX规范。

JBoss的组件结构允许根据部署应用程序的需要增加服务配置。

我们相信通过动态部署和拆卸系统服务来重构应用服务器对构建高效资源框架的动态分布部署的J2EE应用程序来说是非常必要的。

本文如下部分是这样组织的。

第2部分提供了必要的背景以理解和研究有关的J2EE组件技术规范。

第3部分对这种架构给出了一般性的描述。

第4部分更深入的描述了有关这种架构特别重要的和有趣的内部机制。

第五部分描述了如何实现这种架构，相关联的工作将在第六部分介绍。

2J2EE背景知识

2.1介绍

组件框架。

组件框架是一种中间件系统，它支持遵守一定标准的有不同组件构成的应用程序。

应用组件被塞入这种确立它们运行环境和规定它们交互的框架中。

这通常是通过容器，组件持有者来实现的。

这种容器也提供通常需要的功能以实现命名，安全性，事务，和持久性！

组件框架为组件的执行提供了一个集成的环境，因此显著的减少了在设计，实现，部署和维护应用程序时工作。

现在工业上的组件框架标准以对象管理组的CORBA组件模型，SUN公司的JAVA2PlatformJ企业版[J2EE]和微软公司的.NET标准，其中在企业里应用最为广泛的组件框架是2EEE。

J2EE.J2EE是开发多层企业应用JAVA程序的综合性的标准。

J2EE规范定义如下：

（1）组件编程模型。

（2）组件和主服务器的链接。

（3）服务器提供给组件的服务。

（4）各种各样的人物角色。

（5）兼容性检验装置和编译测试程序。

在众多的服务列表中，消息通信，事务处理，命名机制和其它应用组件用到的服务是应用服务器必须提供的。

用J2EE进行应用开发必须遵守经典的3层结构—表现层，业务层和企业信息系统层。

属于各层的J2EE组件在开发时遵守具体的J2EE标准。

1、表现层或者网络层

这一层实际上又被分为客户端和服务器端。

客户端包括浏览器，applets，Java应用程序等和负责和服务器端的表现层或者业务层进行交互。

服务器端包括servlet、jsp和静态网页内容。

这些组件负责把业务数据传递给终端用户。

数据本身通常从业务层获得有时也从企业信息系统层直接获得。

表现层的服务器端通常通过Http协议来进行访问。

2、业务层或者EJB层

这一层包含EJB，即企业应用的事务逻辑模型。

这些组件提供了持久化机制和事务支持。

EJB中的组件通过RMI被调用。

在Java虚拟机调用或者异步的消息传递，取决与EJB组件的类型。

EJB规范定义了很多种组件。

它们在调用风格（同步和异步，本地和远程）与状态（完全状态，不可持久状态，可持久）方面不同。

同步调用的EJB组件通过特定的工厂代理对象来表现自己。

这种工厂代理对象通常被EJB部署者绑定在JNDI中。

EJB对象允许或者本地EJB对象是特定EJB实例的代理。

3、企业信息系统或者数据层

这一层指的就是企业信息系统，比如关系数据库，ERP系统，消息系统等。

业务层和持久层在资源适配器的帮助下与该层进行通信。

资源适配器在Java连结结构中被定义。

J2EE编程模型一直被认为是分布式的编程模型，在该模型中应用组件在J2EE服务器上运行并且彼此可以相互交互。

经过初始化说明和第一个服务实现后，该技术，更显著的说EJB技术，已经明显地从纯粹的分布式计算模型转向了本地交互。

转变的背后有合理的性能有关的原因，然而分布式的特征现在还存在。

J2EE规范已经经过了好几次修订，现在最稳定的版本是1.3，1.4版本正处于重审阶段。

我们应该把注意力放在1.3版本上，而实际上是在学习后者。

适用与商业的J2EE实现可以大量的从BEA系统，IBM，Oracle等赞助商得到。

包括JBoss和JOnAS在内的开源实现据称兼容性也不错。

最近名单上有多出了新的ApacheprojectGeronimo。

2.2J2EE组件编程模型

在我们基本的J2EE组件前，先让我们强调一下什么是组件。

软件组件是有一系列的具体的接口和明确的上下文环境构成。

它可以被独立的部署而且易于被第三方重构。

根据以上的定义，如下的组成J2EE应用程序的实体可以看作是软件组件：

（1）EJBS（会话，实体，消息驱动）。

（2）Web组件（Servlet、JSP）。

.

（3）消息目的。

（4）数据源。

EJB和Web组件被部署在由应用服务赞助商提供的容器中.它们有定义良好的容器规则来管理生命周期，线程，持久化和其他问题。

EJB和Web组件都利用JNDI目录机制去寻找资源和它们想要交互的其EJB组件。

目录被执行的JNDI环境被独立的由容器的每个组件加以维护。

该种环境下的绑定机制通常由组件部署的解释者加以配置。

消息目的地，像对话和队列，是由消息服务执行所提供的资源。

数据源是提供给应用服务器的为事务组件进入到企业信息服务层提供数据接口，通常由被应用服务器管理的JDBC连接池实例化。

一个J2EE编程者明确编写的项目只有EJB和Web组件。

这些用户编写的组件彼此交互而且系统服务可以是明显的也可以是隐含的。

例如，EJB开发者可以选择明确的事务区分方式，这种方式意味着开发者假设通过定义良好接口的事务经理服务平台来书写明确的程序交互。

或者，开发者也可选择容器管理事务区分的方式。

这样由于组件的事务行为通过他的描述者来定义而且全部用EJB容器来处理，因此作为一个隐式独立的EJB提供潜在的事务管理服务。

2.3组件间的链接

2.3.1远程交互

J2EE仅定义了三种可以在不同应用服务器间传递的基本组件间连接类型。

在这三种情况下，通信通过特定的Java对象来完成。

（1）远程EJB调用：

同步的EJB调用通过主EJB对象和EJB对象接口来实现。

（2）Java连结器的外部连接：

同步消息接收，同步和异步消息发送，用连接工厂和连接接口进行数据库查询。

（3）Java连接器的内部连接：

异步消息传递进入消息驱动Bean只能使用ActivationSpec对象。

在前两个实例中，应用组件的开发者不仅书写执行在组件的运行时JNDI环境中的对象目录代码，而且书写发布方法调用，与远程的组件相互发送和接受消息。

组件的运行时JNDI环境为每一个组件部署所创建。

环境中的绑定在组件部署时由部署者进行初始化。

这些绑定被假设为是静态的，因为规格中没有提供任何的容器和组件间协议去提示绑定发生了变化。

在Java连接器的内部通信情景下，ActivationSpec对象查询以及所有的相应的M容器隐式的完成。

虽然查询的协议还没有被标准化，但是假设一个基于JMX或者JNDI的查询是合理的。

假设潜在的应用服务器提供了所有的设备去控制部署过程的每一步，那么在两个J2EE组件间确立一个连接需要涉及：

（1）部署目标组件类。

（2）创建一个特定的Java对象用作目标组件代理。

（3）用组件的命名服务去绑定目标。

（4）启动目标组件。

（5）部署指定的组件类。

（6）在主机的命名服务中，创建和进行指定组件的运行环境。

（7）启动指定的组件。

然而，没有一个现代的应用服务器允许详细的控制所有组件类型的部署过程除了在它们的部署解释器中的有限的选择。

因此我们的架构将使用简化的途径，它所依赖的特征在现在的大多数的应用服务器上都可以得到。

（1）动态部署消息目的和数据源的能力。

（2）创建和绑定特定的JNDI目标去访问消息目的和数据源的能力。

（3）把初始绑定的EJB对象到EJB部署组件的能力。

（4）用在参考组件运行环境中的JNDI指引去指出绑定的参考EJB的能力。

在只有相同的应用服务器的架构中，上面的功能对通过简单的部署控制解释器方式来控件间的连接已经足够了。

然而，在不同应用服务器的环境下，由于跨服务器的类下载问题，这种简单的控制解释器的方式是不够的。

2.3.2本地交互

一些组件间的交互可以发生在同一地点的相同应用服务器虚拟机的组件间，有时候甚至可以发生在只有相同容器的组件间。

在Web层，这种交互的例子是servlet到servlet的请求转发。

在EJB层，这种交互的例子是CMP实体关系和通过EJB本地接口的调用。

这种本地部署所关心的不是在分布式架构中去表现而是去增强一致性。

因此，这种架构把所有的本地的组件请求当作一个单一的组件加以对待。

2.4部署J2EE应用程序和系统服务

2.4.1部署应用程序组件

部署和拆卸标准的J2EE组件还没有统一的标准，因此每个应用服务的提供商对组件的部署和拆卸提供了单独的功能于J2EE规范中没有定义标准组件的包，包的格式和包内的基于xml部署解释器的位置，因此这种包对于没有所属权变化的应用服务器不需要部署。

具体变化的例子有：

（1）支持或者取代标准所有者解释器的新的所有者解释器的产生。

（2）具体服务应用程序类的代码的更替。

为了着手构建一个能够部署不可网络的动态的分布式的架构，我们提出了一种普遍的部署单元即一个简单的基于xml部署的解释器或者是一组类似的绑定到文档中的解释器。

文档可能包含用于执行组件的Java类或者任何其它的所需组件。

相应地，部署解释器也可以简单地用URL来索引代码。

我们假设这种动态的部署和拆卸服务存在于所有的兼容的J2EE服务器上而且在不理解类重载相关问题时一个健壮的类重载结结构的应用服务器就能够重复的部署生命周期。

大多数现代的应用服务器都提供这样的功能。

2.4.2部署系统组件

对应用组件来说，J2EE规范只是少了在部署和拆卸时的明确定义，而对系统服务来说，在这方面做的更糟。

对系统服务来说不仅没有具体的定义一个标准化的部署，实际上，这个规格甚至连没有强调在生命周期属性方面的要求，更不用手强调依赖也潜在的系统服务的应用组件的明确规范了取而代之的是它定义了部署者的角色，这个角色负责确保像组件的本性和系统的解释器所暗示的那样，所需的服务是基于应用组件对系统服务依赖性的基础之上。

例如，假如有一个事务容器要至少用一种方法去开始一个新的事务，那么一个带有这样的事务容器的EJB就需要在应用层表示事务管理服务。

与之相似的是，一个消息驱动的bean，也隐式需要一种运行在网络上消息服务实例。

它为MDB管理消息目的以及基于查询的Java连接器通过它的管理服务层去提供这种消息服务。

考虑到应用层可能通常只用到了应用服务器所提供的服务的一个子集，根据应用层的需要允许递增的配置服务的组件应用服务器允许更高效的利用多种资源。

包括，开源的应用服务器，JBoss和OnAS在内，已经有多种J2EE应用服务器已经全部或者部分的实现了组件化。

我们感觉到通过动态的部署和拆卸系统服务，动态的配置应用服务器对动态分布的部署J2EE应用程序是一种十分重要的构建资源有效型框架的方法。

因此我们提倡并将把用JBoss应用服务器设计的微内核的应用服务器用作一个模型。

在该模型中，一个微型的服务包括了系统调用总线，一个稳健的类下载子系统，一些命名子系统和一个动态配置子系统。

所有其它的服务是热部署并且通过一个普通的调用总线来进行通信。

例如，JBoss利用Java管理扩展服务器来实现基本的命名和调用功能。

除此之外，JBoss实现了一个先进的类下载子系统和部署服务。

所有其它的JBoss是动态配置的，并外在的表现为具有良好机制和生命周期的JMXMBeans.这样的一种应用服务器根据系统服务外在利用应用组件去设计相关功能，并且只有需要的系统服务才会得到合理配置和部署！

参考文献

[1]MattBishop.ComputerSecurity:

ArtandScience.NewYork,2002

[2]MattBishop.VulnerabilitiesAnalysis.ProceedingsoftheSecondInternationalSymposiumonRecentAdvancesinIntrusionDetection.LosAngeles2006

[3]Balasubramaniyan.ArchitectureforIntrusionDetectionusingAutonomousAgents[M].DepartmentofComputerSciences,PurdueUniversity,1998.

InfrastructureforAutomaticDynamicDeployment

OfJ2EEApplicationinDistributedEnvironments

AnatolyAkkerman,AlexanderTotok,andVijayKaramcheti

Abstract:

inordertoachievesuchdynamicadaptation,weneedaninfrastructureforautomatingJ2EEapplicationdeploymentinsuchanenvironment.ThisneedisquiteevidenttoanyonewhohasevertrieddeployingaJ2EEapplicationevenonasingleapplicationserver,whichisataskthatinvolvesagreatdealofconfigurationofboththesystemservicesandapplicationcomponents.

Keywords:

j2ee;

component;

Distributed;

DynamicDeployment;

1Introduction

Inrecentyears,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-basedapplicationsinwideareanetworks

Throughdeploymentofadditionalapplicationcomponentsdynamicallybasedonactivemonitoring.However,inordertoachievesuchdynamicadaptation,weneedaninfrastructureforautomatingJ2EEapplicationdeploymentinsuchanenvironment.ThisneedisquiteevidenttoanyonewhohasevertrieddeployingaJ2EEapplicationevenonasingleapplicationserver,whichisataskthatinvolvesagreatdealofconfigurationofboththesystemservicesandapplicationcomponents.ForexampleonehastosetupJDBCdatasources,messagingdestinationsandotherresourceadaptersbeforeapplicationcomponentscanbeconfiguredandd