第5章 WebService基础

1、 WEB SERVICES 一.WEB服务简介 1定义：简而言之，WEB服务就是可编程 的URL，就是使用标准的INTERNET协议 （比如HTTP或XML）远程可调用的应用程 序组件。它要想成功用于Internet就需要提 供一个与操作系统无关、与程序设计语言 无关、与机器类型无关、与运行环境无关 的平台 。 二WEB服务技术体系： Internet: IPv4, IPv6 Transport: HTTP, FTP, SMTP Messaging: SOAP Service Description: WSDL Service Discovery, Integration: UDDI Work

2、flow: WSFL Routing, Reliability and Transaction Management Quality of Service Security Wire / Wireless WEB服务体系架构： (Web Services和Web Service) 服务提供者 服务中介者 服务请求者 发布 发现 绑定 三WEB服务相关的技术： 第一部分：表示数据 (XML) 第二部分：交换消息 (SOAP) 第三部分：服务描述 (WSDL) 第四部分：服务发现与发布 (UDDI和WS- Inspection) XML模式：(XML Schema) XML模式是DTD（Docum

3、ent Type Definition）的 超集，DTD可以指定元素是包含字符数据还是其他 数据或是一个空元素，DTD不能指定某个特殊元素 是否包含整数、浮点数或字符串。另外，DTD有自 己的语法，而XML模式遵循XML语法。 1.用途：数据类型定义。 2.xs:或xsd前缀一般保留给模式定义，xsi前缀用 于模式实例。 xsi:schemaLocation=http:/ von1.xsd (1).Schema声明： Schema元素是XML Schema中的第一个出现的元素， 用于声明该XML文档是一个Schema文档。 例： (2).元素定义: ElementType元素是用于定义XML

4、Schema文档中出现的元 素。ElementType只是起到声明元素的作用，而元素的真 正引用还是要依靠element. 语法定义如下： (3)元素引用 element元素是用于声明在ElemntType中 引用的元素。其语法表达式为： 注：type唯一指定了要引用的元素类型，因此其取值必须同 ElementType中的name属性严格一致。 (4)分组定义： (5)属性定义：用于定义该Schema文 档中出现的属性类型。 (6)属性引用： AttributeType和attribute的关系与 ElementType和element的关系相同。 (7)数据类型： 元素和属性的数据类型可以使

5、用元素datatype来 定义。 datatype元素只是定义数据类型的一个手段，我 们更方便用dt:type属性。 例如： 和 Schemal例子： 第二部分：交换消息 请求消息 响应消息 服务请求者 服务提供者 1.定义 SOAP（Simple Object Access Protocol） 是基于XML实现了一种消息格式以交换请 求和使用，使用XML作为SOAP消息的基础 使得任何实现基本的INTERNET通信服务 的系统都能处理和传送这类消息 。 解释： a:SOAP中的“简单”一词是相对术语，在这里， 相对于其他用于此目的的协议来说，它是简单的， 包括DCOM和CORBA，他们也能实

6、现软件之间的通信， 但是也很不友好。 b:而术语“协议”表示双方认可的一个标准，即 如何格式化消息以便双方能够通信。SOAP协议 只是定义了一种消息格式，它并没有为交换消息 而强加某种特定的传送协议，因此可采用HTTP， FTP ,SMTP等协议来传送消息。 2.SOAP的设计目标： 简明性：主要表现在SOAP的整个消息结构非常简 单（一个Envelop中只包含了Header和Body两部分） 除了消息结构外，SOAP没有定义额外的表述结构 标准，没有定义自己的编码标准，没有定义自己 的传输协议。 可扩展性：表现在SOAP可以使用任意的模式定 义方式来定义内部传输内容的结构（编码方式一 般使用

7、XML Schemal），可以与任意的网络传输 方式来完成传输。 3.SOAP的消息交换模型： SOAP一般会和实现模式结合，例如：请求 响应 。 soap响应 soap消息 soap消息 CA中心 e-Marketplace 企业 Account Service Product Service Purchase Order 4.结构: SOAP（Simple Object Access Protocol ）它包 括四个部分： 1.SOAP封装(envelop)，封装定义了一个描述消 息中的内容是什么，是谁发送的，谁应当接受并 处理它以及如何处理它们的框架； 2.SOAP编码规则（encodi

8、ng rules），用于表示 应用程序需要使用的数据类型的实例; 3.SOAP RPC表示(RPC representation)，表示远 程过程调用和应答的协定; 4.SOAP绑定（binding），使用底层协议交换信 息。 POST /StockQuote HTTP/1.1 Host: Content-Type: text/xml; charset=utf-8“ Content-Length: nnnn SOAPAction: /2001/06/quotes DIS SOAP消息 SOAP消息响应： HTTP/1.1 200 OK Content-Type

9、: text/xml; charset=utf-8“ Content-Length: nnnn 34.5 (1)SOAP包封 SOAP HeaderSOAP Header 典型的扩展例子可以是实现一些诸如认证、 事务管理以及支付的Header条目。 SOAP actor属性: SOAP actor属性的值是一个URI， 指明下一个进行消息处理的SOAP中介。若省略 SOAP actor属性，则表明接收者是SOAP消息的最 终接收者。 SOAP mustUnderstand属性:用于指明一个Header 条目是否能够被接受方正确的理解。将返回 “true”或“false”. SOAP Body

10、这个调用负责指定要执行的方法名以及 所有传递给方法的参数。在WEB服务者 接受、翻译并处理完了这个方法调用之 后，它就会发送一个响应或错误消息。 SOAP Fault SOAP Fault元素是用于在SOAP消息中传输 错误或状态信息。如果SOAP消息需要包含 SOAP Fault元素的话，它必须作为一个 Body条目出现，同时在Body元素内它必须 不出现多于一次(至多出现一次)。 SOAP Fault元素定义了如下子元素 faultcode :faultcode :此元素必须在SOAP Fault 中出现， SOAP定义了一个小的错误集合，用于定义覆盖基 本的SOAP错误。 faultst

11、ringfaultstring：是为那些错误代码提供一个人可以 读懂的错误解释。 faultactor :faultactor :用于指示错误源，属性的值是一个 标识该源的一个URI。 Detail:Detail:它可以添加用户自定义的错误（包括错误 消息和错误号 ） (2)SOAP编码 SOAP编码规则(encoding rules)，定义了一 个数据的编码机制，通过这样一个编码机 制来定义应用程序中需要使用的数据类型， 它遵循XML模式规范的结构和数据类型定 义，其中包括简单类型（整数，字符串等） 和一些复杂类型（struct,Array等） 。 (3)SOAP与传输协议绑定： （一般是H

12、TTP） 将SOAP绑定在HTTP上可以利用HTTP丰富的特性集， 更恰当的描述应当是SOAP的语义通过HTTP的映射 而很自然地成为HTTP的语义。同时，SOAP很自然 的利用HTTP的请求响应模型。 SOAPAction HTTP请求：可以用于指示SOAP HTTP 请求的目的，它的值是一个标识该目的的URI。 SOAP对于格式上并没有严格的限制，同时对URI的 描述以及是否要是可解析的都没有严格的限制。 当发出SOAP HTTP请求时，HTTP客户必须使用该头 字段。 (4).在RPC中使用SOAP SOAP RPC表示(RPC representation)， 定义了一个用于表示远端过

13、程调用和响应 的约定，例如如何传输过程调用，在具体 传输协议的哪个部分传输过程响应，因为 我们可以在HTTP的响应的时候传递过程响 应。 为实施一个方法调用，需要以下信息: 目标SOAP结点的URI 方法名 可选的方法或过程的特征 方法或过程的参数 可选的头数据 例子：fuction copy(in s:string; in Index ; in Count:Integer): string; 从传入的字符串s中，从位置Index处开始删除长度为Count的子 串。 （假设这些函数是位于URI ） SOAPAction :http:/ 上的system. 。 。 。 响应： 。 5总结： SO

14、AP简单的理解，就是这样的一个开放协 议SOAP=RPC+HTTP+XML：采用HTTP作为底层 通讯协议；RPC作为一致性的调用途径， 作为数据传送的格式，允许服务提供 者和服务客户经过防火墙在INTERNET进行 通讯交互。 SOAP的优势： .SOAP是平台独立的：SOAP是普通的XML，可以 运行任何平台。 SOAP消息描述了消息负载的每个数据元素， 这样就可以很容易的诊断可能出现的问题 。 自由的传输绑定 (不仅仅是HTTP)；自由的语 言绑定 (比如Java, C#)。 SOAP降低了安全风险：SOAP只是XML，因 此它能够使用端口80，而该端口通常配置HTTP， 因此SOAP消

15、息无需开放其他任何端口，就能通 过防火墙的优点，从而降低了潜在的安全风险。 SOAP的不足： SOAP允许每个平台按照他们认为的方式考 虑如下的特征： . 对象调用：SOAP规范不打算定义如何创建对 象实例。 . 垃圾收集：SOAP规范没有定义不再需要对象 时如何销毁对象，如没有定义如何去除对象。 . 安全性：SOAP没有讨论，依靠其他技术（比 如安全套接层SSL） 。验证：SOAP也没有提到，众多技术都可以实 现。 第三部分：服务描述 XML是一种编码数据的标准方法。SOAP基于 XML定义了一种消息格式以便交换方法请求 和响应，并最终完成WEB服务的调用，而 WSDL则是用于描述如何使用S

16、OAP来调用WEB 服务的。 1.定义： WSDL将WEB服务描述定义为一组服务访问 点。它包含对一组操作和消息的抽象定 义，绑定到这些操作和消息的一个具体 协议和这个绑定的一个具体服务访问规 范。 1Types：数据类型的容器，它是用某种类型系统， 很多情况下这个部分指的是XML模式定义（XML Schema Definition, XSD） 2Messages通信消息的数据机构的抽象类型化定义。 使用TYPE所定义的类型来定义整个消息的数据结构。 3Operation：对服务中所支持的操作的抽象描述， 一般单个Operation描述了一个访问入口的请求响应 消息对。 4. PortType

17、s：对于某个访问入口点类型所支持的操 作的抽象集合。 5 Bindings：特定端口类型的具体协议和数据格式 规范的绑定。 6 Port :定义为协议数据格式绑定与具体WEB访问 地址组合的单个服务访问点。 7. Services：相关服务访问点的集合。 8. Import: 引用其他的接口服务文档。 2.结构 类型部分：数据类型的容器，包含了所有在消 息中使用的XML元素的类型定义定义。 消息部分：具体定义了通信中使用消息的数据 结构，Message元素包含了一组Part元素（相 当于函数中的参数） 端口类型部分：定义了一种服务访问入口类型类型。所谓 访问入口类型就是传入传出消息模式及其格式

18、模式及其格式 （WSDL中支持四种访问入口调用的模式：A：单请求； B：单响应；C:请求响应；D:响应请求）。 PortType的定义会引用消息定义部分的一到两个消息， 作为请求或响应消息的格式。一个PortType可以包含 若干个Operation，而一个Operation则是指访问入口 支持的一种类型的调用 。 小结：以上三种描述了WEB服务的抽象定 义（抽象定义层），这三部分与具体WEB服 务部署细节无关，是可复用的描述。（即 这三部分可以说是WEB服务本身，与具体的 语言实现，遵从的平台的细节规范，被部 署到那台机器无关） 绑定部分：定义了某个PortType与具体的网络 传输协议或消

19、息交换协议相绑定,以及具体的数 据格式规范。从这一层开始，就与具体的服务 部署相关了。 服务部分:描述的是一个具体的被部署的WEB服 务所提供的所提供的所有访问入口的部署细节， 一 个 S e r v i c e 往 往 有 多 个 服 务 访 问 入 口 （Port）。Port描述的是一个服务访问入口的 部署细节 。 第四部分：服务发现与发布 WEB 服务发现是定位或发现一个或多个说 明特定的WEB 服务的文档的过程，WEB 服 务的客户通过发现来知道某个Web 服务是 否存在，以及从哪里功能获取这个WEB 服 务的文档。 1.定义： UDDI是一种使贸易伙伴彼此发现对 方和查询对方的规范。

20、它是最终用户通过搜 索企业列表、企业分类或者实际WEB服务的 可编程描述。使查找产品和服务成为可能。 解释：UDDI不仅是一个简易的搜索引擎，它也 包含了如何通过编程来和这些WEB服务进行 交互。 （对UDDI的使用可以用手动查询或程序查询） UDDI工作原理工作原理 2.UDDI数据表类型： 白页：包含了基本的企业信息，诸如企业名称、文字 性介绍（可能是多国语言）以及联系方式，包括名称、电 话号码、电子邮件以及属于这些企业的网站。 黄页：按分类法对企业信息进行分类，在UDDI的第一 个版本中，这种分类法包括了对行业、产品或服务以及位 置的分类。 绿页：包含了如何与企业进行电子交互的信息，包含

21、 交易过程（也就是，创建订单和检查存货等多种WEB服 务）、服务描述（个人WEB服务和它们的用途）以及解释 如何通过调用一个给定的WEB服务的捆绑信息。 UDDI的数据结构： 商业实体信息：商业实体信息：businessEntity businessEntity 元素元素 许多合作伙伴希望能准确地定位到你提供的服 务的相关信息，并把这些信息作为了解你们企 业的开始。技术人员、程序员或应用程序希望 知道你的企业名称和一些关键性的标识。所有 “businessEntity”中的信息支持“黄页”分类 法。如：Business Key, Name，Description， Contacts等。 商业服

22、务信息：businessService元素 businessService 和下面要提到的 bindingTemplate一起构成了“绿页”信 息。businessService 结构是一个描述性 的容器，它将一系列有关商业流程或分 类目录的Web 服务的描述组合到一起。 (包含 businessKey,serviceKey,name,descripti on). 技术绑定信息：技术绑定信息：bindingTemplatebindingTemplate元素元素 对于每一个businessService，存在一个或多 个Web 服务的技术描述bindingTemplate。这 些技术描述包括应用

23、程序连接远程Web 服务并 与之通讯所必须的信息。这些信息包括Web应 用服务的地址、应用服务宿主和调用服务前必 须调用的附加应用服务等。另外，通过附加的 特性还可以实现一些复杂的路由选择，诸如负 载平衡等。 包括 （ bindingKey,businessKey,serviceeKey,acces sPoint（指向WEB服务入口点的URL、EMAIL、 电话号码等）等）。 规范描述的指针和技术标识规范描述的指针和技术标识tModeltModel 调用一个服务所需要的信息是在 bindingTemplate的结构中定义的。不过一般来 说，仅知道Web服务所在的地址是不够的 。因 此，每一个b

24、indingTemplate元素都包含一个 特殊的元素，该元素包含了一个列表，列表的 每个子元素分别是一个调用规范的引用。这些 引用作为一个标识符的杂凑集合，组成了类似 指纹的技术标识，用来查找、识别实现了给定 行为或编程接口的Web 服务。（主要包含name, Description,categoryBag等) 描述商业实体之间关联关系的关联信息：描述商业实体之间关联关系的关联信息： pulisherAssertionpulisherAssertion UDDI2.0新增加了一个结构，这种机制能令 多于一个的已注册的bussinessEntity元素 以某种方式互相连接，用以表示一种特定 类

25、型的关联关系。因为大型商业实体有很 多小型的部分组成，UDDI允许他们以多个 组成部分的形式来实施注册。 3.UDDI程序员的API规范： UDDI程序员的API规范是一个文档，概述了公共课 调用SOAP接口在UDDI站点上执行的每项操作。它 由两部分组成：Inquiry API，用于查询和浏览 UDDI注册表来发现最终用户查询的企业和服务： Publisher API，用于添加、更新和删除UDDI注册 表中的企业和服务信息。 详细信息可查阅：http:/www.uddi- /pubs/ProgrammersAPI-V2.00-Open- 20010608-CN.pdf (1

26、)查询用API： 每个UDDI数据结构 （ businessEntity,businessService,bindingTempl ate和tModel）都有一个find_xxx和get_xxx函数。 这8个函数构成了查询API。它允许用户在数据实 体上的注册表中搜索关键词或者值，然后给出所 有与这个条目相关的数据。这个API主要作为查找 和显示最终用户想查找的企业、服务等的一种方 法。 Find_xxx一般是用于定位特定的服务，get_xxx一 般是用于得到完整的信息。 (2).发布用API： 每个UDDI数据结构都有一个save_xxx和 delete_xxx函数。加上权限认证函数 （ge

27、t_authToken,discard_authToken)这些函数 形成了Pulication(发布)API，它允许用户（经过 注册授权的用户）对现有的注册标目进行更新， 用save_xxx创建新的条目，用delete_xxx能完全 删除给出的数据结构。但是用户必须是已经授权 的终端使用者。 实例:(发布一个WEB服务） 1.向指定的UDDI注册中心站点申请登陆并要求获得认证令牌。 2.如果登陆成功、验证通过，那么UDDI注册中心站点将响应一个 authToken消息，这个令牌将是其他发布函数的必备参数。 SESSION$90X0232-ABKNC 3,如果用户不存在或密码错误,那么将返回下

28、列错误信息(用相应的 errcode和errno表示，）。 4.调用成功后，用户可以用其他的发布API进行发布。当完成一系 列的调用后，用户应该丢弃令牌。 SESSION$90X0232-ABKNC 5.调用成功后，UDDI会返回一个成功响应的消息。 例:发布tModel: save_tModel generic=“2.0” xmlns=“urn:uddi- org:api-v2 注:在发布的时候，tModel键应当是空的，表示该数据 是新增的，但发布之后再返回的信息中UDDI将为这个 tModel分配一个新的tModel标识符（tModelKey)。 3.UDDI和WSDL的关系： UDDI

29、数据实体提供了对定义业务和服务信息的支持，WSDL 中定义的服务描述信息是UDDI注册信息的补充，UDDI提供 了许多不同类型的服务描述的支持。因此，UDDI没有对 WSDL的直接支持，也没有对任何其他服务描述机制的直接 支持。 WSDL文档被分成两种类型，即服务接口和服务实现。 服务接口包括types,message,portType, Binding等元素。通过使用import元素，一个服务接口 文档可以使用另一个服务接口文档。 服务实现文档包含实现一个服务接口类型服务的描述， 包含import和service元素。 服务接口文档：在UDDI注册中心被当作tModel 发布； 服务实现文档

30、：包含的每个service元素都被 用作UDDI businesssService;(port相当于 bindingTemplate） WS-Inspection（分布式分布式WEB服务发现技术服务发现技术） 1.介绍:WS-Inspection 规范并不定义一种 服务描述语言。WS-Inspection 文档提供 一种方法来聚集不同类型的服务描述。WS- Inspection 文档中，一个服务可以有多种 对服务描述的引用。例如，可以既使用 WSDL 文件又在 UDDI 注册中心描述一个 Web 服务。对这两种服务描述的引用应该 放在 WS-Inspection 文档中。 WS-Inspection的使用： 2.WS-Inspection 规范的两个主要功能 (1).定义 XML 格式用于列举对现有服务描述 的引用引用。 (2).定义一组约定，这样能容易定位 WS- Inspection 文档。 3.WS-Inspection 文档格式文档格式 前面已经提到WS-Inspection 文档提供对服务描 述的引用的集合。这些服务描述可以用任何服务 描述格式（例如 WSDL、UDDI 或者简单 HTML）定 义。 WS-Inspecti