初步理解一下：SOA, SOAP, Web Service, WSDL等

Posted 2023-03-21

参考技术A

什么是SOA、SOAP?

SOA到底是什么？

SOA（Service-Oriented Architecture）的定义是面向服务的架构，就是说将软件按照功能设计成一个个服务，这些服务用标准的方式定义接口、并通过标准的协议进行调用。 SOA所定义的接口和调用方式是独立于编程语言和运行平台的，广义上讲SOA可以基于不同的底层技术实现，比如CORBA和Web Services。但CORBA由于过于复杂和臃肿已很少使用，所以目前所说的SOA绝大多数是基于Web Services技术实现。在Web Services的实现方式下，SOA服务的接口用XML进行定义。

在SOA架构下，软件开发从业务流程分析开始，使用组件化业务建模的方法识别和分析各种业务模型，将各种实践融入其中，在这个基础上建立用例，用例直接产 生BPEL，这些BPEL则可以被融入一个服务整合框架中，其描述了各种服务的信息，从而把ESB上的各个模块统一起来，形成一个巨大的服务仓。

将中间层再进行抽离，在中间层作一个跨技术架构的元数据和业务逻辑，使之成为跨技术架构的、可长期继承、并不断积累的企业业务库和最宝贵的信息资产，也就 是面向服务的组件库，而且这个服务组件库也可以被其它企业复用，且不依赖于任何一种技术架构。夸张一点说，如果所有软件企业都使用SOA架构，那么世界软 件业将会发生彻底的改变。显然，这样一个框架不是一种产品，也不仅仅是一种技术，而是一种解决问题的方法论。

SOA可能应用于两个场景：第一种是业务互通互联；第二种是封闭交易系统，即将元数据和业务逻辑抽离，形成可复用。举个例子，在第一种场景中，当不同企业 之间的业务需要相互调用，这时就可能采用SOA技术；在第二种场景中，在企业内部需要将系统进行迁移时，利用SOA技术定义的原有数据和业务流程，可以很 快完成。

SOA并不是一个新事物，IT组织已经成功建立并实施SOA应用软件很多年了，BEA、IBM、等厂商看到了它的价值，纷纷跟进。SOA的目标在于让IT 变得更有弹性，以更快地响应业务单位的需求，实现实时企业（Real-Time Enterprise，这是Gartner为SOA描述的愿景目标）。而BEA的CIO Rhonda早在2001年6月就提出要将BEA的IT基础架构转变为SOA，并且从对整个企业架构的控制能力、提升开发效率、加快开发速度、降低在客户 化和人员技能的投入等方面取得了不错的成绩。

SOA是在计算环境下设计、开发、应用、管理分散的逻辑（服务）单元的一种规范。这个定义决定了SOA的广泛性。SOA要求开发者从服务集成的角度来设计 应用软件，即使这么做的利益不会马上显现。SOA要求开发者超越应用软件来思考，并考虑复用现有的服务，或者检查如何让服务被重复利用。SOA鼓励使用可 替代的技术和方法（例如消息机制），通过把服务联系在一起而非编写新代码来构架应用。经过适当构架后，这种消息机制的应用允许公司仅通过调整原有服务模式 而非被迫进行大规模新的应用代码的开发，使得在商业环境许可的时间内对变化的市场条件做出快速的响应。

SOA也不仅仅是一种开发的方法论--它还包含管理。例如，应用SOA后，管理者可以方便的管理这些搭建在服务平台上的企业应用，而不是管理单一的应用模 块。其原理是，通过分析服务之间的相互调用，SOA使得公司管理人员方便的拿到什么时候、什么原因、哪些商业逻辑被执行的数据信息，这样就帮助了企业管理 人员或应用架构师迭代地优化他们的企业业务流程、应用系统。

SOA的一个中心思想就是使得企业应用摆脱面向技术的解决方案的束缚，轻松应对企业商业服务变化、发展的需要。企业环境中单个应用程序是无法包容业务用户 的（各种）需求的，即使是一个大型的ERP解决方案，仍然不能满足这个需求在不断膨胀、变化的缺口，对市场快速做出反应，商业用户只能通过不断开发新应 用、扩展现有应用程序来艰难的支撑其现有的业务需求。通过将注意力放在服务上，应用程序能够集中起来提供更加丰富、目的性更强的商业流程。其结果就是，基 于SOA的企业应用系统通常会更加真实地反映出与业务模型的结合。服务是从业务流程的角度来看待技术的--这是从上向下看的。这种角度同一般的从可用技术 所驱动的商业视角是相反的。服务的优势很清楚：它们会同业务流程结合在一起，因此能够更加精确地表示业务模型、更好地支持业务流程。相反我们可以看到以应 用程序为中心的企业应用模型迫使业务用户将其能力局限为应用程序的能力。

企业流程（enterprise process）是流经企业框架的空气，它赋予业务模型里的组件以生命，并更加清晰地定义了它们之间的关系。流程定义了同业务模型进行交互操作的专门方 法。例如，会计可能是企业服务系统的一个组件--但是将发票寄给客户却是一个业务流程。服务被定义用来支持业务流程，因而贯穿整个流程始终的是：各种服务 组件在流程和逻辑实现过程中的装配操作。理解业务流程是定制服务的关键所在。

有利于企业业务的集成传统的应用集成方法（点对点集成、企业消息总线或中间件的集成（EAI）、基于业务流程的集成）都很复杂、昂贵，并且不灵活。这些集 成方法难于快速适应基于企业现代业务变化不断产生的需求。基于面向服务架构 (SOA) 的应用开发和集成可以很好的解决其中的许多问题。

SOA 描述了一套完善的开发模式来帮助客户端应用连接到服务上。这些模式定制了系列机制用于描述服务、通知及发现服务、与服务进行通信。

不同于传统的应用集成方法，在 SOA 中，围绕服务的所有模式都是以基于标准的技术实现的。大部分的通信中间件系统，如 RPC、CORBA、DCOM、EJB 和 RMI，也同样如此。可是它们的实现都不是很完美的，在权衡交互性以及标准定制的可接受性方面总是存在问题。SOA 试图排除这些缺陷。因为几乎所有的通信中间件系统都有固定的处理模式，如RPC 的功能、CORBA 的对象等等。然而，服务既可以定义为功能，又可同时对外定义为对象、应用等等。这使得 SOA 可适应于任何现有系统，并使得系统在集成时不必刻意遵循任何特殊定制。

SOA 帮助企业信息系统迁移到"leave-and-layer"架构之上，这意味着在不用对现有的企业系统做修改的前提下，系统可对外提供 Web 服务接口，这是因为它们已经被可以提供 Web 服务接口的应用层做了一层封装，所以在不用修改现有系统架构的情况下，SOA 可以将系统和应用迅速转换为服务。SOA 不仅覆盖来自于打包应用、定制应用和遗留系统中的信息，而且还覆盖来自于如安全、内容管理、搜索等 IT 架构中的功能和数据。因为基于 SOA 的应用能很容易地从这些基础服务架构中添加功能，所以基于SOA的应用能更快地应对市场变化，为使企业业务部门设计开发出新的功能应用。

Soap是什么？

SOAP 是Simple Object Access Protocol（简单对象访问协议）的缩写。

SOAP是一个用于分布式环境的、轻量级的、基于XML进行信息交换的通信协议.

对于Soap的理解：

第一步理解：SOAP＝HTTP＋XML

第二步理解：SOAP把XML的使用代码化为请求和响应参数编码模式，并用HTTP作传输。

SOAP是把成熟的基于HTTP的WEB技术与XML的灵活性和可扩展性组合在了一起。

第三步理解：具体地讲，一个SOAP实现可以简单地看作遵循SOAP编码规则的HTTP请求和响应。

注意：SOAP 是一个协议，与编程语言无关。实际上，许多语言已经开始支持 SOAP，如：Java，C，C＋＋以及javascript。

Soap的起源？Soap解决的问题？

SOAP最初由微软发起研究，用以解决MTS/COM资源消耗大，不够轻巧等问题，后逐渐被IBM等巨头接纳并加入研究，现已提交W3C，成为Web Service应用传输标准。SOAP技术主要用于实现大量异构程序和平台之间的互操作性，从而使存在的应用能够被广泛的用户所访问。

SOAP意思是简单对象访问协议（Simple Object Access Protocol）。的确如它的名字一样，SOAP是很简单的。它是一个基于XML的协议，允许程序组件和应用程序彼此使用一种标准的Internet协 议--HTTP来通讯。SOAP是一种独立的平台，它不依赖程序语言，它是简单的，弹性的，很容易扩展的。目前，应用程序能够彼此使用一种基于DCOM和 CORBA技术的远程过程调用（RPC）来进行相互通讯，但HTTP不被设计为这个目的。RPC在Internet上应用是非常困难的，它们会出现许多兼 容性和安全性的问题，因为防火墙和代理服务器通常都会阻断（block）这些类型的流量。应用程序之间最好的通讯方式是通过HTTP协议，因为HTTP是 支持所有Internet浏览器和服务器的。基于这个目的，SOAP协议被创建出来。

SOAP（Simple Object Access Protocol ）简单对象访问协议是在分散或分布式的环境中交换信息的简单的协议，是一个基于XML的协议，它包括四个部分：SOAP封装(envelop)，封装定义 了一个描述消息中的内容是什么，是谁发送的，谁应当接受并处理它以及如何处理它们的框架；SOAP编码规则（encoding rules），用于表示应用程序需要使用的数据类型的实例; SOAP RPC表示(RPC representation)，表示远程过程调用和应答的协定;SOAP绑定（binding），使用底层协议交换信息。

虽然这四个部分都作为SOAP的一部分，作为一个整体定义的，但他们在功能上是相交的、彼此独立的。特别的，信封和编码规则是被定义在不同的XML命名空间(namespace)中，这样使得定义更加简单。

什么是CXF？

Apache CXF = Celtix + XFire，Apache CXF 的前身叫 Apache CeltiXfire，现在已经正式更名为 Apache CXF 了，以下简称为 CXF。CXF 继承了 Celtix 和 XFire 两大开源项目的精华，提供了对 JAX-WS 全面的支持，并且提供了多种 Binding 、DataBinding、Transport 以及各种 Format 的支持，并且可以根据实际项目的需要，采用代码优先（Code First）或者 WSDL 优先（WSDL First）来轻松地实现 Web Services 的发布和使用。目前它仍只是 Apache 的一个孵化项目。

Apache CXF 是一个开源的 Services 框架，CXF 帮助您利用 Frontend 编程 API 来构建和开发 Services ，像 JAX-WS 。这些 Services 可以支持多种协议，比如：SOAP、XML/HTTP、RESTful HTTP 或者 CORBA ，并且可以在多种传输协议上运行，比如：HTTP、JMS 或者 JBI，CXF 大大简化了 Services 的创建，同时它继承了 XFire 传统，一样可以天然地和 Spring 进行无缝集成。

CXF 包含了大量的功能特性，但是主要集中在以下几个方面：

支持 Web Services 标准：CXF 支持多种 Web Services 标准，包含 SOAP、Basic Profile、WS-Addressing、WS-Policy、WS-ReliableMessaging 和 WS-Security。

Frontends：CXF 支持多种“Frontend”编程模型，CXF 实现了 JAX-WS API （遵循 JAX-WS 2.0 TCK 版本），它也包含一个“simple frontend”允许客户端和 EndPoint 的创建，而不需要 Annotation 注解。CXF 既支持 WSDL 优先开发，也支持从 Java 的代码优先开发模式。

容易 使用： CXF 设计得更加直观与容易使用。有大量简单的 API 用来快速地构建代码优先的 Services，各种 Maven 的插件也使集成更加容易，支持 JAX-WS API ，支持 Spring 2.0 更加简化的 XML 配置方式，等等。

支持二进制和遗留协议：CXF 的设计是一种可插拨的架构，既可以支持 XML ，也可以支持非 XML 的类型绑定，比如：JSON 和 CORBA。

我们来利用cxf创建一个简单的webservice吧。

首先cxf 所需要的包：更具网站说明以下的包都是必须的，但是在我的实际项目中红色部分的包并没有用到。

大家可更具自己需求来添加适应的包。

cxf.jar

commons-logging.jar

geronimo-activation.jar (Or the Sun equivalent)//

geronimo-annotation.jar (Or the Sun equivalent)//

geronimo-javamail.jar (Or the Sun equivalent)//

neethi.jar

jaxb-api.jar

jaxb-impl.jar

stax-api.jar//

XmlSchema.jar

wstx-asl.jar

xml-resolver.jar

分布式应用程序和浏览器

研究一下当前的应用程序开发，你会发现一个绝对的倾向：人们开始偏爱基于浏览器的瘦客户应用程序。这当然不是因为瘦客户能够提供更好的用户界面，而是因为 它能够避免花在桌面应用程序发布上的高成本。发布桌面应用程序成本很高，一半是因为应用程序安装和配置的问题，另一半是因为客户和服务器之间通信的问题。

传统的Windows富客户应用程序使用DCOM来与服务器进行通信和调用远程对象。配置好DCOM使其在一个大型的网络中正常工作将是一个极富挑战性的 工作，同时也是许多IT工程师的噩梦。事实上，许多IT工程师宁愿忍受浏览器所带来的功能限制，也不愿在局域网上去运行一个DCOM。在我看来，结果就是 一个发布容易，但开发难度大而且用户界面极其受限的应用程序。极端的说，就是你花了更多的资金和时间，却开发出从用户看来功能更弱的应用程序。不信？问问 你的会计师对新的基于浏览器的会计软件有什么想法：绝大多数商用程序用户希望使用更加友好的Windows用户界面。

关于客户端与服务器的通信问题，一个完美的解决方法是使用HTTP协议来通信。这是因为任何运行Web浏览器的机器都在使用HTTP协议。同时，当前许多防火墙也配置为只允许HTTP连接。

许多商用程序还面临另一个问题，那就是与其他程序的互操作性。如果所有的应用程序都是使用COM或.NET语言写的，并且都运行在Windows平台上， 那就天下太平了。然而，事实上大多数商业数据仍然在大型主机上以非关系文件(VSAM)的形式存放，并由COBOL语言编写的大型机程序访问。而且，目前 还有很多商用程序继续在使用C++、Java、Visual Basic和其他各种各样的语言编写。现在，除了最简单的程序之外，所有的应用程序都需要与运行在其他异构平台上的应用程序集成并进行数据交换。这样的任 务通常都是由特殊的方法，如文件传输和分析，消息队列，还有仅适用于某些情况的的API，如IBM的"高级程序到程序交流(APPC)"等来完成的。在以 前，没有一个应用程序通信标准，是独立于平台、组建模型和编程语言的。只有通过Web Service，客户端和服务器才能够自由的用HTTP进行通信，不论两个程序的平台和编程语言是什么。

什么是WebService?

Web services是建立可互操作的分布式应用程序的新平台。作为一个Windows程序员，你可能已经用COM或DCOM建立过基于组件的分布式应用程序。COM是一个非常好的组件技术，但是我们也很容易举出COM并不能满足要求的情况。

Web service平台是一套标准，它定义了应用程序如何在Web上实现互操作性。你可以用任何你喜欢的语言，在任何你喜欢的平台上写Web service ，只要我们可以通过Web service标准对这些服务进行查询和访问。

Web service平台需要一套协议来实现分布式应用程序的创建。任何平台都有它的数据表示方法和类型系统。要实现互操作性，Web service平台必须提供一套标准的类型系统，用于沟通不同平台、编程语言和组件模型中的不同类型系统。在传统的分布式系统中，基于界面 (interface)的平台提供了一些方法来描述界面、方法和参数（译注：如COM和COBAR中的IDL语言）。同样的，Web service平台也必须提供一种标准来描述Web service，让客户可以得到足够的信息来调用这个Web service。最后，我们还必须有一种方法来对这个Web service进行远程调用。这种方法实际是一种远程过程调用协议(RPC)。为了达到互操作性，这种RPC协议还必须与平台和编程语言无关。

Web Service 是一种新的web应用程序分支，他们是自包含、自描述、模块化的应用，可以发布、定位、通过web调用。Web Service可以执行从简单的请求到复杂商务处理的任何功能。一旦部署以后，其他Web Service应用程序可以发现并调用它部署的服务。

Web Service是一种应用程序，它可以使用标准的互联网协议，像超文本传输协议(HTTP)和XML，将功能纲领性地体现在互联网和企业内部网上。可将Web服务视作Web上的组件编程。

1 历史

web广泛用到的技术：

◆TCP/IP：通用网络协议，被各种设备使用

◆html：通用用户界面，可以使用HTML标签显示数据

◆Java：写一次可以在任何地方运行的通用编程语言

◆XML ：通用数据表达语言，在web上传送机构化数据的容易方法

他们的特点是其开放性，跨平台性，开放性正是Web services的基础。

2 Web发展的趋势

内容更动态化

◆带宽Bandwidth更便宜，易于获得

◆存储器Storage更便宜，更易获得

◆普遍式计算变得更加重要：大量的设备，例如移动电话，页面，电脑，pc，已经在Internet上变得普遍，平台变得更多元化，象XML这样的跨平台技术变得更重要

3 Web Services扮演什么角色？

上述的这些趋势意味着，更加智能的处理，操作和汇总内容变得十分重要。让我们看看按照Web services角度所预示的四个趋势：

◆内容更加动态：一个web service必须能合并从多个不同源来的内容，可以包括股票，天气，新闻等，在传统环境中的内容，如存货水平，购物订单或者目录信息等，都从后端系统而来

◆带宽更加便宜：web services可以分发各种类型的内容（音频，视频流等）

◆存储更便宜: web services必须能聪明地处理大量数据，意味着要使用数据库，LDAP目录，缓冲，和负载平衡软件等技术保持可扩展能力

◆普遍式计算更重要：web services不能要求客户使用某一版本的windows的传统浏览器，必须支持各种设备，平台，浏览器类型，各种内容类型。

4 两种重要技术

要达到这样的目标，Web services要使用两种技术：

◆XML XML是在web上传送结构化数据的伟大方式，Web services要以一种可靠的自动的方式操作数据，HTML不会满足要求，而XML可以使web services十分方便的处理数据，它的内容与表示的分离十分理想

◆SOAP SOAP使用XML消息调用远程方法，这样web services可以通过HTTP协议的post和get方法与远程机器交互，而且，SOAP更加健壮和灵活易用。

其他象UDDI和WSDL技术与XML和SOAP技术紧密结合用于服务发现。</SPAN>

组成Web service平台的这三个技术。

XML和XSD

可扩展的标记语言(XML)是Web service平台中表示数据的基本格式。除了易于建立和易于分析外，XML主要的优点在于它既是平台无关的，又是厂商无关的。无关性是比技术优越性更重要的：软件厂商是不会选择一个由竞争对手所发明的技术的。

XML解决了数据表示的问题，但它没有定义一套标准的数据类型，更没有说怎么去扩展这套数据类型。例如，整形数到底代表什么？16位，32位，还是 64位？这些细节对实现互操作性都是很重要的。W3C制定的XML Schema(XSD)就是专门解决这个问题的一套标准。它定义了一套标准的数据类型，并给出了一种语言来扩展这套数据类型。Web service平台就是用XSD来作为其数据类型系统的。当你用某种语言(如VB.NET或C#)来构造一个Web service时，为了符合Web service标准，所有你使用的数据类型都必须被转换为XSD类型。你用的工具可能已经自动帮你完成了这个转换，但你很可能会根据你的需要修改一下转换 过程。

WSDL

你会怎样向别人介绍你的Web service有什么功能，以及每个函数调用时的参数呢？你可能会自己写一套文档，你甚至可能会口头上告诉需要使用你的Web service的人。这些非正式的方法至少都有一个严重的问题：当程序员坐到电脑前，想要使用你的Web service的时候，他们的工具(如Visual Studio)无法给他们提供任何帮助，因为这些工具根本就不了解你的Web service。解决方法是：用机器能阅读的方式提供一个正式的描述文档。Web service描述语言(WSDL)就是这样一个基于XML的语言，用于描述Web service及其函数、参数和返回值。因为是基于XML的，所以WSDL既是机器可阅读的，又是人可阅读的，这将是一个很大的好处。一些最新的开发工具 既能根据你的Web service生成WSDL文档，又能导入WSDL文档，生成调用相应Web service的代码。

webservice soap wsdl简介

先给出一个概念 SOA ，即Service Oriented Architecture ，中文一般理解为面向服务的架构，

既然说是一种架构的话，所以一般认为 SOA 是包含了运行环境，编程模型，

架构风格和相关方法论等在内的一整套新的分布式软件系统构造方法和环境，

涵盖服务的整个生命周期。而在 SOA 的架构风格中，服务是最核心的抽象手段。

SOA 中的服务是构建在一些列基于开放标准的基础之上的，

Web 服务定义了如何在异构系统之间实现通信的标准化方法，

从而就使得 Web 服务可以跨越运行平台和实现语言，

同时也使得 Web 服务成为了实现 SOA 中服务的主要技术。

至于SOA 的话，太高深的技术，这里不予讨论（嘿嘿），本篇博文只介绍 WebServices 这项技术。

引子

有没有一种办法可以实现跨应用程序进行通信和跨平台进行通信呢？

换句话说，就是有什么办法可以实现我的应用程序 A 可以和应用程序 B 进行通信呢？

或者说是，我用 Java 写的应用程序和用 . Net 开发的应用程序之间进行通信呢？

很多时候，上面提到的这些，我们是必须要使用的，比如，一个跨应用程序吧，

拿腾讯 QQ 来说吧，我估计每一个人都用过腾讯 QQ 上面的天气预报工具吧 ！ ！ ！

 

上面的这个天气预报功能是如何实现的呢？

有一种办法，那就是腾讯公司放个卫星上天，并且在公司中成立一个气象部门，天天关注于天气，

然后每时每刻更新腾讯 QQ 上的这个天气预报信息，

确实，这种办法确实行得通，不过，要真这样做的话，估计马化腾也该被踢出去了（哪有这么蠢啊？），

那么上面这个是如何实现的呢？别急，且听我慢慢道来~~~

然后，我们再来看看跨平台这个东东又是什么呢？

这里主要是拿 . Net 平台和Java 平台来说明例子，

假若，有两个公司，每个公司呢都有自己的一个项目，一个公司呢使用 . Net 开发，一个呢，使用 Java 开发，

恩，本来呢，这两个是相互独立的，进水不犯河水，但是有一天，突然，这两个公司给合并了，

合并后的老总发现，如果把两个项目结合起来将会大大的赚一笔，为此，如何做？

因为要把两个项目结合在一起，那么这两个项目之间总应该通通信吧 ！！！

可这两个项目又是基于不同的平台，怎么通信呢？麻烦了吧 ！！！

而后再看一种情况，就是比如一个公司使用的服务器是 Windows Server 2008，

那么它如何和 IT 供应商的UNIX 或者是 Linux 服务器进行连接呢？也很复杂吧 ！！！

WebServices特点介绍

WebServices 提供一个建立分布式应用的平台，使得运行在不同操作系统和不同设备上的软件，或者是用不同的程序语言和不同厂商的软件开发工具开发的软件，所有可能的已开发和部署的软件，能够利用这一平台实现分布式计算的目的。WebServices的思想是：使得应用程序也具有 Web 分布式编程模型的松散耦合性。

WebServices的特点：

（1），WebServices 是自包含的。即在客户端不需要附加任何软件，只要客户机支持 HTTP 和XML 就 OK 了。

（2），WebServices 是自我描述的。在客户端和服务端都不需要知道除了请求和响应消息的格式和内容外的任何事。

（3），WebServices 是跨平台和跨语言的。客户端和服务端均可以在不同的平台和语言环境中实现，同时，不必为了支持 WebServices 而更改现有的代码。

（4），WebServices 是基于开放和标准的。XML 和 HTTP 是WebServices 的主要技术基础，而 XML 和HTTP 早就成了业内标准了。

（5），WebServices 是动态的。

（6），WebServices 是可以组合的。也就是通过一个 WebService 访问另外一个 WebService 来达到组合的目的。通过组合 WebServices 便可以将简单的 WebServices 聚合成为实现更多复杂功能的复杂的服务。

（7），WebServices 是松散耦合的。它完全解耦了客户端和服务端。

（8），WebServices 提供编程访问的能力。换句话说，就是可以通过编写程序来访问Web 服务。

（9），WebServices 是基于经过考验的成熟技术上构建的。比如 XML 和 HTTP。

（10），WebServices 提供打包现有应用程序的能力。

（11），WebServices 通过网络进行发布，查找和使用。

上面这些特点呢，现在不清楚的话，也不用紧，等下还会有详细的说明的 ！！！

WebServices到底是什么？

如果简单的说的话，WebServices就是一组函数库，不过这和我们平时概念中的函数库却又有所不同，我们平时所使用的函数库要么是自己写的（在自己的应用程序当中写一组函数库），

要么是调用底层的 API（操作系统 API 如Win32 API），上面的这两种情况有一个共同点，

那就是函数库是位于客户端本地的，比如，您调用 Win32 API的话，就是调用本地操作系统上的函数库，而这里提到 Web 服务也是一组函数库这个概念和上面提到的函数库这个概念的区别就在此处，因为 Web服务看做一组函数库的话，那么这组函数库不是位于本地的，而是位于远程机器上（当然也可以是本地机器中）。

何为 Web 服务？

也就是网络服务，那就是把网络上不知道那个地方的一些函数看做是一组服务，然后我再通过网络就可以使用这些服务。

关于什么是 Web 服务，上面的说法那是山寨版的，稍微正经一点的说法是：

Web 服务是一种部署在 Web 上的对象或者是应用程序组件。

Why WebServices？

为什么需要使用 WebServices呢？这必须根据 WebServices 的特点以及其优势进行分析了。

首先，上面呢，也说了，Web服务的话，就是一组网络上的应用程序组件，

这样的话，您便可以通过在您的应用程序中使用 Web 服务来将您的应用程序提升到服务层面上来。

既然可以看做是一组服务了的话，那么当然就是可以提供给别个（别的应用程序）使用咯。

比如，我可以通过 Web 服务来公开一些接口给别个使用，至于这些要不要收费呢？那就看我心情了，前面举了腾讯 QQ 上查询天气的例子，这个例子呢，就可以在这里来做一个解释了，

在中国，应该只有一个卫星来进行天气预报的吧？腾讯也不可能为了天气预报而专门放个卫星上天吧？

可是腾讯 QQ 又确实是可以查询天气的，这里，便可以通过 Web 服务来解决。

首先，中国气象局应该是有一个卫星的，气象局根据卫星所返回的结果实时发布全国各地的天气状况，并且将这些天气信息以 Web 服务的形式公开，然后呢，腾讯 QQ 便可以通过这个 Web 服务来访问到天气状况了，再将这些天气状况反馈到 QQ 上就 OK 了。

然后，上面提到了 Web服务是应用程序组件，既然是组件，那么就可以对这个组件重复的进行使用了，

同时可以通过 Web 服务来实现将这个应用程序组件作为一个服务来进行使用，

更为强大的是，可以将多个 WebServices组合成为更为强大的 WebServices ，

并且是通过互联网哦！！！

这也是一大优点啊，

然后呢，最基本的 WebServices是基于 XML 和 HTTP 的

（当然这是最基本的 WebServices ，比如 WebServices 还可以通过 HTTPS 或者是 SMTP 来实现通信），

这又有什么好处呢？很明显，XML 和HTTP 这些都已经是标准了，

不论你是 Java 平台呢，还是 . Net 平台开发出来的（或者是是使用 Web 服务），既然我是使用 XML 和 HTTP 的话，我才懒得鸟你什么 Java 还是 . Net 呢，我也不管你是 Linux 还是 Windows ，这一切都和我 Web 服务无关，

我关注的只是通过 HTTP 协议来传输 XML 就 OK 了，

至于这些 XML 是如何被服务提供者开发出来的或者这些 XML 是如何被服务请求者使用的，这些都和我无关，这里便可以看出 Web 服务的另一个优势了，那就是跨语言跨平台（实现协同工作），所以可以通过 Web 服务来实现不同应用程序和不同平台之间的通信。

Web 服务允许独立于实现服务基于的硬件或者是软件平台和编写服务所用的编程语言使用服务，

根据上面这两点呢，

便可以解决掉最开始提出的使用 Java 开发的应用程序如何和使用 . Net 开发的应用程序之间进行通信这一问题，

同时，也可以解决 Linux 或者是UNIX 和 Windows Server 2008 之间进行连接这一问题了。

最后就是通过使用不同的 Web 服务，也不管 Web 服务是那种编程语言实现的，

我们都可以从不同的平台和操作系统进行访问，从而大大提高了不同应用程序共享数据和应用的能力。

并且 Web服务提供了构建 SOA 所必须得技术基础。

从上面可以看出通过 WebServices解决了我们曾经想都不敢想的问题，这么强大的东西为什么不加以好好利用呢？

           

          

           

WebServices体系结构

 

在Web 服务的体系结构中，涉及到三个角色，

一个是 Web 服务提供者，一个是 Web 服务中介者，还有一个就是 Web 服务请求者，

同时还涉及到三类动作，即发布，查找，绑定，

Web 服务提供者：

可以发布 Web 服务，并且对使用自身服务的请求进行响应，

Web 服务的拥有者，它会等待其他的服务或者是应用程序访问自己。

Web 服务请求者：

也就是 Web 服务功能的使用者，它通过服务注册中心也就是 Web 服务中介者查找到所需要的服务，

再利用 SOAP 消息向 Web 服务提供者发送请求以获得服务。

Web 服务中介者：

也称为服务代理，用来注册已经发布的 Web服务提供者，并对其进行分类，同时提供搜索服务，

简单来说的话，Web 服务中介者的作用就是把一个 Web 服务请求者和合适的 Web 服务提供者联系在一起，

充当一个管理者的角色，一般是通过 UDDI来实现。

发布：

通过发布操作，可以使 Web服务提供者向 Web 服务中介者注册自己的功能以及访问的接口。

发现（查找）：

使得 Web 服务请求者可以通过 Web 服务中介者来查找到特点的种类的 Web 服务。

绑定：

这里就是实现让服务请求者能够使用服务提供者提供的服务了。

            

          

          

WebServices三种基本元素之 SOAP

SOAP 即 Simple Object AccessProtocol 也就是简单对象访问协议。

SOAP 呢，其指导理念是“唯一一个没有发明任何新技术的技术”，

是一种用于访问 Web 服务的协议。

因为 SOAP 基于XML 和 HTTP ，其通过XML 来实现消息描述，然后再通过 HTTP 实现消息传输。

SOAP 是用于在应用程序之间进行通信的一种通信协议。

因为是基于 XML 和HTTP 的，所以其独立于语言，独立于平台，并且因为 XML 的扩展性很好，

所以基于 XML 的 SOAP 自然扩展性也不差。

通过 SOAP 可以非常方便的解决互联网中消息互联互通的需求，

其和其他的 Web 服务协议构建起 SOA 应用的技术基础。

SOAP 协议的一个重要特点是它独立于底层传输机制，Web 服务应用程序可以根据需要选择自己的数据传输协议，

可以在发送消息时来确定相应传输机制。

由于 HTTP 协议本身的一些特点和局限性，

使得当 SOAP 使用HTTP 绑定的 Web 服务并不能满足某些企业应用的需求。

比如，HTTP 不是一个可靠传输协议，所以有可能在传输过程中出现问题，

然后 HTTP 协议基于Request/Response 模型，也就是说客户端需要在等待响应消息接收完成后才能继续执行，

而此时如果响应时间过长呢？

基于上面的这些需求，便需要选择合适的传输协议了。

关于这方面的内容的话，有点深奥了，有兴趣的可以去看看 IBM 的一些关于这方面内容的介绍。

还有一点需要提及一下，那就是 SOAP 是可以绕过防火墙的，将来将会作为 W3C 的标准进行发展。

            

          

          

WebServices三种基本元素之 WSDL

WSDL 即Web Services Description Language也就是 Web 服务描述语言。

是基于 XML的用于描述 Web 服务以及如何访问 Web 服务的语言。

服务提供者通过服务描述将所有用于访问 Web服务的规范传送给服务请求者，

要实现 Web服务体系结构的松散耦合，服务描述是一个关键，

不管是请求者还是服务提供者，通过服务描述便可以不必了解对方的底层平台，编程语言等，

服务描述与底层的 SOAP 基础结构相结合，

足以封装服务请求者的应用程序和服务提供者的 Web服务之间的这个细节。

WSDL 描述了 Web服务的三个基本属性：

（1）服务所提供的操作

（2）如何访问服务

（3）服务位于何处（通过 URL 来确定就 OK 了）

        

       

    

WebServices三种基本元素之 UDDI

UDDI 即 Universal Description，Discovery and Integration，也就是通用的描述，发现以及整合。

WSDL 呢，用来描述了访问特定的 Web 服务的一些相关的信息，可以在互联网上，

或者是在企业的不同部门之间，如何来发现我们所需要的 Web 服务呢？

而 Web 服务提供商又如何将自己开发的 Web 服务公布到因特网上，

这就需要使用到 UDDI 了，UDDI的话，是一个跨产业，跨平台的开放性架构，

可以帮助 Web 服务提供商在互联网上发布 Web 服务的信息。

UDDI 呢是一种目录服务，企业可以通过 UDDI 来注册和搜索 Web 服务。

简单来时候话，UDDI 就是一个目录，只不过在这个目录中存放的是一些关于 Web 服务的信息而已。

并且 UDDI 通过SOAP 进行通讯，构建于 . Net 之上。

        

           

开发 Web服务的方式

（1）开发阶段：

        实现一个 Web 服务，使这个 Web 服务能响应和接收 SOAP 消息，

      （这个呢，其实可以通过 Visual Studio 来帮助实现），

       定义好逻辑模块（这个 Web 服务总要干点事情吧），

       然后再撰写 WSDL 文件（这个呢，开发工具会自动生成的，不需要人工撰写了）

（2）部署阶段：

       指定 Web 服务的传输协议，将 Web 服务注册到相应服务描述部署文件（这些也是可以由工具来自动完成的）

（3）发布阶段：

       将 Web 服务的接口和调用的地址公开给客户端调用，

       常用的发布方式为基于 Web 提供的WSDL 的链接，当然 UDDI 也是一个选择。

         

          

     

总结一下 WebServices的优点

其实呢，前面介绍的都是关于 WebServices 的优点，在这里就只是浅要的总结一下了。

首先，WebServices 是基于 Internet 和异构平台的应用，

这样便可以方便的实现通过网络来通信，同时可以实现在不同的平台之间共享数据。

然后就是，WebServices 是基于 XML 和HTTP 的，

也就是基于标准和开放的，基于 XML 的话，扩展性自然好，自然跨语言。

基于 HTTP 的话，自然跨平台了。

最后，再回忆一下 WebServices 是一种应用程序组件吧，这样便可以将 WebServices 重复使用了。

      谈谈 WebServices 的缺点

首先就是由于 XML 文件的难以解析，所以在使用 Web 服务的时候，会消耗较多的 CPU 和内存资源，

而后，SOAP 是基于XML 的，所以在网络传输中传输的是 XML 文件，

但是由 XML 文件相比于二进制文件来说，要大很多，自然就会消耗更多的网络资源了。

而后，由于通过 WSDL 解耦了Web 服务提供者和请求者，且 SOAP 消息时从发送者向接收者单向传送的，

这在一定程度上造成了 WebServices 是一种无状态服务，

尽管现在在 . Net 中可以通过 Session 来实现在客户端和服务端共享一些数据，

但是单单依靠 Session 来实现客户端和服务端的状态交互也太牵强了吧

WebServices 在数据绑定上也存在一些缺陷，

因为所有的数据在传输中都是使用的 XML 来实现的，

因此，需要在二进制数据和 XML 之间进行一个转换（通过序列化和反序列化来实现），

而在转换过程中有可能出现语义丢失的情况。

最后就是 WebServices 的技术要求相对比较高，

因为涉及到底层的 HTTP 协议以及SOAP ，WSDL 和UDDL 这三大平台元素，

所以学习的曲线也是比较长的，

当然，在 . Net 中可以通过 Visual Studio 非常快速和简单的开发和访问一个 Web 服务，

但这只限于在简单的使用上，而对于本质的东西，是比较难的。

后续

正如题目所言，是 WebServices 简介，既然是简介的话，那么自然就是以简为目标了，

说明一下的是，上面的这篇博文呢，源自前几天做的一个关于 WebServices 的演讲，

演讲的 PPT 还存有，有兴趣要的可以留个邮箱的。

          

          

        

. Net中 WebServices 的实战

下面呢，就来具体看看在 . Net中如何开发一个WebServices 以及如何使用这个 WebServices

开发环境：

Windows 7 下IIS 7.5

Visual Studio TeamSystem 2008

Sql Server 2008

首先来看看如何开发一个 WebServices

先建立一个 ASP.NET 应用程序项目，然后再在项目中添加一个 WebServices 服务，

 

然后就是在这个 WebServiceTest中编写业务逻辑了，

本次实例的业务逻辑呢就是从数据库“图书馆管理系统”中取出所有的读者的信息。

WebServiceTest.asmx中的代码如下

usingSystem.Web.Services;
usingSystem.Data; 
usingSystem.Data.SqlClient; 
usingSystem.Web.Configuration;

namespace WebServiceDemo
{ 
    [WebService(Namespace = "http://tempuri.org/")]
   [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
    [System.ComponentModel.ToolboxItem(false)]

    public classWebServiceTest :System.Web.Services.WebService
    { 
        [WebMethod] 
       public DataSet GetAllReader()
        { 
            DataSet ds = newDataSet();
           string connStr =
               WebConfigurationManager.ConnectionStrings["DBConnString"].ConnectionString;
            string sqlStr = "SELECT[ReaderID],[ReaderIDType],[ReaderName]," +
                                  "[ReaderSex],[ReaderBirth]" + 
                           "FROM [图书馆管理系统].[dbo].[Reader]";
            using (SqlConnection sqlCon = new SqlConnection(connStr))
            { 
               using (SqlCommand sqlCom =sqlCon.CreateCommand())
               { 
                   sqlCom.CommandType = CommandType.Text; 
                   sqlCom.CommandText = sqlStr; 
                  using (SqlDataAdapter sqlDa = newSqlDataAdapter(sqlCom))
                   { 
                       sqlDa.Fill(ds); 
                   } 
               } 
            } 
            return ds;
        } 
    } 
}

然后我再在这一个项目 WebServiceDemo中添加一个页面 Test . aspx

来实现访问自身应用程序中的 WebServices

（Test. aspx和 WebServiceTest . asmx 位于同一应用程序中）。

这个 Test . aspx 呢非常简单，仅仅在上面放了一个 GridView ，然后稍微写点 Code-Behind 就 OK 了，

其代码如下：

using System;

namespace WebServiceDemo
{ 
    public partial class Test : System.Web.UI.Page 
    { 
        protected void Page_Load(objectsender, EventArgs e) 
        { 
            if(!IsPostBack) 
            { 
               WebServiceTesttest= new WebServiceTest();
               GridView1.DataSource = test.GetAllReader();
               GridView1.DataBind(); 
            } 
        } 
    } 
}

再来浏览一下 Test . aspx页面

 

可以看出已经达到了预定的效果，也就是从数据库中通过 WebServices取出了数据。

而从上面的代码可以看出，仅仅是将 WebServices看做是一个类了，

将其作为一个类来进行使用（实质上也就是一个类而已）。

下面我们还需要看一种情况，

那就是，实现在另外的一个应用程序中访问上面建立的 WebServices。

其实这种情况呢，就是和访问网络上的 WebServices 一样了，

比如腾讯 QQ 就是使用这种方式来实现的，

为了模拟这种实现，我首先将上面建立的这个 ASP.NET 应用程序 部署到 IIS 上面，

且指定了一个端口为 81

 

       

然后我再建立一个项目 TestWebServices

并且在这个项目里面也添加一个页面 Test . aspx

在Test . aspx 上也只放一个 GridView 控件。

 

然后就要给这个项目添加 Web服务的引用了（右键TestWebService 点击“添加 Web 引用”）

 

如果您要访问的是互联网上的 Web服务，比如查询天气，

那么就需要在上面的 URL中写入 Web 服务所在的地址，然后“前往”就 OK 了，

由于本次的演示，我只是把我的 Web服务放在了本地的 IIS 上面，

所以在此处呢选择“本地计算机上的 Web服务”，

 

从上面的截图中就可以看出，在 81号端口上面我有一个 Web 服务，

就是前面的 Demo中建立的 Web 服务 WebServiceTest

然后我选择这个 Web 服务，单击它即可，

 

上面的这幅截图中便可以看出我在 Web 服务WebServiceTest 中公开的接口了，

由于我只在其中写了一个接口 GetAllReader ，所以在这里便只显示了一个了。

在这一步中，您便可以添加这个 Web 引用了，不过要注意的是，

如果在这一步添加 Web 引用的话，那么这个 Web 服务中所有被公开的方法都会被添加到您的项目中，

比如，如果我在上面的 Web 服务中还有一个 GetAllName 的方法的话，

那么在这一步添加 Web 引用的话，就会将 GetAllReader 和 GetAllName 全部添加到您的项目当中，

但是有时候，这样会太浪费了，因为我可能根本就不需要使用 GetAllName 而只需要 GetAllReader，

此时，可以单击上面的 GetAllReader 进入下一步，

 

在这一步中添加 Web 引用的话，那么就只会在项目中添加 GetAllReader 这个方法的引用了，

我们在这里使用这种方法来添加 GetAllReader 的引用。

单击“添加引用”，此时可以看到在项目中生成一些文件，

（这里呢，其实就是代理模式来实现了）

 

既然在项目中引用了这个 Web服务了，

那么下一步就是在 Test . aspx中使用这个 Web 服务了。

看看 Test . aspx的 Code-Behind 吧

using System;

namespace TestWebService
{ 
    public partial class Test : System.Web.UI.Page 
    { 
        protected void Page_Load(objectsender, EventArgs e) 
        { 
            if(!IsPostBack) 
            { 
                //WebServiceTest.GetAllReader 这一段是我引用后的服务名 
               WebServiceTest.GetAllReader.WebServiceTesttest =
                   new WebServiceTest.GetAllReader.WebServiceTest();
               GridView1.DataSource = test.GetAllReader();
               GridView1.DataBind(); 
            } 
        } 
    } 
}

下面就来看一看效果了

 

从上面的效果便可以看出，我们已经成功在另外的应用程序中访问了 Web 服务，

也可以得出 Web 服务实现了在不同应用程序之间数据的共享。

如果，读者对通过网络 URL 来访问WebServices 有疑问的话，

可以参考一下笔者的另外一篇稍微带有 WebServices 性质的博文，

在其中实现了一个访问互联网上提供的天气查询 Web 服务。

http://www.cnblogs.com/QinBaoBei/archive/2010/03/30/1700898.html

上面呢，通过几个 Demo 对WebServices 在 .Net 中的实战进行了一个简单的应用了。

在这里一切似乎都和前面所提到的 SOAP ，WSDL，UDDI 均扯不上关系，

其实不然，只不过这些全部都由别个（工具）给你完成了，而你只是简单的开发一下逻辑就 OK 了，

不过呢，简单归简单，理解前面的一些原理还是很有必要的。