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

　　为实现此目的，企业应用程序供应商正积极考虑将表示层代码置于最终用户的机器中，以便完全或部分消除 HTML 的两个主要缺点。这创造了一些有趣的部署暗示，但许多商店正寻求同时创建瘦客户端和富客户端表示层—富客户端用于公司防火墙的内部，而瘦客户端用于公司的外部（再次证明您不能太富或太瘦）。此方法招致了必须处理两个不同框架的麻烦，但至少我们愿意拥有一种将数据从用户输入传递到后端存储库的统一方法，而且最好能够针对“富”客户端和“瘦”客户端将这种传递进行某种形式的标准化 — 由此便产生了 JSR 227，一个通用的数据绑定框架。

　　“我们愿意拥有一个将数据从用户输入传递到后端存储库的统一方法；因此，便产生了 JSR 227。”

　　聚合器正如系统可以提供多个“入口点”一样，如果您愿意，系统还可以建立在多个后端的基础上，从而从不同的资源收集数据并按一致和有意义的方式显示它。（既然显示和操作的数据是多个资源/数据库的聚合，因此也就有了术语“聚合器”。）并且，在开始创建此聚合数据的操作和存储用例的 30 秒之后，显而易见的是，必须使用某种类型的原子性以便两个数据库所做的修改保持同步。这正是 Java 事务 API（以及它之前的 X/A 规范）的用途，而事务处理和业务逻辑的交叉部分则是 EJB 产生的原因。

　　但它不仅仅是事务。多个资源所带来的不仅仅是两个不同的数据库 — 有时，系统需要的可靠性要高于单个数据库机器所能提供的可靠性。毕竟，系统中任何位置的单个机器只表示单个故障点，而且通常情况下（除所有“热交换”故障切换情况以外），我们只需关闭数据库以对其执行某些预定的维护 — 可能包括新的模式更改以满足代码变换。Java 命名和目录接口 (JNDI) 用作所有“查找”操作的单个 API，从实际底层物理数据库机器中提供一个间接层，这意味着如果不缓存 JNDI 查找结果，则管理员可以更改 JNDI 入口，以从一台机器指向不同的机器，同时 J2EE 应用程序将简单地进行相应的调整，从而将创建一个无缝和透明的指向新数据库的“开关”，这在没有间接层的情况下是无法实现的。