Web Services概述
Web Service微软提出的基于互联网的开发模型，一经提出即收到业界的广泛推从。本文将总结了一些Web Services相关的一些重要概念，解释了什么是Web Service,详细说明了Web Service的体系结构，如何运用Web Service，如果你是初次接触Web Service，那么你一定会有不少的收获。
体系结构描述
概念
定义一：
Web Services是自包含的、模块化的应用程序，它可以在网络（通常为Web）中被描述、发布、查找以及调用。
定义二：
Web Services是基于网络的、分布式的模块化组件，它执行特定的任务，遵守具体的技术规范，这些规范使得Web Service能与其他兼容的组件进行互操作。
定义三：
所谓Web服务，它是指由企业发布的完成其特别商务需求的在线应用服务，其他公司或应用软件能够通过Internet来访问并使用这项应用服务。（UDDI规范2.0）
体系结构
Web 服务的一个主要思想，就是未来的应用将由一组应用了网络的服务组合而成。只要两个等同的服务使用统一标准和中性的方法在网络上宣传自己，那么从理论上说，一个应用程序就可以根据价格或者性能的标准，从两个彼此竞争的服务之中选出一个。除此之外，一些服务允许在机器之间复制，因而可以通过把有用的服务复制到本地储存库，来提高允许运行在特定的计算机（群）上的应用程序的性能。
Web Services体系结构是面向对象分析与设计（OOAD）的一种合理发展（logical evolution），同时也是电子商务解决方案中，面向体系结构、设计、实现与部署而采用的组件化的合理发展（logical evolution of components geared towards the architecture, design, implementation, and deployment of e-business solutions）。这两种方式在复杂的大型系统中经受住了考验。和面向对象系统一样，封装、消息传递、动态绑定、服务描述和查询也是Web Services中的基本概念，而且，Web Services另外一个基本概念就是：所有东西都是服务，这些服务发布一个API供网络中的其他服务使用，并且封装了实现细节。
下面我们就来看一下Web Services的体系结构--面向服务的体系结构（SOA）。
图1：面向服务的体系结构（SOA）
从图1可以看出，SOA结构中共有三种角色：
① Service provider：发布自己的服务，并且对使用自身服务的请求进行响应
② Service broker：注册已经发布的Service provider，对其进行分类，并提供搜索服务
③ Service requester：利用Service broker查找所需的服务，然后使用该服务
SOA体系结构中的组件必须具有上述一种或多种角色。
在这些角色之间使用了三种操作：
① publish操作：使Service provider可以向Service broker注册自己的功能及访问接口
② find操作：使Service requester可以通过Service broker查找特定种类的服务
③ bind操作：使Service requester能够真正使用Service provider
为支持结构中的三种操作（publish、find和bind），SOA需要对服务进行一定的描述，这种服务描述（Service Description）应具有下面几个重要特点：首先，它要声明Service provider的语义特征。Service broker使用语义特征将Service provider进行分类，以帮助具体服务的查找。Service requester根据语义特征来匹配那些满足要求的Service provider。（因此，语义特征中重要的一点就是对Service provider的分类。）其次，服务描述应该声明接口特征，以访问特定的服务。最后，服务描述还应声明各种非功能特征，如安全要求，事务要求，使用Service provider的费用等等。接口特征和非功能特征也可以用来帮助Service requester对Service provider的查找。
注意，服务描述和服务实现是分离的，这使得Service requester可以在Service provider的一个具体实现（implementation）正处于开发阶段、部署阶段或完成（execution）阶段时，对其（具体实现）进行绑定。
另外，SOA中的组件相互之间必须能够进行交互，才能进行上述三种操作。所以Web Services体系结构的另一个基本原则就是使用标准的技术，包括服务描述、通讯协议以及数据格式等。这样一来，开发者就可以开发出平台独立、编程语言独立的Web Services，从而能够充分利用现有的软硬件资源和人力资源。
最后，SOA体系结构没有对Web Service的粒度进行限制，因此一个Web Service即可以是一个组件（小粒度），该组件必须和其他组件结合才能进行完整的业务处理；Web Service也可以是一个应用程序（大粒度）。
相关技术规范
协议及消息传递（Protocol and Messaging）
SOAP
即简单对象访问协议（Simple Object Access Protocol），它是用于交换XML编码信息的轻量级协议。它有三个主要方面：XML-envelope为描述信息内容和如何处理内容定义了框架；将程序对象编码成为XML对象的规则；执行远程过程调用（RPC）的约定。
SOAP 可以运行在任何其它传输协议上。例如，您可以使用 SMTP，即因特网电子邮件协议来传递SOAP消息。在传输层之间的头是不同的，但XML有效负载保持相同。
性能：
SOAP 用 XML 将消息编码，因此在调用过程的任何一步都极易处理消息。另外，调试 SOAP 消息的方便性使各种 SOAP 执行能快速聚合在一起，这点很重要因为 SOAP 就是要达到大范围的协同工作。（CORBA、DCOM 和 RMI 对参数和返回值使用二进制编码。除此之外，他们假设发送端和接收端充分了解消息的前后关系，因此对诸如参数名称或类型的任何元信息都不编码。这种方法产生了良好的性能，但使中介很难处理消息。因为每个系统使用不同的二进制编码，所以建立互操作的系统很难）。
表面看来，基于 XML 的模式本应比基于二进制的慢，但它并不像表面那么简单。首先，当SOAP被用于通过因特网发送消息时，在每个端点给消息编码／解码的时间与在端点间传输字节的时间相比较是微不足道的，所以这种情况下使用 XML 没太大问题。
其次，当SOAP用于封闭环境下的点对点间的消息传送，如在同一公司部门间的传送时，各端点可能将运行相同的SOAP执行。这样，这个特定执行就拥有专门的优化机会。例如，一个SOAP客户端可添加一个 HTTP header 标记到 SOAP 请求上，这个请求说明它支持一个特定的优化。如果SOAP服务器也支持那个优化，它会在第一个SOAP响应中返回一个 HTTP header 标记，告诉客户端可以在下面的通信中使用这种优化。接下来，客户端和服务器可以开始使用这种优化了。
接口描述（Interface Description）
1. WSDL
WSDL是用来描述网络（network）服务或终端（endpoint）的一种XML语言，它用于定义Web Services以及如何调用它们（描述Web服务的属性，例如它做什么，它位于哪里和怎样调用它）。WSDL文档可用于动态发布Web Services、查找已发布的Web Services以及绑定Web Services。
在WSDL中包含了使用SOAP的服务描述的绑定，也包含了使用简单HTTP GET和POST请求的服务描述的绑定。
WSDL将Web服务定义成一系列的端口（port），每个端口用来表示从抽象端口类型（port type）到用于调用Web服务的具体通信协议的一个映射。端口类型由一组与Service provider交换信息的操作组成，它支持对包含消息的数据类型的定义。（可参考具体的WSDL文档定义http://www-900.ibm.com/developerWorks/webservices/ws-peer4/listing1.html）
一个完整的 WSDL 服务描述是由一个服务接口和一个服务实现文档组成的。 由于服务接口表示服务的可重用定义，它在 UDDI 注册中心被作为 tModel 发布。服务实现描述服务的实例。每个实例都是使用一个 WSDL service 元素定义的。服务实现文档中的每个 service 元素都被用于发布 UDDI businessService。
因为 WSDL 包含了对服务接口的完整描述，所以我们可以使用它来创建能简化服务访问的存根，该存根为一段Java代码（假设使用Java），它自动生成了访问Web服务的类。如果我们需要访问Web服务，只需调用该类中对应的方法即可，而不用在客户端程序中再写入那些令人头疼的配置信息了。通过IBM提供的工具包可以轻松创建WSDL文档对应的存根。（由此看出，不用WSDL也可以访问Web服务）
WSDL取代了IBM的NASSL（Network-Accessible Service Specification Language）和Microsoft的SCL（SOAP Contract Language）。
2. UDDI
即Universal Description, Discovery and Integration。它提供了在Web上描述并发现商业服务的框架。UDDI通过服务注册，以及使用SOAP访问这些注册信息的约定来实现上述目标。
UDDI计划的核心组件是UDDI商业注册，它使用一个XML文档来描述企业及其提供的Web服务。从概念上来说，UDDI商业注册所提供的信息包含三个部分："白页(White Page)" 包括了地址，联系方法，和已知的企业标识；"黄页(Yellow page)"包括了基于标准分类法的行业类别；"绿页(Green Page)"则包括了关于该企业所提供的Web服务的技术信息，其形式可能是一些指向文件或是URL的指针，而这些文件或URL是为服务发现机制服务的。所有的UDDI商业注册信息存储在UDDI商业注册中心中。
借助XML 和SOAP ，集成和交互的问题将从层次上被简化。XML 提供了跨平台的数据编码和组织方法，而SOAP 建立在XML 之上，定义了一种跨系统平台的信息交换的简单包装方法。绑定于HTTP之上的SOAP协议，可以跨语言、跨操作系统进行远程过程调用(RPC)，实现了编程语言和系统平台的无关性。而以前的调用方式则和复杂的分布式对象标准或是中间件有密切的关系，从长期的眼光来看，这些都不是高效的解决方案。XML 和SOAP 这样的跨语言、跨平台的解决方案大大简化了不同企业系统之间的交互问题。
但如果仅仅是XML和SOAP的话，对于公司间的交流仍存在着巨大的鸿沟。UDDI 规范在XML 和SOAP 的基础之上定义了新的一层，在这一层次，不同企业可以用相同的方法描述自己所能提供的，并能查询对方所能提供的服务。
互操作
协议栈 统一服务互操作协议
（这些协议尚未定义）
统一描述、发现和集成协议 (UDDI)
简单对象访问协议 (SOAP)
扩展标注语言 (XML)
通用Internet协议 (HTTP, TCP/IP)
以下图表描述了这些协议的层次关系：
UDDI 注册使用的核心信息模型由XML Schema 定义。使用XML 是因为它提供了平台无关的数据描述并很自然的描述了数据的层次关系。而选择XML Schema 是因为它支持丰富的数据类型，便捷的描述方式及其按信息模型对数据进行验证的能力。
UDDI XML Schema 定义了四种主要信息类型，它们是技术人员在需要使用合作伙伴所提供的Web 服务时必须了解的技术信息。它们是：商业实体信息、服务信息、绑定信息和服务调用规范的说明信息。
UDDI程序员API规范分为两个逻辑部分：查询API 和发布API 。查询API 又分为两个部分:一部分被用来构造搜索和浏览UDDI 注册信息的程序，另一部分在Web服务出现错误时使用。程序员可以利用发布API创建各种类型的工具，以直接与UDDI注册中心进行交互，便于企业技术人员管理businessEntity 或tModel 结构的发布信息。
UDDI调用模型
每一个独立发布的Web服务都是使用一个bindingTemplate结构来建模的。对这个Web服务的调用通常通过缓存bindingTemplate 数据来实现。注意到这一点后，在你准备编写调用某种Web 服务的程序时，该如何使用UDDI 就很清楚了。下面列出了基本步骤：
1．编写调用远程Web 服务的程序时，程序员使用UDDI 商业注册中心(通过使用Web界面或其它基于查询API 的工具)来定位businessEntity 信息，这些信息是由(或为)提供该Web 服务的企业注册的。
2．程序员可以进一步获得更详细的businessService信息，或是得到一个完整的businessEntity结构。因为businessEntity结构包含了有关已发布的Web服务的所有信息，因此程序员只需简单地选择一个bindingTemplate 并保存留待以后使用。
3．基于Web服务在bindingTemplate的tModel中提供的调用规范的相关信息，程序员可以按照该Web服务的调用规范编写程序。
4．在运行时，程序可以按需要使用已保存下来的 bindingTemplate的信息来调用Web服务。
一般说来，只要远程Web 服务和调用它的程序都准确的实现了必要的接口(按照在tModel 中所引用的调用规范)，对远程服务的调用就一定会成功。
服务发现（Service Discovery）
1． UDDI（同上）
2． ADS
即Advertisement and Discovery of Services。这是由IBM提出的建议，它使服务提供者（service provider）能够对他们的服务进行广告宣传。它允许将这些服务的信息集中到大家熟悉的地方，而且还提供了连接内容及服务的方式。
由于ADS提供了可选择的、分散的服务公告机制，因而补充了基于注册的访问方案。这遵循了Microsoft的DISCO（Discovery of Web Services）思想，但更为先进。
156
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
