Web服务之路越走越亮

张诚

回顾Web服务（Web Services）的历程，可以说它现在正处于技术成熟的第一个阶段，即已经被接受。虽然目前Web服务体系结构还只是用来创建简单的应用类型，开发人员还处于熟悉其基本概念的阶段。但应该承认，Web开发界已经逐渐将Web服务视做可行的工具，并逐步将它用于实现许多更陈旧、更庞大的技术所不能完成的任务，比如在平台和操作系统之间实现无缝的互操作。有理由相信，近期内，它将成为Internet上自动查找信息和应用的最主要方法。

现在，开发商们已经不再怀疑Web服务的可行性，而是开始研究如何最大限度地利用SOAP和其他支持 Web服务的技术来构建Web服务。现阶段的Web服务就像清晨的路，有越走越亮的趋势。虽然基于Web服务，将SOAP、WSDL和UDDI部署到企业环境的成功应用还不是很多，但是在企业应用领域中Web服务的发展和进步非常迅猛。Apache Axis Engine（这个工具目前仍在开发中）已经许诺将开发出构建在企业Web服务之上的高价值、高性能和高稳定性的产品。

Web服务：共享应用

Web服务的目的就是为了使商务应用能够在Internet上进行交流，并且同其他应用系统进行协同工作。传统的Internet应用和服务之间的交互需要知道它们的位置，然后通过人工定位来实现。而Web服务允许应用本身在标准的目录结构中查找Web服务，然后通过最少的人工干预与这些服务捆绑在一起（如图1所示）。

Web服务允许对象在Web站点上分布式分布，客户可以通过Internet访问它们。当客户需要某一种服务时，就可以通过全球服务注册机构（站点）进行查找并发现自己需要的服务。之后，客户选择其中的一个，并与这种服务捆绑在一起，在一段时间内使用这个服务。由于对这些服务的发现和选择一般情况下不需要人工干预，因此服务与服务之间的切换非常迅速。通过自动服务发现（Automated Service Discovery）机制可以建立非常优秀的服务网络。如果有多个Web服务提供相似的功能，那么客户可以很方便地在当前使用的服务出现问题时切换到备份系统中，从而保证系统的健壮性。

在这个领域中最重要的标准有UDDI（Universal Description, Discovery, and Integration，统一描述、发现和集成）、SOAP（Simple Object Access Protocol，简单对象访问协议）和WSDL（Web Services Description Language，服务描述语言）。其中UDDI用于注册和发现Web服务，SOAP用于Web服务之间的通信，以及配合WSDL来描述Web服务接口。

Portlets：通向Web服务

由于Web服务主要通过非人工干预来获取Internet上的信息和应用，这就要求Portals能够尽快将数据源和远程应用组件集成为Web服务。一般说来，Portal可以从本地或远程获得数据资源。这些数据资源可能来自于其他的数据库、交易系统、联合内容供应商，或另外的远程Web站点。Portal将这些数据资源综合起来形成复杂页面，以易于用户接收的表单形式返回给用户。除了提供这些单纯的数据信息，许多Portal还提供E-mail、日历、银行账单等应用。所以说，Portal非常重要，它是用户从不同位置访问不同信息和应用的焦点。

而Portlets是运行在Portal的Portlet容器（Container）中的插件，在许多方面都类似于Servlets。Portlets用Portlet API来编写，就像Servlets用Servlet API来编写一样，不同的是Portlets运行在Portal环境中，而Servlets运行在服务器端的Servlet容器中。另外，Servlet直接与客户端通信，而Portlet则通过Portal的应用来调用。Portlets只有在生成了适合大页面显示的内容之后，才会在Portal环境中适当运行（如图2所示）。

在基于Web服务的Portal应用中，一个典型的例子就是新闻Portlet(如图3中的新闻Portlet)。新闻Portlet使得用户能够配置用于跟踪的新闻分类，然后从Web服务中获取该类别下的最新新闻并且显示出来。在这个例子中，Web服务提供信息，本地的Portlet则用于显示这些信息，Portlet代码运行在本地的Portal中。Web服务返回的信息可以作为一个XML文件。

另外一种基于Web服务的Portal应用是与其他Portals共享Portlets。在这种情况下，远程服务器即另外一个Portal，在UDDI目录中发布Portlets作为远程Portlet Web服务。这样本地Portal在UDDI目录中就可以查找远程的Portlet服务并且与它们捆绑在一起，本地Portal用户无需在本地Portal服务器上安装Portlet代码就可以直接访问远程Portlet服务（如图3中的股票信息和天气预报建立的Portlet代理）。

当前状况:用Portlet架构Web服务

过去，Portlets可以通过多种方式访问信息和应用。在Intranet中，通常通过数据库连接、LDAP连接、Java RMI、DCOM或CORBA来实现上述访问。在Internet环境中，大多数情况下使用HTTP协议来发送请求和接收响应。随着Web服务的发展，相信在短时期内，SOAP协议将成为最主要的、通过Potrlets请求远程服务的通信机制，并且会逐步取代上述这些通信机制。

Web服务和客户端的通信、全球Web服务以及多目录管理都会用到SOAP和UDDI。这样可以通过应用程序去查找、捆绑和运用Web服务。Web服务可以用WSDL描述，然后通过适当的工具，针对特定的程序设计语言来生成SOAP代理。同样，也有工具将已有的代码用WSDL来描述，然后生成Web服务。

图4说明了如何用Portlet来架构Web服务。当Portlet接收到请求去访问Web服务时，Portlet会首先调用SOAP代理对象，该代理把请求参数排列成与程序设计语言无关的SOAP请求，再把该请求发送到Web服务中。Web服务将接收到的SOAP请求进行拆包，将请求参数进行还原，并根据这些参数来调用本地的Web服务，完成服务请求。当服务返回结果后，SOAP封装器将结果封装成同样与程序设计语言无关的SOAP响应，并将它送回给SOAP代理。最后，SOAP代理把返回的结果数据进行拆包，送给调用它的Portlet。

近期未来：远程Portlet Web服务

我们知道，一个Portal不可能提供所有的服务，因此当用户请求访问其他Portal服务器上的Web服务时，本地Portal服务器的Portlets就可以动态地同远程Portal服务器的Portlets进行通信。这样就不需要在本地的Portal服务器中安装相应的Portlet文件。为了达到这个目的，Portlets本身必须作为Web服务提供给其他的Portlets，同时必须用WSDL来描述远程Web服务接口。

WSDL定义了所有远程Portlets所需的参数、返回值以及相应的Portlet API集合。这样，远程Portlets不一定非得用Java实现，而可以用其他的程序设计语言实现。

Web服务供应商如果想发布远程Portlet Web服务，必须先发布适当的UDDI目录入口，以便引导至用WSDL描述的远程Portlet Web服务接口。远程Portlets一旦发布，Portal管理员就可以用Portal管理工具来搜索UDDI目录，查找用远程Portlet Web服务接口实现的Web服务，预选一些经过匹配的Portlet Web服务，并将它们加到Portal的Portlets注册表中（见图5）。

Portlets注册登记后，用户就可以选择这些Portlets并把它们加到自己的页面中去。另外，Portal也可以建立一些渠道，让本地Portal的用户浏览Portlet Web服务目录，在个人页面中加入一些引导，指向远程Portlets。

当页面中指向远程Portlets的引导得到了返回结果，Portal通过RPI（Remote Portlet Invocation）协议用Portlet代理去调用远程Portlet Web服务。Portlet调用Portlet代理就像调用本地的Portlets一样解析Portlet请求(Portlet Request)和Portlet响应(Portlet Response)两个对象，然后Portlet代理在内部调用SOAP代理，把所有参数进行排列，并打包到SOAP请求中，再把SOAP请求发送到远程服务器上。该远程服务器运行Portlet Web服务，在Web服务端的SOAP封装器将收到的请求信息进行拆包，然后再去调用远程Portlets。

无论是Portlets引擎还是Web服务接口的调用，对远程的Portlets来说都是透明的。无论哪种情况，远程Portlets都会处理输入参数，返回Portlets响应对象。而SOAP封装器则将响应排列到SOAP响应中，并且将它返回给SOAP代理，然后顺序拆包给Portlets代理，将Portlets响应对象返回给Portlets引擎。

本文原载于计算机世界报