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在进入操作和离开操作之间进行一定形式的协调。操作端口WebServiceType1请求响应端口端口操作操作请求请求操作响应响应Type2WebService协调图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类型的同步服务的典型例子包括：返回特定股票的当前价格；提供特定地区的当前天气情况；在完成业务交易之前，核实潜在贸易伙伴的信用情况。异步服务：是文档类型的服务或消息驱动类型的服务。当客户端调用消息类型的服务时，客户端通常发送整个文档，诸如订购单，而不是单独发送一些参数。服务收到整个文档后，会处理它，然后返回（也可能不返回）一个消息结果。调用异步服务的客户端在继续运行应用程序的其它部分之前，并不需要等待响应，从服务发回