Web服务技术标准与规范Word文档格式.docx

Web服务技术标准与规范Word文档格式.docx

《Web服务技术标准与规范Word文档格式.docx》由会员分享，可在线阅读，更多相关《Web服务技术标准与规范Word文档格式.docx（11页珍藏版）》请在冰豆网上搜索。

Web效劳栈〔WebServicesStack〕

Web效劳不同于已有的构件对象模型以及相关的对象模型协议，如CORBA和IIOP〔InternetInter-ORBProtocol〕、COM和DCOM以及Java和RMI〔RemoteMethodInvocation〕。

Web效劳可以用任何语言编写，并且可以使用HTTP访问。

从技术上看，一个Web效劳是一个由内容、应用代码、过程逻辑、或者这些局部的任意组合所构成的XML对象，并且可以通过任何TCP/IP网络访问，只要网络中使用SOAP标准集成，使用WSDL标准进行自描述，使用UDDI标准在一个公共的或者私有的目录中注册和发现。

如图1所示，Web效劳由多个层构成，这些层堆叠在一起形成了发现和调用一个独立的Web效劳所提供功能的标准机制的根底。

即，Web效劳栈以层次结构来表示，高层在低层的根底之上构建。

图中HTTP提供了分布式应用之间的通信机制，XML定义了数据交换和描述的格式，SOAP是调用Web效劳的协议，WSDL描述Web效劳的格式，而UDDI那么是注册、查找和使用Web效劳的中枢组织。

下面分别介绍这些协议及相关的标准。

2．HTTP

Web效劳栈中的最底层是网络层，也可以称为协议层。

分布式的应用需要有网络协议来定义两个并发过程之间的通信机制。

概念上，Web效劳的设计是与协议无关的，在图1的分层体系结构模型中，从底向上任何标准的Internet协议都可以用于在网络上调用Web效劳。

但目前主要是HTTP〔HypertextTransportProtocol〕和HTTPS〔HypertextTransportProtocolSecure〕协议。

是一个基于文本的、“请求－响应〞〔request-response〕型的协议，它规定一个客户翻开到效劳器的一个连接，然后以专门的格式发送一个请求，效劳器进行响应，同时如果必要那么保持连接的翻开状态。

HTTP使用的普遍性及其固有的穿防火墙的能力使它成为主导的Web效劳网络协议。

但同时由于HTTP是基于文本的协议而缺乏表示远程过程调用〔RPC〕消息参数值的机制。

其它的请求/响应类型的传输协议，如文件传输协议〔FileTransferProtocol，FTP〕和简单邮件协议〔SimpleMailTransportProtocol，SMTP〕也可以使用，但是并没有在Web效劳的各种标准中定义，目前也只有极少数实现支持这些协议。

另外，最近IBM发布了一个可靠通信协议的提案，称作HTTPR。

HTTPR在HTTP的根底上加强了可靠性，在保持HTTP优点的同时能够保证消息可以不受阻碍地发送到目的地。

可靠的通信对Web效劳来说是一个非常关键的方面，虽然目前对由协议层实现是否最适合仍然有争议，但在不远的将来它肯定会以某种形式出现。

3．XML〔ExtensibleMarkupLanguage，可扩展标记语言〕

基于XML的消息层包括数据表示、数据格式和消息传输协议。

XML为信息交换定义了描述和格式。

数据表示

HTTP是一种基于文本的协议，因而缺乏表示RPC消息中的参数值的机制，这也是XML作为Web效劳的一个重要成分出现的原因。

XML是一种元语言，可以通过标准的编码和格式化信息的方法进行跨平台的数据交换。

XML允许数据被串行化为易于被任何平台解码的消息格式，提供了在网络应用之间交换结构化数据的机制。

XML采用纯文本表示，设计的初衷是为了存储、传送和交换数据的。

XML是一种标记语言，标记在XML中不是预先确定的，而必须由使用者自己定义。

XML允许使用者自由发表有用的信息，不仅可以是有关数据结构的，也可以是关于数据意义的。

另外，XML文档的结构、内容和外观可以作为三个不同的局部进行维护，提供了更高的独立性。

对于数据表示层来说，可扩展性是一个关键因素。

为了支持可扩展性，Web效劳需要一种机制以防止名字冲突，并允许一个程序只处理自己所关心的元素。

XML名空间〔namespaces〕提供了一种简单、通用的方式以区分相同名字的元素或属性。

为了支持可扩展性，XML中的每个元素和属性都有一个相关的名空间URI。

数据格式

Web效劳需要一种方法定义Web效劳消息中使用的数据类型。

XMLSchema标准标准化了一个描述XML数据类型的符号集，还定义了一个内置简单数据类型的集合和在各XML文档中建立元素类型的机制。

XMLSchema规定了XML文档的逻辑结构，定义了元素、元素属性以及元素和元素属性之间的关系。

XML仍然处于不断的开展中。

需要说明的是，XML本身只是一种标记语言，只是进行描述，并不提供商务逻辑，Web效劳提供对这些逻辑的访问。

这也是为什么Web效劳的更高层的、基于XML概念同样非常重要的原因。

4．SOAP〔SimpleObjectAccessProtocol，简单对象访问协议〕

SOAP是目前被广泛接受的消息传输协议。

SOAP是一个为信息交换设计的轻量协议，用于在网络应用程序之间交换结构化数据，是一种基于XML的机制。

SOAP主要是在分布的、分散的环境中提供了一个跨Internet调用效劳的框架结构，并提供了独立于编程语言和分布对象底层根底结构的跨平台集成机制。

SOAP代表了xml-rpc的开展，已经被W3C作为一种Internet标准采纳。

SOAP是一个远程过程调用〔RPC〕协议，使用标准的Internet协议进行传输：

同步调用时的HTTP或异步调用时的SMTP。

由于可以在HTTP上运行，这使得SOAP在穿防火墙进行操作的方面优于DCOM、RMI和IIOP，而在嵌入设备上实现SOAP也比开发一个ORB更简单。

SOAP的主要设计目标是简单性和可扩充性。

为了到达这两个目标，SOAP中省略了在其它消息系统和分布式对象系统中常见的一些特性，如无用存储单元收集、消息批处理等。

SOAP没有定义一种编程模型或实现，而是定义了一个模块化的包装模型，并在模块内定义了编码数据的编码机制。

这使得SOAP可以在从消息传递系统到远程过程调用的任何系统中应用。

SOAP的组成

SOAP由四个局部组成：

•〔1〕一个SOAP封皮〔Envelope〕，定义了描述消息所包含信息的框架结构，即消息中包含什么信息、由谁来处理以及是必需的或可选的。

•〔2〕一组SOAP编码规那么〔Encodingrules〕，定义了一个串行化机制，用于交换应用定义的数据类型的实例。

SOAP编码的类型使用简单的标量类型和复合类型，如结构和数组。

这些类型以XML文档元素的形式表现，XMLSchema标准中定义的数据类型以及这些数据类型的派生类型都可以直接用作SOAP元素。

•〔3〕SOAPRPC表示，定义如何表示远程过程调用和响应。

SOAP的设计目标之一是用XML的可扩展性和灵活性封装RPC功能，在SOAP1.2中详细定义了RPC和响应的统一表示，将对一个方法的调用和响应作为结构来建模，结构中包含了返回值，或者还可能包括传入的参数。

•〔4〕SOAP绑定〔binding〕，定义如何使用底层传输协议进行SOAP消息的交换。

虽然SOAP本身可以和多种协议结合使用，但SOAP1.2中只描述了在HTTP中的使用。

SOAP和HTTP绑定可以同时使用SOAP的形式方法与分散的灵活性以及HTTP丰富的特性集。

在HTTP中使用SOAP并不意味着SOAP覆盖了HTTP现有的语义，而是SOAP继承了HTTP的语义。

SOAP消息

SOAP消息是用XML编码的文档，由三个局部组成：

•〔1〕SOAP封皮〔SOAPEnvelope〕，是描述SOAP消息的XML文档的顶点元素。

•〔2〕SOAP消息头〔SOAPHeader〕，提供了一种灵活的机制对SOAP消息以分散的、模块化的方式进行扩充，而通信的各方〔SOAP发送者，SOAP接收者以及SOAP中介〕不必预先知道。

SOAP消息头是可选的。

•〔3〕SOAP消息体〔SOAPBody〕，定义了一个简单的机制来交换要发送给最终SOAP接收者的消息中的必要信息，是这些信息的容器。

典型的使用是编组RPC调用和SOAP错误报告。

SOAP消息交换模型

SOAP消息是单方向的，从一个SOAP发送者〔sender〕到一个SOAP接收者〔receiver〕。

但单独的消息通常可以被组合在一起形成其它消息机制。

例如，SOAP通过在HTTP请求中提供一个SOAP请求消息和在HTTP响应中提供一个SOAP响应消息实现HTTP的请求/响应消息模型。

SOAP消息交换模型要求接收到一个SOAP消息的应用程序执行以下操作：

〔1〕识别SOAP消息中意图供应本应用的局部，本应用可以作为SOAP中介将消息的其它局部传递给另外的应用。

〔2〕检验SOAP消息中指定的所有必须处理的局部，并进行相应的处理。

〔3〕如果SOAP应用不是消息的最终目的地，它应该在删除所有自己消耗的局部后将消息转发给消息要供应的下一个应用。

SOAP只是一种包装和绑定调用一个Web效劳所需信息的方式，Web效劳也可以使用其它的编码技术调用。

另外，SOAP本身没有严格地归入Web效劳，SOAP可以作为一种对任何类型的远程对象或过程的访问机制使用，也可以只是一个简单的消息传递机制。

除了SOAP以外，W3C创立的XMLP工作组还建立了XML协议〔ExtensibleMarkupLanguageProtocol，XMLP〕。

XMLP是类似于SOAP的XML消息协议，包括封皮、对象串行化方式、HTTP传输绑定以及进行远程过程调用的方式几个局部。

甚至有人认为XMLP将逐步取代SOAP。

5．WSDL〔WebServicesDescriptionLanguage，Web效劳描述语言〕

Web效劳的目标之一是允许应用程序以标准的方式在两个或多个同等的效劳之间进行选择，因为有时应用可以由作为支持网络的效劳而实现的构件构造而成，甚至可以从这些效劳中进行动态选择。

效劳描述层定义了为程序提供足够信息所需的描述机制，使程序能够根据一定的准那么选择效劳，如效劳的质量、平安性、可靠性等。

到Web效劳的接口由基于XML的WSDL定义，它提供了应用访问指定的Web效劳所必需的全部信息，描述效劳提供了什么功能、效劳位于何处以及效劳如何调用。

WSDL以XML格式描述网络效劳，将效劳描述为在包含面向过程或面向文档信息的消息上进行操作的一组端点。

操作和消息是抽象描述的，然后绑定到具体的网络协议和消息格式以定义一个端点。

相关的具体端点被组合成为抽象端点〔效劳〕。

WSDL是可扩展的，允许描述任何端点和消息，而不考虑通信使用的消息格式或网络协议。

WSDL使用下面的元素定义网络效劳：

•类型〔Types〕，使用某种类型系统的数据类型定义的容器。

WSDL并没有引入新的类型定义语言，而将XSD作为自己的标准类型系统，并允许通过可扩展性使用其它的类型定义语言。

•消息〔Message〕，对要传送的数据的一个抽象定义。

•操作〔Operation〕，对效劳支持的动作的抽象描述。

•端口类型〔PortType〕，一个或多个端点支持的操作的一个抽象集合。

•绑定〔Binding〕，对特定端口类型的一个具体协议和数据格式规格。

•端口〔Port〕，一个单独的端点，由一个绑定和一个网络地址组合在一起定义。

•效劳〔Service〕，一组相关的端点的集合。

一个Web效劳由一组端口定义，而端口由绑定到一个具体协议和数据格式标准的一组抽象操作和消息定义。

操作和消息的抽象是为了使它们可以复用和绑定到不同的协议和数据格式，如SOAP、HTTPGET/POST或MIME。

在WSDL中，端点和消息的抽象定义是和它们的具体网络配置和数据格式绑定相别离的；

另外，WSDL定义了一个公共的绑定机制，用于将特定的协议或数据格式或结构连接到抽象的消息、操作或端点，这些都允许对抽象定义的复用。

WSDL目前已经被广泛支持，但还不是W3C推荐的标准语言。

6．UDDI〔UniversalDescription，Discovery，andIntegration，统一描述、发现和集成〕

面对极度丰富的效劳，最常出现的问题是“在哪里以及如何找到需要的信息？

〞。

统一UDDI标准在底层协议的根底上又定义了一层，在这一层，不同的企业能够以相同的方式描述自己提供的效劳和查询对方提供的效劳。

UDDI是一套基于Web的、分布式的、为Web效劳提供的信息注册中心的实现标准标准，同时也包含一组使企业能将自身提供的Web效劳注册以使别的企业能够发现的访问协议的实现标准。

信息结构

UDDI为表示XML中商业效劳描述定义了一个数据结构标准，提供了更高层次的商业信息以补充WSDL中的说明。

UDDI定义了四种根本的结构：

•商业实体〔Businessentity〕，描述商业信息，如名称、类型等。

•商业效劳〔Businessservice〕，已发布的Web效劳的集合。

•绑定模板〔Bindingtemplate〕，访问信息，如URL。

•技术标准〔tModel〕，对效劳类型的技术规格说明，如接口定义、消息格式、消息协议、平安协议等。

效劳发布和发现

在进行一个Web效劳调用之前，必须先找到具有所需效劳的企业，发现调用接口和语义，然后编写或配置自己的软件以便与效劳合作。

UDDI的核心部件是UDDI商业注册，它用一个XML文档来描述企业及其提供的Web效劳。

UDDI商业注册是一个基于SOAP的Web效劳，提供企业用于将它们的效劳发布到注册中心的接口。

注册中心是分布式的，彼此之间不断进行复制操作。

Web效劳根本上是机器到机器的通信，为了有效工作，这种体系结构必须具有进行基于Web的应用和业务过程集成的有效工具。

UDDI商业注册中心包含三类信息，企业可以通过这些信息发现一个Web效劳。

•白页，包括企业的名称、地址、联系方式和企业标识，并允许其它公司按照名称查找目录。

•黄页，包括基于标准分类法的行业类别。

•绿页，包括了关于该企业所提供的Web效劳的技术信息，其形式可能是一些指向文件或URL的指针，而这些文件或URL是为效劳发现机制效劳的。

绿页还允许注册的公司之间使用XML进行连接，提供了业务过程自动化的关键机制。

编程接口

UDDI标准提供了编程接口，允许商业注册一个Web效劳，以及查找指定Web效劳的注册。

一旦想要的Web效劳被确定，将提供一个指向WSDL文档所在位置的指针。

编程接口分为查询API和发布API两个逻辑局部。

查询API又分为两个局部：

一局部用来构造搜索和浏览UDDI注册信息的程序，另一局部在Web效劳出现错误时使用。

发布API可以用来创立各种类型的工具，以直接与UDDI注册中心进行交互，便于企业技术人员管理发布信息。

使用UDDI

UDDI标准包含了对基于Web的UDDI商业注册中心可以实施的整套共享操作。

一般来说，程序或程序员通过UDDI商业注册中心来获得Web效劳的位置及其技术信息。

其中对于程序员来说，是对自己的系统实现准备，以使自己的系统能和那些Web效劳实现访问兼容，或是描述自己的Web效劳从而能让别人使用。

从商业层次上来说，UDDI商业注册中心可以被用于核查某个合作伙伴是否拥有特定的Web效劳的调用接口，或是找出在某行业中能提供某种类型效劳的公司，并确定某合作伙伴的Web效劳的技术描述及交互时所需的技术细节。

UDDI是完全可选的，也就是说，具有Web效劳的公司，如果只是想对有限的人员或设备提供特定功能，它们不需要对外发布它们的效劳。

其它标准

除了UDDI以外，效劳发现层还有其它一些标准。

如由Microsoft开发的DISCO〔DiscoveryofWebServices〕标准。

DISCO定义了一个基于XML的发现文档格式和一个检索该发现文档的协议。

DISCO允许开发人员通过一个HTTPGET操作发现效劳。

使用发现文档格式，可以将一个发现文档发送到一台远程效劳器，如果存在支持SOAP的Web效劳，那么收回一个效劳所提供的WSDL描述。

7．效劳集成和工作流

工作流的概念在设计电子商务应用时愈加重要。

当一个企业需要集成来自多方的Web效劳并为终端用户组织这些效劳时，必须掌握其系统的过程和顺序。

对于这些具有异步特征的应用，适合使用工作流引擎。

要使Web效劳的实现不仅仅停留在简单的请求/响应模式上，商业过程协作和工作流是必不可少的，其中包括跨企业边界的Web效劳的合成与自动化。

要成功进行企业间的自动化和协作的必需条件是要有一个标准化的商业协议来描述这些商业过程。

效劳工作流领域目前尚未形成固定的标准，有一定影响的是WSFL、Xlang以及BPMI。

WSFL

Web效劳流程语言〔WebServicesFlowLanguage，WSFL〕是一个描述商业过程的标准。

WSFL提出了两种Web效劳组合的类型：

一是商业过程，一是合作伙伴交互。

商业过程作为一组为到达一个特定的商业目标而顺序执行的Web效劳建模。

合作伙伴交互描述Web效劳之间如何彼此交互。

Web效劳被连接在一起以说明一个Web效劳与另一个Web效劳接口的操作交互作用。

XLang

Xlang是Microsoft的BizTalk效劳器使用的XML商业过程语言。

Xlang用于描述商业过程，这些过程在运行时由BizTalk控制引擎〔Orchestrationengine〕执行。

Xlang还允许将Web效劳结合到商业过程中以及Web效劳的组合。

另外，Xlang支持补偿过程。

Xlang不支持代价较高的两阶段提交协议，而是提供了一个可供选择的开放式模型的表示方法，其中可以为活动明确指定抵消该活动影响的补偿活动。

由于Microsoft先前与IBM在WSDL和UDDI上的合作，有人认为将来二者可能会向W3C提出将Xlang和WSFL结合起来的提议。

BPMI

BPMI〔BusinessProcessManagementInitiative〕推进公共商业过程的标准化。

这些过程可能跨多个应用、部门或商业合作伙伴，可能在防火墙之后或者可以通过Internet访问。

制定了一些开放标准，如BPML和BPQL，这使得可以对电子商务过程用即将出现的BPMS〔BusinessProcessManagementSystem〕进行基于标准的管理。

•BPML〔BusinessProcessModelingLanguage〕，是商业过程建模的元语言。

BPML将商业过程定义为为了到达一个共同目标在参与者和根据定义的规那么集合执行的活动之间的交互作用。

•BPQL〔BusinessProcessQueryLanguage〕是到一个过程效劳器的管理接口，允许商业分析员查询由过程效劳器管理的过程实例的状态，并控制过程实例的执行。

该接口是基于SOAP的。

为了过程的注册、广告和发现，由过程库管理的过程模型通过BPQL接口可以作为UDDI效劳对外提供。

BPML和BPQL都是开放标准。

8．其它相关标准和领域

其它许多组织在Web效劳标准的制定方面也做了大量的工作。

这里只简单介绍几种比拟知名的标准。

ebXML

EbXML的结构类似Web效劳栈，是在Internet上用标准技术引导电子商务的协议和标准的一个栈。

EbXML曾被考虑作为Web效劳的另一个选择，其时间也早于Web效劳模型。

然而这两个模型之间有一些重叠，而ebXML更注重EDI方式的信息交换。

一种可能的设想是Web效劳模型和ebXML之间的逐步合并。

UN/CEFACT和OASIS最近已经采纳SOAP作为ebXML消息传递底层结构的根底。

W3C也积极考虑ebXML标准，并将并入标准中那些满足作为标准化Web效劳体系结构的需求的方面。

JAXPack

JAXPack是Sun封装了Java领域的各种标准的结果。

JAX是一组XML的JavaAPI，其设计支持Web效劳标准API，包括SOAP、XMLP、WSDL和UDDI等。

JAXPack中包括的API如下：

•JAXP〔JavaAPIforXMLParsing〕，包含SAX〔SimpleAPIforXML〕，DOM〔DocumentObjectModel〕和XSLT。

•JAXB〔JavaAPIforXMLBinding〕，一种将XML数据类型定义编译到能够将XML读入Java对象并将再其写回的Java类中的机制。

•JAXM〔JavaAPIforXML-basedMessaging〕，一个发送消息的基于SOAP的协议。

•JAXR〔JavaAPIforXMLRegistries〕，一个包罗众多的标准，其中为UDDI和ebXML注册及其它可能的注册提供了统一接口。

•JAX-RPC〔JavaAPIforXML-basedRemoteProcessCommunication〕，一个请求远程效劳器上操作的基于SOAP的协议。

除了上面描述的各种标准以外，还需要提及一些其它的重要领域，这些领域涉及Web效劳栈的所有层，其中包括平安性、管理、效劳质量和事务等。

在Web效劳具有转换企业商业关系的能力之前，企业需要这些额外的特性以及随之而来的附加机制、平安、身份确认、合同管理、质量控制等。

其中最重要的是平安性和事务。

平安性

XML密钥管理系统〔XMLKeyManagementSystem，XKMS〕是将PKI和数字化证书与XML应用集成的结果，由W3CXML签名工作组开发。

该领域的其它标准