Web Services和J2EE：集成中的伙伴

申请免费试用、咨询电话：400-8352-114

Web Services和J2EE：集成中的伙伴

长期以来，对于如何集成遗留的系统一直并存着多种解决方案。Web服务的出现为如何利用已存在的EAI（企业应用集成）投资带来了曙光。Web服务可以将后端应用和数据改造成为一种简单、可重用和长生命周期的服务，通过Web服务，后端的应用和数据走向了前台。

过去，以EAI集成应用时程序员不得不编写专用的连接程序来实现应用A和应用B的互通。但是，如果有第三方应用C需要与A、B实现集成时，程序员们必须在应用A与应用C之间以及应用B与应用C之间开发新的连接程序。这样，随着需要集成的应用的增多整个集成将成为一张越来越复杂的集成网络，因为我们需要在任意两个应用之间开发专用的连接程序。

在一些企业里，采用集成代理的方法可以缓解诸如EAI所带来的负担。所有的集成提供者都认为采用一种依赖于私有协议的中间件作为应用之间通信的代理是非常好的一个想法。这样，每个应用之间只需要一个单独的连接器即可，应用之间的映射关系则由代理来解决。这种集中辐射式技术最大的缺点就是其缺少可移植性。一旦选中了一种集成代理，那么将意味着集成中的所有的设计都不得不一直以这种集成代理作为基础。

解决上面所提到的两个问题的一个明显的答案就是开发出一种能够实现系统松耦合从而实现更简单应用集成的标准。这个标准就是Web服务技术。为了使集成框架工作得更好，建立的标准必须涵盖服务的通信、服务描述和服务发现等标准。通信的标准用来限定Web服务的通信方式；服务描述标准向用户解释一个服务到底具有哪些功能；服务发现标准告诉用户如何寻找到一个Web服务并为服务提供商提供了一种发布其Web服务的一种方法。这三种功能标准分别由SOAP （Simple Object Access Protocol）、UDDI （Universal Description, Discovery and Integration） 和WSDL （Web Services Description Language）来实现。SOAP提供通信机制，WSDL负责服务的描述，UDDI则是发现服务的一种工具。

Web服务的工作方式如下：

首先，作为一个服务的制造商，公司将它的应用想要公开的功能进行标记。

接下来，Web服务的服务器通过调用相应的程序实现对这些已标记功能的包装（Web服务的服务器通过Internet的HTTP协议和基于XML的SOAP文档通信；SOAP是一种用来定义应用间通信方式的协议）。

然后，公司将开发出一个WSDL文档用来定义服务。WSDL也是一种基于XML的技术，它是Web服务功能性描述的一种协议。各个服务的制造商们将它们的Web服务加入到UDDI的目录列表中，这个目录列表就象是Web服务的电话本一样。

最后，Web服务的用户通过查询UDDI目录中的服务来找到自己需要调用的远程应用。UDDI为用户返回一个WSDL文档，通过这个文档用户就可以通过某种工具的帮助创建自己的客户端应用。这个客户端调用服务的过程与通过HTTP协议调用SOAP文本的过程没有区别。

通过上面的介绍可以看出，Web服务是一种大量依靠XML的技术，这是因为XML技术已经被大部分流行的编程语言所支持。Web服务的这种跨平台和跨语言特性可以满足任意两个应用之间的通信需要。

举个例子。假设有一个后端的COBOL应用正在通过5270端口与一个运行在基于Windows的Java应用服务器上的应用共享信息。共享的信息可能显示在一个iMac上的Opera浏览器中或者显示在Nokia手机的显示屏上。通过Web服务，你就可以以这种方式共享任何信息和应用的功能。

Java应用服务器和Web服务

既然标准已经存在了，随之而来的就是那些越来越多的对服务器的需求。这些服务器是能够代理Web服务处理任务的一类服务器。所以，应用服务器的提供商们开始在他们的商品中提供对Web服务的支持。因为大多数的企业已经采用应用服务器来建立它们的Web使能应用，所以应用服务器就理所当然的成为了Web服务的服务器。

目前的应用服务器市场已经证明了Sun公司的J2EE (Java 2 Enterprise Edition)规范的成功。J2EE平台不仅是一种技术成熟的平台而且比它的对手Microsoft的.NET平台更好地支持工业的标准。

J2EE应用服务器提供了一种跨供应商的标准，这样用户就可以容易地将他们的J2EE应用从一个供应商的J2EE应用服务器移植到另外一个供应商的J2EE应用服务器上。已经证明，只需要非常小的修改或者根本不修改，J2EE应用就可以运行在许多不同的操作系统上并与Web浏览器集成。Java和J2EE平台为EAI解决方案带来了可移植性。任何投资都会带来风险，而运行在J2EE平台上的Web服务则可以最小化这些风险并为采用这种方案的集成商们带来可观的回报。

与其它的底层组件相比，J2EE的功能要更加复杂并且容易混淆。以J2EE作为应用服务器的统一模式将造成性能的降低，例如，与企业后台应用的不兼容。

另外，J2EE规范的1.3版增加了更易于移植和重用的Java集成工具——JCA (Java Connector Architecture)。该工具为开发人员提供了一种开发或者购买可嵌入的Java连接器的标准，该连接器通过将遗留的系统集成到Java应用服务器上来实现遗留数据基于Internet或Intranet的共享。

为了更好的支持Web服务的部署，许多Java应用服务器现在都包含必要的工具来帮助应用开发人员通过UDDI路径发现Web服务。一旦该路径返回了WSDL的文档，这个工具就能够生成访问该Web服务的客户端的基本代码。然后，这些工具通过SOAP协议建立和共享Web服务并将Web服务注册到UDDI注册表。

采用Web服务的风险

今天我们已经建立了一系列的Web服务标准，应用服务器的供应商们也正在将这些标准融入到他们的产品中。我们也拥有一个支撑Web服务开发的正在趋于完美的平台——J2EE。那么，我们为什么还要限制开发人员都来采用Web服务作为集成的解决方案呢？

采用Web服务的体系框架给人们带来了两个方面的困惑和恐惧：

1．Web服务是一种前沿的技术，它的支撑软件还不够成熟。

2．各种各样的新规范诞生的非常快，人们需要投入大量的资金来紧跟和测试这些新的规范。

对于上面的第2点来说，尽管新的规范必须兼容早期的版本并且由多个团体共同制定，但是，随着技术的逐渐成熟，规范修改的内容和次数也会越来越少（例如HTTP）。

对于上面的第1点来说， J2EE已经是一种相对成熟的技术，而Web服务市场的激烈竞争也很快为Web服务的开发人员确定了一批优秀的开发工具。

Web服务的回报

采用Web服务和J2EE来集成遗留的系统，其潜在的回报是巨大的。你可以充分使用集成服务器所带来的优点而不需要考虑其它集成系统所存在的一个很大的不足：缺少可移植性。如果一个集成方案是在某个Web服务提供商的J2EE和Web服务平台所建立的，那么它的应用可以非常容易地移植到其它供应商的服务器上。

另外，无论是已经拥有的应用服务器还是准备在一个电子商务项目中购买的应用服务器都可以较为经济的享有Web服务和J2EE所提供的集成所带来的一切优点。通过这个集成服务器，用户只需要针对每一个应用建立一个连接，而不需要为任意两个应用的每个联系建立连接。Web服务和J2EE是建立在一些容易理解的技术（例如，Java 和 XML）基础之上的，在过去的几年里这些技术已经赢得了大量的支持和使用。所以，基于Web服务和J2EE的集成解决方案就成为一种不断发展、功能不断增强的方案，这是其带来的另一个好处。

最后，随着基于标准的开发工具的不断完善，这些工具将大大提高用户的生产能力，它将使用户通过图形操作界面和简单的点击、拖拉操作在短短的几个小时内建立应用的连接。

总结

通过简化和利用现有的技术和知识，Web 服务和J2EE能够减少遗留系统集成的必要投资，提供可移植性和可重用性。通过使用一系列单一的标准技术——XML, Java 和 Web 服务——集成项目的周期将会大大的缩短。同时，由于所采用的技术是标准的，所以集成方案的透明化也就变得可能了。

通过实施基于Web服务和J2EE的集成方案，IT的管理者们可以降低他们的投资成本，缩短项目周期和扩展项目的应用。不容置疑，今天Web服务已经引起了开发人员和集成人员的注意，并为之兴奋。