外文翻译--J2EE体系结构.doc

外文翻译--J2EE体系结构.doc

《外文翻译--J2EE体系结构.doc》由会员分享，可在线阅读，更多相关《外文翻译--J2EE体系结构.doc（24页珍藏版）》请在冰豆网上搜索。

浙江工业大学之江学院

毕业设计（论文）外文翻译

毕业设计（论文）题目：

基于J2EE的企业电子投票系统开发与设计

外文翻译

（一）题目：

J2EE体系结构

外文翻译

（二）题目：

J2EE项目的选择与风险

分院（系）：

信息工程分院专业：

计算机科学与技术

班级：

0402姓名：

学号：

200420100219指导教师：

毕业设计（论文）外文翻译要求

1、毕业设计（论文）外文翻译应有两篇，总字符数不少于20000，其文献来源应由指导教师选定后以纸质（复印或打印件）形式随同毕业设计（论文）任务书一并发给学生。

复印或打印件上应有指导教师和专业教研室主任的签名和日期。

要求每位学生的外文翻译内容不重复。

2、翻译的外文文献应主要选自学术期刊、学术会议的文章、有关著作及其他相关材料，应与毕业论文（设计）主题相关，并列入毕业论文（设计）的参考文献；在每篇中文译文首页“页脚”处注明原文作者及出处，中文译文后应附外文原文（指导教师提供的原文，论文上应有指导教师和教研室主任签名）。

3、中文译文的基本撰写格式为：

题目采用三号黑体字居中打印，正文采用宋体小四号字，行间距一般为固定值20磅，标准字符间距。

页边距为左3cm，右2.5cm，上下各2.5cm，页面统一采用A4纸。

4、封面上的“外文翻译题目”指中文译文的题目；两篇外文文献，按“封面、译文一、外文原文

（一）、译文二、外文原文

（二）、外文翻译评阅表”的顺序统一装订。

浙江工业大学之江学院毕业设计（论文）外文翻译

译文一

J2EE体系结构

在讨论了J2EE设计中的一些高层次问题之后，现在该来看一看J2EE应用的几个可选体系结构。

常见概念

首先，让我们来看一看所有J2EE体系结构都共有的几个概念。

J2EE应用中的体系结构层

下面要讨论的每个体系结构都含有三个主要层，尽管有些体系结构在中间层内因如了另外的划分。

经验已经证明了将企业级系统明确地划分成多个层的价值。

这确保了责任的明确划分。

J2EE的3层体系结构是各类系统中的经验结晶。

具有3个或3个以上层的系统已经证明比其内没有中间层的客户-服务器系统具有更大的可缩放和灵活性。

在一个设计完备的多层系统中，每一层应该只依赖于它下面的那一层。

例如，对数据库的更改不应该要求对WEB接口的更改。

每一层所特有的东西应该向其他层隐藏起来。

例如，WEB应用中的WEB层只应该依赖于服务器小程序API，而中间层只应该依赖于JDBC之类的企业资源API。

这两个原则确保了应用修改起来容易，同时修改又不级联到其他层。

下面依次来看典型的J2EE体系结构的每一层。

企业信息系统（EIS）层

这一层有时也叫做综合层（INTEGRATIONTIER），由J2EE应用完成其工作所必须访问的企业资源所组成。

这些资源包括数据库管理系统（DBMS）和遗留的主机应用。

EIS层资源通常是事务性的，EIS位于J2EE服务器的控制之外，尽管该服务器的确以一种标准方式管理事务和连接建池。

J2EE设计师对EIS层的设计与部署将是变化的，视该项目的性质（现有服务的绿色场或集成度）而定。

如果该项目包含现有服务的集成，EIS层资源可能会影响中间层的实现。

J2EE为与EIS层资源的借口提供了强有力的能力，比如访问关系数据库的JDBCAPI、访问目录服务器的JNDI以及允许连接其他EIS系统的JACACONNECTORARCHITECTURE（JACA连接器体系结构，简称JCA）。

J2EE服务器负责建立连往EIS资源的连接池、横跨资源上的事务管理以及保证J2EE应用不危及EIS系统的安全。

中间层

这一层含有应用的业务对象，并调停对EIS层资源的访问。

中间层构件主要从事务管理和连接建池之类的J2EE容器服务中受益。

中间层构件独立于选定的用户接口。

作者：

〔美〕亨特﹑〔美〕罗夫特斯来源：

《精通J2EE（Java企业级应用）》，2004.7：

23-28

如果使用了EJB，我们把中间层分离成两层：

EJB以及使用这些EJB来支持该接口的对象。

但是，这种分离不是保证一个干净中间层所必须的。

用户接口（UI）层

这一层将中间业务对象暴露给用户。

在WEB应用中，UI层由服务器小程序所使用的助手类以及诸如JSP页之类的试图构件所组成。

为了清楚起见，我们在讨论WEB应用时将把UI层称做“WEB层”。

业务接口的重要性

许多人将EJB看做J2EE应用的核心。

从J2EE的EJB中心论角度看，会话EJB将暴露应用的业务逻辑，而其他对象（比如BusinessDelegateJ2EE设计模式中的Web层“业务委托”对象）将由他们与EJB的关系来确定。

但是，这种假设将一种技术（EJB）抬高到了OO设计考虑之上。

EJB不是在J2EE应用中实现中间层的唯一技术。

正式业务接口层的概念体现了一不好的习惯，不管是不是使用了EJB，我们都应该使用这个概念。

在下面将要讨论的所有体系结构中，业务接后层都有客户（比如UI层）直接使用的中间层接口所组成。

业务接口层为普通Java接口中的中间层定义了联系人；因此，EJB就是一个实现策略。

如果我们没有使用EJB，业务接口的实现将是运行在J2EEWeb容器中的普通Java对象。

当使用了EJB时，业务接口的实现将隐藏掉与EJB层的交互。

一定要设计到Java接口，而不要设计到具体类，也不要设计到技术。

下面来看一下满足不同需求的4种J2EE体系结构。

非分布式体系结构

下面的这些体系结构适合Web应用。

他们可以把所有应用构件只运行在单个JVM中。

这使他们变得简单而有效，但限制了部署的灵活性。

具有业务构件接口的Web应用

在大多数情况下，J2EE用来构造Web应用。

因此，同一个J2EEWeb容器可以提供许多应用所需要的整个基础结构。

和EJB一样，J2EEWeb应用实际上享有对企业API的相同访问权。

它们受益于J2EE服务器的事务管理和连接池能力，并可以使用JMS,JDBC和JavaConnectorAPI之类的企业服务。

除实体组件之外的所有数据存取技术都是可以使用的。

Web应用的Web层和中间层运行在同一个JVM中。

但是，在逻辑上使他们保持不同是极其重要的。

Web应用中的主要设计风险是UI构件与业务逻辑构件之间的责任模糊不清。

业务接口层将由普通Java类所实现的Java接口来组成。

这是一个简单而又可缩放的体系结构，并且能满足大多数应用的需要。

长处

这种体系结构具有下列优点：

l简单性。

这通常是Web应用的最简单结构。

但是，如果事务管理或线程化问题要求开发分复杂的代码，使用EJB可能将更简单。

l速度。

这样的体系结构遇到了来自J2EE服务器的最小系统开销。

lOO设计不会被J2EE构件问题（比如调用EJB的影响）所妨碍。

l容易测试。

如果设计合理，无需Web层就能够对业务接口进行测试。

l我们可以发挥服务器的事务支持。

l缩放性很好。

如果Web接口是无状态的，则根本不需要来自容器的聚类支持。

但是，Web应用可以通过使用服务器支持会话状态复制来分布。

弱点

应该注意下列这些缺点：

l这种体系结构只支持一个Web接口。

例如，它不能支持独立的GUI客户（中间层和这个Web接口在同一个JVM中）。

但是，正如我们稍后将回看到的，可以增加一个Web服务层。

l整个应用仅运行在单个JVM中。

虽然这提高了性能，但我们无法将构件自由地分配给不同的物理服务器。

l这种体系结构不能使用EJB容器事务支持。

我们将需要在应用代码中创建和管理事务。

l服务器没有提供对并发编程的支持。

我们必须亲自处理线程化问题，或使用一个解决常见问题的类库，比如util.concurrent。

l将实体组件用于数据存取是不可能的，但可以证明的是，这根本不是什么损失。

访问本地EJB的Web应用

Servlet2.3规范（SRV9.11）可从

在这种体系结构中，Web层与刚讨论过繁荣Web应用体系结构的Web层相同。

业务接口也是相同的；这两种体系结构的不同之处从它们的出现（EJB层）开始。

因此，中间层被划分成了两部分（运行在Web容器中的业务接口和EJB），但这两部分运行在同一个JVM中。

有两种方法可以用来实现业务接口：

l代理方法。

在这种方法中，一个本地EJB直接实现业务接口，而Web容器代码被赋予一个对该EJB的本地接口的引用，同时无需处理必不可少的JNDI查找。

l业务委托方法。

在这种方法中，业务接口的Web容器实现明确地托付给相应的EJB。

这具有允许高速缓存和允许故障操作在适当地点被重试的优点。

我们无需担心上述任一情况中的java.rmi.RemoteException捕获。

传输错误不会出现。

在这种体系结构中，和通过EJB来暴露一个远程接口的体系结构不同，EJB的使用仅仅是这种体系结构的一个实现选择而已，而不是一个基本特征。

不用改变总体设计，也不用EJB，就可以实现任何一个业务接口。

长处

这种体系结构具有如下这些优点：

l它没有分布式EJB应用那么复杂。

lEJB使用不更改应用的基本设计。

在这种体系结构中，只使这样一些对象成为EJB：

它们需要一个EJB容器的那些服务。

lEJB使用只强加相当小的性能开销，因为没有远程方法调用或串行化。

l它提供EJB容器事务与线程管理的各种好处。

l如果需要，它允许我们使用实体组件。

弱点

这种体系结构的缺点有如下这些：

l它比纯Web应用更复杂。

例如，它遇到EJB部署和类装人复杂性。

l它仍不能支持除一个Web接口之外的客户，除非我们添加一个Web服务层。

l整个应用仍运行在单个JVM中，这意味着所有构件都必须运行在同一台物理服务器上。

l具有本地接口的EJB测试起来很困难。

我们需要在J2EE服务器内运行测试案例（比如用服务器小程序）。

l作为使用EJB的结果，仍存在一些调整对象设计的诱惑，即使含有本地接口，EJB调用仍慢于普通的方法调用，而且这可能会诱惑我们修改业务对象的自然粒度。

有时，我们可能会决定把EJB引进到一个没有适应它的体系结构中。

这可能是由“做可能管用的最简单事情”的XP方法所造成的。

例如，最初的需求可能没有证明由EJB引入的复杂性是值得的，但后来增加的需求可能会提出使用EJB。

如果采用上面描述的业务构件接口方法，引进具有本地接口的EJB将不会引起问题。

可以简单地选择应该被实现成具有本地的代理EJB的那些业务构件接口。

引进具有远程接口的EJB可能有较大疑问，因为这不仅仅是一个引进EJB的问题，而且也是一个从根本上改变了应用的性质的问题。

例如，可能需要使业务接口粒度变的更粗，以避免