精通J2EE应用程序开发之交叉分析J2EE

　　当出现多个数据库或其他后端问题时，请考虑故障可分性和使用分布式事务实现可分性的需要，以及拥有一个良好的间接可热交换层来访问资源的故障切换建议。当现有系统之间的集成成为问题时，请记住除 Web 服务以外还有很多选择（尽管 Web 服务方法比较实用并且通常被看作是标准），并记住消息驱动的系统以及是否可以将业务逻辑置于数据库本身中以便其他需要与该系统交互的平台更容易地访问此数据库。

　　请记住，J2EE 只是用于实现某个目标的方法，对于任何技术的武断看法通常将失去技术作为总体的意义。例如，不要试图在烟囱系统上使用 EJB，这是因为 EJB 主要适用于事务处理（尤其是两个阶段的提交事务处理，此种事务处理比较占用资源并且必须在作为同一事务一部分的两个或更多资源中获取可分性），但当聚合器应用程序依靠您执行操作时不要忽略它的使用。当 JMS（和消息驱动 bean，当需要事务处理时）的异步本质更适合于此目的时，不要尝试将所有内容编写为会话 bean。等等。

　　其次，一定要始终确切地牢记应用程序的性能和可伸缩性目标（参见我的《高效企业 Java》一书）。尽管这对于以任何语言编写的任何应用程序通常都很重要，但在企业 Java 领域中更重要，这是因为企业 Java 开发人员有那么多的技术可以选择。您的系统需要为每个用户操作提供亚秒级响应？基于浏览器的应用程序（尤其是跨广域网应用程序）很难实现此目标，这是因为 HTML 浏览器通常需要大约一秒的时间来处理甚至是中等复杂的 HTML 页；或许一个更好的方法是考虑通过 JavaWebStart 提交的“富客户端”前端，以便使跨网络传送的数据数量尽可能得小，以及接收数据的时间尽可能得短（以避免分析表示元素）。

　　是否需要在整个互联网上拥有预测的 100 万个用户？用户界面肯定需要改变，而 Java 在普通用户的 PC 上的低普及率使 WebStart 并不切合实际，或许 applet 或传统的 HTML 更为合适。但扩展到此用户数目意味着开发人员需要特别留意在高峰负载下每个请求的响应时间，或许以不同的方式构建用户界面可以避免频繁的服务器回程。等等。

　　第三，请记住，Java 开发人员的工具套件在不断的改进，过去五年中的大部分工作一直在朝 J2EE 领域的方向进行，想方设法使定义 J2EE 组件更简单、更容易。大型商业供应商在该领域的优势超过开源项目，这是因为供应商可以围绕他们的商业服务创建完整的端到端开发经历，其中开放源项目只是浅尝辄止。例如，将 Oracle ADF 中提供的某些新功能与尝试在 Eclipse 中构建 JSF 应用程序进行比较。或者，将在 JDeveloper 中定义 Web 服务与在 Axis 编写 .wsdd 文件进行对比。工具越来越完善，我们只能期望此趋势得以继续，因为这要看供应商有没有兴趣使其继续了。 “工具越来越完善，我们只能期望此趋势得以继续，因为这要看供应商有没有兴趣使其继续了。”

　　最后但并非不重要的，在本系列的后续文章中留意此技术领域，这些后续文章将介绍从建模和设计到调试以优化/监视代码（这将比您现在定义的性能和可伸缩性目标简单很多）等主题。

　　最重要的是要放松。生命太短暂了。

　　结论

　　尽管企业 Java 领域有时像一组令人眼花缭乱的规范、实现，而实际上似乎迎合短暂流行风格的各种标准和框架已经做好充分的准备并意识到，对于五种类型的应用程序的任何一种而言，任何可用的 Java/J2EE 技术都可以工作（并出色地工作）。