Web服务的语义表示模型

导读：

　　对Web服务的描述包括形式和内容（语法和语义）两个方面。在形式方面，需要采用XML、WSDL等相关标准；在服务的内容描述方面，如服务的功能、性能等的描述，需要制定一套描述语义的标签以及标签之间的关联、规则，比如用OWL-S。可以说，完整的服务描述模型是建立基于Web服务的动态应用集成的基础[35]。而无论何种形式的表示，这种包含Web服务各方面信息的描述都是由Web服务提供者来掌握的，如果Web服务的使用者想要了解这些信息，就必须亲自与Web服务提供者取得联系来获取，而这种方式对于想要完成Web服务自动组合功能来说无疑是非常不利的。因此，一种解决办法就是把Web服务的相关描述信息扩展到UDDI中，而对于针对某一领域内的Web服务组合来说，服务的表示还需要相应的分类标准以及每类服务所对应的属性方面，这些需要有行业本体作为支撑，综合这两方面，我们可以在UDDI中建立一个比较全面的Web服务表示模型。在此之前，让我们先来看一下公共UDDI中对Web服务的信息描述。

　　公共UDDI中Web服务的信息描述构成Web服务商业注册的信息描述包括六种数据结构类型，这六种数据结构中包含了描述Web服务的机制。这种根据信息类型的划分为快速定位和理解构成商业注册的不同信息提供了一种简单的划分方法。UDDI注册使用的核心信息模型由XML Schema定义，它们是技术人员在需要使用合作伙伴所提供的Web服务是必须了解的基本技术信息。其中UDDI2.0定义了六种类型[10]：商业实体信息businiessEnitity、服务信息businessService、绑定信息bindingTemplate、技术规范tModel和关联关系断言publisherAssertion。在UDDI3.0中新增了一个信息类型：subscription实体订阅信息。

　　 商业信息实体： businessEntity 元素

　　在商业领域内，合作伙伴和潜在的合作伙伴都期望能准确地定位到商业实体所能提供的服务或产品的相关信息。而在技术领域，技术人员、程序员或应用程序都期望能知道他们需要集成的商业实体的名称和一些关键性的标识，以及该商业实体是属于那个具体工业分类之类的分类信息，以及联络方法(包括Email、电话、URL)等。这些信息都包含在"businessEntity"结构中，它是商业实体专属信息集的最高层的数据容器，位于整个信息结构的最上层。所有"businessEntity"中的信息支持"黄页"分类法。因此可以执行这样的搜索，如可以定位属于某个行业分类或提供某种产品的企业，也可以是定位处于某个地域范围内的企业。

　　 服务信息： businessService 元素和 bindingTemplate 元素

　　businessService 结构将一系列有关商业流程或分类目录的Web 服务的描述组合到一起。businessService和下面要提到的bindingTemplate一起构成了"绿页"信息。其中，一个可能的商业流程的例子是一组相关的Web 服务信息，包括采购服务、运输服务和其它的高层商业流程。这些服务都将是提供这些商业流程服务的商业实体所需要注册的Web服务。

　　对于每一个businessService，存在一个或多个Web 服务的技术描述bindingTemplate。这些技术描述包括应用程序连接远程Web 服务并与之通讯所必须的信息。这些信息包括Web应用服务的地址、应用服务宿主和调用服务前必须调用的附加应用服务等。另外，通过附加的特性还可以实现一些复杂的路由选择，诸如负载平衡等。

　　 规范描述的指针和技术标识： tModel 元素

　　当一个程序或是程序员需要调用某个特定的Web服务时，必须根据应用要求得到了足够充分的调用规范等相关信息，以使调用被正确地执行。因此，每一个bindingTemplate元素都包含一个特殊的元素，该元素包含了一个列表，列表的每个子元素分别是一个调用规范的引用。这些引用作为一个标识符的杂凑集合，组成了类似指纹的技术标识，用来查找、识别实现了给定行为或编程接口的Web 服务。实际上，这些引用是访问服务所需要的关键的调用规范信息。被称为"tModel"的数据项是关于调用规范的元数据，它包括服务名称，发布服务的组织以及指向这些规范本身的URL指针等。通过这种方式，很多公司可以提供与该调用规范相兼容的Web 服务。

　　 描述商业实体之间关联关系的关联信息： publisherAssertion

　　在200年7月发布的UDDI规范2.0版中引入了一个基于“发布者断言（publisher assertion）”的断言特性。发布者断言是这样一种机制的基础，这种机制能令多于一个的已注册的bussinessEntity元素以某种方式互相链接，用以表示一种特定类型的关联关系。发布者断言一旦完整创建，即被用于在已注册的数据中建立标准可见的关联关系。围绕使得商业实体能在不同的组成部分之间描述关联关系的设计目标是为了满足大型商业实体为在UDDI中描述数据的需要，使得他们在UDDI注册中心中能以多个组成部分的形式来实施注册。同时对于其中的每个商业个体都有很多不同种类的Web Services需要描述。在UDDI规范2.0版之前，那些想对非常复杂的商业实体进行建模的注册这是无法完成需要的功能的。

　　 实现实体信息订阅的订阅信息： subscription 元素

　　在UDDI1.0/2.0中，并没有包含subscription元素，就是没有考虑订阅功能。然而，对于公共UDDI注册中心，是面向海量数据注册的，对于UDDI的使用者而言，保持对感兴趣的数据实体的跟踪是非常重要的，如果每次需要查询数据都要到这个海量数据库中进行，或者当数据发生了更新，使用者要查到他下一次查询UDDI注册中心时才能发现数据的更新，那么这对于UDDI的使用而言是极不方便的，为了解决这个问题，UDDI3.0添加了subscription元素，以帮助UDDI的使用者收到UDDI注册中心所主动发出的数据更新消息。

　　Web服务描述的语义扩展

　　在对SDOWSCS进行最初设计时，选定了自助旅游领域作为我们的研究背景，目的是通过对此领域内Web服务组合的研究，抽象出一个通用于每个专业领域的Web服务组合系统。而对UDDI中Web服务描述进行语义扩展也是通过对此领域内的各种活动进行分析后得出的。为此，我们首先有必要了解一下理想状态下的组合服务模型。

　　组合服务模型在参考一些应用实例和生活常识后，我们以自助旅游为例，建立了组合服务的模型.

　　模型图中的活动状态表示在一个组合Web服务模式中的一个基本的Web服务。基本的Web服务是由互联网上提供的。不同的Web服务提供者可能提供相同的基本Web服务。此外，开始节点表示此过程的开始，结束节点表示此过程的结束。分支节点是一系列由同一个状态分出的跃迁，过程将执行每一个满足跃迁条件的活动状态。箭头表示流程在Web服务之间的依赖关系及执行顺序。一个组合的Web服务实例是一个组合Web服务的流程模式的执行过程。这样一个组合Web服务模型可以被多次实例化，也即可以重复执行多次。

　　分类标准为了更方便快捷的实现Web服务的注册、发布和发现，UDDI中需要提供一个对注册进UDDI的所有Web服务进行分类的一个分类标准。前面曾提到，有效的分类是基于服务描述中提供的有效的信息和代理所使用的合适的分类方法。服务可以被注册到多个分类中，提供与这些分类相匹配的功能。在公共UDDI中，对Web服务的分类是体现在businessEntity和businessService数据结构中，在这两个数据结构中存在一个字段名为categoryBag字段，它是一个名/值对的可选列表，这些名/值对用于为Web服务标注相关的特定分类法信息。目前公共UDDI注册中心操作入口站点默认提供对三种分类法的有效支持，这三种分类法是工业代码（NAICS）、产品与服务分类（UNSPSC）和地理分类（ISO 3166）。

　　而在SDOWSCS中，由于定义的服务组合是针对某一特定领域的，所以需要根据这一领域定义符合领域要求的分类标准以及分类粒度。对自助旅游领域来说，我们根据该领域所涉及的服务类别进行分类，比如预订票、预定旅馆、租车等等，预定票中又包括预定机票、预定火车票等子类别。根据这些分类以及每一类服务所具有的公共属性来确定这类服务的框架，这些分类和属性等信息一起构成了行业本体（关于行业本体的建立详见3.2节）。除了这些与自助旅游直接相关的类别外，还需要一些辅助类别来更好的支撑Web服务的组合。比如对于两地点之间进行距离计算的服务，系统使用者在进行出行工具选择的时候往往会需要得知出发地与目的地之间的距离来决定做火车还是坐飞机。这样，这些辅助类别及其相关信息也需要加入到行业本体中，支持对UDDI的扩展。

　　Web服务属性的扩展在公共UDDI中，只是包含了一些最基本的信息，包括Web服务提供者自身的描述、服务的基本描述以及服务访问方式的描述。而对Web服务自身更详细信息的描述，主要是在服务提供者方利用WSDL进行描述。WSDL文档将Web服务定义为服务访问点或端口（Port）的集合。但是，由于WSDL集中描述与服务调用有关的具体细节，例如网络协议、消息格式、参数的类型等，也就是集中在Web Services的物理信息的描述上，而没有充分地描述服务的语义信息和性能信息。对于Web Services的动态组合来说，仅仅依靠WSDL描述的物理信息，还不能完全达到这些目标。这就要求在WSDL之外提供服务的语义描述信息和性能信息，从而便于实现以下任务：服务的发现、调用、互操作、组合、验证、执行监控等。

　　OWL-S就是一种用来描述Web服务的属性和功能的本体规范，它的目标是使得Web服务成为计算机可理解的实体。在OWL-S中，描述服务的基本信息主要有三个基本类[36]：

　　1)

　　Service Profile：描述服务做什么？它给出服务查询代理需要用来判断服务是否适合他的要求的一组信息。

　　2)

　　Service Model：描述服务如何工作？它描述了服务执行时发生了什么，具体的逻辑执行顺序。

　　3)

　　Service Grounding：描述如何访问服务？它描述访问服务使得通信协议及其他一些特定细节。

　　OWL-S侧重在服务的语义描述模型，对于如何从具体服务的WSDL描述文件到各个语义描述文件的生成没有明确阐述。

　　不管是WSDL还是OWL-S，它们对Web服务的描述都是由Web服务提供者所提供的，确切的说是它们所描述的Web服务在物理空间上是存在于Web服务提供者一方的，其中包含了Web服务的实现细节。而在SDOWSCS中，对Web服务属性进行扩展的目的是在UDDI中建立一个比较全面的Web服务表示模型，以便能够实现基于语义的Web服务查找和Web服务组合。我们只需要把Web服务所能提供的功能及调用方法了解清楚，而不需要知道Web服务具体是怎么实现的，所以扩展UDDI中Web服务表示模型在保留公共UDDI中对Web服务的描述信息外，参考了WSDL和OWL-S对Web服务描述的方法，建立一个适用于一定应用背景的Web服务表示模型。

　　另外，还需要考虑的问题是，从简单的角度来说，Web服务可以看作是由应用程序构成，能够完成一定的功能，而这些功能可能由一个应用程序完成，也能是由若干个各自完成不同子功能的应用程序构成。也就是说，一个Web服务中可以包含一个或多个操作，每个操作完成各自单独的功能。这些功能之间可以有关联，也可以没有关联。因此，对Web服务的描述和表示可以转化为对Web服务中每个操作的描述和表示，如果我们建立了一个表示模型可以把Web服务中的操作表示清楚，那么也就可以说这个模型能够表示和描述Web服务。

　　经过以上分析，我们首先定义了完整描述一个服务资源需要的信息包括：

　　1)

　　物理信息：主要描述服务所关联的具体程序的URL地址信息，服务对外提供的函数的接口信息以及各自需要的输入和输出的参数的格式、个数、顺序等信息。

　　2)

　　性能信息：主要描述服务的服务质量（QoS）等非功能的性能指标。例如完成服务所需要的执行时间、使用服务的费用、服务的可靠性、可用性等信息。

　　3)

　　语义信息：主要描述该服务所完成功能所具有的语义属性，便于计算机理解、利用和处理的。为了提供对语义描述的支持，需要建立一个领域知识本体库，来描述统一的行业知识，为系统中不同实体间的理解和交互提供语义基础。

　　因此，在公共UDDI对Web服务的描述表示基础上，结合WSDL和OWL-S



本文转自

http://soa.5d6d.com/redirect.php?fid=4&tid=93&goto=nextnewset