精通J2EE应用程序开发之交叉分析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 中编写存储过程，从而简化了存储过程的编写。