Web服务搜索与执行引擎(一)——项目提出的有关背景

　 在接下来的blog里，我将会写一系列项目总结的文章，里面很多内容是我们Cactus团队成员一起完成的，最主要的目的是把我们的想法说出来，跟大家探讨，欢迎大家提出宝贵意见。     

1 项目的背景和意义

1.1 Web服务出现的意义

Web 服务是一种想把全世界的Internet/Intranet变成一个虚拟计算环境的 观念和技术。在由Web Service组成的虚拟环境中使用者可以任何的客户端软件，例如浏览器，一般的Window或是Java应用程序或是手机等，来调用Web服务提供的服务。而Web服务本身则可以由任何的技术来编写，例如开发者可以使用Delphi，Java，C/C++或是C#等语言和工具来开发。因为Web服务视作Web上的组件编程，从理论上讲，开发人员可通过调用Web应用编程接口(API)（就像调用本地服务一样），将Web服务集成到应用程序中，不同的是Web API调用可通过互联网发送给位于远程系统中的某一服务。

1.2发现和利用现有Web服务是个问题  

但是，目前来说，在如何发现和充分利用现有Web服务上仍然是个问题。当前的搜索引擎只能支持搜索Web 页面，它们只是搜索到网站的链接，用户执行某个操作需要点击链接进入后，面对很多五花八门的无用的页面信息，然后经过了复杂的查找，操作后才能找到您真正想要的某种服务的正确位置来执行。这种方式并不能发现网络上大量可用的Web服务，所以为了发现和利用互联网上存在的大量优秀的Web服务，需要一个Web服务发现和执行引擎。

1.3拥有Web服务发现和执行引擎的必要性

在信息化大潮的推动下，未来人们的许多活动都将会在网上执行，有了这样的Web服务发现和执行引擎可以有效发现用户所需的Web服务，并且提供一个执行机制，用户搜索到某个具体的可执行组件，而不管其是什么平台，选定后在网页中输入执行此操作所需的输入数据后，远程的可执行组件再将返回结果交给系统最后呈现给用户。这样，未来会出现这样的情况，用户想要完成银行转账操作，不必去银行主页，而在引擎中输入“银行转账”几个字，搜出一批结果，点击某个进入后，输入数据，即可执行，完成了想要的服务，十分方便。

1.4企业做信息整合时需要的

   互联网正在发生很多变化。它已经成了Web服务推动器，而不再仅仅是一个信息仓库。很多组织都将它们的核心业务以Web服务的形式放到互联网上，并在互联网上找到其他所需Web服务，从而构建出新的增值服务。因此，需要一个类似当前广泛使用的搜索引擎的工具，以有效发现所需Web服务，并及时执行，从而可以测试发现服务的可用性、可靠性和正确性，为实现整合提供支持并保障整合的有效性。

2 国内外研究现状

  而ebXML,XML/EDI体系结构里的注册表也是属于一种资源库，但是它存放的是一种具有协作关系的Web服务，即它们是贸易伙伴。我想目前来说，跟Web服务搜索有关能扯上关系的，说得最多的应该算是UDDI了吧，

2.1 UDDI

UDDI，统一描述、发现和集成协议，它的数据结构是无限制的，只规定了很少的信息，而且结构所基于的分类数据（categorization data）也不是被广泛认同的——这样的数据结构造成了极多问题。UDDI 曾被定位为企业内部的技术，也就是在这方面UDDI取得了一些成功，但是 UDDI在这方面的标准工作做得仍不够。最主要的一个不足是，使用一个XML文档来描述企业及其提供的Web服务，对于那些服务消费者他们从UDDI资源库里只能找到以下三种信息：1.服务提供商的地址，联系方法，和已知的企业标识。2.基于标准分类法的行业类别。3.关于该企业所提供的Web服务的技术信息，其形式可能是一些指向文件或是URL的指针，而这些文件或URL是为服务发现机制服务的。而有了这些信息也还不能去执行一个特定的Web服务，服务消费者自己还必须做很多额外的工作才能使那些搜索到的Web服务给自己有效利用。

2.2 ebXML,XML/EDI

20多年前，电子商务的想法诞生，通过链接在一起的计算机系统，数据能从一个系统传送到其他系统，从而不再使用纸介质文件来交换商业数据。这个概念就是70年代中期产生的EDI（Electronic Data Interchange，电子数据交换）的原型。EDI的出现大大提高了商业运作效率，但虽然全世界的前10000家公司中98％以上都在使用EDI，但全世界其他公司中却仅有5％是EDI的用户，因为EDI虽然很有效，但启动费用很高。当时人们一直在寻找EDI的替代方案，希望能够找到一种使全球不同规模的公司都能受益的简单、便宜的交换标准商务文档的方法。在这样的背景下ebXML应运而生了。ebXML的技术体系结构里的注册表（registry），企业通过注册表登记CPP（collaboration protocol profile，合作草案档案），列出它们的电子商务服务能力供潜在的贸易伙伴检索，也可以通过注册表搜索合适的贸易伙伴。知识库（repository）则是用于存储这些内容的。

ebXML和Web服务所具有的共同特点是：基于松散耦合的应用交互。松散耦合的特性意味着企业可以自由地选择供应厂商、硬件平台、软件框架等电子商务的组成部分，只要这些供应厂商在相应的硬件平台上提供了支持ebXML规范或Web服务规范的软件框架就能够构建可用于交易的电子商务系统。ebXML的注册系统(repository)提供一整套分布式服务，使得彼此有意愿进行商务流程集成的企业可以通过共同遵循ebXML规范来达到共享信息以及应用集成的目的。但是通过ebXML的注册系统（repository）搜索到的只是合适的贸易伙伴，关注点并不是具体到某种详细的Web服务。

3 我们的解决方案

基于1.1项目背景意义跟1.2国内外研究现状，我们Cactus团队实现了这样的解决方案：基于XML和Web Service技术,开发了一个Web服务动态搜索与执行引擎。

3.1本项目完成的功能

首先是Web服务的搜索功能，用户可以像百度等典型搜索引擎那样输入Web服务名关键字，然后系统的搜索模块可以返回当前在我们系统的服务资源库里注册的所有带有用户输入的关键名的Web服务列表，服务消费者可以选择他所想要的Web服务，查看有关此Web服务的所有详细信息，如提供商的信息，Web服务的信息等。更重要的是Web服务的执行功能：对于想要执行Web服务的某种操作的消费者来说，我们的系统为消费者屏蔽掉了执行远程Web服务的复杂过程，所以无论远程的Web服务是基于何种平台开发出来的，在服务消费者看来都是做这几个简单的操作：当服务消费者搜索到他所想要的Web服务后，进入到了Web服务详细信息页面，此页面列出了这个Web服务的所有可执行操作列表，消费者可以选择想要的操作，然后填写执行此操作所需的某些数据后传到系统，然后系统以用户的输入作为有效负载远程调用此可执行组件，再将返回结果交给系统进行解析，最后呈现给用户。

那些在不同的平台下已经开发好web服务的个人或公司，只要提供一个开发好的Web服务的描述文件WSDL文档的URL，可以不受异构平台的影响把他们的Web服务注册到我们系统的服务资源库中，我们的系统将会做为一个”传媒中介机构”向服务的消费者们展示服务提供者所提供的web服务的有关信息。

3.2本项目的创新点。

3.2.1 Web服务的调用技术

传统的WEB服务调用方的构建是在服务的调用方人为的对WEB服务了解的情况下进行的，不能实现一个针对任何服务都能使用的公用客户端，面对我们的需求，需要反复的重写代码，根本不可取。

我们运用WSDL4J与SAAJ技术自行构建SOAP消息，构建出了一个公共的客户端应用，很好的解决了我们的需求。

备注：WSDL4J与SAAJ经常是为供应商底层实现标准API所用（如传统方式客户端代理程序的构建底层就运用了以上两种技术），我们利用此技术属于深度挖掘，从底层实现。

3.2.2 基于Lucene的Web服务搜索

本地服务资源库是一个存放有关远程web服务的索引数据库，如果通过SQL直接查询数据库速度将会难以忍受。为了提高检索效率，需要建立索引，按照倒排文件的格式存放。用户输入搜索条件后搜索程序将通过索引数据库Lucene,进行检索然后把符合查询要求的数据库按照一定的策略进行分级排列并且返回给用户。

3.2.3 J2ME手机客户端开发技术

用户除了可以使用游览器，通过Internet,HTTP协议以及手机游览器通过WAP协议访问外，我们还使用SUN公司的J2ME技术，给用户提供了一个手机客户端应用，手机用户可以通过GPRS连接系统的服务器进行方便的操作。

附Cactus团队成员合照：