|
J2EE集成企业应用程序 |
作者：未知 发布时间：2005-03-12 来源：JSP天空网
|
把这些企业技术结合起来使 EAI 更容易进行
Daniela Rudrof（Daniela.Rudrof@de.ibm.com），IT 专家，IBM Security Operations
Andre Tost（atost@us.ibm.com），解决方案设计师，IBM WebSphere Business Development Group
2002 年 11 月
一段时间以来，IT 员工已经能够使用 Java 2 平台，企业版（Java 2 Platform, Enterprise Edition（J2EE））的元素集成后端系统了。最近出现的 Web 服务技术已经使我们能够用一些以前想不到的新方法来实现类似的目的。在本文中，Andre Tost 和 Daniela Rudrof 向您说明了如何结合 J2EE 和 Web 服务使企业应用程序集成（enterprise application integration（EAI））变得更轻松。您还将看到如何把 Java 消息传递服务（Java Messaging Service）和 Java 2 连接器体系结构（Java 2 Connector Architecture）与 Web 服务技术一起使用使集成过程达到一个新的抽象层次。
目前，开发者要在应用程序集成方面花费很多精力和资源。这包括把新应用程序与先前已有的应用程序集成在一起以及使现有的应用程序互相通信 ? 同时所有这些工作都尽量使这些应用程序的更改达到最少。通常情况下，这类集成被称为企业应用程序集成或 EAI。目前市场上有几种产品可以使 EAI 的过程更轻松。大多数情况下，企业是通过构建一个中间件基础架构和几个适配器（这些适配器允许不同的后端应用程序插入到一个某种类型的公共协议，从而互相交换数据）来实现集成。
Java 2 平台，企业版（J2EE）满足了用一种健壮的、安全的、事务性的方法在 Web 上提供现有的应用程序和业务流程的需要。J2EE 环境下已经建立了几个规范，最值得注意的是 Java 消息传递服务（JMS）和 Java 2 连接器体系结构（JCA），这些规范主要用来把 J2EE 应用程序与非 J2EE 环境集成在一起。另外，Web 服务技术最近在集成领域引起了许多关注，因为它们定义了一些通用的方法使应用程序可以跨异构编程语言和操作系统互相交互。这一点成为可能是因为 Web 服务使用 XML 作为它们的数据格式基础，将其用于描述特定的服务（即 Web 服务定义语言（Web Services Definition Language）或称 WSDL）或实际调用服务（即简单对象访问协议（Simple Object Access Protocol）或称 SOAP）。
在本文中，您将学到如何利用 J2EE 集成技术（特别是 JMS 和 JCA 标准）的优势，以及如何用 Web 服务技术增强这些技术，以便用更基于标准和互操作性更好的方式来实现企业应用程序的集成。我们将展示基于 Web 服务的公共接口如何帮助您把一个后端系统集成到 J2EE 环境中。这样，您将支持更高级别的自动化，并支持使用各种工具环境，从而使后端系统的互相连接更加容易，并且不需要太关心各个 API 和协议。
在阅读本文之前，您应该对 Web 服务和 J2EE 技术有基本的理解。如果您不熟悉这些主题，请参阅下面的参考资料部分获得一些有用的论文、文章和教程的链接。
J2EE、JMS 和 JCA
人们已经写了许多关于 J2EE 及 J2EE 所包含的 API 的文章，所以我们就不在这里重复所有那些信息了。但为了让读者都能够及时了解这篇文章中将讲些什么内容，我们来简要概述一下将作为我们的讨论的基础的一些技术。
Java 消息传递服务
Java 消息传递服务（JMS；请参阅参考资料以了解更多相关信息）定义了一个可以用来在应用程序间交换消息的公共 API。它允许应用程序间的异步通信，在这种通信中一个应用程序向消息队列发送一条消息并随后继续自己的正常处理而不是等待该消息被另一个应用程序接收。任何负责接收的应用程序都从该队列检索消息，解释该消息并适当地处理它。两方的应用程序都可能在同一时间或不同时间，在相同的或不同的机器上运行。
上面所描述的应用程序间的通信被称为点对点通信（point-to-point communication），因为一个应用程序发送的消息只被另外一个应用程序接收。另一个描述多个应用程序如何在 JMS API 上进行交互的模型被称为发布-预定（publish-subscribe）模型。在这个模型中，一个应用程序将消息发布到某个被称为主题的目的地那里，该消息被任意已经预定了这个特定主题的应用程序接收。这样，同一条消息就有可能被多个客户机应用程序接收到。
JMS 规范只定义了一个编程接口来使用消息队列和主题，并把这个 API 的实现留给了所谓的消息提供者，每个与 J2EE 1.3 兼容的应用程序服务器都带有这种消息提供者。
在使用 JMS 集成后端应用程序时，我们经常说这些应用程序是松散耦合的。这描述了这样一条消息 ? 它在一个事务中被创建、发送，然后从队列中被取出，并在一个独立的事务中被处理。把消息的创建者与处理者分开在一定程度上是间接的。只要消息交换在进行，JMS 就是事务性的，但交换和处理发生在相互分开的事务中。换句话说就是，JMS 提供者可以向消息的发送方保证将消息发送到目的地（一个队列或主题），并且是一次性发送。但在消息的处理过程中是否发生了错误就完全是另一回事了。
Java 2 连接器体系结构
Java 2 连接器体系结构（JCA；请参阅参考资料了解更多的相关信息）定义了一种用来使 J2EE 应用程序与非 J2EE 环境（通常情况下，是企业信息系统（enterprise information system），或称 EIS）用一种安全的、事务性的方式进行通信的方法。利用 JCA API 的解决方案比基于 JMS 的解决方案与后端耦合得更紧；更确切地说是 JCA 规范可以在同一次消息交换或同一个事务中把消息的发送和处理结合起来。
规范定义了应用程序和 EIS 间各种级别的接口。规范基本上是描述如何在应用程序服务器和后端应用程序间部署所谓的资源适配器。资源适配器存在于应用程序服务器的地址空间内，并实现了允许应用程序服务器和 EIS 间交互的编程接口。
JCA 规范中定义了两种级别的编程接口。一种级别被称为公共客户机接口（common client interface（CCI）），任何 J2EE 组件都可以用这种接口与 EIS 进行交互。它的使用是可选的，这意味着资源适配器不一定非得实现它。EIS 供应商可以自由使用它自己的接口。这一点很有意义，特别是当这个接口已经被用一种更早的集成方法实现过的时候，就更有意义。例如，一个数据库可能已经有了连接到数据库并处理 SQL 语句的包装器类。
JCA 定义的其他接口是一个系统编程接口（system programming interface（SPI））集合，它们只被应用程序服务器内部使用。SPI 分为三种类别，用来解决下面几个问题：
安全性（Security）接口允许应用程序服务器和资源适配器处理在 EIS 上的登录 ? 例如，通过隐式方法把用户标识和密码组合发送到代表客户机的后端。
连接池（Connection pooling）接口确保与 EIS 进行通信所需的任何资源都在许多客户机间被共享，并被合用。
事务处理（Transaction handling）接口负责管理跨支持两阶段提交协议的各种后端的分布式事务。
图 1 显示了 JCA 规范定义的各种类型的接口
图 1. Java 2 连接器体系结构概览
JCA 的许多方面本身就值得进行更深入、更详细的研究，但我们将把这个任务留给其他的文章和论文。对于我们来说，要记住的关键一点是，与基于使用 JMS 进行消息交换的系统相比，使用 JCA 进行的集成耦合得更紧密。EIS 进行的处理是同步的，因此可以成为 J2EE 应用程序服务器管理的事务的一部分。因此，被 J2EE 应用程序跨多个后端应用程序运行的业务流程可以是事务性的 ? 这些应用程序所执行的步骤要么全部被提交，要么一步也不提交。
图 2（这张图是从 J2EE Connector Architecture and Enterprise Application Integration 一书摘录的 ? 请参阅参考资料获得该书的链接）向您展示如何使用 JMS 和 JCA 把企业信息系统连接到 J2EE 环境。
图 2. 使用 JMS 和 JCA 把 J2EE 和非 J2EE 系统连接起来
关于 Web 服务的疑问
目前为止，我们已经讨论了 J2EE 世界中的两个主要接口，这两个接口使我们能够使用运行在 J2EE 应用程序服务器内的解决方案来集成非 J2EE 环境。一种方案解决了松散耦合的、基于 JMS 的异步集成，而另一种方案描述了耦合更紧密且同步的模型，这种方案使用的是 JCA。那么 Web 服务更适合哪一种呢？
通常 Web 服务描述的编程世界与我们所习惯的那种稍有不同，也就是在 Web 服务所描述的编程世界中，某些业务功能是用服务而不是用对象或组件表示的。服务用允许从任何编程语言和任何平台（通常是跨网络）调用该服务的方法来实现业务流程一部分。服务所提供的公共接口是用一种被称为 Web 服务描述语言（WSDL）的语言描述的，这种语言基于 XML 并定义了一些方法来用一种与编程语言无关的风格抽象描述操作以及这些操作的输入和输出消息。同样，Web 服务也提供了一种机制来集成业务功能，用这种机制集成时可以不考虑实现这些功能时所用的语言或特定 API。显然，这使得它们对于任何旨在集成异构后端应用程序的工作来说都非常有用。
Web 服务并没有解决它们自身的 EAI 问题。相反，它们考虑到了更好的自动化和更好的工具以及运行时支持，所以即便它们不是为这个目的而被构建也可以使应用程序的通信变得更容易。例如，有这样一些工具，它们可以构建用来访问 WSDL 文档所描述的服务的客户机端代理。WSDL 文档可以从现有代码中派生出来。由于 WSDL 是一个事实上的标准（经过了 W3C 的正式标准化，这是不久的将来所需要的），所以它得到了多个供应商实现的支持。同样，还存在各种运行时软件包，它们支持通过 SOAP 供应和消费 Web 服务，我们只是给出了一个协议作为示例。
考虑到所有这些因素，把 J2EE 环境的特征（健壮性、可伸缩性、安全性和其他特征）与 Web 服务技术的优点（也即平台和编程语言独立性）结合在一起用于企业应用程序的集成好象是一个显而易见的选择。要使用我们在上面描述的 J2EE 规范（JMS 和 JCA），应用程序开发者需要了解一些特定的编程接口。我们想定义一个独立于这些接口的编程模型，这个模型提供了从面向服务的角度来看待现有业务流程和功能。这表示着我们正在寻求一个通用的编程模型，这个模型可以跨各种不同的调用机制应用。在这个模型中，作为一个开发者您只需要关心用 WSDL 描写的服务的接口，而无需关心用来访问该服务的特定调用协议。
WSDL 中的协议绑定
任何 WSDL 文档都包含三部份。第一部分定义了服务的抽象接口，用端口类型（port type）表示，它包含操作集合（也就是业务功能）。每个操作都是通过输入消息和可选的输出消息定义的。这些消息就是 XML 文档，用一个或多个 XML Schema 描述。
WSDL 定义的第二部分被称为协议绑定（protocol binding）。这部分指定给定的服务所响应的协议。例如，目前的大多数 Web 服务都是使用 SOAP 协议（请参阅参考资料）实现的。您可以在该服务的 WSDL 文档中添加关于如何构建服务可以解释的 SOAP 信封（envelope）的详细信息。
最后，WSDL 文档中包含的第三部分信息是所描述的服务的端点（endpoint） ? 也就是驻留在应用程序服务器上某个地方的实际业务逻辑的位置。这个位置可以是一个 URL（对于 SOAP 来说），或者只是协议可以用来定位服务的地址。
我们在上面已经说过，J2EE 标准定义了一些通过使用象 JMS 和 JCA 这样的 API 集成非 J2EE 应用程序的方法。那么，同时利用 J2EE 和 Web 服务需要些什么呢？业务功能的抽象定义（可以通过一个 WSDL 中的端口类型来描述）并不依赖所使用的协议。这样，我们就可以在 WSDL 定义中的协议绑定部分描述关于服务的所有特定于 JMS 和特定于 JCA 的信息。图 3 展示了如何将 JCA 资源适配器的一些部件映射为相应的 WSDL 构件。
图 3. WSDL 到 JCA 的映射示例
我们可以为所有类型的不同协议定义绑定。我们已经提到了 JMS 和 JCA，它们可能是与企业应用程序集成联系最为紧密的协议。但我们还可以很容易地利用 WSDL 进行普通的调用或调用 Enterprise JavaBeans。对于应用程序开发者开说，所使用的特定协议应该是透明的，这样他或她才能够将注意力集中在业务接口上，而不必处理调用这些接口的各种客户机编程模型。这样，您就有可能通过许多客户机访问协议来访问服务，如图 4 所示。
图 4. 创建到一个服务实现的多个绑定
Web 服务调用框架
目前为止，我们已经说过，如果想使用 J2EE、JMS 和 JCA 中提供的集成技术集成旧应用程序的话，我们可以把旧应用程序的接口描述为 WSDL 端口类型，并添加协议绑定（这些绑定附带关于如何访问它们的信息）。为了真正独立于所有的编程接口，我们需要这样一种机制，它可以解析和解释 WSDL 中包含的绑定信息，还可以为服务生成适当的运行时调用。例如，如果一个服务可以通过 JCA 资源适配器访问，我们就需要一种方法来自动利用该适配器提供的 CCI 接口 ? 而不必要求应用程序开发者知道如何使用 CCI。换句话说就是，我们希望能够只根据服务的接口来调用这个服务，而不是根据其实现或协议。
Web 服务调用框架（WSIF；请参阅参考资料获得相关链接）提供了一个接口，该接口允许对 Web 服务的调用独立于被用于与该服务实际进行通信的协议。它的编程接口严格基于 WSDL 端口类型定义的抽象服务接口。适当的请求消息是在运行时根据 WSDL 文档中的绑定信息构建的，这样它对应用程序开发者就是透明的。
结束语
现在的许多 IT 工厂都面临着集成运行在异构环境中的应用程序的挑战。Java 2 平台，企业版定义了各种允许集成这些应用程序的编程接口，然后这些应用程序就可以被用来构建新的、支持 Web 的、健壮的且安全的企业解决方案。这些接口中最突出的是 JMS 和 JCA。JMS 将异步且松散地耦合旧应用程序，而 JCA 允许通过同步且事务性的接口进行更紧密的耦合。
Web 服务技术为业务系统引入了面向服务的体系结构这个概念。业务功能是用基于 XML 的抽象定义表示的，就象 WSDL 文档中描述的那样。我们可以通过用 WSDL 定义用于 JMS 和 JCA 的特定的协议绑定来集成 J2EE 和 Web 服务技术；这样我们就可以用一种通用的、独立于协议的方式来定义后端接口。在运行时，“Web 服务调用框架”处理服务调用的生成而不考虑协议，这意味着应用程序开发者不必管理用来访问业务功能的多个编程接口。
虽然这种技术并不排除对 EAI 的需要，但由于它增加了标准的级别，得到了许多供应商的支持，而这些都是可以利用的，所以它从运行时和工具这两方面都提高了可以用来集成异构应用程序的自动化程度。这样只会使集成过程更加容易。
参考资料
看一下 Sun Microsystems 关于 Java 消息传递服务（JMS）和 Java 2 连接器体系结构（JCA）的页面。
如果想了解 W3C 的标准化工作进展情况，请通过该组织的 Web Services Architecture Working Group 了解最新动态。
Rahul Sharma、Beth Stearns、Tony Ng、Scott Dietzen 合著的 J2EE Connector Architecture and Enterprise Application Integration，（Addison Wesley，2001）是一篇关于 EAI 的优秀书籍。图 2 就是从这个文本中摘录的。
要查找更多关于 WSIF 的信息，请阅读“Applying the Web Services Invocation Framework”，Paul Fremantle（developerWorks，2002 年 6 月）。
学习更多关于 Apache Axis 的知识。
关于作者
Daniela Rudrof 是一位安全性操作（Security Operation）方面的 IT 专家，在 IBM 的 Control and Compliance GU Main 部门工作。她帮助确保 IBM 内以及外部客户的安全性标准。在开始从事目前的工作之前，她在 WebSphere Business Development Group 写了自己最后的论文，主要是关于 J2EE 技术和 Web 服务的。Daniela 在德国居住和生活。在闲暇时候，她喜欢出门，参与一些体育活动，包括英式足球、游泳和武术。您可以通过 Daniela.Rudrof@de.ibm.com 与 Daniela 联系。
Andre Tost 是 IBM WebSphere Business Development group 的一位解决方案设计师，他在这个部门帮助 IBM 的战略联盟伙伴把他们的应用程序与 WebSphere 集成在一起。他的工作重点是贯穿整个 WebSphere 产品系列的 Web 服务技术。在开始从事他目前的任务之前，他有十年的时间是在 IBM 软件开发工作中担任各种开发和体系结构方面的角色，最近是在从事 WebSphere Business Components 产品。他出生于德国，目前在美国明尼苏达州的罗切斯特居住和工作。在业余时间，他喜欢和他的家人在一起，只要有可能就去踢球或者看球。您可以通过 atost@us.ibm.com 与 Andre 联系。 |
| |
|
|
|
