WebServices技术架构和应用第2章

WebServices技术、架构和应用10第2章WebServices带来了什么2.1什么是WebServices从技术的角度来看，WebService可以被认为是一种部署在Web上的对象（WebObject），因此，具有对象技术所承诺的所有优点；同时，WebServices的基石是以XML为主的、开放的Web规范技术，因此，具有比任何现有对象技术更好的开放性。2.1.1WebServices的概念首先，我们需要来区分两个相似的概念：WebServices和WebService。刚刚接触WebServices的读者往往对这两个概念毫无感觉，认为是一个东西。初看，似乎一个是复数形式，一个是单数形式。然而，WebServices是指用于架构WebService的整体技术框架，而WebService则是使用WebServices技术而创建的应用实例，当然也有很多时候，WebServices的含义也是具体的应用实例，只不过此时是泛指（即复数），因此在本书的其余部分，对于表示架构WebService的整体技术框架的那个WebServices，我们将使用WebServices技术来阐述，而表示使用WebServices技术而创建的应用实例的那个WebServices，我们一律使用泛指的方式：WebServices。WebServices是描述了一些操作的接口，通过标准化的XML消息传递机制，可以通过网络访问这些操作。WebServices是用标准的、规范的基于XML的WSDL语言描述的，这称为WebServices的服务描述。这一描述囊括了与服务交互所需要的全部细节，包括消息格式（详细描述操作的输入输出消息格式）、传输协议和位置。该接口隐藏了服务实现的细节，允许通过独立于服务实现、独立于硬件或软件平台、独立于编写服务所用的编程语言的方式使用该服务。这使得基于WebServices的应用程序具备松散耦合、面向组件和跨技术实现的特点。WebServices都履行一项特定的任务或一组任务。WebServices可以单独或同其他WebServices一起用于实现复杂的商业交易。2.1.2Web对象从外部使用者的角度而言，WebServices是一种部署在Web上的对象/组件，它具备以下特征。完好的封装性：WebServices既然是一种部署在Web上的对象，自然具备对象的良好封装性。对于使用者而言，他能且仅能看到该对象提供的功能列表。松散耦合：这一特征也是源于对象/组件技术，当一个WebServices的实现发生变更的时候，调用者是不会感到这一点的。对于调用者来说，只要WebServices的调用接口不变，WebServices实现的任何变更对他们来说都是透明的，甚至当Web第2章WebServices带来了什么11Services的实现平台从J2EE迁移到.NET或者反向迁移时，用户都可以对此一无所知。从前，分布式的应用程序逻辑需要使用分布式的对象模型，诸如Microsoft的分布式组件对象模型（DCOM）、对象管理集团（OMG）的公用对象请求代理程序体系结构（CORBA）或SUN的远程方法调用（RMI）。通过使用这种基本结构，开发人员仍可拥有使用本地模型所提供的丰富资源和精确性，并可将服务置于远程系统中。这些系统有一个共同的缺陷，那就是它们无法扩展到互联网上。它们要求服务客户端与系统提供的服务本身之间必须进行紧密耦合，即要求一个同类基本结构。这样的系统往往十分脆弱：如果一端的执行机制发生变化，那么另一端便会崩溃。例如，如果服务器应用程序的接口发生更改，那么客户端便会崩溃。对于松散耦合而言，尤其是在Internet环境下的WebServices而言，需要有一种适合Internet环境的消息交换协议。而XML/SOAP正是目前最为适合的消息交换协议。使用协约的规范性：这一特征从对象而来，但相比一般对象，其界面规范更加规范化并易于被机器理解。首先，作为WebServices，对象界面所提供的功能应当使用标准的描述语言来描述（比如WSDL）。其次，由标准描述语言描述的服务界面应当是能够被发现的，因此，这一描述文档需要被存储在私有的或公共的注册库里面。同时，使用标准描述语言描述的使用协约将不仅仅是服务界面，它将被延伸到WebServices的聚合、跨WebServices的事务、工作流等，而这些又都需要服务质量（QoS）的保障。我们知道安全机制对于松散耦合的对象环境的重要性，因此，需要对诸如授权认证、数据完整性（比如签名机制）、消息源认证以及事务的不可否认性等运用规范的方法进行描述、传输和交换。最后，所有层次上的处理都应当是可管理的，因此，需要对管理协约运用同样的机制。使用标准协议规范：作为WebServices，其所有公共的协约完全需要使用开放的标准协议进行描述、传输和交换。这些标准协议具有完全免费的规范，以便由任意方进行实现。一般而言，绝大多数规范将最终有W3C或OASIS作为最终版本的发布方和维护方。高度可集成能力：由于WebServices采取简单的、易理解的标准Web协议作为组件界面描述和协同描述规范，完全屏蔽了不同软件平台的差异，因此，无论是CORBA，DCOM还是EJB，都可以通过这一种标准的协议进行互操作，实现了在当前环境下最高的可集成性。2.1.3WebServices体系架构模型WebServices体系结构基于三种角色（服务提供者、服务注册中心和服务请求者）之间的交互。交互具体涉及到发布、查找和绑定操作。这些角色和操作一起作用于WebServices构件：WebServices软件模块及其描述。在典型情况下，服务提供者提供可通过网络访问的软件模块（WebServices的一个实现）。服务提供者定义WebServices的服务描述，并把它发布到服务请求者或服务注册中心。服务请求者使用查找操作从本地或服务注册中心搜索WebServices技术、架构和应用12服务描述，然后使用服务描述与服务提供者进行绑定，并调用相应的WebServices实现，同它交互。服务提供者和服务请求者角色是逻辑结构。图2-1展示了这些操作、提供这些操作的组件以及它们之间的交互。2.1.3.1角色WebServices体系结构中的角色包括如下。服务提供者（ServiceProvider）：从企业的角度看，这是服务的所有者。从体系结构的角度看，这是托管被访问服务的平台。服务请求者（ServiceRequestor）：从企业的角度看，这是要求满足特定功能的企业。从体系结构的角度看，这是寻找并调用服务，或启动与服务交互的应用程序。服务请求者角色可以由浏览器来担当，由人或无用户界面的程序（例如，另外一个WebServices）来控制它。ServiceRegistryServiceRequestorServiceProviderServiceDescriptionServiceServiceDescriptionPublish(WSDL,UDDI)BindFind(WSDL,UDDI)图2-1WebServices体系架构模型服务注册中心（ServiceRegistry）：这是可搜索的服务描述注册中心，服务提供者在此发布他们的服务描述。在静态绑定开发或动态绑定执行期间，服务请求者查找服务并获得服务的绑定信息（在服务描述中）。对于静态绑定的服务请求者，服务注册中心是体系结构中的可选角色，因为服务提供者可以把描述直接发送给服务请求者。同样，服务请求者可以从服务注册中心以外的其他来源得到服务描述，例如，本地文件、FTP站点、Web站点、ADS文本文件（AdvertisementandDiscoveryofServices）或DISCO文件（DiscoveryofWebServices）。2.1.3.2行为对于利用WebServices的应用程序，必须发生以下三个行为：发布服务描述、查询或查找服务描述以及根据服务描述绑定或调用服务。这些行为可以单次或反复出现。WebServices体系架构中包含的这些具体操作如下。发布（Publish）：为了使服务可访问，需要发布服务描述以使服务请求者可以查找它。发布服务描述的位置可以根据应用程序的要求而变化。第2章WebServices带来了什么13查找（Find）：在查找操作中，服务请求者直接检索服务描述或在服务注册中心中查询所要求的服务类型。对于服务请求者，可能会在两个不同的生命周期阶段中牵涉到查找操作：在设计时，为了程序开发而检索服务的接口描述；而在运行时，为了调用而检索服务的绑定和位置描述。绑定（Bind）：最后需要调用服务。在绑定操作中，服务请求者使用服务描述中的绑定细节来定位、联系和调用服务，从而在运行时调用或启动与服务的交互。而WebServices体系架构中包含如下WebServices构件。服务（Service）：在这里，WebServices是一个由服务描述语言描述的接口，服务描述的实现就是该服务。服务是一个软件模块，它部署在由服务提供者提供的可以通过网络访问的平台上。服务的存在目的就是要被服务请求者调用或者同服务请求者交互。当服务的实现中利用到其他的WebServices时，它也可以作为请求者。服务描述（ServiceDescription）：服务描述包含服务的接口和实现的细节。其中，包括服务的数据类型、操作、绑定信息和网络位置。还可能包括可以方便服务请求者发现和利用的分类及其他元数据。服务描述可以被发布给服务请求者或服务注册中心。WebServices体系结构解释了如何以一种可以互操作的方式实现这些操作。2.1.3.3开发生命周期WebServices开发生命周期则包括了设计和部署以及在运行时对服务注册中心、服务提供者和服务请求者每一个角色的要求。每个角色对开发生命周期的每一元素都有特定要求。开发生命周期有以下四个阶段。构建：生命周期的构建阶段包括开发和测试WebServices实现，定义服务接口描述和定义服务实现描述。可以通过创建新的WebServices，把现有的应用程序变成WebServices和由其他WebServices和应用程序组成新的WebServices，从而提供WebServices的实现。部署：部署阶段包括向服务请求者或服务注册中心发布服务接口和服务实现的定义，以及把WebServices的可执行文件部署到执行环境（典型情况下，被部署到Web应用服务器）中。运行：在运行阶段，可以调用WebServices。在此，WebServices完全部署、可操作，并且服务提供者可以通过网络访问服务。现在，服务请求者可以进行查找和绑定操作。管理：管理阶段包括持续的管理和经营WebServices应用程序。安全性、可用性、性能、服务质量和业务流程问题都必须被解决。2.1.4WebServices协议栈在前一节中我们已经了解到，为了完成在松散耦合环境下的对象访问，以及在基本对象访问之上的事务、工作流、安全机制等。实现一个完整的WebServices体系需要有一系列的协议规范来支撑。WebServices技术、架构和应用14图2-2展示了当前投入使用的WebServices协议栈：WebServicesStack。ToolLayerWSFLServiceFlowStaticUDDIDirectUDDIWSDLSOAPServiceDiscoveryServicePublicationServiceDescription:-ServiceImplementation-ServiceInterfaceXML-basedMessagingBusinessIssuesSecurityManagementQualityofServiceXMLDataPresentationXMLSchemaDataModelingHTTP,FTP,SMTP,MQTransportToolLayerWSFLServiceFlowStaticUDDIDirectUDDIWSDLSOAPSer