精通J2EE应用程序开发之交叉分析J2EE - 编程入门网
| 存储库的统一方法，而且最好能够针对“富”客户端和“瘦”客户端将这种传递进行某种形式的标准化 — 由此便产生了 JSR 227，一个通用的数据绑定框架。
“我们愿意拥有一个将数据从用户输入传递到后端存储库的统一方法；因此，便产生了 JSR 227。” 聚合器正如系统可以提供多个“入口点”一样，如果您愿意，系统还可以建立在多个后端的基础上，从而从不同的资源收集数据并按一致和有意义的方式显示它。（既然显示和操作的数据是多个资源/数据库的聚合，因此也就有了术语“聚合器”。）并且，在开始创建此聚合数据的操作和存储用例的 30 秒之后，显而易见的是，必须使用某种类型的原子性以便两个数据库所做的修改保持同步。这正是 Java 事务 API（以及它之前的 X/A 规范）的用途，而事务处理和业务逻辑的交叉部分则是 EJB 产生的原因。 但它不仅仅是事务。多个资源所带来的不仅仅是两个不同的数据库 — 有时，系统需要的可靠性要高于单个数据库机器所能提供的可靠性。毕竟，系统中任何位置的单个机器只表示单个故障点，而且通常情况下（除所有“热交换”故障切换情况以外），我们只需关闭数据库以对其执行某些预定的维护 — 可能包括新的模式更改以满足代码变换。Java 命名和目录接口 (JNDI) 用作所有“查找”操作的单个 API，从实际底层物理数据库机器中提供一个间接层，这意味着如果不缓存 JNDI 查找结果，则管理员可以更改 JNDI 入口，以从一台机器指向不同的机器，同时 J2EE 应用程序将简单地进行相应的调整，从而将创建一个无缝和透明的指向新数据库的“开关”，这在没有间接层的情况下是无法实现的。 集成器 当需要连接两个单独维护的业务逻辑集合时，集成器系统将发挥作用，并且必须开始考虑烟囱系统从不需要的互操作性。例如，如果必须执行传统的请求-响应服务，那么如何执行请求和响应？开发人员通常立刻求助于 WS-* 服务，但如上所述，WS-* 规范有时太多（并且在当前实现中太不成熟），以至于无法可靠地满足集成/互操作性的需要。而 J2EE 规范通过要求每个 EJB 容器符合 CORBA 调用（意味着任何 CORBA 客户端可以与 EJB 容器中封装的业务逻辑交互）再次满足了此需要。 但并非所有集成均以请求-响应的方式进行。为避免 RPC 和请求-响应通信的异步本质中暗藏的瓶颈，许多系统选择使用基于消息的方法相互集成。基于消息的方法是 Java 消息服务规范（以及关联的实现，如 Oracle 的高级队列）以及/或 Java API for XML Messaging (JAXM) 及其关联的 SOAP API for Attachments in Java (SAAJ)（用于执行“使用尖括号的消息传递”）的用武之地。 数据库本身还用作集成层，但与传统 RPC 或消息驱动系统并不相同。很多情况下，集成和互操作性仅仅体现在将程序“A”中的数据传递到程序“B”，而数据库（以及其他资源）通常用作不同平台（尤其是 J2EE 和 .NET）的有用（和理解充分）的中介语言。尽管它并不满足所有互操作性的需要，但对于许多系统而言，此方法刚好满足需要 — 它具有自身的好处，尤其是当业务逻辑（通过存储过程）嵌入到数据库中时。此外，.NET 无需了解如何调用驻留在 EJB 服务器中的 Java 代码，Java 也无需了解如何调用驻留在 COM+ ServicedComponent 中的 .NET 代码，或如何在两者之间共享单个分布式事务 ID，等等。尤其是考虑到这样一个事实：Oracle 允许您在 Java 而非 PL/SQL 中编写存储过程，从而简化了存储过程的编写。 企业应用程序 最后，我们了解一下“真正的”企业应用程序，它是以下三个层的多个 facet 的融合：表示层、逻辑层和数据访问层。传统的 |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
