5. 创建您所知道的。
反复的开发工作将使您能够逐渐地掌握所有的 J2EE 模块。要从创建小而简单的模块开始而不是从一开始就马上涉及到所有的模块。
我们必须承认 J2EE 是庞大的体系。如果一个开发小组只是开始使用 J2EE，这将很难一下子就能掌握它。在 J2EE 中有太多的概念和 API 需要掌握。在这种情况下，成功掌握 J2EE 的关键是从简单的步骤开始做起。
这种方法可以通过在您的应用程序中创建小而简单的模块来得到最好的实现。如果一个开发小组通过创建一个简单的域模型以及后端的持久性机制（也许使用的是 JDBC）,并且对其进行了完整的测试，这会增强他们的自信心，于是他们会使用该域模型去掌握使用 servlet 和 JSP 的前端开发。如果一个开发组发现有必要使用 EJB，他们也会类似地开始在容器管理的持久性 EJB 组件之上使用简单的会话 Facades，或者使用基于 JDBC 的数据访问对象（JDBC-based Data Access Objects，DAO），而不是跳过这些去使用更加复杂的构造（例如消息驱动bean和JMS）。
这种方法并不是什么新方法，但 是很少有开发组以这种方式来培养他们的技能。相反地，多数开发组由于尝试马上就构建所有的模块，同时涉及 MVC 中的视图层、模型层和控制器层，这样做的结果是他们往往会陷入进度的压力之中。他们应该考虑一些敏捷（Agile）开发方法，例如极限编程（XP），这种 开发方法采用一种增量学习及开发方法。在 XP 中有一种称为 ModelFirst 的过程，这个过程涉及到首先构建域模型作为一种机制来组织和实现用户场景。基本说来，您要构建域模型作为您要实现的用户场景的首要部分，然后在域模型之上 构建一个用户界面（UI）作为用户场景实现的结果。这种方法非常适合让一个开发组一次只学到一种技术，而不是让他们同时面对很多种情况（或者让他们读很多 书），这会令他们崩溃的。
还有，对每个应用程序层重复的开发可能会包含一些适当的模式及最佳实践。如果您从应用程序的底层开始应用一些模式如数据访问对象和会话 Facades，您就不应该在您的JSP和其他视图对象中使用域逻辑。
最后，当您开发一些简单的模块时，在开始的初期就可以对您的应用程序进行性能测试。如果直到应用程序开发的后期才进行性能测试的话，这往往会出现灾难性的后果。
6. 当使用 EJB 组件时，始终使用会话 Facades。
决不要将实体 bean 直接暴露给任何用户类型。对实体 bean 只可以使用本地 EJB 接口（Local EJB interfaces）。
当使用 EJB 组件时，使用一个会话 Facades 是一个确认无疑的最佳实践。实际上，这个通用的实践被广泛地应用到任何分布式的技术中，包括 CORBA、EJB 和 DCOM。从根本上讲，您的应用程序的分布"交叉区域"越是底层化，对小块的数据由于多次重复的网络中继造成的时间消耗就越少。要达到这个目的的方法就 是：创建大粒度的 Facades 对象，这个对象包含逻辑子系统，因而可以通过一个方法调用就可以完成一些有用的业务功能。这种方法不但能够降低网络开销，而且在 EJB 内部通过为整个业务功能创建一个事务环境也可以大大地减少对数据库的访问次数。
EJB 本地接口（从 EJB 2.0 规范开始使用）为共存的 EJB 提供了性能优化方法。本地接口必须被您的应用程序显式地进行访问，这需要代码的改变和防止以后配置 EJB 时需要应用程序的改变。由于会话 Facades 和它包含的整个 EJB 对于彼此来说都应该是本地的，我们建议对会话 Facades 后面的实体 bean 使用本地接口。然而，会话 Facades 本身的实现（典型例子如无状态会话 bean）应该设计为远程接口。
为了性 能的优化，可以将一个本地接口添加到会话 Facades。这样做利用了这样一个事实：在大多数情况下（至少在 Web 应用程序中），您的 EJB 客户端和 EJB 会共同存在于同一个 Java 虚拟机（JVM）中。另外一种情况，如果会话 Facades 在本地被调用，可以使用 J2EE 应用服务器配置优化（configuration optimizations），例如 WebSphere 中的"No Local Copies"。然而，您必须注意到这些可供选择的方案会将交互方法从按值传递（pass-by-value）改变为按引用传递（pass-by- reference）。这可能会在您的代码中产生很微妙的错误。当您要利用这些方案时，您应该在一开始就考虑其可行性。
如果在您的 会话 Facades 中使用远程接口（而不是本地接口），您也可以将同样的会话 Facades 在 J2EE 1.4 中以兼容的方式作为 Web 服务来配置。这是因为 JSR 109（J2EE 1.4 中的 Web 服务部署部分）要求使用无状态会话 bean 的远程接口作为 EJB Web 服务和 EJB 实现的接口。这样做是值得的，因为这样做可以为您的业务逻辑增加客户端类型的数量。
7. 使用无状态会话 bean，而不是有状态会话 bean。
这样做可以使您的系统经得起错误的终止。使用 HttpSession 存储和用户相关的状态。
以我们的观点看来，有状态会话 bean 的概念已经过时了。如果您仔细对其考虑一下，一个有状态会话 bean 实际上与一个 CORBA 对象在体系结构上是完全相同的，无非就是一个对象实例，绑定到一个服务器，并且依赖于服务器来管理其生命周期。如果服务器关闭了，这种对象也就不存在，那 么这个 bean 的客户端的信息也就不存在。
J2EE 应用服务器为有状态会话 bean 提供的故障转移（failover）能够解决一些问题，但是有状态的解决方案没有无状态的解决方案易于扩展。例如，在 WebSphere Application Server 中，对无状态会话 bean 的请求，是通过对部署无状态会话的成员集群进行平衡加载来实现。相反地，J2EE 应用服务器不能对有状态 bean 的请求进行平衡加载。这意味着您的集群中的服务器的加载过程会是不均衡的。此外，使用有状态会话 bean 将会再添加一些状态到您的应用服务器上，这也是不好的做法。这样就增加了系统的复杂性，并且在出现故障的情况下使问题变得复杂化。创建健壮的分布式系统的 一个关键原则是尽量使用无状态行为。
因此，我们建议对大多数应用程序使用无状态会话 bean 方法。任何在处理时需要使用的与用户相关的状态应该以参数的形式传送到 EJB 的方法中（并且通过使用一种机制如 HttpSession 来存储它）或者从持久性的后端存储（例如通过使用实体 bean)作为 EJB 事务的一部分来进行检索。在合适的情况下，这个信息可以缓存到内存中，但是要注意在分布式的环境中保存这种缓存所潜在的挑战性。缓存非常适合于只读数据。
总之，您要确保从一开始就要考虑到可伸展性。检查设计中的所有设想，并且考虑到当您的应用程序要在多个服务器上运行时，是否也可以正常运行。这个规则不但适合上述情况的应用程序代码，也适用于如 MBean 和其他管理界面的情况下。
避免使用有状态性不只是对 IBM/WebSphere 的建议，这是一个基本的 J2EE 设计原则。
8. 使用容器管理的事务。
学习一下 J2EE 中的两阶段提交事务，并且使用这种方式，而不是开放您自己的事务管理。容器在事务优化方面几乎总是比较好的。
使用容器管理的事务（CMT）提供了两个关键的优势（如果没有容器支持这几乎是不可能的）：可组合的工作单元和健壮的事务行为。
如果您的应用程序代码显式地使用了开始和结束事务（也许使用 javax.jts.UserTransaction 或者甚至是本地资源事务），而将来的要求需要组合模块（也许会是代码重构的一部分），这种情况下往往需要改变事务代码。例如，如果模块 A 开始了一个数据库事务，更新数据库，随后提交事务，并且有模块 B 做出同样的处理，请考虑一下当您在模块 C 中尝试使用上述两个模块，会出现什么情况呢？现在，模块 C 正在执行一个逻辑动作，而这个动作实际上将调用两个独立的事务。如果模块 B 在执行中失败了，而模块 A 的事务仍然能被提交。这是我们所不希望出现的行为。如果，相反地，模块 A 和模块 B 都使用 CMT 的话，模块 C 也可以开始一个 CMT（通常通过配置描述符），并且在模块 A 和模块 B 中的事务将是同一个事务的隐含部分，这样就不再需要复杂的重写代码的工作了。
如果您的应用程序在同一个操作中需要访问多种资源，您 就要使用两阶段提交事务。例如，如果从 JMS 队列中删除一个消息，并且随后更新基于这条消息的纪录，这时，要保证这两个操作都会执行或都不会执行就变得尤为重要。如果一条消息已经从队列中被删除，而 系统没有更新与此消息相关的数据库中的纪录，那么这种系统是不稳定的。一些严重的客户及商业纠纷源自不一致的状态。
我们时常看到一 些客户应用程序试图实现他们自己的解决方案。也许会通过应用程序的代码在数据库更新失败的时候 "撤销"对队列的操作。我们不提倡这样做。这种实现要比您最初的想象要复杂得多，并且还有许多其他的情况（想象一下如果应用程序在执行此操作的过程中突然 崩溃的情况）。作为替代的方式，应该使用两阶段提交事务。如果您使用 CMT，并且在一个单一的 CMT 中访问两阶段提交的资源（例如 JMS 和大多数数据库），WebSphere 将会处理所有的复杂工作。它将确保整个事务被执行或者都不被执行，包括系统崩溃、数据库崩溃或其他的情况。其实现在事务日志中保存着事务状态。当应用程序 访问多种资源的时候，我们怎么强调使用 CMT 事务的必要性都不为过。
