Web服务技术标准与规范1Word下载.docx

Web服务技术标准与规范1Word下载.docx

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

其它组织也做了大量的工作，如UDDI.org，OASIS，UN/CEFACT，BPMI.org，以及ebXML.org等。

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）协议。

HTTP/1.1是一个基于文本的、“请求－响应”（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访问。

BPMI.org制定了一些开放规范，如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密钥管理系统（XMLKeyManagementSyste