WebService总结

在现有的各种异构平台的基础上，构筑一个通用的，与应用无关、语言无关的技术层，各种不同平台之上的应用依靠这个技术层来实施彼此的连接和集成，即：传统的的Web技术解决的问题是如何让人来使用Web应用所提供的服务，而Web Service则要解决如何让计算机系统来使用Web应用所提供的服务。从表面上看，Web Service就是一个应用程序，它向外界暴露出一个能够通过Web进行调用的API。这就是说，你能够用编程的方法通过Web调用来实现某个功能的应用程序。例如，创建一个Web Service，它的作用是查询某公司某员工的基本信息。它接受该员工的编号作为查询字符串，返回该员工的具体信息。你可以在浏览器的地址栏中直接输入HTTP GET请求来调用罗列该员工基本信息的ASP页面，这就可以算作是体验Web Service了。从深层次上看，Web Service是一种新的Web应用程序标准，它们是自包含、自描述、模块化的应用，可以在网络(通常为Web)中被描述、发布、查找以及通过Web来调用。Web Service便是基于网络的、分布式的模块化组件，它执行特定的任务，遵守具体的技术规范，这些规范使得Web Service能与其他兼容的组件进行互操作。它可以使用标准的互联网协议，像超文本传输协议HTTP和XML，将功能体现在互联网和企业内部网上。Web Service平台是一套标准，它定义了应用程序如何在Web上实现互操作性。你可以用你喜欢的任何语言，在你喜欢的任何平台上写Web Service。

?

?

RPC 架构	客户机存根	服务器存根
CORBA	存根	框架
DCOM	代理	存根
Web 服务	服务代理	服务实现模板

Web Service出超的地方：

尽管 CORBA 和 DCOM 已经在各种平台上得到了实现，然而实际情况是建立在这些协议之上的任何解决方案都依赖于单一厂商的实现。因此，如果要开发一个 DCOM 应用程序，分布式应用程序中所有参与的节点都必须以 Windows 风格运行。如果要开发 CORBA 应用程序，应用程序环境中的每个节点都要运行相同的 ORB 产品。现在也有来自不同厂商的 CORBA ORB 能够相互操作。但是那种互操作性并不能扩展到像安全与事务管理那样的更高级别的服务中去。不仅如此，所有特定于厂商的优化在这种情况下将丢失殆尽。这两种协议都依赖于严格管理的环境。要找到能成功地在外部调用 DCOM 或 IIOP 的任意两台计算机的几率比较小此外，程序员们必须处理数据排列和数据类型所需的协议唯一的消息格式规则。DCOM 和 CORBA 都是服务器对服务器通信的合适的协议。然而，它们在客户机对服务器通信方面都存在严重的缺陷，特别是当客户机遍布因特网时。 我们需要一个建立在开放因特网标准基础上的新的分布式计算模型。

Web 服务技术提供了一个全新的编程模型来利用开放因特网标准建立分布式应用程序。这一全新的分布式计算解决方案采用特定因特网技术的开放性解决了许多 CORBA 和 DCOM 的互操作性问题。Web 服务技术组件是一套开放的规范，它们要么是现有的因特网标准，要么是被广泛接受并正在通过正常步骤成为标准的规范。组件的基本部分包含 HTTP、XML、SOAP、WSDL、UDDI 以及 WSFL。这部分的基础是 HTTP，它是一个被广泛运用的、类似 RPC 的简单协议，并且是防火墙友好的。接下来，是 XML 中的通用数据表示法语言，它同样被广泛使用。SOAP 是一个基于 XML 的消息传递协议，它不确定平台及语言。它同时支持消息传递和请求／响应通信模型。与 CORBA 和 DCOM 一样，它需要一个 IDL。它所使用的 WSDL 是一个基于 XML 的服务 IDL，定义了服务接口和其实现特征。

特别是，Web 服务

• 使用 HTTP 来实现防火墙友好和不确定有效负载；
• 将 XML 作为一个编码模式使用，它能比 DR 和 CDR 更为广泛地被采用；
• 提供关于 HTTP/SOAP 服务器环境的免费的经济价值建议，或提供关于 ORB 框架的收费的经济价值建议；
• 使用广泛深入的 URL 因特网概念来解决对象识别问题；
• 提供的不只是互操作性的承诺。厂商们正积极工作以证明它们的 SOAP 实现确有互操作性。

2.XML Web 服务

一个能够使用XML消息通过网络来访问的Interface,这个Interface描述了一组可访问的操作，由SOAP+WSDL包装的Object，服务的行为、输入/输出都可使用WSDL描述，适应松散耦合的网络环境，可通过Web访问，手段是SOAP Message。

3.Web Service 部署在Web上的对象

对象接口描述: WSDL?
对象访问: SOAP?
对象界面发现: UDDI?
对象实现: EJB,COM+,CORBA以及任何可用于对象实现的技术

4.架构

三个参与者：

• 服务提供者（Service Provider）：从企业的角度看，这是服务的所有者。从体系结构的角度看，这是托管访问服务的平台。
• 服务请求者（Service Requester）：从企业的角度看，这是要求满足特定功能的企业。从体系结构的角度看，这是寻找并调用服务，或启动与服务的交互的应用程序。
• 服务代理（Service Broker）：这是可搜索的服务描述注册中心，服务提供者在此发布他们的服务描述。在静态绑定开发或动态绑定执行期间，服务请求者查找服务并获得服务的绑定信息（在服务描述中）。服务请求者也可以从服务注册中心以外的其它来源得到服务描述。

三个基本操作

• 发布（Publish）：为了使服务可访问，需要发布服务描述以使服务请求者可以查找它。
• 查找（Find）：在查找操作中，服务请求者直接检索服务描述或在服务注册中心中查询所要求的服务类型。对于服务请求者，可能会在两个不同的生命周期阶段中牵涉到查找操作，在设计时为了程序开发而检索服务的接口描述，在运行时为了调用而检索服务的绑定和位置描述。
• 绑定/调用（Bind/Invoke）：最后需要调用服务。在绑定操作中，服务请求者使用服务描述中的绑定细节来定位、联系和调用服务，从而在运行时调用或启动与服务的交互。

5.工作过程

服务提供者将所提供的服务发布到服务代理的一个目录上，服务请求者首先到服务代理提供的目录上搜索服务，得到如何调用该服务的信息，根据得到的信息调用服务提供者提供的服务。

6.构建过程

?

7.使用过程

8.Web服务的请求过程实例

9.特点

• 完好的封装性：使用者仅看到Web Service提供的功能列表
• 松散耦合：只要接口不变，其使用方法就不会改变
• 使用标准协议规范：使用开放的标准协议进行描述、传输和交换
• 高度可互操作性：可以跨越平台、语言进行调用
• 高度可集成能力
• 动态性：可以自动发现服务并进行调用

10.分类

• Business-Oriented Web Service：面向企业应用的服务，将企业内部的大型系统，如ERP、CRM系统等，封装成Web Service的形式在网络中（Internet or Intranet）提供。企业内部的应用更容易集成；企业间的众多合作伙伴的系统对接更加容易
• Customer-Oriented Web Service：面向电子商务用户的服务，主要针对原有B2C网站的改造，Web Service技术为B2C网站增加了Web Service的应用界面，使得桌面工具可以提供跨越多个B2C服务的桌面服务，如将机票预定、炒股等服务集成到一个个人理财桌面系统中使得用户使用Internet更加方便，能够获得更加便捷的服务。
• Device-Oriented Web Service：面向其它接入设备的服务，如手持设备、日用家电等将原有的网络服务封装成Web Service，支持除PC以外的各种终端，如天气预报、E-mail服务、股票信息等。
• System-Oriented Web Service：如用户权限认证、系统监控等服务，将这些系统级服务封装成Web Service，发布到Internet或者企业内部的Intranet上，其作用范围将从单个系统或局部网络拓展到整个企业网络或整个Internet上。如一个跨国企业的所有在线服务可以使用同一个用户权限认证服务。

11.服务标准

• SOAP?http://www.w3.org/TR/SOAP
• WSDL?http://www.w3.org/TR/wsdl
• UDDI?http://www.oasis-open.org/committees/uddi-spec/tcspecs.shtml

a）SOAP——Simple Object Access Protocol

定义：SOAP 是一个简单的用于在Web上交换结构信息的XML协议。

设计目标: 只提供最必要的功能，简单性和可扩展性，这意味着传统的消息系统和分布对象系统的某些性质不是SOAP?规范的一部分。

模块化和可扩展：没有应用语义和传输语义。

包含：

• 信封 ：消息中包含谁处理消息，是可选还是强制的。
• 数据的编码规则 ：定义了一套编码机制用于交换应用程序定义的数据类型的实例。消息可以采用自身特定的XML词汇，使用namespace来区分彼此。用户只需要了解SOAP消息的格式，而对底层实现的细节可以无需关心，做到信息隐藏。

???????

• RPC调用规范 ：定义了一个用于表示远程过程调用和响应的约定。
• SOAP绑定：定义了一个使用底层传输协议来完成节点之间交换SOAP信封的约定。

b）WSDL——Web Service Description Language

采用XML语言来描述Web Service的属性的语言，WSDL文档可以包含以下内容：What：Web Service做什么；Where：Web Service位于哪里；How：怎样调用。

Web Service作为一个分布式对象来看，WSDL就是Web Service的接口描述语言（IDL）。WSDL定义了一套基于XML的语法，将Web Service描述为能够进行消息交换的服务访问点的集合。

c）UDDI?
基于标准的服务描述和发现的规范(specification)，以资源共享的方式由多个运作者一起以Web Service的形式运作UDDI商业注册中心。核心组件是UDDI商业注册，它使用XML文档来描述企业及其提供的Web Service。

角色和主要操作：

• Service Provider：提供e-Business Service，通过Service Registry发布(Publish)其提供的可用的Service。
• Service Registry：为Service的发布和定位提供支持，类似电话黄页。
• Service Requestor：通过 Service Registry发现(Find)需要的Service，绑定(Bind) Service Provider提供的Service,并实施调用。

与SOAP和WSDL的关系：

• WSDL：Publish的内容、Find的返回结果和Bind的信息都是WSDL描述的服务信息
• SOAP：Service Registry的访问(Publish/Find)、Service的访问都是通过SOAP Message实现

数据模型：

任何企业都可以到其中的一个注册中心去免费注册企业的信息和提供的服务。注册中心之间可以同步数据，所以只要到任何一个中心注册，就可以把自己的企业信息发布到全球所有的注册中心上。

UDDI 和 SOAP

12.Web Service vs. CORBA/DCOM/EJB 对比

?

从体系结构上讲，Web Service不会取代CORBA、COM/DCOM、EJB，四者的概念有所区别：CORBA、COM/DCOM、EJB为分布式应用程序建立服务，通过服务对象来执行客户端调用的服务，Web Service是基于XML和HTTP通信的的分布式对象模型，SOAP可以作为前三者的对象的通信协议，使用Web Service可以实现使用前三者开发的应用的整合。

从通信协议上讲，是竞争的关系：前三者的通信协议规范都定义了传送信息的语义，对参数和返回值使用二进制编码，可以对诸如参数名称或类型的任何元信息都不编码，这使得中介很难处理消息，又因为每个系统使用不同的二进制编码，系统间互操作性很难实现。SOAP并没有定义信息的语义，而是采用XML进行消息编码，正确的处理需要服务器和客户端本身来执行，理解和执行彼此使用的信息格式，应用程序本身在语义解析中扮演者十分重要的角色，可以很好的实现互操作性。SOAP和CORBA/DCOM/EJB所使用的底层通信协议（IIOP/DCOM-RPC）是竞争的。

13.应用

B2C的龙头老大Amazon发布了一套可以通过两种接口访问(XML/HTTP以及XML/SOAP)的Web Services，通过这套Web Services，用户可以使用程序获取Amazon所提供的各种商品的结构化数据，包括产品名称、制造商、价格等等。具体的获取方式包括关键词搜索以及内容树浏览。

GE Global eXchange Services是GE公司的一个组成部分，同时也是基于Internet的B2B电子商务的领导者，在2002年5月1日，它宣布在其为中小企业提供的电子商务事务中提供了Web Services接口。GE Global eXchange Services(GXS)是全球最大的B2B电子商务网络之一，拥有100,000个贸易伙伴，每年完成10亿个商业事务，成交金额达到1万亿美元。

搜索引擎服务商Google发布了一个开发工具包，这个开发工具包使得开发人员可以在自己的应用程序中集成Google搜索，搜索的接口是通过SOAP/WSDL实现的，也就是说Google将他自己的搜索服务包装成了Web Services，目前这个工具包支持Java和.NET两种技术，使用范围被限制在非商业领域，同时单个用户的使用频率被限制在每天1000次搜索以内。

附录：

Web Service与组件的比较（From http://book.51cto.com/art/200911/164310.htm）

开发Web Service的主要目的是提供分布式应用的基本框架， 这些分布式应用之间能够以某些形式进行相互通信，从而促进应用的相互了解、 复用、 开发和集成。乍一看，分布式组件间涉及一些共同的关注事项， 因此很可能将Web Service和组件简单地视为同一类分布式计算， 仅是风格不同而已。然而， 若对Web Service和组件进行进一步的比较可以发现，分布式组件通常用于开发紧耦合的解决方案， 而Web Service的目的并不是定义一个新的组件模型， 而是定义一个功能分布的服务规范，该规范可以应用于任何已有的组件模型、 编程语言或执行环境。

Web Service和组件所支持的集成方案的主要需求是实现多层次的中立性， 通过建立抽象层隐藏端点实现的细节。抽象层既可以实现为Web Service， 也可以实现为组件。对于不同的平台、 语言、 应用程序组件模型、 事务模型、 安全性模型、 传输协议、 调用机制、 数据格式、端点可用性模型等， 集成方案都必须是中立的。这一目标可以很自然地分为下列五个方面： 通信模式、 端点间的耦合类型、 接口类型、 调用类型、代理类型。我们将从这几方面对Web Service和分布式组件进行一个简要的对比。

通信类型： 分布式组件间的交互基于RPC范式， 通常在多个请求中传递少量的数据项， 并且同步地获取少量的返回数据。在组件方式中， 网络通信基于细粒度的对象， 这通常是不可靠的， 并且开销很大。

组件使用同步通信， 然而Web Service却既使用同步通信， 也使用异步通信。对于简单的Web Service，可以采取RPC类型的请求/响应同步通信， 进行细粒度的对象交互。而对于复合的Web Service， 需要采用更松散的异步通信模式，通常采用基于消息的系统。

端点间的耦合类型： 分布式组件依靠紧耦合方式进行交互。在紧耦合的交互中，通常需要调用多个细粒度的API（应用编程接口）。这类紧耦合的交互主要依赖于一点，即设计应用的模型需要能够得到普遍接受。这迫使客户端和服务端都需要采用类似的基础架构， 从而使得分布式组件平台间不能很方便地进行互操作。例如， CORBA需要所有的应用都遵循接口描述语言（IDL）， 并需要使用对象请求代理，而远程方法调用（RMI）则需要进行通信的所有实体都是使用Java语言编写的。对于这类与特定的组件技术紧耦合的实现，在受控环境中是完全可以接受的。然而在Web环境中， 紧耦合的实现将变得不切实际， 并且无法做到可伸缩性。在集成的业务流程中，参与者可能会不断发生变化， 所采用的技术也可能会不断发生变化。这就使得保证所有的参与者都采用统一的基础设施变得非常困难。

另一方面， Web Service并不使用特定的应用接口进行相互绑定， 而是使用抽象的消息定义来进行相互间的绑定，即使用消息定义来取代方法签名。通用的消息定义使得应用程序能独立处理具体的复杂消息， 从而可以复用接口。由于仅需要处理消息， Web Service完全无须关心具体的语言、 平台和对象模型， 从而使那些请求该服务的应用可以在任何平台上使用任何语言来实现。

接口类型： 组件将细粒度的对象层接口暴露给应用程序。在分布式组件方式中， 对于接受者如何激活应用程序，以及对于被调用的这类接口及它们的签名， 发送者都进行了许多假设。与此相反， Web Service仅需要暴露应用层接口。另一方面， Web Service所使用的消息系统在有线格式（wire format）层形成约定。请求者唯一需要假定的就是接收者能够理解所发送的消息。请求者既无须假定接受消息后会发生什么，也无须假定发送者和接收者之间可能发生的事情。

在Web Service方式中， 应用层接口是粗粒度的接口， 描述了在业务层有用的服务。例如， 在Web Service方式中，库存服务将暴露库存补给服务和相关的参数。与基于组件的方式不一样， Web Service方式不会暴露库存对象及它的所有接口，也不会暴露补给服务对象和它的接口， 它们与业务应用都没有直接的关联。

调用类型： 组件通过名称查找服务， 例如CORBA使用命名上下文（Naming Context， 也称命名环境）。与此相反， 在Web Service中引入了“服务能力”这一概念。服务能力描述了分类、 功能及发布、 发现和调用特定服务的条件。例如，我们可以发现许多业务可提供的服务的类别， 例如制造或物流服务， 并可基于价格和QoS（包括响应时间、 负载平衡等技术参数）选择最合适的服务。

请求代理的类型： 分布式计算的传统方式（例如组件框架）使用预定义的接口来调用远程对象：使用服务的程序能够了解目标服务的消息的格式。服务可使用完全不同的绑定方式： 静态绑定和动态绑定。在静态绑定中，应用程序在设计时就了解协作服务的各种详细信息。而在动态绑定中， 应用程序通过服务代理来确定协作服务。

Web Service和组件的其他重要的不同方面还包括： 1）Web Service广泛使用了开放标准， 而组件技术却缺乏开放标准； 2）Web Service可以提供一些组件技术不具有的高级功能。这些高级功能包括运行时协商的QoS（按照QoS标准，在不同的服务提供者之间进行选择）、 反应式服务和流程（服务能根据具体的环境进行调整， 并且不会影响运行效率）、 工作流、 协调，以及基于服务的应用程序的事务部件。

综上所述， 对于体系结构定义明确、 主要面向内联网和企业内部集成的应用， 最适合使用组件系统构建。例如， CORBA这类的分布式组件技术比较适合构建受控环境中的分布式应用。在这样的环境中， 所有的分布式实体间可能共享通用的对象模型，并且对分布式实体间通信的粒度大小和通信量的多少没有限制。此外， 这类环境中的系统部署相对稳定，因此可直接将网络地址变换为对象引用。对于集成各不相同的端点， 分布式组件技术提供了很好的支持。然而， 对于构建业务流程管理的解决方案，分布式组件技术却并不适用（至少不是非常适合）。若要构建跨企业的分布式系统， 需要创建技术协议和协调， 然而分布式组件技术很难做到这些。

因为Web Service提供了一个语义丰富的集成环境， 所以可以使用Web Service构建企业内部或跨企业的业务流程管理解决方案。Web Service最适合用于实现企业间的共享业务， 然而也可使用Web Service集成企业应用。