WebService基础原理解析.docx
《WebService基础原理解析.docx》由会员分享，可在线阅读，更多相关《WebService基础原理解析.docx（19页珍藏版）》请在冰点文库上搜索。
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的应用程序进行比较，有四方面的显著差异[Aldrich2002]：
◆对于请求或调用WebService的应用程序而言，无论这种调用是否需要人的干预，请求或调用的WebService都可视作应用程序的资源。
这意味着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松耦合
“耦合”这一术语表示了两个系统之间彼此相互依赖的程度。
在紧耦合的交换中，应用程序需要知道它们的合作伙伴的应用程序是如何运行的。
它们也需要知道有关合作伙伴如何进行通信的详细细节，以及和它们写作的应用程序的详细位置。
在紧耦合环境中，核心设计模式是同步交互。
在松耦合系统中，当发生变化时，应用程序不需要直达和它们写作的应用程序是如何运作的，也不需要了解写作的应用程序是如何实现的。
好处就在于它的灵活性。
当构成应用程序的各个服务的内部结构和实现不断发生变化时，松耦合系统可以做到随需应变。
若使用WebService。
则从服务请求者到服务提供者之间的绑定是松耦合的。
这意味着服务请求者无须了解服务提供者实现的具体技术细节，诸如编程语言、部署平台等。
服务请求者通常好似用消息来调用服务，即服务请求者通过消息进行请求，服务提供者也通过消息进行相应，而不是使用应用编程接口或文件格式。
紧耦合
松耦合
交互模式
同步
异步
消息类型
RPC类型
文档类型
消息路径
硬编码
路优化
底层平台
同构
异构
绑定协议
静态
动态—延迟绑定
目的
服用
灵活性、广泛的适用性
1.4.5服务粒度
简单请求通常是细粒度的，例如它们通常不可再分。
复合服务通常是粗粒度的，例如通常涉及在一个或多个会话中和其他服务或最终用户进行交互。
粗粒度的通信意味着更大型、更丰富的数据结构，并且使松耦合成为可能。
1.4.6同步
服务的两类编程方式：
一类是同步或远程过程调用（RPC）方式；另一类是异步或消息（文档）方式。
同步服务：
同步服务的客户端将它们的请求表示为带变量的方法调用，方法返回一个包含返回值的响应。
这意味着，当客户端发送一个请求消息时，它会首先等待响应消息，然后才会继续向下运行，这就使得整个调用不是完全成功就是完全失败。
简单的RPC类型的同步服务的典型例子包括：
返回特定股票的当前价格；提供特定地区的当前天气情况；在完成业务交易之前，核实潜在贸易伙伴的信用情况。
异步服务：
是文档类型的服务或消息驱动类型的服务。
当客户端调用消息类型的服务时，客户端通常发送整个文档，诸如订购单，而不是单独发送一些参数。
服务收到整个文档后，会处理它，然后返回（也可能不返回）一个消息结果。
调用异步服务的客户端在继续运行应用程序的其它部分之前，并不需要等待响应，从服务发回的响应可以在数小时甚至数天后才出现。
1.4.7良定义
服务间的交互必须是良定义的。
★
应用程序使用WSDL可以向其它的应用程序描述连接和交互的规则。
1.4.8服务的使用环境
从WebService请求者的角度，将信息服务划分为可替代的服务于关键任务服务这两类。
可替代的服务是多个提供者可提供的服务。
关键任务服务是很可能只被一个特定的服务者提供的服务。
1.5服务接口和实现
（1）服务接口部分定义了外部世界可以看到的服务功能，并提供了访问这些功能的方式。
服务描述了它自身的接口特性、操作的可用性、参数、数据类型及访问协议。
（2）服务实现部分实现了具体的服务接口。
（3）服务、接口、对象和组件之间的关系：
服务实现可包含服务接口规范以及具体组件（业务对象）的实现。
组件技术通常用于实现服务的功能。
服务之间进行交互的唯一方式就是通过它们的接口。
（4）服务编配接口：
必须明确地描述组合服务客户端所期望的全部接口，以及那些组合到服务中的由环境所提供的接口。
服务编配接口的思想如图1.3所示：
图1.3服务、接口和服务的实现
1.6面向服务的体系结构
目前，应用程序集成的最主要的方法是通过交换，而WebService却能超越这种简单的方式，可以访问、编程和集成应用服务。
应用服务封装了已有的应用和新建的应用。
这以为着，不仅可以在应用程序之间交换信息，而且可以利用本地和远程应用中的大量的后端系统和遗留系统，从而复合地、可定制地组合应用。
这个概念的关键是面向服务的体系结构（SOA）。
SOA是一种设计软件的逻辑方法，可通过发布或发现的接口向终端用户应用或网络上的其它服务提供服务。
SOA的主要目的就是使得已有的技术间具有通用的互操作性，并使得未来的应用和体系结构具有可扩展性。
作为一种设计理念，SOA独立于任何具体的技术。
1.6.1SOA中进行交互的角色
SOA的主要组成部分设计三个方面，这是由SOA中的三个主要决策决定的，分别是服务提供者、服务注册中心和服务请求者（或称客户端）。
服务提供者是提供服务的软件代理，提供者负责发布服务的描述，服务将服务描述提供给服务注册机构。
客户端是请求执行服务的软件代理。
代理既是服务客户端，同时又是服务提供者。
客户端必须能够发现所需的服务描述，并能与相应的服务进行绑定。
为了实现这一功能，SOA建立在目前WebService所采用的一些基本规范之上，诸如SOAP、WSDL、UDDI和BPELforWebService。
（1）WebService提供者
从业务角度看，WebService提供者是拥有WebService的组织，并实现了通过服务体现出来的业务逻辑。
从体系结构角度看，WebService是一个平台，驻留和控制对服务的访问。
WebService提供者负责发布WebService。
（2）WebService服务请求者
从业务角度看，它是需要满足一定功能的企业。
从体系结构角度看，它是搜寻并调用服务的应用。
（3）WebService注册机构
WebService注册机构是一个可供搜索的目录，可在该目录中发布和搜索服务描述。
1.6.2SOA中的操作
在SOA中，当应用程序利用WebService在三个角色之间进行交互时，必然涉及三个主要操作，分别是：
发布服务描述、发现服务描述、以及基于服务描述绑定或调用服务。
SOA的逻辑视图如图1.4所示。
首先，WebService提供者将WebService发布到发现代理结构。
然后，WebService客户端使用发现代理机构的注册中心搜索所需的WebService。
最终，基于从发现代理机构所获得的信息，WebService客户端调用（绑定到）WebService提供者所提供的WebService。
图1.4WebService的角色和操作
（1）发布操作
发布操作实际上由两个操作组成：
对WebService本身的描述；对WebService的注册。
服务提供者首先需要使用WSDL正确地描述WebService。
需要以下三类基本信息：
◆业务信息：
有关WebService提供者或服务实现的信息。
◆服务信息：
WebService的特征信息。
◆技术信息：
有关WebService的实现细节及调用方法的信息。
WebService发布后，紧接着就需要进行注册。
存储到WebService注册机构中。
（2）查找操作
主要包含两个操作：
首先需要在发现机构的注册中心搜索服务，然后从搜索结果中选择所需的WebService。
搜索WebService时，将在发现机构的注册中心中查询满足WebService请求者需求的WebService。
根据请求者的不同，发现操作有两类：
◆发现操作可在设计时静态制定，检索程序开发所需的服务的接口描述。
◆发现描述也可动态制定，检索调用所需的服务的绑定和位置描述。
搜索操作将会返回一个WebService结果集。
有两类选择方法：
手动选择和自动选择。
（3）绑定操作
服务请求者使用绑定信息定位并联系服务，从而调用或者初始化一个运行时交互。
有两种不同类型的调用：
◆一种是WebService请求者使用服务描述中的技术信息直接调用WebService。
◆一种是在调用WebService时，由发现机构进行中转。
1.6.3SOA：
一个涉及综合服务的样例
图1.5SOA：
复合服务的实例
1.6.4SOA中的层次
根据使用SOA的企业需求和业务重点的不同，有三类不同的SOA入口点：
（1）实现企业服务编配
这是基本的SOA入口点，是在部门内部或者在少量的部门好企业资产之间的一种典型的实现方式。
包含两个步骤：
首先将企业资产和应用程序转换为SOA实现，然后将那些已经服务化的应用以及新创建的服务应用进行服务编配。
（2）提供给整个企业的服务
在SOA入口点层次，下一阶段将是企业寻找一些基于SOA组件的通用服务。
（3）实现端到端协作型业务流程
术语“端到端的业务流程”意味着成功地集成了不同企业的自动化业务流程和信息系统。
其目标是，向外延企业的所有成员——从产品设计者、供应商、贸易伙伴、物流商到最终用户，提供无缝的互操作和互动关系。
将SOA进行分层的方式如图1.6所示：
图1.6SOA分层
在图中，SOA包含六个不同的层次：
域、业务流程、业务服务、基础架构服务、服务实现及运营系统。
在分层的SOA开发模型中，应用的逻辑流程主要致力于自顶向下的开发方式，该方式强调将业务流程分解为业务服务集合，并利用企业已有的应用程序实现这些服务。
其他的方式还包括自底向上（主要用于企业信息系统）和较常见的中间会师式。
自底向上的方式主要强调如何将印有的应用转换为业务服务，以及如何将业务服务组合成业务流程。
Ø从顶层开始，一次向下分析分层的SOA开发模型：
（1）第一层的划分是基于如下观察：
企业中的所有业务流程都是服务于业务领域。
（2）第二层是业务流程层，它是业务领域的划分。
（3）第三层是业务服务，如何给流程规定合适的业务服务：
就是将流程不断细分为更小的子流程，直到无法再分。
（4）第四层的技术服务是粗粒度的服务，提供了开发、交付、维护的技术基础架构，还提供了单个的业务服务（在第三层）、由业务服务所集成的流程（在第二层），以及提供了维护诸如安全性、性能和可用性这类QoS的能力。
（5）第五层是组件实现曾，用于实现运营系统中已有的应用和系统的服务。
这一层使用组件实现所需的功能。
（6）第六层的运营系统实现业务服务和流程。
第六层包含已有的企业系统或应用，包含客户关系管理和ERP系统与应用、遗留应用、数据库系统与应用、其他打包的应用程序等。
这些系统通常被称为企业信息系统。
1.7WebService的技术架构
图1.7WebService技术架构
（1）使能技术标准
WebService在传输层利用了HTTP协议。
另一个使能技术是可扩展的标记语言（XML）。
WebService基本都是用XML作为基础构造的。
（2）核心服务标准
包括基本标准SOAP、WSDL和UDDI。
◆简单对象访问协议：
SOAP是一个基于XML的简单的消息协议，WebService依靠该协议进行相互间的信息交换。
SOAP协议基于HTTP。
为了进行WebService间的相互通信，SOAP实现了一个请求/响应模型，并使用HTTP来穿透防火墙，将防火墙配置为接受HTTP和FTP服务请求。
◆服务描述：
使用WebService描述语言（WSDL）来描述WebService的功能特性。
WSDL定义了XML语法，将服务描述为能够交换消息的通信端点的集合。
◆服务发布：
使用UDDI可进行WebService的发布。
UDDI是一个公开目录，可提供在线服务的发布，并有助于WebService的最终发现。
（3）服务的组合与协作标准
◆服务组合：
业务流程执行语言（BPEL）可实现WebService的服务组合。
◆服务协作：
WebService编排描述语言（WS-CDL）可指定业务协作中所有参与的WebService的共同的可观测行为，因此通过WebService编排描述语言可实现服务协作。
◆协调/事务标准：
对BPEL进行了补充，提供了定义具体的标准化协议的机制，可用于事务流程系统、工作流系统或者其他需要协调多个WebService的应用。
◆增值标准：
包括安全性和认证机制、授权机制、信任机制、隐私机制、安全会话机制、合同管理机制等。
1.8服务质量（QoS）
QoS指的是WebService的一种能力，它能响应预期的请求，并能以一定的服务质量完成相关的任务，并且所提供的服务质量符合服务提供者与客户的预期。
（1）可用性：
是指服务正常运行的时间，它表示了服务正常运转的概率。
（2）可访问性：
表示了WebService请求能够被服务的程度，也可以通过一个概率来表示在一个时间点上服务能够成功地实例化的比率。
（3）符合标准：
描述了WebService遵循标准的情况。
（4）完整性：
描述了WebService按照它的WSDL描述及服务等级协议（SLA）完成任务的情况。
（5）度量性能：
吞吐量和等待时间。
吞吐量表示了服务在一个特定的时间段内所能服务的请求数。
等待时间指的是客户端在发送请求和收到响应之间的时间间隔。
（6）可靠性：
是指服务能够正确地、始终如一地运行，并且无论系统或网络是否发生故障，都能提供同样的服务质量。
通常是通过每月或每年的事务故障数来表示的。
（7）可伸缩性：
是指伴随服务请求的需求量发生变化，服务能力也能进行相应的变化。
（8）安全性：
诸如认证、授权、消息完整性、机密性等。
（9）事务性：
WebService所需的事务行为和上下文传播有几类不同的情况。
在WebService的SLA中，可描述WebService所需的事务行为，并且WebService提供者需要维护这一属性。
SLA是提供者与客户之间的一种正式协议，在某种程度上对WebService的详细情况进行了形式化，从而保证了服务提供者和服务请求者之间的相互了解、相互预期。
SLA基本上是一个服务质量保证，通常通过逆向计费或其他的一些机制来支持服务质量保证。
SLA可以包含以下部分：
◆Purpose（目的
升级会员 