英语原文共 10 页，剩余内容已隐藏，支付完成后下载完整资料
Using J2EE on a large, Web-based project
java2企业版是一个面向对象的企业应用开发工具，在本文中，作者叙述了自己在大型企业网络应用开发中使用J2EE技术时的经验与教训。
建立大型的，多层的，基于Web的应用程序需要一系列的软件服务，从动态HTML生成到商业领域工程的构建。与从零开始开发一个工程相比，设计者发现使用标准的，开源的框架更有效率。Sun公司提出的J2EE框架在这些java编程语言中提供了一个规范的，标准的接口。J2EE技术使软件供应商提供了具有竞争力的实现方法。这反过来促使应用开发者自由选择服务的实现方法，这可以是开发者集中精力与代码的编写。
我们所描述的项目是为一个世界财富榜前100的客户开发的基于网络的企业软件系统。我们使用J2EE技术开发了一系列内容包括JavaBeans（EJBs）和Java服务器页面（JSPs），这个系统大约包含700kLOC，5600个类，和500个JSP页面。这个工程我们连续开发了3年，目前为止我们的客户已经正常使用了两年。
我们把这项工程横向的分为三层：
- 表示层，该层驱动用户界面。
- 会话层，该层管理用户的工作空间和会话业务逻辑。
- 实体类层，它处理持久性和实体业务逻辑。
这个系统的前段是一系列JSP页面，每个页面都对应了一个“display bean”以提供定义和表示显示逻辑。这些display bean通过会话层加载管理的XML传输对象来访问和更新数据。这个系统还可以通过网络整合一系列外部服务。
接下来，我们讨论一下在处理5个关键的开发主题时的经验和教训，它们包括：J2EE HTML渲染技术，JSP国际化，外部系统集成，在使用XML数据传输对象和用代码维护复杂的实体对象的层间共享信息。
一 J2EE HTML渲染技术
大部分互联网应用使用HTML来渲染用户界面，Java系统通常使用servlet，jsp，或者两者结合动态生成HTML。
我们的解决方法：
我们决定仅仅使用JSP页面基于多个原因。第一，把开发角色分开有一些经常被引用的的好处：一些灵活可靠且相对便宜的开发者可以使用静态JSP，同时另一些昂贵的Java项目可以在后端使用动态内容。然而，在实际的开发过程中分离被证明是不那么重要。一个内部业务应用程序的界面设计的要求通常比一些公开的网站要低，所以我们并不需要一个图形界面设计团队。因此，我们鼓励我们的技术人员研究各个层面的技术，从HTML到体系结构，只有少部分专攻图形设计。
另一方面，我们计划编写即使在工程结束后客户依然能修改这些设计的页面。所以，在开发过程中角色分离就不是那么重要了。我们预期在以后的维护过程中客户可以轻松地修改项目内容以适应不同业务的需要。
最后，一个模板样式的前端更容易工作和测试。当HTML和动态数据混合在Java代码中时，观察程序和HTML的输出流是一件非常困难的事。同时，这样也很难调试静态HTML或者在不打破HTML的同时修改代码。
经验：
经过两年多的JSP使用，我们的经验已经混合了。尽管JSP技术允许Java从HTML分离，但它不能执行它。开发者还可以把Java代码段（称为脚本）嵌入JSP中或者编写display-bean方法，从而产生HTML并且从JSP中调用。事实上，在自定义标签出现前，很多任务在不借助HTML和脚本的情况下是几乎不可能完成的。我们仍然在重构我们的一些旧的JSP页面和display beans从而使HTML和Java分离。
我们确实在快速定义原型上取得了优势。使用标准HTML编辑器，我们可以快速创建原型屏幕，然后将生成的HTML文件重命名为JSP，然后把它连接到display bean。
我们还了解到一些数据关于JSP技术是否适用于不同类型的页面。JSP模型对于填充由静态HTML及从应用程序中取得的数据填充的页面是十分优秀的。然而，JSP是不够的，需要不同的条件下，不同的布局或设计高度动态的页面。对于中度不同结构的页面，你必须使用HTML和Bean方法或者控制了页面显示内容的脚本。对于更大的变化，通常需要导入或包含，它包含了其他困难，比如语法上保持有效的HTML输出。他们还强迫你处理Bean的隐含依赖和各种共享或者喷涌的样式表。
二 JSP国际化
许多商务应用程序必须把内容提供给多个国家的用户，因此必须显示多种格式的数据。有时这和使用不同的货币与日期格式一样简单，另外一些情况下，它的逻辑差别实在太大以至于需要一个看起来完全分离的应用。
国际化要求我们扩展应用程序到加拿大和澳大利亚，我们需要的表示层功能与欧洲版本相似。由于不同国家地区的商业政策和法律法规不同，大多数应用都有轻微的差异。我们的主要设计抉择在于是否：
- 编写一个个不同的JSP以应对每一个国家的版本。（整体方法）
- 为每个国家的JSP写一个单独的版本。（量身定制的方法）
我们的解决方法：
最初，我们选择了量身定制的方法。我们有三个主要的原因：严格的时间限制，开发者的个人偏向和我们暂时无法升级JSP容器去支持自定义标签。没有了自定义标签，整体的设计方法会要求我们在每一个局部格式输入，表格和超链接上使用脚本。正如我们前面提到的，脚本会快速混乱的是一个JSP变得难以管理。如果我们扩大到支持5个或者10个不同的国家，整体设计方法会使JSP变得过于复杂难以阅读，以至于我们不得不把JSP为每一个国家分解成一个个单独的版本。此外，如果一旦它变得那么复杂，分离JSP却不出错是非常困难的。
经验：
我们很快就意识到，量身定制的方法有严重的问题：系统更新的时候很容易漏掉某一个国家的版本，因为我们的系统有太多的JSP，保持他们的同步几乎是不可能的。即使只有三个国家，维护也变成了一场噩梦。
一旦我们升级了servlet容器去支持自定义标签，我们找到了一个解决问题的方法。自定义标签提供了一个简单的，干净的方式来定义共享JSP的行为。这使我们整合不同地区的版本成了一个便于阅读和修改的JSP。因为自定义标记可以有选择地包括或排除一个JSP部分，我们就不需要很多越来越复杂的脚本。所以，取代了整体设计的充斥着脚本的JSP的是：
lt;%if(bean.getLocalization().equals(Localization.CANADA)||bean.getLocalization().equals(Localizations.US)){%gt;Canada or US-only HTMLlt;% } %gt;
我们用了一个简单的自定义标签：
lt;localize show=“CA,US”gt;
Canada or US-only HTML
lt;/localizegt;
这个例子是一个典型的标签使用方法。自定义标签不仅避免了代码的膨胀，而且我们猜想把这个自定义标签扩展到10个国家会变得更加容易。到目前为止，自定义标签已经被证明足以应对国际化需要。
然而，我们可以清晰地预见到，想要清楚的捕获这些不同版本的页面将会比较困难。在这些情况下，我们可以每个国家一个JSP的方法，有大量变化的就包含这些JSP，否则就使用自定义标签。问题是开发者在编辑一个简单的静态页面时必须跟踪多个文件的内容。或许研究者某天可以开发出一个工具可以让程序员一次开发完成全部国家的版本，同时在所有国家中保持数据不变。
三 整合第三方软件
极少数企业应用程序可以自主运行，大多数必须连接到现有的系统。鉴于这样的系统往往是过时的，使用专有的接口，或简单地使用了一个有点不兼容的技术，这种集成往往很不容易。
我们客户的业务领域需要复杂的计算。我们的应用程序通过提供了整合第三方的财务软件，这将把这里作为TPS（第三方软件）。第三方供应商最初写TPS目的是作为一个独立的应用程序。客户想要把第三方软件和我们的系统集成起来以简化版本管理和其它第三方软件的接口。
我们的解决方法：
首先，第三方供应商提供给我们一个动态链接库（DLL）文件，暴露了TPS的对象的一个子集，通过微软的组件对象模型（COM）。为了驱动这个动态链接库我们写了一个由两个成分组成的适配器：一个服务器和一个池。
为了进行财务计算，主程序要发送XML去描述金融参数和所需的TPS适配器的服务器组件的计算结果。然后多线程的服务器组件将此XML请求传递给翻译组件。该组件将XML转换成一系列的TPS库的COM调用，并返回XML格式的结果。服务器组件保持一组翻译控件，由于TPS动态链接库不是线程安全的，每一个翻译组件都运行在各自的Java虚拟机上。我们发现使用多个线程来处理一个以上的请求可以提高性能。
经验：
在把TPS整合到网络应用的过程中产生了一系列的挑战。主要的问题是，有成千上万的TPS的输入参数。虽然我们不使用它们，但我们使用的子集本身可以产生大量的参数组合。没有错误的再现这多的功能是很难的，特别是因为我们没有使用相同的TPS链接库接口作为独立的TPS。因为以前没有人在复杂的TPS库中使用过COM接口，我们不可避免地要以意想不到的方式使用适配器软件。结果是，翻译过程偶尔崩溃，有时在不可重复的方式。为了防止这些因素导致TPS应用崩溃，我们给服务组件添加了重启子程序的功能。在这种情况下，它会重复请求一次，只有在同一个请求的过程中两次失败的情况下才会报错。对于不可重复的崩溃，第二次请求会返回详细情况。对于可重复的崩溃，这种策略避免了翻译池的出错。此外，我们的服务器组件在每次成功计算后重新启动翻译过程也是如此。这消除了由于内存泄漏或第三方DLL（这很少，但不可预知的出现）变量的初始化产生的任何问题。成本是一个小小的性能损失。然而，这种选择，再加上要求服务器组件复活子进程，保证了TPS财务计算引擎在很长的时间周期仍然可用。
测试应用程序引起了其他挑战。因为COM对象有复杂的相互依存关系，这是很常见的问题域，因为编写是独立的，细粒度的单元测试是困难的。相反，我们选择了一组回归测试，每个XML由输入和预期XML输出组成。这些测试是相当简单的自动化和自然产生的，因为我们可以从中检索我们的应用程序的日志中的XML。它们也易于使用可扩展样式表语言转换（XSLT文件）来维持。然而，他们需要更长的时间进行单元运行测试，所以我们不经常运行它们，每天一次而不是每小时，这意味着我们捕获回归误差仅在每天。但是，因为只有一个或两个人同时在TPS适配器上工作，我们还没有发现这是一个问题。
由于复杂的TPS COM对象的相互依存关系，供应商提供DLL需要大量的质量保证：该供应商增加新的功能，将结果发送给我们，我们用我们的回归测试套件，以确保没有其他改变。幸运的是，我们与供应商的关系良好，而且他们一直快速处理我们的错误修复请求。尽管如此，这种来回通信花费了大量的时间。理想情况下，测试应该配合供应商的开发工作，使反馈更加迅速。
为了解决这个问题，我们正在从TPS COM接口朝向XML接口远离。使用XML接口，只有一个具有单独方法COM对象来接受XML输入并返回XML输出。现在，供应商的软件转换XML为库函数调用。当我们发现一个bug，我们简单地把他们暴露在其输入的XML。他们可以很容易地处理该XML的调试环境并追查原因。此外，供应商可以维护一组反映了我们应用程序如何使用TPS的回归测试并把这些测试纳入其QA流程。我们希望这大大减少把附加的TPS功能集成到我们的应用程序需要的时间。
四 分布：XML数据传输对象
为了方便各层之间的信息流、多层次、分布式企业应用程序通常使用数据传输对象的设计。DTO封装了一组参数，一个组件发送或返回到另一个组件来完成单个远程方法调用（比如我们的主要应用TPS的计算要求）。在我们的应用中，一个对象调用一个XML翻译构建了一个基于XML的DTO在域对象层的数据并把它运送到会话或表示层，使得一个数据得到轻量级的封装。使用的DTO防止锁定问题，网络繁琐，并频繁调用对实体bean。
在我们的项目早些时候，DTO是绝对必要的，因为生产EJB和servlet容器都在不同的城市，以及依靠直接访问实体Bean的网络延迟太大了。使是现在，在同一个JVM上运行的服务器，为每个方法调用一个新的连接依然花费不小。
我们的解决方法：
对于我们的DTO，我们选择了混合XMLJava对象的方法：XML文档中包含数据，并通过易于访问的Java类包装。无论从域对象的数据建立的DTO和保存修改的DTO回域对象都在在会话层中运行，并执行DTO域对象映射翻译。
我们也可以用部分元素树构造DTO表示层。当翻译这样存在的DTO时，它仅更新包含域对象的更新值的那些领域。这让客户只需要简单更新一些领域，而不是把一个大的域对象图转换为XML，修改一个或两个字段，然后保存整个XML回域对象。
我们生成一个示例XML文档中的Java包装类。我们不生成翻译，因为数据往往需要以不同的形式在表示层而不是对象层中，并且我们想要控制翻译。在个人领域的水平，我们经常使用不同的数据类型。例如，我们定义了什么可能在XML的地位关键字是数据库中的一个整数状态ID（“进行中”，“已过期”或“取消”），并可能是什么数据库可以在一个SQL日
全文共8401字，剩余内容已隐藏，支付完成后下载完整资料
资料编号：[154866]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
