JSP企业电子投票系统(源代码+论文+开题报告+外文翻译+文献综述)
收藏
资源目录
压缩包内文档预览：(预览前20页/共26页)
编号：149932440
类型：共享资源
大小：420.05KB
格式：RAR
上传时间：2021-10-10
上传人：好资料QQ****51605
认证信息
个人认证
孙**（实名认证）
江苏
IP属地：江苏
20
积分
- 关 键 词：
-
JSP
企业
电子
投票
系统
源代码
论文
开题
报告
外文
翻译
文献
综述
- 资源描述：
-
JSP企业电子投票系统(源代码+论文+开题报告+外文翻译+文献综述),JSP,企业,电子,投票,系统,源代码,论文,开题,报告,外文,翻译,文献,综述
- 内容简介：
-
浙江工业大学之江学院毕业设计（论文）外文翻译毕业设计（论文）题目：基于J2EE的企业电子投票系统开发与设计 外文翻译（一）题目： J2EE体系结构 外文翻译（二）题目： J2EE项目的选择与风险 分院（系）： 信息工程分院 专 业：计算机科学与技术 班 级： 0402 姓 名： 徐栋杰 学 号： 200420100219 指导教师： 冯志林 毕业设计（论文）外文翻译要求1、毕业设计（论文）外文翻译应有两篇，总字符数不少于20000，其文献来源应由指导教师选定后以纸质（复印或打印件）形式随同毕业设计（论文）任务书一并发给学生。复印或打印件上应有指导教师和专业教研室主任的签名和日期。要求每位学生的外文翻译内容不重复。2、翻译的外文文献应主要选自学术期刊、学术会议的文章、有关著作及其他相关材料，应与毕业论文（设计）主题相关，并列入毕业论文（设计）的参考文献；在每篇中文译文首页“页脚”处注明原文作者及出处，中文译文后应附外文原文（指导教师提供的原文，论文上应有指导教师和教研室主任签名）。3、中文译文的基本撰写格式为：题目采用三号黑体字居中打印，正文采用宋体小四号字，行间距一般为固定值20磅，标准字符间距。页边距为左3 cm，右2.5 cm，上下各2.5 cm，页面统一采用A4纸。4、封面上的“外文翻译题目”指中文译文的题目；两篇外文文献，按“封面、译文一、外文原文（一）、译文二、外文原文（二）、外文翻译评阅表”的顺序统一装订。浙江工业大学之江学院毕业设计（论文）外文翻译译文一J2EE体系结构在讨论了J2EE设计中的一些高层次问题之后，现在该来看一看J2EE应用的几个可选体系结构。常见概念首先，让我们来看一看所有J2EE体系结构都共有的几个概念。J2EE应用中的体系结构层下面要讨论的每个体系结构都含有三个主要层，尽管有些体系结构在中间层内因如了另外的划分。经验已经证明了将企业级系统明确地划分成多个层的价值。这确保了责任的明确划分。J2EE的3层体系结构是各类系统中的经验结晶。具有3个或3个以上层的系统已经证明比其内没有中间层的客户-服务器系统具有更大的可缩放和灵活性。 在一个设计完备的多层系统中，每一层应该只依赖于它下面的那一层。例如，对数据库的更改不应该要求对WEB接口的更改。 每一层所特有的东西应该向其他层隐藏起来。例如，WEB应用中的WEB层只应该依赖于服务器小程序API，而中间层只应该依赖于JDBC之类的企业资源API。这两个原则确保了应用修改起来容易，同时修改又不级联到其他层。下面依次来看典型的J2EE体系结构的每一层。企业信息系统（EIS）层这一层有时也叫做综合层（INTEGRATION TIER），由J2EE应用完成其工作所必须访问的企业资源所组成。这些资源包括数据库管理系统（DBMS）和遗留的主机应用。EIS层资源通常是事务性的，EIS位于J2EE服务器的控制之外，尽管该服务器的确以一种标准方式管理事务和连接建池。J2EE设计师对EIS层的设计与部署将是变化的，视该项目的性质（现有服务的绿色场或集成度）而定。如果该项目包含现有服务的集成，EIS层资源可能会影响中间层的实现。J2EE为与EIS层资源的借口提供了强有力的能力，比如访问关系数据库的JDBC API、访问目录服务器的JNDI以及允许连接其他EIS系统的JACA CONNECTOR ARCHITECTURE （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将暴露应用的业务逻辑，而其他对象（比如Business Delegate J2EE设计模式中的Web层“业务委托”对象）将由他们与EJB的关系来确定。但是，这种假设将一种技术（EJB）抬高到了OO设计考虑之上。EJB不是在J2EE应用中实现中间层的唯一技术。正式业务接口层的概念体现了一不好的习惯，不管是不是使用了EJB，我们都应该使用这个概念。在下面将要讨论的所有体系结构中，业务接后层都有客户（比如UI层）直接使用的中间层接口所组成。业务接口层为普通Java接口中的中间层定义了联系人；因此，EJB就是一个实现策略。如果我们没有使用EJB，业务接口的实现将是运行在J2EE Web容器中的普通Java对象。当使用了EJB时，业务接口的实现将隐藏掉与EJB层的交互。一定要设计到Java接口，而不要设计到具体类，也不要设计到技术。下面来看一下满足不同需求的4种J2EE体系结构。非分布式体系结构下面的这些体系结构适合Web应用。他们可以把所有应用构件只运行在单个JVM中。这使他们变得简单而有效，但限制了部署的灵活性。具有业务构件接口的Web应用在大多数情况下，J2EE用来构造Web应用。因此，同一个J2EE Web容器可以提供许多应用所需要的整个基础结构。和EJB一样，J2EE Web应用实际上享有对企业API的相同访问权。它们受益于J2EE服务器的事务管理和连接池能力，并可以使用JMS,JDBC和Java Connector API之类的企业服务。除实体组件之外的所有数据存取技术都是可以使用的。Web应用的Web层和中间层运行在同一个JVM中。但是，在逻辑上使他们保持不同是极其重要的。Web应用中的主要设计风险是UI构件与业务逻辑构件之间的责任模糊不清。业务接口层将由普通Java类所实现的Java接口来组成。这是一个简单而又可缩放的体系结构，并且能满足大多数应用的需要。长处这种体系结构具有下列优点：l 简单性。这通常是Web应用的最简单结构。但是，如果事务管理或线程化问题要求开发分复杂的代码，使用EJB可能将更简单。l 速度。这样的体系结构遇到了来自J2EE服务器的最小系统开销。l OO设计不会被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）可从/products/servlet/download.html站点上获得。如果一个应用被部署在一个集成的J2EE应用服务器中且该服务器运行在单个JVM中，该规范通过本地接口来保证EJB的Web层对象访问。这使我们技能从一个EJB容器中得到好处，又不至于招致过度的复杂性或把我们的应用变成分布式的。在这种体系结构中，Web层与刚讨论过繁荣Web应用体系结构的Web层相同。业务接口也是相同的；这两种体系结构的不同之处从它们的出现（EJB层）开始。因此，中间层被划分成了两部分（运行在Web容器中的业务接口和EJB），但这两部分运行在同一个JVM中。有两种方法可以用来实现业务接口：l 代理方法。在这种方法中，一个本地EJB直接实现业务接口，而Web容器代码被赋予一个对该EJB的本地接口的引用，同时无需处理必不可少的JNDI查找。l 业务委托方法。在这种方法中，业务接口的Web容器实现明确地托付给相应的EJB。这具有允许高速缓存和允许故障操作在适当地点被重试的优点。我们无需担心上述任一情况中的java.rmi.RemoteException捕获。传输错误不会出现。在这种体系结构中，和通过EJB来暴露一个远程接口的体系结构不同，EJB的使用仅仅是这种体系结构的一个实现选择而已，而不是一个基本特征。不用改变总体设计，也不用EJB，就可以实现任何一个业务接口。长处这种体系结构具有如下这些优点：l 它没有分布式EJB应用那么复杂。l EJB使用不更改应用的基本设计。在这种体系结构中，只使这样一些对象成为EJB：它们需要一个EJB容器的那些服务。l EJB使用只强加相当小的性能开销，因为没有远程方法调用或串行化。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的问题，而且也是一个从根本上改变了应用的性质的问题。例如，可能需要使业务接口粒度变的更粗，以避免“罗嗦的”调用和实现足够的性能。我们还可能需要把所有业务逻辑实现转移到EJB容器内部。分布式体系结构 下面这两种体系结构除了支持Web应用之外，还支持远程客户。具有远程EJB的分布式应用这种体系结构被广泛地看做“经典的”J2EE体系结构。它提供了这样一种能力：通过给EJB及使用EJB的构件（比如 Web构件）使用不同的JVM来物理和逻辑地划分中间层。这是一个复杂的体系结构，并具有显著的性能开销。虽然描述了一个Web应用，但该体系结构可以支持任一J2EE客户类型。它特别符合独立客户应用的需要。该体系结构在UI层（或者说其他远程客户）与业务对象之间使用RMI，而这些业务对象被暴露为WJB（RMI通信的细节由EJB容器来隐藏，但我们仍需要处理使用它所带来的影响）。这使远程调用变成了一个主要的性能决定要素和一个核心的设计考虑因素。我们必须尽量最大限度的减少远程调用的数量（避免“罗嗦的”调用）。在EJB与EJB客户层之间传递的所有对象都必须是可串行化的，而且我们必须处理更复杂的错误处理需求。该体系结构中的WEB层和上面所讨论的那些结构中的WEB层相同。但是，业务接口的实现将处理对（可能是远程）EJB容器中的EJB的远程访问。在已讨论过的用于本地EJB的两种连通性方法（代理和业务委托）中，只有业务委托在这里是有用的，因为EJB远程接口上的所有方法都抛出JAVAX。RMI。REMOTEEXCEPTION。这是一个已检查异常，否则REMOTEEXCEPTION将需要在UI层代码中被捕获。这把它不正确地束缚到了一个EJB实现上。EJB层将单独负责与EIS层资源的通信，而且应该含有应用的业务逻辑。长处这种通信结构具有如下这些特有的优点l 它可以通过提供一个共享的中间层来支持所有J2EE客户类型l 它允许应用构件在不同物理服务器上的分布。如果EJB层是无状态，这个特点特别管用，进而允许使用无状态的会话EJB。含有有状态UI层和无状态中间层的应用将会从这种部署选择中获得最大的好处，而且将会给J2EE应用实现尽可能大的缩放性。弱点这种体系结构的弱点有如下这些：l 这是我们已讨论过的最复杂的方法，如果这种复杂性确定是业务需求的合理要求，很可能会导致整个项目周期内的资源浪费，并为故障提供一个滋生地。l 它影响性能。远程方法调用会比使用引用的本地调用慢数百倍，总体性能方面的影响结果取决与必须的远程调用数量。l 分布式应用的测试和测试变得很困难。l 所有业务构件都必须进行EJB容器中。虽然这为远程客户提供了一个综合性接口，但如果EJB不能用来解决业务需求所引起的每个问题，这是有问题的。例如，如果SIN-GLETON设计模式完全适用，用EJB满意地实现起来将会很困难。l OO设计被RMI的集中使用所严重阻碍。l 异常处理在分布式系统中变得更复杂。我们除了必须考虑应用故障外，还必须兼顾传输故障。当使用这种体系结构，千万不要破坏它。SUN JAVA CENTER的“FAST LANE READER”J2EE模式主张从WEB层中执行只读JDBC访问，以便最小化通过EJB层进行调用的系统开销。这违背了每个层只应该跟直接位于它下面的那些层进行通信的原则，也降低了缝补式体系结构的一个重要优点；部署灵活性。现在，运行WEB层的服务器必须能够访问数据库，而这会使特殊的防火墙规则车工内为必须之物。即使我们使用了远程接口，如果EJB及使用EJB的构件被放在了一起，那么大多数J2EEE服务器仍能优化远程调用并替换按引用的调用。这可以极大地减少使用具有远程接口的EJB所造成的性能影响，但无法消除远程语义所因如的有害影响。这种配置更改了应用的语句。要想让这种配置得到使用，关键是保证EJB支持本地调用（按引用）和远程调用（按值）。否则按引用的调用者可能会修改要传递其他调用者的对象，进而产生严重的后果。不要因为使用了具有远程借口的EJB导致一个应用变成分布式的，除非业务需求明确指出需要一个分布式体系结构。外文原文（一）J2EE ArchitecturesNow that weve discussed some of the high-level issues in J2EE design, lets look at some alternative architecture for J2EE applications.Common ConceptsFirst, lets consider some concepts shared by all J2EE architectures.Architectural Tiers in J2EE ApplicationsEach of the architectures discussed below involves three major tiers, although some introduce an additional division within the middle tier.Experience has shown the value of cleanly dividing enterprise systems into multiple tiers. This ensures a clean division of responsibility.The three-tier architecture of J2EE reflects experience in a wide range of enterprise systems. Systems with three or more tiers have proven more scalable and flexible than client server systems, in which there is no middle tier.In a well-designed multi-tier system, each tier should depend only on the tier beneath it. For example, changes to the database should not demand changes to the web interface.Concerns that are unique to each tier should be hidden from other tiers. For example, only the web tier in a web application should depend on the servlet API, while only the middle tier should depend on enterprise resource APIs such as JDBC. These two principles ensure that applications are easy to modify without changes cascading into other tiers.Lets look at each tier of a typical J2EE architecture in turn.Enterprise Information System (EIS) TierSometimes called the Integration Tier, this tier consists of the enterprise resources that the J2EE application must access to do its work. These include Database Management Systems (DBMSs) and legacy mainframe applications. EIS tier resources are usually transactional. The EIS tier is outside the control of the J2EE server, although the server does manage transactions and connection pooling in a standard way.The J2EE architects control over the design and deployment of the EIS tier will vary depending on the nature of the project (green field or integration of existing services). If the project involves the integration of existing services, the EIS tier resources may impact on the implementation of the middle tier.J2EE provides powerful capabilities for interfacing with EIS-tier resources, such as the JDBC API for accessing relational databases, JNDI for accessing directory servers, and the Java Connector Architecture (JCA) allowing connectivity to other EIS systems. A J2EE server is responsible for the pooling of connections to EIS resources, transaction management across resources, and ensuring that the J2EE application doesnt compromise the security of the EIS system.Middle TierThis tier contains the applications business objects, and mediates access to EIS tier resources. Middle tier components benefit most from J2EE container services such as transaction management and connection pooling. Middle-tier components are independent of the chosen user interface. If we use EJB, we split the middle tier into two: EJBs, and objects that use the EJBs to support the interface. However, this split isnt necessary to ensure a clean middle tier.User Interface (UI) TierThis tier exposes the middle-tier business objects to users. In web applications, the UI tier consists of servlets, helper classes used by servlets, and view components such as JSP pages. For clarity, well refer to the UI tier as the web tier when discussing web applications.The Importance of Business InterfacesMany regard EJBs as the core of a J2EE application. In an EJB-centric view of J2EE, session EJBs will expose the applications business logic, while other objects (such as business delegate objects in the web tier in the Business Delegate J2EE design pattern) will be defined by their relationship to the EJBs. This assumption, however, elevates a technology (EJB) above OO design considerations.Important EJB is not the only technology for implementing the middle tier in J2EE applications.The concept of a formal layer of business interfaces reflects good practice, and we should use it regardless of whether we use EJB. In all the architectures we discuss below, the business interface layer consists of the middle-tier interfaces that clients (such as the UI tier) use directly. The business interface layer defines the contract for the middle tier in ordinary Java interfaces; EJB is thus one implementation strategy. If we dont use EJB, the implementation of the business interfaces will be ordinary Java objects, running in a J2EE web container. When we do use EJBs, the implementations of the business interfaces will conceal interaction with the EJB tier.Important Design to Java interfaces, not concrete classes, and not technologies.Lets now look at four J2EE architectures that satisfy different requirements.Non-distributed ArchitecturesThe following architectures are suitable for web applications. They can run all application components in a single JVM. This makes them simple and efficient but limits the flexibility of deployment.Web Application with Business Component InterfacesIn most cases, J2EE is used to build web applications. Thus, a J2EE web container can provide the entire infrastructure required by many applications.J2EE web applications enjoy virtually the same access to enterprise APIs as EJBs. They benefit from the J2EE servers transaction management and connection pooling capabilities and can use enterprise services such as JMS, JDBC, JavaMail, and the Java Connector API. All data access technologies are available with the exception of entity beans.The web tier and middle tier of a web application run in the same JVM. However, it is vital that they are kept logically distinct. The main design risk in web applications is that of blurred responsibilities between UI components and business logic components.The business interface layer will consist of Java interfaces implemented by ordinary Java classes.This is a simple yet scalable architecture that meets the needs of most applications.StrengthsThis architecture has the following strengths:l Simplicity. This is usually the simplest architecture for web applications. However, if transaction management or threading issues require the development of unduly complex code, it will probably prove simpler to use EJB.l Speed. Such architectures encounter minimal overhead from the J2EE server.l OO design isnt hampered by J2EE component issues such as the implications of invoking EJBs.l Easy to test. With appropriate design, tests can be run against the business interface without the web tier.l We can leverage the servers transaction support.l Scales well. If the web interface is stateless, no clustering support is required from the container. However, web applications can be distributed, using server support session state replication.WeaknessesThe following drawbacks should be kept in mind:l This architecture supports only a web interface. For example, it cannot support standalone GUI clients. (The middle tier is in the same JVM as the web interface.) However, a layer of web services can be added, as we shall see later.l The whole application runs within a single JVM. While this boosts performance, we cannot allocate components freely to different physical servers.l This architecture cannot use EJB container transaction support. We will need to create and manage transactions in application code.l The server provides no support for concurrent programming. We must handle threading issues ourselves or use a class library such as util.concurrent that solves common problems.l Its impossible to use entity beans for data access. However, this is arguably no loss.Web Application that Accesses Local EJBsThe Servlet 2.3 specification (SRV.9.11), which can be downloaded from /products/servlet/download.html, guarantees web-tier objects access to EJBs via local interfaces if an application is deployed in an integrated J2EE application server running in a single JVM. This enables us to benefit from the services offered by an EJB container, without incurring excessive complexity or making our application distributed.In this architecture, the web tier is identical to that of the web application architecture weve just considered. The business interfaces are also identical; the difference begins with their implementation, which faces the EJB tier. Thus the middle tier is divided into two (business interfaces running in the web container and EJBs), but both parts run within the same JVM.Two approaches can be used to implement the business interfaces:l A proxy approach, in which a local EJB implements the business interface directly and web container code is given a reference to the EJBs local interface, without needing to handle the necessary JNDI lookup.l A business delegate approach, in which the web-container implementation of the business interfaces explicitly delegates to the appropriate EJB. This has the advantage of permitting caching and allowing failed operations to be retried where appropriate.We dont need to worry about catching java.rmi.RemoteException in either case. Transport errors cannot occur.In this architecture, unlike an architecture exposing a remote interface via EJB, the use of EJB is simply an implementation choice, not a fundamental characteristic of the architecture. Any of the business interfaces can be implemented without using EJB without changing the overall design.StrengthsThis architecture has the following strengths:l Its less complex than a distributed EJB application.l EJB use doesnt alter the applications basic design. In this architecture, only make those objects EJBs that need the services of an EJB container.l EJB use imposes relatively little performance overhead as there is no remote method invocation or serialization.l It offers the benefits of EJB container transaction and thread management.l It allows the use of entity beans if desired.WeaknessesIts drawbacks are as follows:l Its more complex than a pure web application. For example, it encounters EJB deployment and class loading complexity.l It still cannot support clients other than a web interface unless we add a web services layer.l The whole application still runs within a single JVM, which means that all components must run on the same physical server.l EJBs with local interfaces are hard to test. We need to run test cases within the J2EE server (for example, from servlets).l There is still some temptation to tweak object design as a result of using EJB. Even with local interfaces, EJB invocations are slower than ordinary method calls, and this may tempt us to modify the natural granularity of business objects.Note Sometimes we may decide to introduce EJB into an architecture that does not use it. This may result from the XP approach of doing the simplest thing that could possibly work. For example, the initial requirements might not justify the complexity introduced by EJB, but the addition of further requirements might suggest its use.If we adopt the business component interface approach described above, introducing EJBs with local interfaces will not pose a problem. We can simply choose the business component interfaces that should be implemented to proxy EJBs with local interfaces.Introducing EJBs with remote interfaces may be more problematic, as this is not merely a question of introducing EJB, but of fundamentally changing the nature of the application. For example, business interface granularity may need to be made more coarse-grained to avoid chatty calling and achieve adequate performance. We will probably also want to move all business logic implementation inside the EJB container.Distributed ArchitecturesThe following two architectures support remote clients as well as web applications.Distributed Application with Remote EJBsThis is widely regarded as the classic J2EE architecture. It offers the ability to split the middle tier physically and logically by using different JVMs for EJBs and the components (such as web components) that use them. This is a complex architecture, with significant performance overhead:Although the diagram shows a web application, this architecture can support any J2EE client type. It is particularly suited to the needs of standalone client applications.This architecture uses RMI between the UI tier (or other remote clients) and the business objects, which are exposed as EJBs (the details of RMI communication are concealed by the EJB container, but we still need to deal with the implications of its use). This makes remote invocation a major determinant of performance and a central design consideration. We must strive to minimize the number of remote calls (avoiding chatty calling). All objects passed between the EJB and EJB client tiers must be serializable, and we must deal with more complex error handling requirements.The web tier in this architecture is the same as in the ones weve discussed above. However, the implementations of the business interface will handle remote access to EJBs in the (possibly remote) EJB container. Of the two connectivity approaches we discussed for local EJBs (proxy and business delegate), only the business delegate is useful here, as all methods on EJB remote interfaces throw javax.rmi.RemoteException. This is a checked exception. Unless we use a business delegate to contact EJBs and wrap RMI exceptions as fatal runtime exceptions or application exceptions, RemoteExceptions will need to be caught in UI-tier code. This ties it inappropriately to an EJB implementation.The EJB tier will take sole charge of communication with EIS-tier resources, and should contain the applications business logic.StrengthsThis architecture has the following unique strengths:l It can support all J2EE client types by providing a shared middle tier.l It permits the distribution of application components across different physical servers. This works particularly well if the EJB tier is stateless, allowing the use of stateless session EJBs. Applications with stateful UI tiers but stateless middle tiers will benefit most from this deployment option and will achieve the maximum scalability possible for J2EE applications.WeaknessesThe weaknesses of this architecture are:l This is the most complex approach weve considered. If this complexity isnt warranted by the business requirements, its likely to result in wasted resources throughout the project lifecycle and provide a breeding ground for bugs.l It affects performance. Remote method calls can be hundreds of times slower than local calls by reference. The effect on overall performance depends on the number of remote calls necessary.l Distributed applications are hard to test and debug.l All business components must run in the EJB container. While this offers a comprehensive interface for remote clients, it is problematic if EJB cannot be used to solve every problem posed by the business requirements. For example, if the Singleton design pattern is a good fit, it will be hard to implement satisfactorily using EJB.l OO design is severely hampered by the central use of RMI.l Exception handling is more complex in distributed systems. We must allow for transport failures as well as application failures.When using this architecture, dont subvert it. For example, Sun Java Centers Fast Lane Reader J2EE pattern advocates performing read-only JDBC access from the web tier so as to minimize the overhead of calling through the EJB tier. This violates the principle that each tier should only communicate with those immediately above on beneath it. It also reduces the deployment flexibility that is a key virtue of the distributed architecture. Now servers running the web tier must be able to access the database, which may necessitate special firewall rules.Note Even if we use remote interfaces, most J2EE servers can optimize out remote invocations and substitute call by reference if EJBs and components that use them are collocated. This may greatly reduce the performance impact of using EJBs with remote interfaces but cannot undo the harmful effects that remote semantics introduce. This configuration changes the semantics of the application. For this configuration to be used, its vital to ensure that the EJBs support local invocation (by reference) and remote invocation (by value). Otherwise, callers by reference may modify objects to be passed to other callers with serious consequences.Important Do not let the use of EJBs with remote interfaces cause an application to be distributed unless business requirements dictate a distributed architecture.译文二J2EE项目的选择与风险企业级软件项目通常很大，成本也很高。它们面对的挑战可能会包括：l 集成一个组织内的资源。企业应用软件可能需要使用多种技术来访问多个数据源和遗留系统。多种技术的集成本身就是有风险的。l 处理像应用服务器和数据库之类的复杂产品。l 满足对服务、性能和可缩放性质量的苛刻期望值。l 开发和维护一个大型代码库。l 给一个组织引进新技术例如当给一个遗留应用软件赋予WEB能力时。有时，这些技术本身是新的，因而造成了它们可能是不熟悉或不成熟的风险。l 具有不同技能集的开发团队的成功运作。l 在一个竞争环境中实现快速的时间到市场。J2EE平台帮助我们解决了企业软件开发的许多问题。但是，选择J2EE仅仅是许多选择中的第一个。在开发周期的早期（编写任何代码之前）所做出的选择，对项目的成功与否以及投资的支配方式都有至关重要的影响。在项目的开始阶段所采取的决策将决定项目开展方式。对J2EE项目中的风险进行管理也是十分重要的，尤其是在涉及到集成的地方更是如此。在本章中，我们除了讨论J2EE项目中的软件体系结构之外，还讨论部分重要的选择。在这些选择中，有许多选择涉及到将随每个应用软件的需要而变化的折中方案。通常情况下，根本没有单一的“正确”答案。我们将尽量涵盖一些主要的问题，并讨论决策制定过程，但具体的选择将留给读者自己来做出。在有些项目中，这些选择中的许多选择将已成为J2EE策略的一部分。但是，参与此类项目的设计师和开发人员应该熟悉本章中所讨论的问题。依据规范版本开发一个策略要做出的第一个决策是贵组织对待规范和语言版本的态度。使用最新的J2EE和J2SE特性是重要的吗？这是增强特性集与成熟功能度之间的一个折中选择。决定性的因素将包括：l 该应用的性质小部分应用可能会从最新J2SE中获得如此之大的利益，一致没有可替代它们的方案。l 该项目的期限对于大型和期限长的项目来说，使策略依据新发布的特性并把应用中需要新作者：王毅周峰孙更新 来源：J2EE经典案例设计与实现，2007.4:179-181特性的那些部分推迟到服务器支持更成熟之后再实现是完全可行的。对于短期项目来说，快速交付一个使用成熟技术的解决方案是最重要的。需要注意的是，使用一个期限长的项目依据非定性J2EE规范中的新技术是非常危险的，因此是不妥当的，即使在存在“预览”实现时。例如，EJB2。0规范在后续的公开草案中发生了根本性的变化。l 该组织的性质一种“等到它工作为止”的方法可能适合对新技术非常看重的组织，但可能不适合金融机构或对可靠性要求很高的其他组织。该组织在新技术方面的技能基础在这里是另一个重要的考虑因素。l 应用服务器之间的可移植性越靠后采用规范版本，可移植性可能回越成问题，因为实现相同规范级别的可替代服务器的选择余地将会受限制。版本选择将既影响应用服务器选择，又受到应用服务器选择的影响。在大型项目开发期间，有新的服务器或规范版本发布是可能的。当出现这种情况时，决定是否升级也很重要。如果新版本是一个故障纠正或识别版本，它可能值得做并且不太贵。如果它是一个重要升级，在采用之前应该仔细考虑，因为可能存在许多稳情，比如不同的工具需求、新的服务器故障以及不同支持需求。跟上一个不断移动的目标是很困难的，而且J2EE仍然在快速地发展。要想最大限度地降低风险，应该避开未经证明的新技术，即使它们好象很有吸引力。一种安全的策略是在项目初期把J2SE和J2EE规范定为目标，因为它们得到了主流应用服务器开发商的支持，尽管有些项目可能需要考虑未来的服务器发布时间表。选择应用服务器选择一个J2EE应用服务器是一个组织将要做出的、最重要的IT决策之一。采用J2EE是一个战略性决策，因此怎样制定该决策将有一个长期的影响。许多应用服务器是很昂贵的，因而对大型安装来说，需要很大数目的许可费用。不过，服务器的成本只是一部分。即使在选择一个像JBOSS那样的免费服务器时，我们仍承担了很大的责任。超出许可费用或许可费用之外的开支可能包括：l 培训成本。服务器供应商通常提供产品特有的培训，而许多应用服务器复杂得足以保证为关键职员购买培训是值得的。不过，培训常常是很贵的，除非培训被提供为购买许可的一个激励品。l 咨询费用。在熟悉应用服务器时，从服务器供应商或第三方那里购买咨询服务可能是必不可少的。l 任何支持成本。对于某些供应商，支持需要另外一份合同，并加上许可成本。l 熟悉新服务器时生产力的损失，以及培训或知道期间开发人员时间的损失。了解服务器市场定位的好处是不同的服务器适合不同的需求。产品性能和价格的比较很快就会变得过时，并容易让人产生误解，而且无法以图书的形式保持最新。因此我们在这里将只讨论做选择时需要加以考虑的问题，而不是推荐或比较产品。在本节中，我们将了解如下内容：l 何时选择应用服务器l 如何选择应用服务器l 谁应该选择应用服务器需要注意的是，最终目的是整个组织在一个同意的应用服务器上的标准化。在整个软件周期内维护多个应用服务器将会是十分昂贵的，而且应该尽可能地避免。通常情况下，一个组织内使用几个不同的应用服务器反映了过去的事物或缺少一个连贯的策略。若一个组织内运行了多个应用服务器，少数几个正当的技术原因之一是，几个应用依赖于某一个特定的特性，而这个特性在通常使用的该应用服务器中是不可获得的。例如，一个应用需要来自J2EE最新版本中的特性，因此它必须运行在一个最近发布的应用服务器上时，而大多数应用却运行在一个已证明的应用服务器上。在这种情况下，长期目标通常将是恢复到单个服务器的使用。在许多情况下，应用服务器在项目开始以前将已被选定。例如，可能有一个关于应用服务器选择的组织级策略。在这种情况下，要尽量使用选定的服务器。不要引进另一个基于你或你的团队所喜爱的服务器，以免使组织的技术混合变得复杂。如果选定的产品确实很次，并且放弃它更有现实意义，要通过游说来改变该选择。外文原文（二）J2EE ProjectsChoices and RisksOverviewEnterprise software projects are often large and costly. The challenges they face may include:l Integrating resources within an organization. Enterprise applications may need to access multiple data sources and legacy systems, using a variety of technologies. Integration of multiple technologies is inherently risky.l Working with complex products such as application servers and databases.l Meeting demanding expectations of quality of service, performance, and scalability.l Developing and maintaining a large codebase.l Introducing new technologies to an organization for example, when a legacy application is web-enabled. Sometimes the technologies are themselves new, posing a risk that they may be unfamiliar or immature.l Successful running of teams with a disparate skill set.l Achieving rapid time-to-market in a competitive environment.The J2EE platform helps us to address many of the problems of enterprise software development. However, choosing J2EE is just the first of many choices.Choices made early in the development lifecycle before any code has been written have a vital influence on the success or failure of projects, and how investment is directed. Decisions taken in the inception phase of a project will determine how it unfolds.It is also vital to manage risk in J2EE projects, especially where integration is involved.In this chapter, we discuss some of the most important choices, besides software architecture, in J2EE projects. Many of these choices involve tradeoffs that will vary with the needs of each application. Often there is no single right answer. Well try to cover some major issues and discuss the decision making process, though particular choices will be left to the reader.In some projects, many of these choices will have already been made as part of an existing J2EE strategy. However, even architects and developers working on such projects should be familiar with the issues discussed in this chapter.Developing a Policy on Specification VersionsThe first decision to be made is your organizations attitude towards specification and language versions. Is it important to use the latest J2EE and J2SE features? This is a tradeoff between enhanced feature sets and proven functionality.Decisive factors will include:l The nature of the application A minority of applications may benefit so much from the latest J2SE and J2EE features that there is little alternative to using them.l The length of the project For a large and lengthy project, it may be possible to predicate strategy on new, published features and defer the implementation of those parts of the application that need them until server support is more mature. For a short project, it will be most important to deliver a solution quickly using proven technology. Note that predicating even a lengthy project on new features in non-final J2EE specifications is very risky, and therefore inadvisable, even when preview implementations exist. The EJB 2.0 specification, for example, changed radically in successive public drafts.l The nature of the organization A wait until it works approach might be appropriate for an organization that prizes technological firsts, but inappropriate for a financial institution or other organization in which reliability is critical. The organizations skill base in the new technologies is another important consideration here.l Portability between application servers The later the specification versions adopted, the more problematic portability is likely to prove, as the choice of alternative servers implementing the same specification level will be limited.Version choice will both influence and be influenced by the choice of application server.New server and specification releases are likely during the lifecycle of large projects. Its also important to decide whether to upgrade when this happens. If the new release is a bug fix or point release, it may be a worthwhile and inexpensive undertaking. If its a major upgrade, think carefully before committing, as there may be many implications, such as different tool requirements, new server bugs, and different support requirements. Its difficult to keep up with a moving target, and J2EE is still moving rapidly.Important To minimize risk, steer clear of new, unproven technologies, even if they seem attractive. One safe policy is to target the versions of the J2SE and J
- 温馨提示:
1: 本站所有资源如无特殊说明，都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
2: 本站的文档不包含任何第三方提供的附件图纸等，如果需要附件，请联系上传者。文件的所有权益归上传用户所有。
3.本站RAR压缩包中若带图纸，网页内容里面会有图纸预览，若没有图纸预览就没有图纸。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 人人文库网仅提供信息存储空间，仅对用户上传内容的表现方式做保护处理，对用户上传分享的文档内容本身不做任何修改或编辑，并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容，请与我们联系，我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
人人文库网所有资源均是用户自行上传分享，仅供网友学习交流，未经上传用户书面授权，请勿作他用。
川公网安备: 51019002004831号