CN101375247A

CN101375247A - 服务创建方法，用于实现所述方法的计算机程序产品和计算机系统

Info

Publication number: CN101375247A
Application number: CNA2007800034129A
Authority: CN
Inventors: P·拉尔韦
Original assignee: Alcatel Optical Networks Israel Ltd
Current assignee: Alcatel Lucent Inc
Priority date: 2006-01-24
Filing date: 2007-01-23
Publication date: 2009-02-25
Anticipated expiration: 2027-01-23
Also published as: KR20080087867A; KR101192874B1; JP2009524173A; US8032644B2; WO2007085589A2; JP5031772B2; US20090216884A1; EP1818816A1; WO2007085589A3; CN101375247B

Abstract

本发明涉及一种根据请求创建服务的方法(100)。本发明的方法包括步骤：包括对自然语言请求的语义分析(30)，该请求可以例如传输自便携式电话或个人数字助理(150)。通过这种方式，可以使用自然语言来阐述(10)请求，而不需要用户具有任何技术知识。上述语义分析(30)可以用于识别(35)Web服务需求(或规范)。随后，基于识别出的服务需求，确定(40)Web服务并且对其进行排序(50)。接着，使得新的服务对于例如做出对应的自然语言请求的用户可用。

Description

服务创建方法，用于实现所述方法的计算机程序产品和计算机系统

技术领域

本发明涉及一种服务创建方法，以及用于实现所述方法的计算机程序产品和计算机系统。

背景技术

在本文描述中，除非另作说明，否则以下术语被用于以下所指示的意思：

-“UDDI注册”：UDDI是“通用描述发现和集成”的缩写，“UDDI注册”是指基于XML的注册，更为特别地是专用于Web服务的注册，特别是在SOA(“面向服务的架构”的缩写)架构内。象用于某些服务提供商的特定注册那样，存在私有注册和公共注册二种。UDDI注册使得在网络上定位被搜索的Web服务成为可能。特别地，它包括用于访问Web服务的信息和上下文信息，诸如对服务及它们的功能的简要描述。特别地，UDDI注册包含：

-白页，其包括与业务相关的信息；

-黄页，其使用WSDL标准列出这些业务的Web服务；以及

-绿页，其提供关于所提供的服务的具体技术信息。

其中，这种技术信息尤其适于描述与其相关联的服务、链接或业务过程。

-“计算机应用”：是指旨在一起工作的任何程序或任何程序集合，其目的是向它们的用户提供服务。

-“BPEL”：BPEL，“业务过程执行语言”的缩写，是用于交互逻辑和交互协议逻辑的形式记号的XML语言，其扩展了Web服务交互模型的语义学。除了Web服务之间的交互之外，BPEL还描述了应用逻辑和这些交互的次序。

-“组合”：在Web服务的上下文中，其是指可作为新的分立的Web服务的服务集合。在通过“编制(orchestration)”的组合与通过“编排(choreography)”的组合之间存在不同：在通过“编制”的组合中，重点被放在对由组合的服务所执行的过程的排序上；在通过“编排”的组合中，各服务的次序是基于所交换的消息以及基于由组合的服务对事件的考虑。

-“输入参数”，是指作为输入提供给Web服务的处理操作的数据；由该操作来转换操作的输入数据以提供输出结果。

-“输出结果”是指由Web服务操作对它的输入数据(或“参数”)执行处理所得到的信息。输出结果是Web服务的用户所期望的产品，所述用户可能是计算机应用或另一Web服务。

-“RSS”(即“真正简单的整合”)是一种用于基于XML描述网页内容的格式，其使得自动索引网站的内容并使之可用成为可能。

-“Web服务”是指可经由标准接口通过因特网访问的应用，其可通过使用通信协议诸如基于XML的通信协议与应用或其他Web服务进行动态交互，并且不管使用的是何种操作系统或编程语言都可以这么做。考虑它的实际接口，Web服务包括基于输入数据或“输入参数”来提供结果的处理操作。为了使用Web服务，通过给其提供所期望的输入数据来调用操作之一，并且获得输出结果。

-“SGML”：用于描述数字文档的内容与其结构之间的关系的一种标准化语言。

-“WSDL”是由W3C(注明日期为2001年3月15日的版本1.1，参见http://www.w3.org/TR/wsdl)标准化的一种语言，特别地，其参考了XML。WSDL描述了一种对Web服务进行公共访问的接口，其使用以下元素：服务名称、操作、被操作的数据类型，以及在这些类型与这些操作之间的链接。通过这种方式，WSDL指出了：为了使用服务如何进行通信、通信协议以及与该服务进行通信所需的消息格式。

-“XML”(即“可扩展标记语言”)：对SGML语言的改进，特别地，该语言被HTML文档的设计者用于定义他们自己的标签，以实现对数据结构进行个性化的目的。

现代电信技术，特别是因特网，使得用户能够快速地访问各种各样的服务。如果一个问题重复出现，通常会创建某个合适的服务来满足用户的重复需求。例如，某些因特网搜索引擎提供诸如机器翻译之类的高级功能。然而，可能出现在用户身上的某些问题不能被现有服务解决。特别地，有时候用户(其不具备专业技术知识)在没有这种现有服务的时候，可能希望访问解决只出现一次的问题的服务。例如，IP终端(诸如移动电话、个人数字助理、袖珍PC等)的用户可能希望获得将给定的RSS服务翻译成他的或她的母语。

由此，需要一种基于(用户)请求来创建服务的方法以及用于实现这种方法的计算机程序产品和计算机系统。

发明内容

为了这个目的，本发明公开一种用于基于请求来创建服务的方法，该方法包括步骤：对自然语言请求进行语义分析；基于所进行的语义分析识别Web服务需求；以及基于识别出的服务需求来确定Web服务并对其进行排序。

在优选的实施例中，本发明用于创建服务的方法包括以下特点中的一个或多个：

-处理还包括编制已排序的Web服务的步骤；

-所述确定Web服务的步骤包括访问UDDI注册；

-所述对请求进行语义分析的步骤包括词法分析和语义分析；

-所述确定并排序的步骤被划分成确定Web服务以及接着对已确定的Web服务进行排序的步骤；

-所述确定Web服务的步骤包括：基于Web服务的描述来识别Web服务特点；将这些特点中的至少某些与识别出的需求进行比较；以及取决于比较的结果来确定Web服务；

-所述对Web服务进行排序的步骤还包括取决于识别出的需求来进行排序的步骤；

-Web服务特点的识别阶段包括，针对每个服务：访问Web服务的描述；以及从该服务的描述来识别该服务的特点；

-对Web服务的描述是用WSDL语言进行的；

-所述识别特点的步骤包括对Web服务的描述进行语义分析；

-所述排序步骤包括涉及到每个确定的服务的至少一个识别出的特点的兼容性测试；

-针对每个服务，识别出的特点包括：至少两个组，每个组都具有至少三个字段，其中一个组中的第一字段属于服务输入；另一个组的第一字段属于服务的输出；每个组中的第二字段属于与第一字段相关的数据类型，而每个组中的第三字段属于与第一字段相关的语义标签，组合步骤包括涉及到每个组中的三个字段的兼容性测试步骤。

-本发明方法还包括基于确定的且排序的Web服务来创建新Web服务的步骤；以及

-本发明的方法还包括步骤：接收针对确定的且排序的Web服务的核准；以及提供新的Web服务。

本发明还涉及一种能够实现本发明方法的步骤的计算机程序产品。

本发明还涉及一种包括能够实现本发明方法的步骤的代码装置的计算机系统。

通过阅读以下仅作为例子给出的对本发明的实施例的详细描述并且通过参考这些例子以及所附的图(唯一的图)，本发明的其他特点和优点将变得明显，其中，附图描述了根据本发明的一个实施例的方法的步骤和组件。

通过这种方式，本发明公开了一种用于基于请求来创建服务的方法。该方法包括对自然语言请求，诸如从便携电话或个人数字助理发送来的自然语言请求，进行语义分析的步骤。因此，请求可以用自然语言来阐述，而不必要拥有任何专业技术知识。所进行的语义分析使得能够识别Web服务需求(或规范)。接着，基于识别出的服务需求来执行对Web服务的确定或排序。于是，使新的服务诸如对做出相应的自然语言请求的用户而言成为可用的。本发明方法使得可基于(例如)来自移动电话的用自然语言表述的请求，通过集合因特网上能发现的现有组件Web服务来创建新服务，并且接着在(如果可行)核准所提议的组件服务的顺序之后使该新服务对于用户而言是可用的。

这种方法优选地实现在“集成的”计算工具内，所述计算工具诸如是包括多个耦合的软件模块的助理或应用，这些模块中的每个都分配有给定的任务。

附图说明

唯一的附图描述了根据本发明的一个实施例的方法的步骤和组件。

具体实施方式

参考该图，本发明的服务创建方法100包括对自然语言请求进行语义分析的步骤30。

例如，该请求可能已经由用户120从个人数字助理150进行阐述(步骤10)。接着，它通过电信网络进行传送(步骤20)并且被服务器(未描绘出)接收。例如，该文本可能是：“我想将路透社的公告文本翻译成德语”。

应当注意，可以在服务器侧或者客户端侧(诸如在所述客户端的移动电话或者个人数字助理内)实现上述计算工具。

例如，分析请求的步骤30可以通过使用句法分析器(或“解析器”，也即一种能够基于对句法单元的识别来分析描述的工具)或耦合到语义分析器的句法分析例程来进行。将这种句法分析和语义分析的耦合称为(第一)“语义模块”。通过定义，该模块能够集成到上述计算工具中，并且其目的是进行对请求的语义分析。

该分析使得可以用计算机可读格式来逻辑地构造请求。对自然语言文本的各种语义分析技术是公知的。通常，从请求中抽取或推导出名称、它们各自的定义、以及这些名称之间的操作。为了这么做，如现有技术中所公知的那样，使用了字典或语法分析。

特别地，语义分析步骤30可以首先包括词法分析。在前面的例子中，词法分析的第一结果是一列相关单词，或当需要时还有它们的标准形式(不相关的单词被忽略)。在表1中描述了该列表。

相关单词	标准形式	同义词
相关单词	标准形式	同义词	获得
德语	德语		获得
德语	德语		翻译	译文，翻译	译本
文本			翻译	译文，翻译	译本
文本			路透社
新闻		公告，当前事件	路透社

表1

其次，可以由语义分析模块添加一条上下文特有的语义信息，如表2中所指出。

相关单词	标准形式	同义词	附加的语义信息
相关单词	标准形式	同义词	附加的语义信息	获得	显示
德语	德语		语言语言	获得	显示

翻译	译文，翻译	译本
翻译	译文，翻译	译本		文本
路透社			公司名称	文本
路透社			公司名称	新闻	公告，当前事件	公告，当前事件，种子

表2

于是，对请求进行词法和语义分析的步骤使得可以识别(步骤35)针对组件Web服务的需求(也即“规范”)。在前面的例子中，考虑附加的语义信息和原始请求的语法形式，语义模块可产生以下针对组件服务的需求：

-获得/显示文本

-文本的译文/文本的译本/翻译文本

-语言＝德语

-新闻/公告/事件/种子(feed)

-公司名称＝路透社

此外，可以用与WSDL格式(参见上面的定义)相当的格式来构造这些需求，以便推动以下步骤，也即确定40Web服务和对其进行排序50。稍后将提供详细描述。

这两个步骤40、50优选地被划分成确定40Web服务的步骤和对已确定的Web服务进行排序50的步骤。通过这种方式，在服务已被确定之后，可以提议一个排序供用户核准(步骤52)。接着，用户可核准它(步骤55)，或者组合其自己的次序，其接着引起机器排序，这里由恰当的模块来处理。

作为替代，Web服务还可一个接一个地被确定，并且接着被提交用于部分和逐步地排序。在这种情况下，确定步骤40和排序步骤50是嵌套的。然而，在排序完成之后，仍可将排序提交给用户进行核准。同样，应当注意可以按照基于预先确定的标准所计算出的次序来提议多种排序。

在一个实施例中，确定Web服务的步骤40包括基于所述Web服务的描述来识别Web服务的特点。在该步骤期间，可用的Web服务可以例如被系统地察看。针对它们中的每个，识别特点，并且在这些特点中的至少某些特点与先前已设置的需求之间进行比较。于是，这使得基于比较的结果来确定Web服务成为可能。

并且关于对Web服务特点的识别的更为详细的方式，使用了这些服务的标准化描述。优选地，使用了Web服务的各自的描述。通过这种方式，针对给定的Web服务，上述计算工具访问服务的描述并且接着基于它的描述来识别具体特点。应当注意，这些特点不是照此显式存在于服务的描述内。它们是由本发明方法推导出的。

优选地，是使用Web服务的各自的描述，特别是如上面所限定的诸如UDDI注册之类的描述目录可用的条件下，尤其如此。

优选地，服务的每个描述是用WSDL语言描述的，如用例如UDDI注册进行的那样。通过这种方式，标准化描述对于每个Web服务都是可用的。此外，这种描述在注册服务器上总是可用的，因为它是由该服务器从所发布的Web服务外部的接口自动编译的。这提供了与本方法的更大的兼容性。

此外，还可以诸如通过使用句法分析器(或“解析器”，如上面所描述)自动地分析这种描述。下面参考了(第二)语义模块。由此，该第二模块的功能是语义上分析WSDL描述。

更为详细地，句法分析器可以例如包括词法分析，诸如现有技术中所公知的那样。接着，进行对Web服务的描述的语义分析，目的是确定已抽取的词法组件的意义。

分析服务的描述使得可以识别每个服务的特点。例如，它使得可以识别针对服务的每个操作的各组特点。稍后，这些特点被用于确定识别出的服务的连接性。

因为先前设置的需求与识别出的特点被优选地类似地构造，所以对它们进行比较变得更容易(诸如通过基于共享的特点的数量)和更快。当该比较完成，并且针对给定的一组需求，确定一个Web服务(或多个)。如果可行，则确定排名以及接着仅保留“最佳”服务(在比较的意义内)是有益的。

当确定组件Web服务的步骤35完成时，给定数量的已知服务是可用的。接着，期望基于在请求中表达的逻辑来组合这些服务。

为了这么做，识别出的特点可用作为基础，所述特点反映先前设置的需求。接着，这些特点将使得可以确定服务的连接性，也即服务连接的可能性。接下来，将可以基于这些服务的连接性来自动地组合这些服务。

在Web服务的各特点中，可以例如尝试识别针对给定Web服务的每个操作的至少一个输入和/或输出。

更为普遍地，可以例如搜索每个服务的每个操作的输入-输出，作为“输入参数”或“输出参数”(参见前面这些术语的定义)。通过这种方式，接着可以通过比较它们的操作的输入/输出特点来测试Web服务的连接性。例如，具有提供了与服务B的操作的输入相兼容的输出的操作的服务A可以连接到服务B。

为了确定服务的连接性，以及着眼于这些服务的将来的组合，在一个实施例中，可以针对给定Web服务的操作的每个输入和每个输出创建一组特点。

如果Web服务的一个操作具有多个输入或多个输出，则一旦Web服务的描述已经被分析，就可以创建相应数量的组。

除了参数自身的名称之外，这些组还可以例如每个都具有三个字段(或更多字段，取决于所安排的测试模型)。然而，应当注意，结果可能是使用两个字段就足够了，这取决于WSDL描述是被如何解析的。

由此，每个组优选地具有三个字段并且是关于Web服务的操作的输入参数或输出结果。第一字段是关于针对正被讨论的参数或结果的输入或输出信息。每个组的第二字段指明了参数或者结果的数据类型。数据类型是在服务的WSDL描述中的元素之一。第三字段是关于语义标签(或下面的例子中的“SemTag”)，其将与参数或结果相关联。语义标签此处可视为名称、字符串，或者更为普遍地，视为与数据相关联并用于进一步在语义上表现其特征的代码。应当注意，如果可以直接从WSDL描述中抽取类型，则在分析该同一描述之后放置标签。

接着，特点的兼容性测试可涉及每个组的每个字段。

上述第二语义模块(通常形成前述计算工具的组成部分)可以用于在每种数据类型上(在输入和输出处)放置语义标签。该标签指明输入/输出数据的性质并且因此指明如何处理数据。通过这种方式，每片输入/输出数据由一个三元组来描述：

{输入或输出、数据类型、语义标签}。

下面所示出的是通过使用三个字段对与稍后将提及的Web翻译服务的输入的语义描述相对应的XML文件的提取(该XML文件提取是对相应的WSDL文件执行语义处理的结果)：

...

<input>

</input>

...

通过这种方式，可以看出，除了输入信息之外，每个参数承载对应着它的名称、它的类型以及它的语义标签(“semtag”)的三个字段。接着在针对服务之间的兼容性的测试期间将使用的三条信息是：输入或输出信息、类型信息和语义标签。

现在，给出关于语义分析的更为详细的解释。

无论何时WSDL文件被分析：四个主要部分可以被识别，其对应于类型、消息、操作和服务名称。此外，对应于“端口类型”和“绑定”的其他信息被识别(这两个术语是WSDL描述中的惯用术语)，其将用于在操作的输入/输出与消息之间创建连接。

对WSDL描述的第一且纯句法的分析级别使得可以获得关于服务的“有用的”句法结构，也即必要且足够的信息。这种信息主要从上述四个部分来获得。对于搜索而言无用的元素被移除。剩余的信息被重新排序并通过使用“绑定”和“端口类型”信息而互连。这容易通过使用句法分析器来实现。在该级别上，语义数据还没被添加。

作为举例，所获得的用于翻译服务的有用的句法结构是下面这样(其中术语来自XML语言)：

<types/>//该输入为空，因为在该例子中没有任何复杂类型

<input>

</input>

</output>

</operation>

</service>

基于有用的句法结构，使用第二语义模块进行更精确的分析。该模块可以例如承担以下操作任务。它挑选出所使用的术语(上面，术语“Translate”、“lang”、“text”、“TranslateResult”等等)并且分解它们(这些术语通常用类似于在编程语言中所使用的术语的方式写出，或者用诸如“_”之类的字符分隔开，等等)，目的是使这些术语“解开连接”。如果有必要，则该模块接着扩展被截断的术语(诸如通过在字典中进行查找)。在前面的例子中，这给出“translate(翻译)”、“text(文本)”和“translate result(翻译结果)”。在完成这之后，通过使用恰当的字典，尝试将名词与遇到的每个动词以及每个名词的定义关联起来。如果可行，检查这些定义以保留某一个而不是另一个。互补技术是公知的，其在可以应用的条件下使得可以简化这些处理任务并容易地获得可用结果。

上面给出的第五个步骤的主要目的是将语义标签添加到服务的上述有用的句法结构中的每个输入/输出的每个名称上。通过这种方式，将针对对应的输入“text”放置标签“text”。通过这种方式，获得了改写的服务描述。在翻译服务的例子中，获得了与上面所描述的对XML文件的提取相类似的描述。

放置语义标签-其可视为“超级标签(supertag)”-使得可以有效地确定Web服务的连接。然而，其他语义分析技术也可用于这种放置。

在这一点上，存在能够使一个Web服务连接到另一个Web服务的全部组件。

下面，通过使用例子来描述确定Web服务的连接性的步骤。

在该例子中，用户在他的请求中表述他希望看到显示的来自翻译服务和RSS服务的对RSS种子(诸如从报纸网站中抽取的一个)的翻译结果。RSS种子从新闻站点自动地复制，特别是复制标题行或者全文。这种格式特别用于利用其内容定期更新的页面。

在这种情况下，假定在这一点上，请求已经被翻译并且接着被分析，已经从请求中提取了Web服务需求，并且最终已经通过查阅UDDI注册发现了这些Web服务。由此，必要的Web服务是可用的。现在，出现的一个问题是如何自动组合这些服务以获得对一段RSS内容的机器翻译。

首先，用于翻译的Web服务是可用的，其拥有输入(用第一语言或语言“1”编写的文本)和输出(用第二语言或语言“2”编写的另一文本)。分析对应的WSDL描述，导致识别输入数据和输出数据，通过以下三元组组来描述：

{输入1，类型＝string，语义标签＝待翻译的文本}；

{输入2，类型＝string，语义标签＝语言1}；

{输出1，类型＝string，语义标签＝已翻译的文本}；以及

{输出2，类型＝string，语义标签＝语言2}；

单词“string”是指字符串。

提供RSS种子的Web服务也是可用的。在由上述工具进行了分析之后，该Web服务可以例如提供如下所指明的输出：

{输出1，类型＝string，语义标签＝标题行}；

{输出2，类型＝string，语义标签＝标题行的语言}；

{输出3，类型＝string，语义标签＝描述}；以及

{输出4，类型＝string，语义标签＝描述的语言}；

...

此外，显示服务是可用的，它在分析之后可如下读取识别出的特点：

{输入＝待显示的文本，类型＝string，语义标签＝文本}；以及

{输出＝显示，类型＝屏幕，语义标签＝显示}；

接着，确定待组合的每个服务的连接性，优选地是每次两个。为了达到这个目的，可以搜索一个Web服务的输入与另一服务的输出之间的语义对应，也即两个语义三元组之间的兼容性。

特别地，这种兼容性可满足三个条件：

a)第一三元组属于输出，另一个三元组属于输入

b)两个类型是相同的或可兼容的

c)两个语义标签是相同的或可兼容的。

出于该目的，可以针对上述计算工具提供兼容性表并使该兼容性表对于上述计算工具是可用的。

在上面的例子中，按下述方向自动地发现兼容性：

RSS服务->翻译服务->显示服务

实际上，对于语义模块可用的表格使得可以通过使用每个服务来创建完美的每次两个的匹配。

另一方面，顺序“RSS服务->显示服务->翻译服务”将不再被考虑，因为显示服务的输出与翻译服务的输入之间的语义不兼容。

应当注意，如果可行，迭代过程或“重复处理”可以被采纳，目的是将给定数量的来自第一服务的相同类型的输出耦合到来自另一服务的输入。在前面的例子中，这特别有用。通过这种方式，每个RSS服务输出(标题、描述，等等)被翻译并且接着被显示。

更为详细地，可以在两个步骤中执行对Web服务的连接性的确定：

i)首先，基于从检查它们各自的输入-输出所提取的逻辑次序；以及

ii)接着，通过输入-输出它们自身的连接，基于它们的语义标签和它们的类型的详细描述(通过进行上述兼容性测试)。

通过这种方式，某个具体的模块被赋予全面确定用于编制这些服务的次序(服务X在服务Y之前，等等)的任务，并且在更为详细的级别上接着确定一个服务的哪个输出连接到另一服务的哪个输入。

如果可行并如上所述，全面的编制次序可以被提议(步骤52)给用户进行核准(步骤55)。然而，该用户可以决定改变该次序或者引入另一服务。

该编制次序可以例如基于规则数据库内可实现的直观推断来确定，并在推理引擎的控制下来放置。例如，如果服务A在其输入-输出处拥有对应于文本的语义标签，并且服务B在其输入处具有不同或不兼容的标签，则次序将优选地是：B，接下来A。

在上述例子中：首先，RSS服务被调用，其输出具有对应于文本的语义标签(输入标签可以例如对应于Web地址，并且不同于“文本”)。接着，翻译服务被调用，翻译服务在其输入和输出处具有对应于文本的标签。此外，RSS服务的输出可连接到翻译服务的输入。

考虑到从语义标签与类型标签的比较中可以看出的明显的不兼容性，所提出的自动连接将如下：

-对应于RSS服务的标题行的文本输出可以被连接到翻译服务的(唯一的)文本输入；以及

-对应于RSS服务的描述的文本输出可以连接到翻译服务的(唯一的)文本输入。

这些提议可以被直接地保持用于后续的组合步骤，或者如果可行，可以供用户核准，如上面所描述的那样。

接着，一旦连接性已经建立，取决于Web服务的连接性，Web服务的实际组合由专门的汇编模块来执行。为了这个目的，连接的字符串可以例如被翻译成形式化的编制(orchestration)或编排(choreography)语言，诸如BPEL(参见本文档开始处的定义)。连接的字符串接着可以被提交给编制引擎，其将负责执行它(步骤60)，因为它是分立的Web服务。特别地，以下类型的连接的字符串：

服务A的“输入1”＝>产生“输出1”

->服务B的“输入2”＝>产生“输出2”

->服务C的“输入3”＝>产生“输出3”

可以被翻译并接着被提交给编制引擎，编制引擎将它作为由A、B和C组成的分立的服务D来执行，并且给定输入1时其可以直接提供“最终结果3”。

该汇编模块接着使得可以自动连接Web服务。

通过这种方式，就获得了由所述计算工具自动地组合(步骤60)的服务。

使得以这种方式组合的服务对于用户是可用的(步骤65，70)。

作为一个替代选择，服务还可以保留(在这种情况下，它被创建)对于用户可用，并且如果可行，可以保留一段给定的时间。

将该工具集成到某个应用使得可以实时获得服务的组合。在上面的例子中，可以基于请求获得被翻译成想要的语言的指明了必须元素的RSS种子。

自然，其他例子和组合可以被预见。

Claims

1.一种根据请求创建服务的方法(100)，包括步骤:

-对自然语言的请求进行语义分析(30)；

-基于所进行的语义分析(30)识别(35)Web服务需求；以及

-取决于识别出的服务需求来确定(40)Web服务并对其进行排序(50)。

2.根据权利要求1所述的方法(100)，还包括编制(60)已排序的Web服务的步骤。

3.根据权利要求1所述的方法(100)，其中所述确定Web服务的步骤包括访问UDDI注册(200)的动作。

4.根据权利要求1所述的方法(100)，其中所述对请求进行语义分析的步骤包括:

-词法和语义分析(30)。

5.根据权利要求4所述的方法(100)，其中所述确定(40)并排序(50)的步骤被划分成确定(40)Web服务和接着对所确定的Web服务进行排序(50)的步骤。

6.根据权利要求5所述的方法(100)，其中所述确定(40)Web服务的步骤包括:

-基于Web服务的描述来识别Web服务的特点；

-将这些特点中的至少某些特点与识别出的需求进行比较；以及

-基于所述比较结果确定Web服务。

7.根据权利要求5所述的方法(100)，其中所述对Web服务进行排序(50)的步骤还包括步骤:

-基于识别出的需求来进行排序。

8.根据权利要求6所述的方法(100)，其中所述识别Web服务的特点的步骤包括:针对每个服务，

-访问所述Web服务的描述；以及

-基于所述服务的描述来识别所述服务的特点。

9.根据权利要求8所述的方法(100)，其中所述Web服务的描述是用WSDL语言进行的。

10.根据权利要求6所述的方法(100)，其中所述识别特点的步骤包括对Web服务的描述的语义分析。

11.根据权利要求6所述的方法(100)，其中所述识别出的特点包括每个确定的服务的输入和/或输出。

12.根据权利要求6所述的方法(100)，其中所述排序(50)步骤包括:

-涉及到每个确定的服务的至少一个识别出的特点的兼容性测试。

13.根据权利要求11所述的方法(100)，其中针对所述服务中的每一个，所述识别出的特点包括:

-至少两个组，每个组具有至少三个字段，其中:

-一个组中的第一字段属于所述服务的输入；

-另一个组中的第一字段属于所述服务的输出；

-每个组中的第二字段属于与所述第一字段相关的数据类型；

-每个组中的第三字段属于与所述第一字段相关的语义标签；

以及其中组合步骤还包括:

-涉及到所述每个组中的三个字段的兼容性测试步骤。

14.根据权利要求1所述的方法(100)，还包括步骤:

-基于所述确定的且排序的Web服务来创建(60)新的Web服务。

15.根据权利要求14所述的方法(100)，还包括步骤:

-接收(55)对所述确定的且排序的Web服务的核准；以及

-使得所述新的Web服务可用(65)。

16.一种计算机程序产品，其能够实现权利要求1至15中的任何一项所述的方法(100)的各步骤。

17.一种计算机系统，其包括能够实现权利要求1至15中的任何一项所述的方法(100)的各步骤的代码装置。