管理结构式Web服务元数据 来源: 时间:2002-08-27 10:49 作者:AMTeam.org 管理结构式Web服务元数据
本文是建立在以前发表在 developerWorks 上的一篇介绍使用资源描述框架(Resource Description
Framework,RDF)来强化 WSDL 的文章的基础之上,并与最近的一篇关于 SOAP 和 RDF 一起使用的文章有关。Uche Ogbuji 着眼于
WSDL 的更新对以前介绍过的技术造成的影响,他还提到了有关 RDF 和 Web
服务描述的重要讨论以向开发者展示如何发挥两者的优势。 对标准的更新 宪章:工作组将提供到 RDF 的映射,以便被描述的信息很容易同其它应用程序的信息合并。该映射将在 RDF Interest
Group 的帮助下开发。 然而,随着 W3C 的 Semantic Web 活动蓬勃发展,RDF 发生了重要的更改。最近的 RDF 模型理论和 RDF/XML 语法规范推动我对曾经采用的 WSDL 映射到 RDF 的方法进行了更改。还需要考虑一些其它因素。尤其是 Eric Prud'hommeaux 不采用我自己的机械的映射方法,而是一直在试图通过建立 WSDL 元素背后底层意图的映射来改进我的方法。当然,对于常规的 RDF 集成,这样的映射更有用,而且人们希望映射可以“丰富”到可以为 Web 服务描述工作组(Web services description working group)所接受。但是,对于自己的方法,我还有一个特殊目的:提供足够简单而且适合非 RDF 类型的映射,并尽可能与 XML 的标识转化相似。 随着 Web 服务和 RDF 阵营之间的合作越来越多,这样一种机械映射不再非常必要,因此,我将更多的着眼于开发者的前景。 您更新映射了吗? 清单 1:更新后的 RDF
中的滑雪板保险服务 任何映射解决的问题都包括 WSDL 的命名方法。对于描述来说,WSDL 功能的名称不一定是唯一的;端口类型可以取与服务相同的名称。WSDL 可以根据上下文自己分辨这一点,但是这令人困惑而且容易出错。RDF 的好处就在于它迫使人们考虑清楚标识;在这一映射中,由一种方便的标记法来命名。全球唯一的 URI 提供实际的标识,虽然 URI 要向 RDF 软件提供重要的锚点,但却不需要让 WSDL 软件看到或理会。事实上,这些标识符可以由映射软件生成为基于随机数的全局唯一标识符(universally-unique identifiers,UUID)。 各种建模中常见的一个问题是,如何处理一起使用并且由相同的通用名来表示的属性和类。例如,在上面的 WSDL 映射中,消息与其部件之间的关系被称为 <wsdl:part>,这够自然的了,而该属性值的类,则被称为 <wsdl:Part>,这也是很自然的。但这有点糟糕,因为它是通过语法方面的细节来排除模棱两可的(也就是说,只能通过 RDF 和大多数语言中的大小写来分辨 URI )。但是,我认为,在这种情况下,最好通过自然命名方法来解决这一问题,而不是耍命名的把戏。 在一种情况下,这样的映射为了清晰而扭曲了这种命名方法:绑定与其相关操作(被命名为 <wsdl:operation>)的绑定细节之间的关系,以及未命名的内联资源所表示的该种细节与抽象的操作定义(来自 WSDL <operation> 元素)之间的关系。后者被命名为 <wsdl:abstractOperation> 以强调这两种关系完全不同的概念意义。WSDL 绑定的其余语句并不符合最初的 WSDL 语法所提议的直接方式,因为我曾尝试通过仔细阅读规范中对绑定元素的描述,来寻找最能抓住概念背后的意义的表达。 虽然这是很值得费些功夫的重要任务,但最终我并没有把元素模式定义分解成低级描述,而是提取每个元素的内容模型作为整段文字模式(literal schema),该模式是用 <rdf:parseType=Literal> 编码的。由于 RDF 1.0 中对 RDF 文本对象的文字内容的规定非常不完整,所以传统观点一直认为这是一种危险的做法,但是 RDF 核心工作组已经在 XML 典范和信息集工作组(XML canonicalization and infoset working groups)工作的基础之上对这一规范进行了非常重要修订工作。 把这些内容用于实际 消息调度 清单 2:抽象的“参保的滑雪板运动者”web 服务的 RDF 描述 <wsdl:Service rdf:about="http://snowboard-info.com/EndorsementSearch"> 正如 WSDL 中规定的,这是 HTTP Web 服务,也许是众多服务之一。每当消息传入服务的托管服务器时,我们可以从 HTTP 协议实现中获得 SOAP 端点和 SOAPAction ,并迅速获取诸如根元素名称空间和本地名称等细节。接着,如果要执行请求,您可以装入包括下列查询的那个模块: 请查找实现 Web 服务的代码模块,该 Web 服务的描述指定 SOAP 动作和端点为 http://snowboard-info.com/EndorsementSearch、文档元素名称空间为 http://snowboard-info.com、名称为
GetEndorsingBoarder。 清单 3:给定进入的 Web 服务请求条件,从资源库中检索代码模块的一个 Versa 查询 1 $port = filter( 这只是介绍了 Versa 的一点皮毛,总体上,它是一种非常简单的查询语言(请参阅参考资料寻找教程的链接)。为了使解释脉络清楚,我给每行都标上了数字。第 1 行开始变量赋值(一直延至第 21 行)。我随意使用了一些空格以加强可读性。Versa 的核心遍历表达式允许您遍历 RDF 图。 $foo - a:predicate -> * 这是向前的遍历,它按照谓词(a:predicate)从给定的主语 foo 检索模型中的所有可以以这种方式找到的宾语。您可以用布尔表达式(比如 eq("bar"))替换 * 字符来进一步细化结果宾语,这样就只能与文字为 bar 的字符串匹配。接下来,您可以象下面这样把结果宾语用作链状遍历表达式的起点: $start-wsdl:binding->* 只要这些动作是带 URL http://snowboard-info.com/EndorsementSearch 的资源,就可以这样检索起始资源的绑定操作的所有 SOAP 动作。Versa 中资源可以写成限定名(<wsdl:binding>),或者把资源 URI 放在引号中,并在前面加上一个 @ 字符(例如,@'http://schemas.xmlsoap.org/wsdl/')。 您也可以以谓词的相反方向进行遍历,也就是说,使用一个回退遍历,从主语到宾语: $foo <- a:predicate - * 当您从定义过的 $port 变量回退到与它间接相关的抽象 Web 服务资源时,您将会看到清单 3 中第 23 行的这个动作。接着,为了获取您正在寻找的代码模块名,您可以从该资源向前移到它的实现。 type() 函数检索所有给定的 <rdf:type> 资源的列表。filter() 函数会以列表作为开始,并根据一组规则不断细化。它只遍历满足所有条件的列表项。第 2 行是第一个参数,给出了初始列表,而其余 4 个参数分别从第 3 行、第 4 行、第 7 行和第 14 行开始,这些参数表示我们已经设定的条件(即,具有指定的 SOAP 动作、SOAP 端点、文档元素名和名称空间的描述)。 结束语 以前在 IBM developerWorks
发表的相关文章
|
|
关键词:
上一篇:无SOAP的Web服务,第一部分 下一篇:理解Web服务互操作性
|
相关文章 |