（计算机软件与理论专业论文）基于领域本体构建分布式的uddi互联架构.pdf

摘要 u n i v e r s a ld e s c r i p t i o n ，d i s c o v e r ya n di n t e g r a t i o n ，简称u d d i ，是构成w 曲 s e r v i c e s 的重要基础设施之一，在整个w e b 服务体系内提供服务发现功能，是 w e b 服务能够从实验室走向工业界必不可少的环节。 传统u d d i 的工作方式类似于p 2 p 网络，各个u d d i 节点之间进行数据的 同步和复制。对于服务请求者来说，从不同的u d d i 节点进入是没有差别的，它 所面对的都是整个u d d i 体系提供的服务发现功能；而对于服务发布者来说，在 某一个u d d i 节点进行服务的发布，然后通过u d d i 节点之间的数据同步和复制 功能，它所发布的服务扩散到整个u d d i 体系中，不同发布节点的差别主要在于 注册数据托管权的问题上。 传统u d d i 的工作方式存在以下主要问题：各个u d d i 节点之间需要持续进 行数据的同步和复制，以便维持数据的全局一致性；忽略了不同u d d i 节点之间 的领域差异。私有u d d i 节点之间的信息很难互联互通。 针对传统u d d i 的工作方式中存在的问题，本文的主要工作包括：提出了一 种基于u d d i 代理的u d d i 互联架构，并详细介绍了u d d i 节点在u d d i 代理中 注册以及通过u d d i 代理进行服务发布和服务请求的过程；基于领域本体和q o s 度量给出了进行u d d i 节点选择和服务选择的方案；针对私有u d d i 节点的管理， 给出了不同层次的方案，在解决了私有u d d i 节点互联互通问题的同时，保障了 其信息的安全性。 关键字：u d d i ，领域本体，d a m l - s ，q o s 中图分类号：t p 3 1 1 5 i i i a b s t r a c t u d d i ，w h i c hi ss h o r to f u n i v e r s a ld e s c r i p t i o n , d i s c o v e r ya n di n t e g r a t i o n ，i so n e o ft h em o s ti m p o r t a n tf o u n d a t i o ni na r e ao fw e bs e r v i c e s i tp l a y sar o l ew h i c h p r o v i d e ss e r v i c ed i s c o v e r y , s e r v i c ep u b l i c a t i o n ，a n ds e r v i c er e g i s t r y w i t h o u tu d d i ，i t i sh a r dt om n gw e bs e r v i c e si n t oc o m p u t e ri n d u s t r y t h et r a d i t i o n a lw o r k i n gw a yo fu d d il o o k sl i k ep 2 p ( p e e rt op e e r ) n e t w o r k s i t i sc o n t i n u o u s l yd o i n gs y n c h r o n i z a t i o na n dc o p yo fs e r v i c e sd a t ab e t w e e nn o d e so f u d d i f o rs e r v i c er e q u e s t o r , i th a sn od i f f e r e n c ef r o mv a r i o u sn o d e so fu d d i f r o m a n yn o d eo fu d d i ，s e r v i c er e q u e s t o rc a nf m ds e r v i c e sw h i c ha r ep r o v i d e db yt h e w h o l eu d d i f o rs e r v i c ep r o v i d e r ，t h eo n l yd i f f e r e n c ei st h es e r v i c ed a t at h a ti t p r o v i d e sb e l o n g st ow h i c hn o d eo fu d d i t h i sk i n do fw o r k i n gw a yh a ss o m e p r o b l e m s ：t h ec o n t i n u o u ss y n c h r o n i z a t i o na n dc o p yo fs e r v i c e sd a t ai n c r e a s e st h e c o s to fu d d ia n di ta l s om a k e sh a r dt om a i n t a i nu d d i i ti g n o r e st h ed i f f e r e n c e so f n o d e so f u d d ii nd o m a i n i ti sh a r dt os h a r ei n f o r m a t i o nf r o md i f f e r e n tp f i v m en o d e s o f u d d ia n di ti sa l s od i f f i c u l tt om a n a g et h ed a t as e c u r i t yo f p r i v a t en o d e so f u d d i i nt h i sp a p e r , o u rw o r km a i n l ys t r e s s e so n ：w ep r o v i d eu d d ib r o k e ra r c h i t e c t u r e n o d e so f u d d ir e g i s t e ri nu d d ib r o k e r s e r v i c ep r o v i d e r sa n ds e r v i c er e q u e s t o r su s e u d d ib r o k e rt op u b l i s hs e r v i c e so rr e q u e s ts e r v i c e st h a tt h e yn e e d w ei m p o r td o m a i n o n t o l o g yt om a r ka t t r i b u t e so fn o d e so fu d d ia n ds e r v i c e s w h e nd o i n gs e r v i c e s s e l e c t i o n , u d d ib r o k e ru s em e a s u r e m e n to fq o st od e t e r m i n ew h i c hs e r v i c e sf i tw e l l w i t hs e r v i c er e q u e s t o r sr e q u e s t s w ep r o v i d eb l u ep r i n tw h i c hm a k e si te a s yt o p r o t e c td a t as e c u r i t yo fp r i v a t en o d e so fu d d lw h e nw es h a r ei n f o r m a t i o nf r o m v a r i o u sp r i v a t en o d e so f u d d i k e y w o r d s ：u d d i ，d o m a i no n t o l o g y , d a m l - s ，q o s c a t e g o r y ：t p 3 1 1 5 论文独铷性声明 本论文是我个人在导师指导下进行的研究工作及取得的研究成果论文中 除了特别加以标注和致谢的地方外，不包含其他人或其它机构已经发表或撰写 过的研究成果其他同志对本研究的启发和所设的贡献均已在论文中作了明确 的声明并表示了谢意 作者签名觯嘲型址一 论文使角授权声明 本人完全了解复旦大学有关保留、使用学位论文的规定即：学校有权保 留送交论文的复印粹允许论文被查阅和借阅：学校可以公布论文的全部或部 分内容可以采用影印、缩印或其它复制手段保存论文保密的论文在解密后 遵守此规定 作懿名：毋埠导嬲：麟献 日期：i 竺2 ：节 引言 o 1 研究的目的与意义 u n i v e r s a ld e s c r i p t i o n ，d i s c o v e r ya n di n t e g r a t i o n ，简称u d d i ，是构成w e b s e r v i c e s 的重要基础设施之一，在整个w e b 服务体系内提供服务发现功能，是 w e b 服务能够从实验室走向工业界必不可少的环节。 传统u d d i 的工作方式类似于p 2 p 网络，各个u d d i 节点之间进行数据的 同步和复制。对于服务请求者来说，从不同的u d d i 节点进入是没有差别的，它 所面对的都是整个u d d i 体系提供的服务发现功能；而对于服务发布者来说，在 某一个u d d i 节点进行服务的发布，然后通过u d d i 节点之间的数据同步和复制 功能，它所发布的服务扩散到整个u d d i 体系中，不同发布节点的差别主要在于 注册数据托管权的问题上。传统u d d i 的工作方式存在以下主要问题： 1 各个u d d i 节点之间需要持续进行数据的同步和复制，以便维持数据的 全局一致性。这种方式不仅大大增加了系统的开销，也增加了维护u d d i 数据的难度，而且由于不同u d d i 节点之间工作机制和数据格式的差异， 有时常常无法进行数据同步和复制。 2 忽略了不同u d d i 节点之间的领域差异。目前不同领域的服务都被混杂 在一起存放，不同的u d d i 节点之间除了服务注册的托管权以外没有显 著差别，这导致服务查找的效率比较低。现实中很多企业依据其行业的 特性建立了很多私有的u d d i 节点，在这些节点所注册的服务具有显著 的领域专门的特性，并且这些节点针对其领域特性往往采取了不同的服 务查找和发布策略，然而目前的u d d i 工作方式没有体现和有效利用领 域的特征。 3 私有u d d i 节点之间的信息很难互联互通。如果采用公有u d d i 节点之 间信息互通的方式，势必要与其他u d d i 节点之间进行数据的同步和复 制，首先这会增加私有u d d i 节点数据管理的负担，它需要管理很多原 本不属于这个组织的毫无关系的数据；其次就是不可避免的很多私有数 据会暴露给整个公有w e b 服务体系，而通过现有的u d d i 管理发布服务 的方式解决这个问题代价很高。 因此我们需要在不改变现有u d d i 基础的情况下，设计一种架构解决以上提 出的几个问题。 0 2 本文的主要工作 本文的主要工作包括： 1 提出了一种基于u d d i 代理的u d d i 互联架构，各个u d d i 节点通过 u d d i 代理进行注册，服务提供者与服务请求者通过u d d i 代理发布和 请求服务，各个u d d i 节点之间不需要进行数据的同步和复制，由u d d i 代理负责把服务提供者的服务发布到若干u d d i 节点上，或从若干 u d d i 节点请求服务并返回给服务请求者。 2 引入领域本体对u d d i 节点的领域特性进行分类存储，服务发布和请求 时u d d i 代理在服务本身和已注册的u d d i 节点之间进行领域相关性的 匹配，以完成u d d i 节点的选择，然后提交给选择出来的若干u d d i 节 点进行实际的服务发布和请求处理。服务请求时，u d d i 代理在若干 u d d i 节点获得的返回结果中，根据q o s 度量的方法进行服务的选择， 把同时满足功能性和非功能性要求的服务返回给服务请求者。 3 为私有u d d i 节点之问的互通互联提供一套完整的解决方案，私有 u d d i 节点可以选择在某一个u d d i 代理注册自己，这样它不必直接与 公共的u d d i 进行互联，通过使用u d d i 代理为其提供的不同层次的管 理方案，它选择对外提供的服务可以通过u d d i 代理被发现，这种工作 方式不仅私有u d d i 节点之间不需要进行数据的同步和复制，同时也可 以在u d d i 代理这一层次上对私有u d d i 节点的数据进行管理，大大提 高了数据管理的便捷性和安全性。 o 3 相关研究 本文提出了基于u d d i 代理扩展u d d i 体系结构的语义描述与检索能力的方 案，在扩展现有u d d i 语义能力方面的相关研究有以下一些方向和实践。 在【2 】 8 】 1 5 】中，使用针对w e b 服务设计的语义描述语言如d a m l s ，o w l s 等描述w e b 服务，然后映射成为现有u d d i 描述w e b 服务的格式，以便在现有 框架内进行服务的发布与检索，同时在现有框架外增添进行这种映射的设施，如 图0 - 1 展示的u d d i 到o w l s 数据描述的映射。这种方式的主要缺陷就是不同 语义空自j 的映射很难保证准确和完整。 图0 1 u d d i 以及e b x m l 到o w l s 的映射 【1 6 提出一种在不更改现有u d d i 框架的前提下为其扩展语义描述与检索能 力的方法，具体思路是在客户端添加支持o w l s 描述能力的设施，借助u d d i 的t m o d e l 数据结构存储服务的语义索引信息( 譬如该服务所属领域的本体信息 u r j ) ，在服务发布与检索时通过扩展设施提供语义的描述与检索能力。具体体 系架构参看图o 2 。 图0 - 2 为u d d i 扩展支持o w l s 的描述与检索能力 f 1 7 q b 指出，为现有u d d i 扩展语义能力的若干方案有一个共同的问题就是 形式化的语义描述( 譬如使用d a m l s 进行服务的描述) 常常代价过高，这阻 碍了在现有u d d i 框架下使用扩展的语义描述与检索能力。它提出一个概念模型 将w e b 服务的属性分为四大类，在每一类中都提供一种w e b 服务相似性匹配的 方法，这四大类即c p ( c o m m o np r o p e r t i e s ，包含一组w e b 服务的公共属性，如 服务名称，服务关键字，服务所有者，服务u r l 地址等等) ，s p ( s p e c i a lp r o p e r t i e f t ， 包含一组w e b 服务独有的属性，譬如一个提供广播的w e b 服务需要描述其提供 的媒体类型信息，s p 属性中包含很多服务的领域相关信息) ，s i ( s e r v i c e i n t e r f a c e ， 描述w e b 服务的接口信息) ，q o s ( q u a l i t y o f s e r v i c e ，度量w e b 服务的可用性， 可靠性等等) 。 在进行服务选择的过程中，u d d i 代理主要基于q o s 度量的方法对从多个渠 道获得的符合功能性要求的服务进行非功能性属性的度量和匹配，以便能够把同 时满足功能性与非功能性要求的服务返回给服务请求者，在扩展现有u d d i 的 q o s 能力方面的研究有以下一些方向和实践。 【9 】通过一个注册到u d d i 的服务( q o sb r o k e r ) 来对w e b 服务进行验证， 监测和运行时跟踪，这里基于的考虑是客户对w e b 服务的选择能力可能有限， 引入权威的第三方机构负责w e b 服务的选择工作。它需要对现有的u d d i 进行 少部分的扩展，一是u d d i 可以注册q o sb r o k e r ，二是u d d i 可以支持对w e b 服务的q o s 能力的描述与检索。 【1 0 】直接扩展现有的u d d i ，使其成为q o s 验证的负责机构。服务提供者在 注册一个服务的时候提供若干测试脚本，u d d i 使用这些测试脚本测试服务，通 过测试后方可接受注册，而客户在实际使用一个服务之前，使用测试脚本测试， 通过测试后方可真正使用该服务。这种架构下，一方面需要对u d d i 进行扩展以 具备执行测试脚本的能力，另一方面存在的问题就是u d d i 验证的工作量可能很 大，可能成为系统的瓶颈。 1 8 】提出的方案是提供一个中间件层，该层存储u d d i 注册信息的一个子集， 并同时存储相关的q o s 信息，如果需要使用q o s 信息则可以通过这个中间件层 提供支持，这种方案可以不更改现有的u d d i 基础设施。 f 1 9 1 1 2 0 2 1 使用一个q o sb r o k e r ( 可以是一个服务，也可以是一个构件) 对 现有u d d i 架构进行扩展以支持q o s 度量的能力，由q o sb r o k e r 负责接收服务 请求者或服务发布者对服务q o s 的描述，并把这些描述信息( 这里默认是用 w s d l 描述q o s 参数信息的) 存储在q o sb r o k e r 中，由它负责选择从哪里获取 符合q o s 描述要求的服务，并通知服务参与者它的要求是否得到了满足。其中 1 9 】的q o sb r o k e r 的体系结构参见图o 3 。 图0 - 3 使用q o s b r o k e r 扩展u d d i 的q o s 能力 【2 2 探讨了一种如何在d o t n e t 架构下扩展w e b 服务q o s 能力的方案，体系 结构中包括w s q o se d i t o r ( 负责描述w e b 服务的q o s 属性) ，w s q o s r e q u i r e m e n t m a n a g e r ( 负责接收并解析客户的q o s 要求) ，w e bs e r v i c e b r o k e r ( 负 责动态根据q o s 要求进行服务选择) ，w s q o sm o n i t o r ( 负责跟踪实际提供服务 的q o s 规约执行情况) 。 0 4 本文的组织 本文的组织结构如下： 第一章是背景知识概述，主要介绍了和本文研究工作关系密切的w e b 服务 的语义描述以及u d d i 工作机制的内容，并就已有的为u d d i 引入语义能力的研 究方向和内容进行了简单的介绍。 第二章介绍了本文提出的u d d i 代理互联架构，并就u d d i 代理的组成模块， u d d i 节点注册到u d d i 代理，基于u d d i 代理进行服务发布和查找的过程等等 方面进行了详细的讨论。 第三章介绍了u d d i 代理互联架构中的两项关键技术，即如何进行u d d i 节点的选择和如何进行服务的选择。在进行服务的选择过程中，为u d d i 扩展了 q o s 度量的能力，并使用d a m l s 描述服务发布与服务查找过程中对q o s 的要 求，介绍了u d d i 代理据此如何进行服务的选择。 第四章介绍了u d d i 代理如何对私有u d d i 节点进行管理以保证私有u d d i 节点数据的安全性，提出了三种针对私有u d d i 节点不同数据对象的管理方案， 基本涵盖了私有u d d i 节点需要进行管理的内容。 第五章是总结与展望，回顾了本文的主要工作，并就未来的研究方向做出了 提示。 最后是本文的参考文献以及致谢。 第一章w e b 服务的语义描述与u d d i 工作机制概述 1 1w e b 服务的语义描述 w e b 服务体系结构基于三种角色，即服务提供者( s e r v i c ep r o v i d e r ) ，服务 注册中心( s e r v i c er e g i s t r y ) 和服务请求者( s e r v i c er e q u c s t o r ) 。三者间的交互 涉及发布，查找和绑定操作。这些角色和操作一起作用于w e b 服务构件，即w e b 服务软件模块及其描述。在典型情况下，服务提供者将其可通过网络访问的软件 模块( w e b 服务的一个实现) 借助定义w e b 服务的服务描述发布到服务请求者 或服务注册中心。服务请求者使用查找操作从本地或服务注册中心检索服务描 述，然后使用服务描述与服务提供者进行绑定并调用w e b 服务的实现或同它交 互。服务提供者和服务请求者角色是一种逻辑结构中的概念 1 】，图1 1 展示了 w e b 服务体系结构中三种角色的关系以及发生在它们之间的操作。 图1 1w e b 服务体系结构 w e b 服务交互过程中三种角色各自的内涵如下： 1 服务提供者：从企业的角度看，这是服务的所有者；从体系结构的角度 看，这是提供可用服务的平台。 2 服务请求者：从企业的角度看，这是要求满足特定功能的企业；从体系 结构的角度看，这是寻找并调用服务，或启动与服务交互的应用程序。 3 服务注册中心：这是可搜索的服务描述注册中心，服务提供者在此发布 它们的服务描述。在静态绑定开发或动态绑定执行期间，服务请求者查 找服务并获得服务的绑定信息( 在服务描述中) 。对于静态绑定的服务 请求者，服务注册中心是可选的角色，因为服务提供者可以把服务描述 直接发送给服务请求者。同样，服务请求者可以从服务注册中心以外的 其它来源得到服务描述，例如本地文件，f t p 站点，w e b 站点等等。 w e b 服务交互过程中会发生三种操作，即服务发布，服务查找和服务绑定， 这些操作具体为： 1 服务发布：为了使服务可访问，需要发布服务描述以使服务请求者可以 查找它。发布服务描述的场所可以根据应用程序的要求而变化。 2 。服务查找：在查找操作中，服务请求者直接检索服务描述或在服务注册 中心中查询所要求的服务类型。对于服务请求者，可能会在两个不同的 生命周期阶段中涉及到查找操作，在设计时为了程序开发而检索服务的 接口描述，而在运行时为了调用而检索服务的绑定和位置描述。 3 服务绑定。最后需要调用服务，在绑定操作中，服务请求者使用服务描 述中的绑定细节来定位，联系和调用服务，从而在运行时调用服务或启 动与服务的交互。 服务提供者是通过服务描述将所有用于调用w e b 服务的规范传送给服务请 求者的。要实现w e b 服务体系结构的松散耦合，服务描述是关键。不管是请求 者还是提供者，都不必了解对方的底层平台，编程语言或分布式对象模型。服务 描述与底层s o a p 协议相结合，足以封装服务请求者的应用程序和服务提供者的 w e b 服务之间的这个细节。早期w 曲服务协议栈中提出的是使用w s d l 进行对 w e b 服务的描述，后来为了增加对w e b 服务语义描述的支持，相继提出了 d a m l s ，o w l s 等等。 1 1 1w s d l w e b 服务体系结构使用w s d l ( w e bs e r v i c ed e s c r i p t i o nl a n g u a g e ) 作为服 务描述的基础性协议，它已经被提交到w 3 c 作为标准 2 3 】。w s d l 是一种x m l 文档，它将w 曲服务描述为一组端点，这些端点会处理包含面向文档或面向过 程的r p c 消息。操作和消息都是被抽象描述的，然后它们会被绑定到一个具体 的网络协议和消息格式，用来定义端点。相关的具体端点被合并到抽象的端点或 服务中。w s d l 可以扩展为允许端点和其消息的描述。不管使用哪种消息格式或 网络协议进行通讯都可以。不过目前经过描述的绑定基本都使用s o a p 协议【1 】。 服务体系结构中对w s d l 的使用按照常规将基本的服务描述分成了两部分： 服务接口和服务实现，参看图1 2 。 j 囝 ib i n d i n g p 。1 t t y p e 图1 2 w s d l 组成部分 服务接口定义是一种抽象或可重用的服务定义，它可以被多个服务实现定义 实例化和引用。你可以将服务接口定义想象成接口定义语言( i n t e r f a c e d e f i n i t i o n l a n g u a g e ，i d l ) ，j a v a 接口或w e b 服务类型。这使常见的行业标准服务类型可 以被多个服务实现者定义和实现，类似于在编程语言中定义抽象接口，然后得到 多个具体实现。 服务接口包含w s d l 元素，它们组成了服务描述中的可重用部分，这些元 素有：w s d l ：b i n d i n g ，w s d l ：p o r t t y p e ，w s d l ：m e s s a g e 和w s d l ：t y p e 元素， 如图1 2 中所描述。w s d l ：p o r t t y p e 元素中定义了w e b 服务的操作。操作定义 了输入和输出数据流中可以出现的x m l 消息。可以将操作想象成编程语言中的 方法说明。w s d l ：m e s s a g e 元素指定哪些x m l 数据类型组成消息的各个部分。 w s d l ：m e s s a g e 元素用于定义操作的输入和输出参数。w s d l ：t y p e 元素中描述 消息中复杂数据类型的使用。w s d l ：b i n d i n g 元素描述特定服务接口( w s d l ： p o r t t y p e ) 的协议，数据格式，安全性和其它属性。 服务实现定义是一个描述给定服务提供者如何实现特定服务接口的w s d l 文档。w e b 服务被建模成w s d l ：s e r v i c e 元素。服务元素包含一组( 通常是一个) w s d l ：p o r t 元素。端口将端点( 例如网址位置或u r l ) 与来自服务接口定义的 w s d l ：b i n d i n g 元素关联起来。 服务接口定义和服务实现定义结合在一起，组成了服务完整的w s d l 定义。 这两个定义包含服务请求者描述如何调用以及与w e b 服务交互的足够信息。服 务请求者可以要求获得其它关于服务提供者端口的信息，此信息由服务完整的 w c b 服务描述提供。 1 1 2d a m l s 为了能将语义引入w e b 服务中，仅靠w s d l 无法描述关于w e b 服务的语义 信息，相继又提出了几种描述w e b 服务语义的语言或协议，得到学术界比较广 泛研究使用的有d a m l s 以及其后在它的基础上发展起来的o w l s 。 d a m l s 是一种由d a r p a 资助的由多家研究机构共同创建的用于描述智能 w e b 服务的d a m l + o i l 本体语言【2 4 】。在d a m l s 的官方网站上是这样描述 d a m l s 的：d a m l s 为w e b 服务供应商提供了一套核心的标记语言集，使之 可以以一种明确的，计算机能够解释执行的方式来描述w e b 服务的属性和功能 【3 】。 d a m l s 是在若干w e b 服务工业标准之上开发的，同时加入了丰富的类型 和类信息，我们可以使用这些信息来描述和限制w e b 服务，而且它采用一种获 取w e b 服务的控制流和数据流的处理模型，集成了更多的类表示。它能把w e b 服务聚合成分类的层次结构，并且还带有类以及类实例之间关系和限制的丰富定 义。这种定义良好的语义信息通过现有的推理技术，就能实现对这些结构的自动 操作。简而言之，d a m l s 使语义w e b 服务的自动交互成为可能。设计d a m l s 是针对语义w e b 服务自动执行的任务，包括自动发现，自动调用，自动交互， 自动集成，自动执行监控与恢复，自动模拟和验证 2 。 在d a m l s 中，所有的实体都是以c l a s s e sa n dp r o p e r t i e s 的方式描述的， d a m l s 设置了一组类和属性来描述服务，这里面s e r v i c e 本体是它的本体层 次中的t o po n t o l o g y 。s e r v i c e 本身的子类并没有明确的规定出来，而是应该 根据功能和市场的实际需要进行定制。服务本体对一个服务的两个方面进行描 述： 1 w h a td o e st h es e r v i c er e q u i r eo f a g e n t s ，a n dp r o v i d ef o r t h e m ? 2 h o w d o e s i t w o r k ? 第一方面通过d a m l s 中的s e r v i c ep r o f i l e 实现，第二方面通过s e r v i c e p r o c e s sm o d e l 实现。 d a m l s 主要由三部分组成，分别是： 1 s e r v i c ep r o f i l e ：描述“w h a tt h es e r v i c ed o e s ”，指明所描述的w e b 服务的 功能与接口，以便于服务代理能够搜索与匹配该w e b 服务。它提供一 些关于服务的基本信息，这些信息可能包括安全性，地点，服务需求等 等方面的描述。 2 s e r v i c e m o d e l ：描述“h o w t h es e r v i c e w o r k s ”，指明当服务被调用时的操 作，以便服务代理进一步匹配，以及进行服务合成和服务的协调工作与 监控。它提供对一个服务的更深入的描述，以便负责服务查找的模块( 下 面简称代理) 决定是否满足它的需求；为多个服务共同完成一个具体任 务来组合描述规约；协调多个不同代理的行为；跟踪服务的执行。总体 来讲，s e r v i c ep r o f i l e 提供信息让代理进行服务的检索，s e r v i c ep r o c e s s m o d e l 提供足够的信息以便代理可以充分利用这些服务。 3 s e r v i c eg r o u n d i n g ：指定调用服务的具体细节，比如通信协议，调用端 口等。 1 1 2 1d a m l ss e r v i c ep r o f i l e 它的功能是通过服务的查找( s e r v i c e sd i s c o v e r y ) 和能力注册( c a p a b i l i t y r e g i s t r i e s ) 来请求和发布服务，包括三方面的信息： 1 服务和服务提供者的描述。 2 服务的功能属性( f u n c t i o n a la t t r i b u t e s ) 。 3 服务的功能行为( f u n c t i o n a lb e h a v i o r s ) 。 s e r v i c ep r o f i l e 在语义上要比u d d i 和w s d l 丰富很多，u d d i 对服务的描 述局限在指向服务的名称，提供者和获取服务的端口，而不包括服务能力的描述； w s d l 定义了服务的交换信息的格式，但是不能提供一个这种信息交换的语义模 型。关于服务描述的内容参见表1 1 。 表1 - 1 服务描述的属性 s q z v l c e h a a e1 ：l 擒n a m eo ft h e 糊f v j c e 。 她删。d p p ah i 垡h 4 e v d d e s c r l l 此l o n o f w h a t n 蹦t n 油秘p i a 啦m f u l “m 虹o fas v t o o 。 t 铂瞒抽b 肾i 肚t o n ab l 幢lh i 韭嗨n r o a d a b k d o s c r l p t i o n o f t h e s s r c l o a 。g 砒舶呐i n g 霄h a t t h e8 融v l 。o o 强e a 讲w h a tc a p e 醢缸岫鼬b e m g m q u a 曲d r o l e a nd h l f a 瞒l i n kt oa c t 讲，t a v o l v e ll n 妇s e r v i c e 壤e c u t l o 乱 r e 掣t 醚l 净 a s l i 扛p r q 嗍ya f r o l 。拍蠡r r l n g 协t h e 嬲r v i 睫r e q u m t 艇 p r o v l d “i b ya b - p t o p 呻o f r 0 1 。r o f , r t n gt ot 籼s 口v l c ep r o v i d o t 这里使用a c t o r 类来描述如人、组织等等的实体，这些实体请求或者提供服 务。a c t o r 类包括两个具体的子类，即s e r v i c ep r o v i d e r 和s e r v i c er e q u e s t e r 。a c t o r 类包含一些属性如p h y s i c a l a d d r c s s ，w e b u r l ，n a m e ，p h o n e ，e m a i l ，f ；等等。 关于服务的功能属性参见表1 2 。它提供服务的一些额外信息，如服务的开销， 分类，由谁保证提供服务的响应时间和准确度等等。 表1 2 服务的功能属性 | i l n c t i o n a la t ：t r i b u t e s g a o g r a p h i c p a d i u sg e o g r a p h i cs c o p eo ft h es e r v i c e e i t h a tt h eg l o b a ls c a l e 伽菩 8 岫i n o 黼jo fa t r e g i o m d 酆出e e g 。p t 渤d e , w r y ) d e g r e e o f 秘a l 姆 q u a l l yq u x l l f l c a t k ，u & s u c h 柚p r o v i d i n gt h ec h o i ro f f 副l t i g tp 僵融b k 雕灯r | c 。 5 目竹i p a r a 血e t 口ra no x p a n d c b kk o fp r o p o m 趣t h a tc h 删孵扛et h e 幔b c u t j o n 税as 甜v i c 。，s u c h 舾i z a 田9 船b p o 订蠊释t 肼o c a t i o d c o g t c 0 皿i c a t l o n t h r nh j g h i 酬s u m m a r y 。fb 瓣 鼬州d em a yc o m m u n i c a t e 。辱 w h a te o 衄m 删c 旗i 。nl a n g u a g ei su s e d ( e g ，k q m l s o a p - n i c t y p b r o a dc l a 母m l i 豫。ft h es e r v i c et h a xm i g h tb ed e s c n b e db ，r o i 蟛o fs e r v i c et y p e s ，b t t c h b 2 b 。b 2 c 毗 b 口f i c 纰蚝y c 蛐g o n e sd e 6 n o dw i t h i n $ o m go 目v i c a t e g o r yo n t o k 嚼y , s u c h c a t 张o r i e sm a yi n c l u d ep w d u c t s n f o r m a “o ns e r m 妇sg t c 。 印n l i t ，慨a t g u a r a n t e t m t t h es 4 , v i c e p r o m l s e b 协d d l v e r ，o g g w b m - j n g 协p f o v i d ea 瑚s p 。n 艚w i t h i n3m i n u t e s 。艟c 。 学n i t 皿n i l g i n d u s , r y h a z e dr a t i n s s 。s u c h 删t h e 嘧h na n db t a d s t r m tr a t - l n g f a r ob m i n e s 关于服务的功能行为，服务通过公开提供的一些功能的选择，其本身就隐含 的表达了它的意图。如一个提供在线购书的服务一般会提供两个功能，一个是浏 览，一个是在线购买，但是如果服务本身对外只提供一个在线购买的功能而没有 提供浏览的功能，它其实暗含着不鼓励那些不打算购买的客户进行浏览。 服务的提供者使用s e r v i c ep r o f i l e 来描述它们的服务并进行发布，服务的请 求者也使用s e r v i c ep r o f i l e 来描述它们的需求并在服务的注册中心( 如u d d i ) 进行查找和匹配，一般来讲，服务的请求者所描述的s e r v i c ep r o f i l e 可能是不完 整的。s e r v i c ep r o f i l e 的高层本体示意图参见图1 3 。 图1 - 3s e r v i c ep r o f i l e 的高层本体示意图 这个高层本体示意图主要包括三个部分： 1 低层是a c t o r 的定义：它代表服务提供者的一些具体信息。 2 中间部分是功能属性的定义：如服务在地理位置方面的限制等等。 3 最上层部分是服务功能的描述：它通过输入，输出，预设条件，影响等 等术语进行描述，譬如一个购书服务的输入就是想要的书的名称和作 者；输出就是对一个订单成功接受并处理的确认；预设条件是服务能够 正常执行需要满足的条件，在购书服务中预设条件可以是合法有效的信 用卡；影响是服务执行后造成的，在这个购书服务的例子中，影响是信 用卡被划账，书的属性改变。 1 1 2 2d a m l - ss e r v i c em o d e l 它用来定义一个服务的控制结构和数据流结构，如执行一个服务可能的步 骤，主要包括两个构件： 1 jp r o c e s so n t o l o g y ：描述一个服务的输入，输出，前件，副作用，后续步 骤等等，当前的d a m l s 版本中已经发布，可以用来支持w e b 服务的 自动调用，组合等等。 2 p r o c e s sc o n t r o lo n t o l o g y ：描述一个服务的过程状态，包括初始激活， 执行，完成等状态，它可以支持自动的服务执行跟踪。 在p r o c e s so n t o l o g y 中最基本的一个实体是p r o c e s s 类，它的属性包括： 1 任意数目的i n p u t s ：代表某些条件下执行过程所需的信息。 2 任意数目的o u t p u t s ：过程执行后的一些信息。 3 过程的p a r t i c i p a n t s ：过程中的参与者。 4 任意数目的p r e c o n d i t i o n s ：调用这个过程所要满足的全部条件。 5 任意数目的e f f e c t s ：执行过程的副作用( s i d ee f f e c t s ) 。 在d a m l s 中，过程可以区分为三类： 1 a t o m i cp r o c e s s e s ：从服务请求者的视角来看，这种过程单步执行，没有 子过程，可直接调用，用来与服务交换信息，它要求提供保证( a g r o u n d i n g ) 来确保请求者可以构造一个调用消息，并可以解释一个应答 的消息。 2 s i m p mp r o c e s s e s ：相对于a t o m i cp r o c e s s e s ，它不可以直接调用，也不需 要一个保证，它被用做抽象过程的元素，仍可以视为单步执行的，一方 面它可以看作a t o m i cp r o c e s s e s 的一种视图，另一方面也可以是 c o m p o s i t ep r o c e s s e s 的一种简化表达。 3 c o m p o s i t ep r o c e s s e s ：这种过程可以被分解为其他过程，分解使用控制 结构完成。可用的一些控制结构参见图1 - 4 。分解可以展示一个c o m p o s i t e p r o c e s s 的内部控制结构以及它的输入输出数据流。每一个 c o m p 0 s i t e p r o c e s s 类都有一个e o m p o s e d o f 属性， 使用 c o n t r o l c o n s t r u c t 表明控制结构，每个c o n t r o lc o n s t r u c t 都有一个 额外的属性c o m p o n e n t s 来指明它所包含的子过程的执行顺序和条件。 c o n s t r u c t 1 3 b e r i p t i o n s e q u e n c ee x e c u l e 且l i s to f p r 0 0 雕l ，强缸bb 帕u 驵c i 出o r d e r c o n c m r