1、基于自动化技术的Web Service的研究在这篇文章中，我们主要提出了一些最新的将自动化用于Web service组成的方法。这里的自动化意思是方案能自动产生过程模型，或如果抽象过程模型已给出，方案就能查找到合适的服务。Benatallah5提出了一些基于工作流的方案。但是据我们的知识，现在还没有一个和人工智能相关的关于服务组成方案的概述发表出来。因此，我们在人工智能方案上要比基于工作流的方案投入更多的注意力。在从前很多方面，人们可能讨论一个组成服务和一个工作流8很相似。组成服务的定义包括自动服务的建立和服务间控制和数据的传递。相似的，一个工作流程详细说明了工作项目的流程。现在在这种灵活的工
2、作流程中取得的成绩，自动过程的适应，跨企业的整合同样也为自动化Web service组成提供了方案。另外，动态的工作流程方法也提供了连接抽象的节点和具体资源或自动服务的工具。另一方面，动态的组成方法被用来自动的产生方案。在这个类别的大多数方法和人工智能计划、演绎法证明相关。这种方法一般假设每一个Web service由计划的前提和结果来确定。首先，Web service是一个软件，它会接受输入的数据和产生输出的数据。因此，前提和结果就分别是服务的输入，输出参数。第二，Web service也在执行以后改变系统的状态。所以，系统的状态预先要求服务执行是前提，新的状态在执行后产生是结果。一个典型的
3、例子是登陆网页的服务，输入的信息是用户名和密码，输出是确认的信息。执行完毕后，系统状态就会由未登录变成登录。登录的状态会一直保持到调用离开系统服务。如果用户能指出组成服务要求的前提和结果，那么运用逻辑定理证明或人工智能计划，而不需要预先确定的工作流程知识，一个计划或是一个过程就会自动产生了。在这个计划中，业务逻辑会在计划制定中产生一些约束。这篇文章的内容如下,第二部分讲述了Web service组成的大概框架，第三部分介绍了基于工作流方案的自动化Web service组成。Web service组成框架这里，我们提出了一个关于自动Web service组成的一般框架。这个框架是一个高层的抽象，
4、它不考虑合成进程中特殊的语言，平台或算法。这个框架的目的是给出一个讨论相似和不同的有用服务组成方案的基本参考。除此之外，我们还用框架来统一文章中用到的项目。一般服务组成系统的框架见fig.1。这个组成系统有两个参与者：服务提供者和服务请求者。服务提供者提供Web service供使用，服务请求者使用服务商提供的信息或服务。这个系统也包含了下面一些组成部分：翻译器、进程生成器、评估器、执行器和服务库。翻译器将参与者使用的其他的语言翻译成进程生成器使用的内部语言。对每一个请求，进程生成器都尽力产生一个计划在服务库里组成一个有用的服务来执行请求。如果找到了多个计划，鉴别器就执行计划并将结果返回给服务
5、提供者。更准确的说，自动化服务组成的过程包括以下一些短语：单服务显示：首先，服务提供者会在全球市场上宣传他们的原子服务。这就需要有多种可用的语言来做宣传。比如说，UDDI4或DAML-S Service Profile14。描述Web service的本质特征包括签名、状态、无函数值。签名由服务的输入、输出和异常来表示出来。它提供了在Web service的执行中数据转换的信息。状态由前提条件和后置条件来说明。我们把它作为模型，将一个状态的设置转换成其他的状态。无函数值有些特征，这些特征用来评价服务，比如成本、服务质量和安全问题。语言翻译：大多数服务组成系统在外部和内部服务规范语言不同。在某种
6、程度上，使用服务的用户用外部语言加强用户的可访问性，使用户能用一个相关简单的方法表达出什么是他们能提供的和什么是他们想要的。这些语言通常和合成进程生成器使用的内部的语言不同，因为这个进程产生器要求更多的正式和精确的语言，比如说逻辑程序设计语言。到现在为止，用户已经习惯了标准Web service的语言，如WSDL和DAML-S。因此，标准Web service语言和内部语言之间的转换成分还需要发展。合成进程模型的产生：服务请求者也能用服务规范语言表达出他们的请求。那么进程生成器试着用服务提供者宣传的组成自动化服务来处理这些请求。进程生成器通常会取出服务的功能部分：描述组成服务的输入和输出进程模
7、块。进程模块包括了一个选择自动化服务的初始化，控制流和数据流。组成服务的评估：很多服务有相同或相似的功能，这是十分普通的。所以计划产生器（planer generate）比一个组成服务能更好的完成请求，这是很可能的发生的。在这个例子中，使用无函数（functional）的性质提供的信息，它们的全部实用程序来评估组成服务。最常用的方法是实用的函数。请求者需要规定每一个无函数性质的权重，最好的组成服务是排在首位。组成服务的执行：在唯一的组成进程被选择后，组成服务就准备执行了。根据进程模块，组成Web service的执行被认为是信息传递的序列。组成服务的数据流被定义为一个动作，这个动作是以前执行服
8、务的输出数据传输给最近的执行的自动化服务的输入。在以上部分，我们给出了一个用于进程产生器产生进程方法的概括。这个方法可以实现全部自动化或半自动化。使用工作流技术的Web service组成在基于工作流的方案中，我们应该区别静态和动态的工作流的产生。静态工作流就是请求者需要在组成计划开始之前建立一个抽象的进程模块。这个抽象进程模块包括了任务的建立和数据相关性。每个任务包括查询子句，查询子句用来查找真正的原子网络服务来完成任务。在这个工作中，只有原子网络服务的选择和绑定是项目自动完成的。最常用的静态方案是用图表详细说明进程模块。另一方面来说，动态组成不仅自动创建了进程模块，还自动创建了选择原子服务
9、。请求者规定了一些约束条件，包括原子的相关性，用户的优先权等等。EFlow是一个合成服务的说明，设定，管理的平台，EFlow使用静态工作流程产生的方案。一个合成服务被曲线图模型化了，曲线定义为在进程中节点之间执行的顺序。这个曲线图是被人工创建的，但是它可以进行动态的更新。曲线图可包含服务，判断，事件节点。服务节点描述的是原子或合成服务的调用，事件节点启动服务进程来发送和接收一些类型的事件。图表中的弧线表示节点之间执行的相关性。虽然图表需要人工说明，但是EFlow提供了自动绑定节点和固定的服务的功能。服务节点的定义包括查找配方。这个配方用于在进程实例时间或运行时间内询问实际的服务。因为服务节点开
10、始了，查找配方也开始执行。返回一个参考值给具体的服务。特别地，当服务节点开始活动时，查找配方（search recipe）也在运行。它们这样做是因为服务的有效性在高度动态的环境中会不断的变化。作者更加细化了服务合成的平台和拟定了集成服务定义语言（CSDL） 。CSDL一个有趣的特征是它可以区分一个服务内的服务和业务的调用。它还有合适的动态的特征，可以处理快速发展的商务和在IT环境里执行Web service。多形进程模块（PPM）运用了静态和动态服务组成的结合。用参考基于进程的多企业进程来支持静态设置。进程由抽象子进程组成。比如：子进程有功能的描述但是却缺少执行过程的说明。抽象子进程由服务和（bined）运行时执行。这和EFlow里的服务绑定相似。PPM的动态部分由基于服务的进程支持。这里，服务被状态机模型化了。这个状态机详细说明了服务和它们翻译可能的状态。翻译过程由服务运行（也叫服务活动）调用或内部服务翻译来解释。在设置里，动态服务组成由依靠状态机的推理操作。
