webservice接口协议有哪些

竭诚为您提供优质文档/双击可除webservice接口协议有哪些

篇一：webservice基础原理

第一部分webservice基本原理

第1章webservice基础

1.1引言

（1）服务是自包含的模块，它们部署在标准的中间件平台上，能够在网络上使用基于xml的技术进行描述、定位、编配和编程。

（2）面向服务的计算并不是一个新的技术，而是分布式系统、软件工程、信息系统、计算机语言、基于web的计算和xml技术的融合。

（3）在面向服务的模型中，可以清晰地区分服务提供者、服务客户端以及服务聚合者。服务提供者提供服务的实现、描述以及相关的技术与业务支持。服务客户端是具体使用服务的终端用户组织。服务聚合者是将多个服务整合成一个新的服务，这个新的服务通常称为业务流程。

（4）服务的主要优点之一是，它们既可以在一台机器上实现，也可以在多个各不相同的设备上实现。服务的实现

可以分步在一个局域网中，甚至也可以跨几个广域网。

1.1.1webservice是什么

（1）webservice是一个可通过网络使用的自描述、自包含软件模块，这些软件模块可完成任务、解决问题或代表用户、应用程序处理事务。（2）webservice可以是：自包含的业务任务，如提款或取款服务；成熟的业务流程，如办公用品的自动采购；

应用程序，如人寿保险应用程序、需求预测与库存补充应用程序；已启动服务的资源，如访问特定的保存病人病历的后台数据库。1.1.2webservice的典型场景

供应商

图1.1涉及多个相互交互的webservice的订购单应用程序

1.2“软件即为服务”的理念

（1）web页面直接面向的是人，而webservice的开发目标是访问者，既可以是人也可以是自动化的应用程序。

（2）“软件即为服务”首先产生于应用服务提供商软件模型中。应用服务提供商

（applicationserviceprovider,asp）是将软件、基础设施要素、业务以及专业的服务进行打包的公司，它们创建完整的解决方案，并将其作为基于订阅的服务向用户推介。asp

是第三方（服务组织者），它们部署、维护并管理打包的应用程序，并通过提供集中管理方式，对跨网络的客户提供应用程序可用性、安全性。asp的基本出发点是向用户出租应用程序。

（3）将webservice与基于web的应用程序进行比较，有四方面的显著差异[aldrich20xx]：

对于请求或调用webservice的应用程序而言，无论这种调用是否需要人的干预，请求或调用的web

service都可视作应用程序的资源。这意味着webservice可以调用其他的webservice，从而将复杂事物中一些处理交由其他的一些webservice实现。这提供了基于web的应用目前无法达到的高度的灵活性和适应性。

webservice是模块化的、自感知和自描述的应用程序。webservice知道它能完成什么功能，也知道何

种如数会产生何种输出，并将其向潜在用户或其他的webservice进行描述。webservice也能描述它的非功能性属性，例如调用webservice花费、webservice覆盖的地理范围、使用webservice所涉及的安全性度量、性能特点、联系信息等。

相比于基于web的应用程序，webservice更容易被监控和管理。可以在任何时候使用外部的应用管理

和工作流系统来监控和管理webservice的状态。本地

应用程序可以检测到webservice的状态，并可管理webservice的输出状态。

可对webservice进行评估和拍卖。加入几个webservice 完成同样的任务，webservice可对索要使用

的服务进行招标。代理科基于webservice的“竞价”属性（花费、速度、安全性）进行选择。

1.3webservice的完整定义

（1）webservice是一个平台独立的、松耦合的、自包含的、基于可编程的web的应用程序，可使用开放的xml标准描述、发布、发现、协调和配置这些应用程序，用于开发分布式的互操作的应用程序。webservice能够在一些常规的计算中提供一些服务，从而完成一个具体的任务，处理相关的业务或解决一个复杂的问题。此外，webservice使用（基于xml的）标准化的因特网语言和标准化协议在因特网或内部网上展示它们的可编程功能部件，并通过自描述接口实现webservice。这些自描述接口基于开放的因特网标准。

（2）webservice是松耦合的软件模块：服务接口的定义必须中立，独立于任何底层平台、操作系统及实现服务所使用的编程语言。因此，服务将可在一些不同的系统上实现，并以一致的形式和通用的方式相互交互。中立的接口定义将不会受到特定实现的很大影响，从而在服务间做到松耦合。

（3）webservice语义封装各个独立的功能：webservice

是一个完成单个任务的自包含的软件模块。该模块描述了自身的接口特征，例如操作可用性、参数、数据类型和访问协议。基于这些信息，其他的软件模块将能确定该模块能完成什么功能，确定如何调用这些功能以及确定可能的返回结果。在这一点上，webservice是契约式的软件模块，模块公开提供了接口特征的可用描述。webservice的潜在客户将能绑定到这些接口，并通过这些接口访问webservice。

（4）编程式访问webservice：可将webservice嵌入到远程的应用中，因此可以查询和更新信息，从而提高了效率、响应性和精确性。

（5）可动态发现webservice并将其添加到应用中：与目前已有的接口机制不一样，可对多个webservice进行装配，从而实现

某个特定的功能、解决一个具体的问题或者向客户提供一个特定的解决方案。

（6）可使用标准的描述语言来描述webservice：webservice描述语言（wsdl）既能描述功能性服务特性也能描述非功能性服务特性。

（7）可在整个因特网上分发webservice：webservice

使用一些非常通用的因特网协议，如http。与web内容一样，webservice也依赖于同样的传输机制。webservice利用已

有的基础架构，并遵循企业当前的防火墙策略。

1.4webservice的特性

1.4.1webservice的类型

按照拓扑结构，webservice可以分为两类，如图1.2所示。第一种类型是信息型，webservice仅支持简单的请求/响应操作。webservice一般在等待请求，然后处理并响应请求。第二种是复合型，webservice在进入操作和离开操作之间进行一定形式的协调。

图1.2信息型和复合型服务的概要视图

（1）简单服务或信息型服务

信息型服务比较简单，它们可对一些内容进行访问，最终用户通过请求/响应序列与这些内容进行交互。信息型服务也可将后端业务应用程序暴露给其他的应用程序。这类被暴露的编程式简单服务完成请求/响应类型的业务任务，并可被视为“原子”（或单元）操作。

按照所解决的业务类型的不同，信息型服务可以进一步细分为三类：

①纯内容服务：纯内容服务编程式访问内容，例如访问天气预报信息、时事新闻等。

②简单的交易服务：是一种比较复杂的信息服务。可以包含跨不同的系统和信息员，对业务系统进行编程式访问，以便请求者可以做出合理的决策。

③信息联合服务：是一些增值信息webservice，旨在嵌

入到不同类型的商业网站，诸如网上交易市场、销售网站等。

信息型服务仅完成一个独立的工作单元，并且底层的数据存储将处于一致的状态。然而，信息型服务本质上并不属于事务性服务。信息型服务并不会保留不同请求之间的信息。也称为无状态的webservice。

信息型服务和简单的交易服务需要得到三个不短发展

的标准的支持：（1）通信协议（简单对象访问协议）；（2）

服务描述（webservice描述语言，简称wsdl）；（3）服务发布和发现（统一描述、发现和集成基础架构）。

（2）复合服务或业务流程

当企业需要将几个服务组合在一起创建一个业务流程，诸如定制订单、客户支持、采购和物流支持等，企业则需要使用复合的webservice。

复合的webservice一般有两类：①构成编程式webservice的复合服务。

②构成交互式webservice的复合服务：这些服务暴露

了web应用的表示（浏览器）层的功能。它们通常暴露多步骤应用的行为，web服务器、应用服务器和底层的数据库系

统相互协作，并将应用直接提交给浏览器，并最终与人进行交互。

复合webservice的标准仍然还在不断修订，并集中在

通信协议（简单对象访问协议）、wsdl、统一描述发现和集

成基础架构、ws-metadataexchange(ws-metadataexchange 允许服务端点向请求者提供元数据信息，并支

持webservice交互的自启动)以及webservice业务流程执行语言（简称bpel）。1.4.2功能属性和非功能属性可使用描述语言对服务进行描述。服务描述主要有两个主要的相互关联的组件：功能特性和非功能特性。功能性描述详述了操作特性。操作特性定义了服务的整个行为，例如定义了如何调用服务、在何处调用服务等细节。功能性描述主要关于消息的语法规则，以及如何配置发送消息的网络协议。

非功能性描述主要关于服务质量属性，诸如服务计量和代价，性能度量，例如响应时间或精度、安全性属性、授权、认证、完整性、可靠性、可伸缩性和可用性。1.4.3状态属性

webservice既可以是无状态的，也可以是有状态的。例如服务可以被重复调用，且无须维持上下文或状态，这样服务则成为无状态的服务。反之，需要维持上下文或状态的服务则成为有装太多服务。1.4.4松耦合

“耦合”这一术语表示了两个系统之间彼此相互依赖的程度。

在紧耦合的交换中，应用程序需要知道它们的合作伙伴的应用程序是如何运行的。它们也需要知道有关合作伙伴如