webservices 什么是Web Services

你是否对于webservices和什么是Web Services感到困惑？别担心，今天小编将为您揭开这个谜团，让我们一同探索吧！

Web Service

Web Service技术是原来的组件技术思想在 Internet时代中的进一步发展，更准确地说，Web Service是封装成单个实体发布到网络上，并提供 API以提供其他程序使用的功能集合，是在 Internet上进行分布式计算的基本构造块，是可用 URL定位服务资源。简言之，Web Service是可远程调用的应用程序组件。Web Service的本质目的是提供一个与操作系统、程序设计语言、机器类型、运行环境均无关的平台，实现 Internet中应用程序的共享。Web Service基于一系列的标准协议，其协议构架如图 4.4示。

图 4.4 Web Service协议架构

统一描述、发现与集成协议 UDDI(UniversalDescription，Discovery and Integration)用于构建Web Service的服务注册中心，实现服务发现功能。Web服务描述语言 WSDL(Web Service DescriptionLanguage)驻留在服务容器中，定义了一种提供Web服务描述的标准化方式。简单对象访问协议SOAP(Simple Object Access Protocol)提供传输数据的标准方式，充当在服务提供方和服务请求方之间激活服务的消息交换服务。可扩展标记语言 XML(Extensible Markup Language)是 Internet上数据交换的标准，在 Web Service中实现信息表达，用于 SOAP，WSDL和 UDDI。超文本传输协议 HTTP(Hyper Text Transfer Protol)是 Web Service最流行的传输协议。Web Service体系结构是一种面向服务的结构，典型的Web Service组件架构如图 4.5示。

Web Service体系结构主要由服务请求者、服务注册中心和服务提供者三部分组成。其实现过程包括服务发布与注册、服务查询与发现、服务绑定与调用三个过程。服务请求者指查询、调用服务的客户端程序;服务提供者即服务的所有者和部署服务的平台;服务注册中心指用来存储服务信息的信息库，服务提供者在这里发布、注册服务、而服务请求者在这里查询、绑定服务，最终实现调用服务提供者的服务。

图 4.5 Web Service组件架构

Web Service有两大核心优势，即分布性和互操作性。在 Web Service架构下，服务提供者和服务请求者都可以是分布式的，一个服务请求者可以远程调用多个服务提供者的服务，服务提供者也可以同时为多个服务请求者提供服务，这为服务共享提供了一个最佳的方式。

互操作性也是服务共享的关键问题。Web Service的信息表达基于标准通用的 XML语言，在 XML语言的基础上，使用 WSDL和 UDDI实现服务注册与发现，使用 SOAP实现服务调用。基于这些标准的协议，Web Service实现了服务的跨平台、跨语言的共享。XML、SOAP、WSDL和 UDDI是用于构建和使用 Web Service的核心标准和技术。以下将分别介绍这四种标准和技术。

4.2.2.1 XML

XML是一种数据描述语言，为 Internet上数据交换的标准。XML定义了应用系统间传递数据的结构，而且这种结构的描述不是基于二进制的、只能由程序去判读的代码，而是一种简单的、能够用通用编辑器读取的文本。XML的基本概念包括元素、属性、DTD，Schema和命名空间等。元素是 XML文档内容的基本单元。语法上而言，一个元素包括一个起始标记、结束标记以及标记之间的数据内容。形式上为:< tag>数据内容< tag>。元素内容可以为其他的元素或未处理文本或两者的混合，还可以是空的。元素的嵌套使得文档的层次结构很容易表示。一个元素可以有多个属性。属性是一个名称数据对，表示为字符串。用户可以根据需要自己定义。一个元素不能有同名的两个属性。

XML的精髓是允许文档编写者制定基于信息描述、体现数据间逻辑关系的自定义标记。如果不对文档标记作明确定义，而是任意地使用它们，则生成的文档是无法识别的。DTD是对文档结构的一个清晰描述，定义了特定文档中允许出现的元素类型、属性和实体，给出了文档的整体结构和语法。XML Schema是定义 XML的数据定义文件。XMLSchema也规定了一套特定文档的结构，这是与 DTD的相同之处。与 DTD相比，最大的不同在于它本身也是 XML文档。此外还有以下的不同: XML Schema可以用 XML解析器来解析;允许使用全局性元素(在整个 XML文档中用相同的方式使用元素)和局部元素(特定的上下文中元素有不同的含义);提供丰富的数据类型(整型、布尔型、日期类型等)，且元素的数据类型可以自定义。

XML命名空间是一组可以用作 XML文档的元素或属性名称的名称集，就是将元素或属性的名称归类。因为 XML的开放性，允许任何人创建属于他们自己的元素或属性名称，这样就不可避免地出现不同的人或组织定义的元素名称或属性名称重复，使得相同的名称表达不同的语义。为了避免元素之间出现相同名称的冲突，命名空间限定这些元素或属性名称在命名空间内是唯一的。一般命名空间由这些统一资源标识符 URI(Universal Resource Identifier)来识别。URI在 Internet上是全球唯一的，用 URI来限定 XML元素名称或属性名称也就确保是全球唯一的。XML主要具有四大优势:

(1)XML用文本格式表示数据，方便在 Internet上的传输。这一点使 XML数据可以方便地利用现有的 Internet上基于文本的各种传输协议(如 HTTP)进行传输，可以安全的穿越防火墙。

(2)XML是可扩展的。XML是一个元语言(MetaLanguage)，它使用了标准化的方法定义其他语言。它只是为结构文档提供了一个数据格式，而没有深入该数据本身，定义它的词汇列表。这使自定义标记语言成为可能，每个行业，每个部门，甚至每个人都可以定义自己的标记语言。

(3)XML可以对信息进行很好的层次描述。它基于信息内容的描述，对信息的表达清晰。

(4)XML可以进行数据完整性的自动检验。XML DTD和 Schema机制使得 XML解析器可以检验 XML文档是否与 DTD或 Schema相配。

4.2.2.2 SOAP

SOAP通过定义一个关于远程组件如何请求信息和如何递交信息的标准，实现 Internet中不同应用之间的集成和交互。SOAP是一个基于 HTTP和 XML的请求、响应 RPC协议。SOAP把 XML使用代码化为请求和响应参数编码模式，并用 HTTP传输。SOAP本身没有定义任何应用程序语义，如编程模型或特定语义的实现，实际上它通过提供一个有标准组件的包模型和在模块中编码数据的机制，定义了一个简单的表示应用程序语义的机制。这使得 SOAP能够被用于从消息系统到 RPC(远程进程调用)的各种应用中。

SOAP规范主要由信封(Envelop)、编码规则(Encoding Rules)和 RPC表示(RPC Representation)三部分组成。①SOAP信封构造定义了一个整体的 SOAP消息表示框架，可以用于表示消息中的内容是什么，是谁发送的，谁接受并处理它，以及这些处理操作是可选的还是必需的等。②SOAP编码规则定义了一个数据的编码机制，通过这样一个编码机制来定义应用程序中需要使用的数据类型，并可用于交换由这些应用程序定义的数据类型所衍生的实例。③SOAP RPC表示定义了一个用于表示远程过程调用和响应的约定，例如，如何使用 HTTP或 SMTP协议于 SOAP绑定，如何传输过程调用，在具体传输协议的哪个部分传输过程响应，如可以在 HTTP的响应的时候传递过程响应。这三部分在功能上是彼此独立的。特别的，信封和编码规则是被定义在不同的 XML命名空间中，这样有利于通过模块化获得定义和实现的简明性。

SOAP消息是 SOAP应用中的主体要素。SOAP为在一个松散的、分布的环境中使用XML对等地交换结构化地和类型化的消息提供了一个简单的轻量级机制。SOAP消息的描述框架格式是以 SOAP信封为根元素，内含 SOAP Header和 SOAP Body子元素的一个XML文档。所有的 SOAP消息都是使用 XML格式来编码的。SOAP消息必须不包含 DTD与 PI(Processing Instructions)。除 SOAP must understand attribute和 SOAP actor attribute外，一般允许属性及属性值自由地选择是在 XML实例中描述还是在 XML Schema中描述。SOAP是一种基于 XML的轻量级消息交换协议，它是建立在现有行业标准之上的，所以在支持这些标准的平台上运行的应用程序可以通过 SOAP消息与其他平台上运行的应用程序有效地进行通信，而且能够穿越防火墙，因而得到了业界的广泛支持。

4.2.2.3 WSDL

Web服务描述语言 WSDL(Web Services Description Language)是基于 XML模式的规范，用于将 Web服务描述为操作集，并将数据输入/输出参数描述为消息。WSDL还定义使用绑定机制将任何传输协议、数据格式或结构附加到抽象消息、操作或终端的通信模型。

WSDL将 Web服务描述为一组服务访问点，或称为一组“端口”，客户端可以通过这些端口对包含面向文档信息或面向过程调用的服务进行访问。一个端口定义了一个“服务”项目的提供地点。一个服务可以有多个提供地点，但只能对一组事先定义好的“信息”做出响应。“信息”是对通信数据的描述，每条信息由一组数据组成，这些数据必须定义为收、发双方都能识别的“类型”。端口和信息结合在一起代表了一组“操作”，并定义了这个服务访问点的“端口类型”。把一种协议和一种数据格式关联在一起就定义出了一种可重复使用的“绑定”。把一个网址和一个绑定关联在一起就定义了一个端口，相关的具体部署的端点通过组合就成为抽象的 Web服务。综上所述，WSDL文档的根元素是 definitions元素，该元素又包含 6个子元素:

(1)Types:包含可由服务器收发的消息的架构定义。最常见的表示架构的方法是使用 XML架构;

(2)Message:充当一个将架构中的消息与消息的定义关联起来的交叉引用。简单地说，就是定义通信中的数据，包括数据输入和输出。

(3)PortType:定义一组 Web服务可公开的接口。一个接口与一个或多个消息关联。

(4)Operation:它是对服务端所实现功能的抽象定义。

(5)Binding:将 PortType定义与某个特定的协议关联。

(6)Service:定义 Web服务公开的相关端点(端口)的集合。

4.2.2.4 UDDI

统一描述、发现和集成协议 UDDI(Universal Description，Discovery and Integration)是一套基于 Web的、分布式的、为 Web服务提供信息注册中心的实现标准规范，同时也包含一组使不同的人或组织能将自身提供的 Web服务注册以使得他人或其组织能够发现的访问协议的实现标准。UDDI注册的工作流程如图 4.6。

UDDI注册中心是 Web服务注册、用户集中管理的地方，通过它可以发布、查询、调用 Web Service，也可以查询特定服务的描述信息，并动态绑定到该服务上。UDDI注册中心同时还提供服务结点管理、用户管理、权限管理、计费管理等功能。服务提供者提供服务需要到 UDDI注册中心进行服务的注册、登记，这样用户就可以通过 UDDI注册中心获取所需要服务的基本信息与技术细节信息，再通过对服务的绑定得到服务和产品。

图 4.6 UDDI注册工作流程

webservice是什么

当前，WebService是一个热门话题。但是，WebService究竟是什么？什么情况下应该用WebService？什么情况下不应该用WebService？是需要我们正确认识的。 Web Services是由企业发布的完成其特定商务需求的在线应用服务,其他公司或应用软件能够通过Internet来访问并使用这项在线服务,它是一种构建应用程序的普遍模型,可以在任何支持网络通信的操作系统中实施运行;它是一种新的web应用程序分支，是自包含、自描述、模块化的应用，可以发布、定位、通过web调用。Web Service是一个应用组件,它逻辑性的为其他应用程序提供数据与服务.各应用程序通过网络协议和规定的一些标准数据格式（Http，XML，Soap)来访问Web Service,通过Web Service内部执行得到所需结果.Web Service可以执行从简单的请求到复杂商务处理的任何功能。一旦部署以后，其他Web Service应用程序可以发现并调用它部署的服务。在构建和使用Web Service时,主要用到以下几个关键的技术和规则: 1.XML:描述数据的标准方法. 2.SOAP:表示信息交换的协议. 3.WSDL:Web服务描述语言. 4.UDDI:找到服务驱动器的的方法;实际上，WebService的主要目标是跨平台的可互操作性。为了达到这一目标，WebService完全基于XML（可扩展标记语言）、XSD（XMLSchema）等独立于平台、独立于软件供应商的标准，是创建可互操作的、分布式应用程序的新平台。由此可以看出，在以下三种情况下，使用WebService会带来极大的好处。长项一：跨防火墙的通信如果应用程序有成千上万的用户，而且分布在世界各地，那么客户端和服务器之间的通信将是一个棘手的问题。因为客户端和服务器之间通常会有防火墙或者代理服务器。在这种情况下，使用DCOM就不是那么简单，通常也不便于把客户端程序发布到数量如此庞大的每一个用户手中。传统的做法是，选择用浏览器作为客户端，写下一大堆ASP页面，把应用程序的中间层暴露给最终用户。这样做的结果是开发难度大，程序很难维护。举个例子，在应用程序里加入一个新页面，必须先建立好用户界面(Web页面)，并在这个页面后面，包含相应商业逻辑的中间层组件，还要再建立至少一个ASP页面，用来接受用户输入的信息，调用中间层组件，把结果格式化为HTML形式，最后还要把"结果页"送回浏览器。要是客户端代码不再如此依赖于HTML表单，客户端的编程就简单多了。如果中间层组件换成WebService的话，就可以从用户界面直接调用中间层组件，从而省掉建立ASP页面的那一步。要调用WebService，可以直接使用MicrosoftSOAPToolkit或.NET这样的SOAP客户端，也可以使用自己开发的SOAP客户端，然后把它和应用程序连接起来。不仅缩短了开发周期，还减少了代码复杂度，并能够增强应用程序的可维护性。同时，应用程序也不再需要在每次调用中间层组件时，都跳转到相应的"结果页"。从经验来看，在一个用户界面和中间层有较多交互的应用程序中，使用WebService这种结构，可以节省花在用户界面编程上20%的开发时间。另外，这样一个由WebService组成的中间层，完全可以在应用程序集成或其它场合下重用。最后，通过WebService把应用程序的逻辑和数据"暴露"出来，还可以让其它平台上的客户重用这些应用程序。长项二：应用程序集成企业级的应用程序开发者都知道，企业里经常都要把用不同语言写成的、在不同平台上运行的各种程序集成起来，而这种集成将花费很大的开发力量。应用程序经常需要从运行在IBM主机上的程序中获取数据；或者把数据发送到主机或UNIX应用程序中去。即使在同一个平台上，不同软件厂商生产的各种软件也常常需要集成起来。通过WebService，应用程序可以用标准的方法把功能和数据"暴露"出来，供其它应用程序使用。例如，有一个订单登录程序，用于登录从客户来的新订单，包括客户信息、发货地址、数量、价格和付款方式等内容；还有一个订单执行程序，用于实际货物发送的管理。这两个程序来自不同软件厂商。一份新订单进来之后，订单登录程序需要通知订单执行程序发送货物。通过在订单执行程序上面增加一层WebService，订单执行程序可以把"AddOrder"函数"暴露"出来。这样，每当有新订单到来时，订单登录程序就可以调用这个函数来发送货物了。长项三：B2B的集成用WebService集成应用程序，可以使公司内部的商务处理更加自动化。但当交易跨越供应商和客户、突破公司的界限时会怎么样呢？跨公司的商务交易集成通常叫做B2B集成。 WebService是B2B集成成功的关键。通过WebService，公司可以把关键的商务应用"暴露"给指定的供应商和客户。例如，把电子下单系统和电子发票系统"暴露"出来，客户就可以以电子的方式发送订单，供应商则可以以电子的方式发送原料采购发票。当然，这并不是一个新的概念，EDI(电子文档交换)早就是这样了。但是，WebService的实现要比EDI简单得多，而且WebService运行在Internet上，在世界任何地方都可轻易实现，其运行成本就相对较低。不过，WebService并不像EDI那样，是文档交换或B2B集成的完整解决方案。WebService只是B2B集成的一个关键部分，还需要许多其它的部分才能实现集成。用WebService来实现B2B集成的最大好处在于可以轻易实现互操作性。只要把商务逻辑"暴露"出来，成为WebService，就可以让任何指定的合作伙伴调用这些商务逻辑，而不管他们的系统在什么平台上运行，使用什么开发语言。这样就大大减少了花在B2B集成上的时间和成本，让许多原本无法承受EDI的中小企业也能实现B2B集成。长项四：软件和数据重用软件重用是一个很大的主题，重用的形式很多，重用的程度有大有小。最基本的形式是源代码模块或者类一级的重用，另一种形式是二进制形式的组件重用。当前，像表格控件或用户界面控件这样的可重用软件组件，在市场上都占有很大的份额。但这类软件的重用有一个很大的限制，就是重用仅限于代码，数据不能重用。原因在于，发布组件甚至源代码都比较容易，但要发布数据就没那么容易，除非是不会经常变化的静态数据。 WebService在允许重用代码的同时，可以重用代码背后的数据。使用WebService，再也不必像以前那样，要先从第三方购买、安装软件组件，再从应用程序中调用这些组件；只需要直接调用远端的WebService就可以了。举个例子，要在应用程序中确认用户输入的地址，只需把这个地址直接发送给相应的WebService，这个WebService就会帮你查阅街道地址、城市、省区和邮政编码等信息，确认这个地址是否在相应的邮政编码区域。WebService的提供商可以按时间或使用次数来对这项服务进行收费。这样的服务要通过组件重用来实现是不可能的，那样的话你必须下载并安装好包含街道地址、城市、省区和邮政编码等信息的数据库，而且这个数据库还是不能实时更新的。另一种软件重用的情况是，把好几个应用程序的功能集成起来。例如，要建立一个局域网上的门户站点应用，让用户既可以查询联邦快递包裹，查看股市行情，又可以管理自己的日程安排，还可以在线购买电影票。现在Web上有很多应用程序供应商，都在其应用中实现了这些功能。一旦他们把这些功能都通过WebService"暴露"出来，就可以非常容易地把所有这些功能都集成到你的门户站点中，为用户提供一个统一的、友好的界面。将来，许多应用程序都会利用WebService，把当前基于组件的应用程序结构扩展为组件/WebService的混合结构，可以在应用程序中使用第三方的WebService提供的功能，也可以把自己的应用程序功能通过WebService提供给别人。两种情况下，都可以重用代码和代码背后的数据。从以上论述可以看出，WebService在通过Web进行互操作或远程调用的时候是最有用的。不过，也有一些情况，WebService根本不能带来任何好处。短处一：单机应用程序目前，企业和个人还使用着很多桌面应用程序。其中一些只需要与本机上的其它程序通信。在这种情况下，最好就不要用WebService，只要用本地的API就可以了。COM非常适合于在这种情况下工作，因为它既小又快。运行在同一台服务器上的服务器软件也是这样。最好直接用COM或其它本地的API来进行应用程序间的调用。当然WebService也能用在这些场合，但那样不仅消耗太大，而且不会带来任何好处。短处二：局域网的同构应用程序在许多应用中，所有的程序都是用VB或VC开发的，都在Windows平台下使用COM，都运行在同一个局域网上。例如，有两个服务器应用程序需要相互通信，或者有一个Win32或WinForm的客户程序要连接局域网上另一个服务器的程序。在这些程序里，使用DCOM会比SOAP/HTTP有效得多。与此相类似，如果一个.NET程序要连接到局域网上的另一个.NET程序，应该使用.NETremoting。有趣的是，在.NETremoting中，也可以指定使用SOAP/HTTP来进行WebService调用。不过最好还是直接通过TCP进行RPC调用，那样会有效得多。总之，只要从应用程序结构的角度看，有别的方法比WebService更有效、更可行，那就不要用WebService

什么是Web Services

一、Web Services解释：

WebService是一个SOA（面向服务的编程）的架构，它是不依赖于语言，不依赖于平台，可以实现不同的语言间的相互调用，通过Internet进行基于Http协议的网络应用间的交互；

WebService实现不同语言间的调用，是依托于一个标准，webservice是需要遵守WSDL（web服务定义语言）/SOAP（简单请求协议）规范的；

WebService=WSDL+SOAP+UDDI（webservice的注册）；

Soap是由Soap的part和0个或多个附件组成，一般只有part，在part中有Envelope和Body；

Web Service是通过提供标准的协议和接口，可以让不同的程序集成的一种SOA架构。

二、Web Service的优点

可以让异构的程序相互访问（跨平台）(2)松耦合；

基于标准协议（通用语言，允许其他程序访问）。

三、Web Service的基本原理

Service Provider采用WSDL描述服务；

Service Provider采用UDDI将服务的描述文件发布到UDDI服务器（Register server）；

Service Requestor在UDDI服务器上查询并获取WSDL文件；

Service requestor将请求绑定到SOAP，并访问相应的服务。

感谢您花时间阅读本文！我们希望通过对webservices和什么是Web Services的问题进行探讨，为您提供了一些有用的见解和解决方案。如果您需要更多帮助或者有其他疑问，请不要犹豫与我们联系。