网络服务

Posted 2020-10-10

主要的系统交互方式

WebService ，RMI，Socket 是现在主要的系统交互方式。

RMI为Java平台的分布式计算提供了一个简单而直接的模型。RMI将Java平台的安全性和可移植性等优点带到了分布式计算中。RMI大大扩展Java的网络计算能力，它为编写基于分布式对象技术的企业级Internet/Intranet应用提供了强大的系统平台支持。远程方法调用作为Java分布式对象技术成为Java核心的API之一(在java.rmi.* 包)。RMI的引入，使得Java程序之间能够实现灵活的，可扩展的分布式通信。

 

Socket称作"套接字"，用于描述IP地址和端口，是一个通信链的句柄。在Internet上的主机一般运行了多个服务软件，同时提供几种服务。每种服务都打开一个Socket，并绑定到一个端口上，不同的端口对应于不同的服务。Socket正如其英文原意那样，象一个多孔插座。一台主机犹如布满各种插座的房间，每个插座有一个编号，有的插座提供220伏交流电， 有的提供110伏交流电，有的则提供有线电视节目。 客户软件将插头插到不同编号的插座，就可以得到不同的服务。java中也提供有Socket编程方式，Socket和ServerSocket类库位于java.net包中。ServerSocket用于服务器端，Socket是建立网络连接时使用的。在连接成功时，应用程序两端都会产生一个Socket实例，操作这个实例，完成所需的会话。对于一个网络连接来说，套接字是平等的，并没有差别，不因为在服务器端或在客户端而产生不同级别。不管是Socket还是ServerSocket它们的工作都是通过SocketImpl类及其子类完成的。

 

RMI是JAVA的首选远程调用协议，非常高效稳定，特别是在少数据量的远程调用方面，与其他通讯协议的差距尤为明显。Web Service的效率是其1/10。RMI与Socket相比，传输相同的有效数据，RMI需要占用更多的网络带宽资源。一旦你的应用需要在client与server之间传输大量的数据，极端的，比如FTP应用，则RMI是不适合的，我们应该使用 Socket。RMI是面向对象的，而socket不是。RMI是与语言相绑定的。比如当你使用Java RMI技术的时候，客户端与服务器端都必须使用Java开发。而socket的网络编程是使用独立于开发语言的，甚至独立于平台。基于Socket的网络编程，客户端与服务器端可以使用不同开发语言和不同的平台。

 

WebService和Socket的对比

(1)Socket是基于TCP/IP的传输层协议。
Webservice是基于HTTP协议传输数据，http是基于tcp的应用层协议。
Webservice采用了基于http的soap协议传输数据。

(2)Socket接口通过流传输，不支持面向对象。
Webservice 接口支持面向对象，最终webservice将对象进行序列化后通过流传输。
Webservice采用soap协议进行通信，不需专门针对数据流的发送和接收进行处理，是一种跨平台的面向对象远程调用技术。

(3)Socket适用于高性能大数据的传输，传输的数据需要手动处理，socket通信的接口协议需要自定义。

Socket缺点 程序员需要自己去解析输入、输出流，解析发送和接收的数据。数据传输的格式不固定，需要程序员开发socket接口时自定义接口协议。

Socket优点 如果要传输大数据量，socket可以满足，如果存在大并发使用socket也可以实现，程序用socket灵活性更大，比如可以socket的高并发框架mina开发。
Webservcie优点  jaxws可以通过面向对象开发webservice，程序员不需要解析输入、输出流。 由于webservice传输数据使用标准的soap协议(基于http传输xml)，soap协议已经被w3c管理了。
Webservcie缺点  如果传输大数据量，webservice不适用。如果webservice开发大并发的应用，webservice依靠web容器提高并发数。

 

RMI的使用约束是 交互的两个系统都必须是Java语言。

Socket的使用主要应用于c/s的系统架构中。

Web Service 是基于SOAP的服务，实现起来最简单，而且交互的系统没有语言限制。

在搭建应用实现方面的容易程度方面

应用容易程度 Web Service>RMI>Socket

 

三种主流Web架构

通常WEB开发就是通过WEB前端管理一个或大或小或独立或分布式的关系型数据库。这里说的WEB架构，是指WEB应用开发中每种技术独有的资源组织形式（包括文件，数据库，HTTP请求处理等），也许说开发方式更容易让人理解一些。

WEB程序的架构基本上可以分成以下三类：

(一) 基于“WEB页面/文件”，例如CGI和php/ASP程序。程序的文件分别存储在不同的目录里，与URL相对应。当HTTP请求提交至服务器时，URL直接指向某个文件，然后由该文件来处理请求，并返回响应结果。比如http://www.website.conm/news/readnews.php?id=1234。可以想像，我们在站点根目录的news目录下放置一个readnews.php文件。这种开发方式最自然，最易理解。要注意产生的URL对搜索引擎不友好，不过你可以用服务器提供的URL重写方案来处理。

 

(二) 基于“动作”(Action)。这是MVC架构的WEB程序所采用的最常见的方式。目前主流的WEB框架像Struts、Webwork(Java)，Ruby on Rails(Ruby),Zend Framework(PHP)等都采用这种设计。URL映射到控制器和控制器中的动作(action)，由action来处理请求并输出响应结果。这种设计和上面的基于文件的方式一样，都是请求/响应驱动的方案，离不开HTTP。比如 http://www.website.com/news/read/id/1234。不同框架可能默认实现方式稍有不同，有的是一个Controller一个文件，其中有多个Action，有的是每个Action一个文件。这种方式的URL通常都很漂亮，对搜索引擎友好，因为很多框架都自带有URL重写功能。可以自由规定URL中controller、action及参数出现的位置。

另外，还有更直接的基于URL的设计方案，那就是REST。通过人为规定URL的构成形式（比如Action限制成只有几种）来促进网站之间的互相访问，降低开发的复杂性，提高系统的可伸缩性。REST对于Web Services来说是一个创新。

 

(三) 基于“组件”（控件）、事件驱动的架构，最常见的是微软的.NET。基本思想是把程序分成很多组件，每个组件都可以触发事件，调用特定的事件处理器来处理。这种设计远离HTTP，HTTP请求完全抽象，映射到一个事件。这种设计原本最常应用于传统桌面GUI程序的开发。所有表现层的组件比如窗口，或者html表单都可以由IDE来提供，我们只需要在IDE里点击或拖动鼠标就能够自动添加一个组件，并且添加一个相应的事件处理器。

 

三种主流Web服务架构

目前知道的三种主流的Web服务实现方案为：

 

REST：表征状态转移（Representational State Transfer），采用Web 服务使用标准的 HTTP 方法 (GET/PUT/POST/DELETE) 将所有 Web 系统的服务抽象为资源，REST从资源的角度来观察整个网络，分布在各处的资源由URI确定，而客户端的应用通过URI来获取资源的表征。Http协议所抽象的get,post,put,delete就好比数据库中最基本的增删改查，而互联网上的各种资源就好比数据库中的记录（可能这么比喻不是很好），对于各种资源的操作最后总是能抽象成为这四种基本操作，在定义了定位资源的规则以后，对于资源的操作通过标准的Http协议就可以实现，开发者也会受益于这种轻量级的协议。REST是一种软件架构风格而非协议也非规范，是一种针对网络应用的开发方式，可以降低开发的复杂性，提高系统的可伸缩性。

 

SOAP：简单对象访问协议（Simple Object Access Protocol）是一种标准化的通讯规范，主要用于Web服务（web service）中。用一个简单的例子来说明 SOAP 使用过程，一个 SOAP 消息可以发送到一个具有 Web Service 功能的 Web 站点，例如，一个含有房价信息的数据库，消息的参数中标明这是一个查询消息，此站点将返回一个 XML 格式的信息，其中包含了查询结果（价格，位置，特点，或者其他信息）。由于数据是用一种标准化的可分析的结构来传递的，所以可以直接被第三方站点所利用。SOAP (Simple Object Access Protocol) 顾名思义，是一个严格定义的信息交换协议，用于在Web Service中把远程调用和返回封装成机器可读的格式化数据。事实上SOAP数据使用XML数据格式，定义了一整套复杂的标签，以描述调用的远程过程、参数、返回值和出错信息等等。而且随着需要的增长，又不得增加协议以支持安全性，这使SOAP变得异常庞大，背离了简单的初衷。另一方面，各个服务器都可以基于这个协议推出自己的API，即使它们提供的服务及其相似，定义的API也不尽相同，这又导致了WSDL的诞生。WSDL (Web Service Description Language) 也遵循XML格式，用来描述哪个服务器提供什么服务，怎样找到它，以及该服务使用怎样的接口规范，简言之，服务发现。现在，使用Web Service的过程变成，获得该服务的WSDL描述，根据WSDL构造一条格式化的SOAP请求发送给服务器，然后接收一条同样SOAP格式的应答，最后根据先前的WSDL解码数据。绝大多数情况下，请求和应答使用HTTP协议传输，那么发送请求就使用HTTP的POST方法。

 

XML-RPC：远程过程调用（remote procedure call，RPC)的分布式计算协议，通过XML将调用函数封装，并使用HTTP协议作为传送机制。后来在新的功能不断被引入下，这个标准慢慢演变成为今日的SOAP协定。XML-RPC协定是已登记的专利项目。XML-RPC透过向装置了这个协定的服务器发出HTTP请求。发出请求的用户端一般都是需要向远端系统要求呼叫的软件。

 

三种方案的简单比较

Webservice本来是个通用词汇代表所有基于web的服务，后来变成了基于XML的SOAP协议的专用词汇。以SOAP为例，一个RPCcall就是把一个XML文档post到某个URL下，这个xml文档里写明我要调用的函数名和参数。服务端会返回一个xml把结果返回。这样的设计是把HTTP当传输层，可以把传输层替换成其他协议只要能在客户端服务端之间传输xml就可以。

REST是完全不同的思路，它充分利用了HTTP协议的4个主要操作，把RPC操作分成4类：- GET：进行幂等的资源获取操作- POST：创建资源- PATCH：修改资源- DELETE：删除资源仔细想一下这其实就是数据库的CRUD操作POST=create、GET=read、PATCH=update、DELETE=delete

 

成熟度上：SOAP在成熟度上优于REST

效率和易用性上：REST更胜一筹

安全性上：SOAP安全性高于REST，因为REST更关注的是效率和性能问题

 

XML-RPC已慢慢的被SOAP所取代，现在很少采用了。基于SOAP的Web Service实现技术和相关代码，虽然较为成熟，且安全性较好，但是使用门槛较高，而且在大并发情况下可能会有性能问题。总体上，因为REST模式的Web服务与复杂的SOAP和XML-RPC对比来讲明显的更加简洁，越来越多的web服务开始采用REST风格设计和实现。REST对于资源型服务接口来说很合适，同时特别适合对于效率要求很高，但是对于安全要求不高的场景。而SOAP的成熟性可以给需要提供给多开发语言的，对于安全性要求较高的接口设计带来便利。

 

随着更贴近HTTP的REST的流行，我觉得像.NET和Java中的抽象组件的方式会受到冲击。因为这些组件并不如它们所承诺的那么方便。未来MVC+REST+RIA的模式应该会比较流行。

 

总的来说，SOAP的Web Service解决方案虽然较为成熟，且安全性较好，但是使用门槛较高，在大并发情况下会有性能问题，在互联网上使用不太普及，因此并不太适合Web 2.0网站服务使用，目前大量的Web 2.0网站使用另外一种解决方案——REST。

 

 

从基本原理层次上说，REST样式和SOAP样式Web Service的区别取决于应用程序是面向资源的还是面向活动的。例如，在传统的WebService中，一个获得天气预报的webservice会暴露一个WebMethod：string GetCityWether（string city）。而REST WebService暴露的不是方法，而是对象（资源），通过Http GET, PUT, POST 或者 DELETE来对请求的资源进行操作。在REST的定义中，一个 Web Service总是使用固定的 URI向外部世界呈现（暴露）一个资源。可以说这是一种全新的思维模式：使用唯一资源定位地址 URI，加上 HTTP 请求方法从而达到对一个发布于互联网资源的唯一描述和操作。REST可以看着是http协议的一种直接应用，默认基于json作为传输格式，使用简单，学习成本低效率高，

 

 

REST是一种架构风格，其核心是面向资源，REST专门针对网络应用设计和开发方式，以降低开发的复杂性，提高系统的可伸缩性。而REST强调面向资源，只要我们要操作的对象可以抽象为资源即可以使用REST架构风格。

 

SOAP偏向于面向活动，有严格的规范和标准，包括安全，事务等各个方面的内容。SOAP强调操作方法和操作对象的分离，有WSDL文件规范和XSD文件分别对其定义。

 

REST

HTTP协议并不是被设计为一种传输协议，它是一种转移协议，非常不幸，HTTP传入我国时，即被翻译为“超文本传输协议”。在HTTP协议中，消息通过在那些资源的表述上的转移和操作，来对资源执行一些动作，从而反映出Web架构的语义，因此使用这个非常简单的接口来获得广泛的功能是完全有可能的。

 

Web服务虽然使用了HTTP协议，但是其实建立在 SOAP 上，以至于我们提到 Web 服务就会想到 SOAP，也就是说，他们并没有直接建立在 HTTP上，仅仅使用HTTP作为一种夹带其他的应用协议穿越防火墙的方法，可以说，他们没有充分挖掘并利用HTTP协议。尽管网络服务目前是以SOAP技术为主，但是REST将是是网络服务的另一选择，并且是真正意义上的网络服务。

REST（Representational State Transfer表述化状态转移）是2000年提出来的一种软件架构风格。　　REST（Representational State Transfer）是一种轻量级的Web Service架构风格，其实现和操作明显比SOAP和XML-RPC更为简洁，可以完全通过HTTP协议实现，还可以利用缓存Cache来提高响应速度，性能、效率和易用性上都优于SOAP协议。

　　REST架构遵循了CRUD原则，CRUD原则对于资源只需要四种行为：Create（创建）、Read（读取）、Update（更新）和Delete（删除）就可以完成对其操作和处理。这四个操作是一种原子操作，即一种无法再分的操作，通过它们可以构造复杂的操作过程，正如数学上四则运算是数字的最基本的运算一样。

　　REST架构让人们真正理解我们的网络协议HTTP本来面貌，对资源的操作包括获取、创建、修改和删除资源的操作正好对应HTTP协议提供的GET、POST、PUT和DELETE方法，因此REST把HTTP对一个URL资源的操作限制在GET、POST、PUT和DELETE这四个之内。这种针对网络应用的设计和开发方式，可以降低开发的复杂性，提高系统的可伸缩性。

REST从资源的角度来观察整个网络，分布在各处的资源由URI确定，而客户端的应用通过URI来获取资源的表征。

4. REST两个基本概念
1.资源（Resource）：将信息抽象为资源，任何能够命名的信息（包括数据和功能）都能作为一个资源，一张图片，一个其他资源的集合等。在REST中，资源又叫做状态，因为它跟随时间的变化。

2.表述（Representation）： REST通过URI来获得资源的表述并对资源执行动作，并在组件间传递该表述。

什么是表述化状态转移？在REST中，资源就是状态，互联网就是一个巨大的状态机：每个网页是其一个状态；Url是状态的表述；REST应用通过点击超链接，从一个状态迁移到下一个状态的状态转移过程，就叫转移。

例如：Bing搜索结果的分页列表，url如下：
第一页：http://www.bing.cn/search?q=REST&hl=zh-CN&newwindow=1&start=0&sa=N  
第二页：http://www.bing.cn/search?q=REST&hl=zh-CN&newwindow=1&start=10&sa=N

在Bing中，把搜索结果的每一页视为资源（状态），并通过url来表示(这就是表述)，同一搜索关键字的不同分页通过start参数来进行区分。当你从第一页点击第二页的链接时，只是从一个状态跳到了下一个状态而已(这就是转移)；

5.REST风格架构的主要约束条件

第一.客户-服务器：分离关注点，将用户接口（如用户界面）和数据存储分离，如果接口不变，组件可独立进化。

 

第二.无状态：从客户端道服务器的每个请求必须包含理解该请求所必需的所有信息，不能利用任何存储在服务器上的上下文。提高了系统的可扩展性，其优点有三：可见性，监视系统不必为了确定一个请求的性质而去查看请求之外的多个请求；可靠性，减轻了从局部故障恢复的任务量，可以快速定位；可伸缩性，不必在多个请求之 间保存状态，允许服务器快速释放资源，并且服务器不必跨请求管理资源。缺点是，由于不能将状态保存在服务器上的共享上下文中，增加了请求中发送的重复数 据，降低网络性能，因此有了约束三。

第三.缓存：请求响应中的数据显示或隐式的标记为可缓存的或不可缓存的。缓存可以为以后相同的请求重用这个响应的数据。但是缓存管理不好，会降低可靠性，导致缓存中陈旧的数据与直接访问服务器得到的数据差别很大。

第四.统一接口：组件之间要有统一的接口，是REST风格架构区别其他风格架构的核心特征。REST由四个接口约束定义：资源的识别，Web-Based系统中资源由URI表示，数据库存储系统中资源可以是XML，JSON等；通过表述对资源执行的动作：表述中包含操作该资源的信息，如增删改查，映射到HTTP协议的GET，POST，PUT，DELETE方法；自描述的消息：消息中包含如何处理该消息的信息，如由哪个WebAPI/Sevlet处理，响应中包含可不可以被缓存等信息；作为应用状态引擎的超媒体。

6. REST基本设计原则

原则一： 使用HTTP的方法进行资源访问
使用HTTP POST方法去创建资源，使用GET方法去读取资源，使用PUT 方法去更新资源，使用DELETE方法去删除资源。

原则二： 使用无状态/无会话的服务设计
很长时间以来，人们采用有状态的服务设计从而在客户端与服务端的多次交互中维护一定的上下文。
然而，有状态的设计使得程序很难随着工作负载的增加而进行伸缩。比如某个服务实例拥有10000个会话的状态，则通常很难通过增加服务实例来分担其工作负载：工作负载被锁定了！ 反之，如果程序被设计成一个无状态的，则可以自由增加服务实例，并且在这些实例之间平衡负载，从而使得服务具有较好的伸缩性，这在大规模分布式系统中尤其重要！！

原则三： 用目录结构风格的URL设计来表示资源
用清晰的URL路径表示资源可以使客户端更容易理解和操作资源。URL可以被看作是一种自我解释的接口，不需要太多解释就可以让人明白该URL指向的是什么资源以及如何获得相关的资源。
http://www.foo.com/research/articles/{article_title}
http://www.foo.com/research/articles/{year}/{month}/{day}/{article_title}

原则四： 使用XML或JSON来传输数据
服务和请求的消息数据中包含了对于资源的属性的描述，服务应该采取结构良好并且易于阅读的方式来描述资源。XML、JSON都是结构良好的语言，并适于阅读。JSON比XML更加简洁。

 

7. REST安全性
安全一：REST/HTTP网络服务的信息包可以被防火墙理解和控制。你可以按照操作和链接进行过滤信息包，如你可以规定从外部来的只能读取（GET操作）自己服务器的资源。这样对于系统管理员而言使得软件管理更为简单。
安全二：REST的安全性还可以利用传输安全协议SSL/TLS、 HTTP基本认证和摘要式认证。
安全三：还可以利用像基于信息的Web Services Security作为安全认证的补充方案。
安全四：用第三方开源的OpenID和Oauth类库作为安全认证方案的选择。

 

Webservice

webservice就是一种基于web的服务，也是一个应用程序，它向外界暴露出一个能够通过Web进行调用的API。这就是说，你能够用编程的方法通过Web来调用这个应用程序。我们把能调用这个Web service 的应用程序叫做客户端程序。Web Service 希望实现不同的系统之间能够用“软件-软件对话”的方式相互调用，打破了软件应用、网站和各种设备之间的格格不入的状态，实现“基于Web无缝集成”的目标。Web Servcie最主要的优点是： 即跨语言，跨平台的不同系统之间的通信。 现在企业内部的很多系统集成，企业和企业之间的系统集成的问题。Web Service是主要的解决方案。（服务重用，降低开发成本，只开放自己愿意开放的服务）。1. webservice基于xml和http进行通信，是可互操作的分布式应用程序，可以穿越防火墙进行通信，通过Soap可以进行异地调用。使用 XML来编解码数据，并使用SOAP来传输数据。Web Services 可使您的应用程序成为Web应用程序。Web Services 通过 Web 进行发布、查找和使用。

 

WebService（Web服务）是WebService真的是一门新兴和有前途的技术。一言以蔽之：WebService是一种跨编程语言和跨操作系统平台的远程调用技术。当前的应用程序开发逐步的呈现了两种迥然不同的倾向：一种是基于浏览器的瘦客户端应用程序，一种是基于浏览器的富客户端应用程序，后一种技术相对来说更加的时髦一些（如现在很流行的Html5技术）从表面上看，WebService就是一个应用程序向外界暴露出一个能通过Web进行调用的API，也就是说能用编程的方法通过Web来调用这个应用程序。我们把调用这个WebService的应用程序叫做客户端，而把提供这个WebService的应用程序叫做服务端。从深层次看，WebService是建立可互操作的分布式应用程序的新平台，是一个平台，是一套标准。它定义了应用程序如何在Web上实现互操作性，你可以用任何你喜欢的语言，在任何你喜欢的平台上写Web service ，只要我们可以通过Web service标准对这些服务进行查询和访问。

 

Web Service本身其实是在实现应用程序间的通信。我们现在有两种应用程序通信的方法：RPC远程过程调用　和消息传递。使用RPC的时候，客户端的概念是调用服务器上的远程过程，通常方式为实例化一个远程对象并调用其方法和属性。RPC系统试图达到一种位置上的透明性：服务器暴露出远程对象的接口，而客户端就好像在本地使用的这些对象的接口一样，这样就隐藏了底层的信息，客户端也就根本不需要知道对象是在哪台机器上。WebService和普通的web本质上一样。只是一个主要是浏览器调用，呈现网页，另一个是一般的程序调用，像一个函数那样获取所需要的数据。

 

通俗点说，webservice只就是POST类型的 HTTP请求；以往的HTTP请求都是浏览器从FORM 里发出的，用于提交表单，比如 浏览器提交 username=tom&password="123456" 给服务器，服务器验证完用户名和密码正确后再返回字符串 "success"。
后来发现可以把提交的内容做的更复杂，因为服务器可以接受更多东西以计算。
比如：提交给服务器 <username>tom</username>
    <password>123456</password>
    <bothdata>19800305</bothdate>
    ........ 还有很长就不写了
  然后服务器返回<result>success</result>

但是这种新的提交方法再叫作POST表单请求就不合适了，所以起个新名叫webservice，这种提交的格式就叫做XML 。因为这东西比原来那个username=tom&password="123456" 更容易被人读懂，而且可以存储表达更多东西。

至于于那个WDSL 就是一种格式规范，他就像是小学语文规定“每个新段落开头要空两个字” 没什么区别，它规定了提交webservice时应该把开头写什么标示，结尾写什么标示，.....

 

在Web Serivce的体系结构中涉及到三个角色，一个是 Web Service提供者，一个是 Web Service中介，还有一个就是 Web Service请求者；同时还涉及到三类动作，即发布，查找，绑定，

Web Service提供者：可以发布 Web Service，并且对使用自身服务的请求进行响应，Web Service的拥有者，它会等待其他的服务或者是应用程序访问自己。

Web Service请求者：也就是 Web Service功能的使用者，它通过服务注册中心也就是 Web Service中介者查找到所需要的服务，再利用SOAP消息向 Web Service提供者发送请求以获得服务。 

Web Service中介：也称为服务代理，用来注册已经发布的 Web Service提供者，并对其进行分类，同时提供搜索服务，简单来说的话，Web Service中介者的作用就是把一个 Web Service请求者和合适的 Web Service提供者联系在一起，充当一个管理者的角色，一般是通过 UDDI来实现。

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

发现（查找）：使得 Web Service请求者可以通过 Web Service中介者来查找到特定种类的 Web Service 接口。 

绑定：这里就是实现让Web Serivce请求者能够使用Web Serivce提供者提供的Web Serivce接口。

 

UDDI：统一描述、发现和集成（Universal Description, Discovery, and Integration，UDDI）UDDI 的目的是为电子商务建立标准；UDDI是一套基于Web的、分布式的、为Web Service提供的、信息注册中心的实现标准规范，同时也包含一组使企业能将自身提供的Web Service注册，以使别的企业能够发现的访问协议的实现标准。 其中包含注册用户企业的地址、联系方法、已知的企业标识。行业类别，也包含关于该企业所提供的Web Service的技术信息。

UDDI数据实体提供对定义业务和服务信息的支持。UDDI构建于网络传输层和基于SOAP的XML消息传输层之上。UDDI提供了一种编程模型和模式，它定义域注册中心通信的规则。UDDI规范中所有的API都用XML来定义，包装在SOAP信封中，在HTTP上传输。UDDI消息的传输，通过HTTP从客户机的SOAP请求传到注册中心节点，再反向传输。注册中心服务器的SOAP服务器接受UDDISOAP消息，进行处理，然后把SOAP响应返回给客户机。

 

WSDL：Web 服务描述语言（Web Services Description Language，WSDL）Web Service描述语言WSDL就是用机器能阅读的方式提供的一个正式描述文档而基于XML的语言，用于描述Web Service及其函数、参数和返回值。因为是基于XML的，所以WSDL既是机器可阅读解析的的，又是人可阅读的。当你向别人介绍你提供的WebService的功能和函数参数时候，你可能会自己写一套文档，你甚至可能会口头上告诉需要使用你的Web Service的人。这些非正式的方法至少都有一个严重的问题：当程序员坐到电脑前，想要使用你的Web Service的时候，他们的工具(如Visual Studio)无法给他们提供任何帮助，因为这些工具根本就不了解你的WebService。解决方法是：用机器能阅读的方式提供一个正式的描述文档。Web service描述语言(WSDL)就是这样一个基于XML的语言，用于描述Web service及其函数、参数和返回值。因为是基于XML的，所以WSDL既是机器可阅读的，又是人可阅读的，这将是一个很大的好处。

     WSDL协议（Web服务描述语言）描述如何与一个Web服务通讯，用于描述Web Service及其函数、参数和返回值。因为基于XML的，所以WSDL既是机器可读，又是人可读。一些新的开发工具能根据Web Service生成WSDL文档，又能导入WSDL文档，生成调用相应的WebService代码。在WSDL定义中，允许不同类型的通讯（绑定）。

 WSDL可与SOAP绑定：当您在UDDI注册中心发布Web服务时，会把WSDL与SOAP/UDDI结合起来。

 WSDL到UDDI的映射：为帮助在UDDI注册中心发布和查找WSDL服务描述,WSDL文档被分为两种类型:服务接口(serviceinterface)和服务实现(serviceimplementatios)。服务接口由WSDL文档来描述,这种文档包含服务接口的types、import、message、portType和binding等元 素。服务接口定义了实现一个或多个服务的WSDL服务,它是Web服务的抽象定义,并被用于描述某种具体类型的服务。

 

SOAP：简单对象访问协议(SOAP,全写为Simple Object Access Protocol)是一种标准化的通讯规范,主要用于Web服务(Web Service)中。它是用于交换XML编码信息的轻量级协议。SOAP是个通信协议， SOAP在HTTP协议的基础上，把编写成XML的REQUEST参数, 放在HTTP BODY上提交个WEB SERVICE服务器， 处理完成后，结果也写成XML作为RESPONSE送回用户端。简单的说 SOAP就是HTTP+XML处理的协议。

SOAP 用来描述传递信息的格式规范， WSDL 用来描述如何访问具体的接口（比如它会告诉你该服务有哪些接口可以使用，参数是什么等等）， UDDI 用来管理、分发和查询 Web Service。下面我们将逐一详细介绍这三个要素，并通过结合实例来进行阐释。SOAP它是一个协议，可以简单的理解为：它定义了一个基于 XML 的可扩展消息信封格式。因为客户端与服务器进行交互，由于大家的平台和应用程序都不一样，所以大家约定都采用 SOAP 这个协议来规范交互时的需要传递的消息。 

 

SOAP是一种简单的、轻量级的基于XML的机制，用于在网络应用程序之间进行结构化的数据交换。SOAP包括三部分：一个定义描述消息内容的框架的信封，一组表示应用程序定义的数据类型实例的编码规则，以及表示远程过程调用和响应的约定。SOAP消息包含在HTTP的请求与应答消息的有效负载区中。由于HTTP POST请求存在有效负载区，因此完全适于携带SOAP消息。HTTP应答消息均遵循相同的格式并携带有效负载。

 

WSDL用来描述服务；

UDDI用来注册和查找服务；

SOAP作为传输层，用来在消费者和服务提供者之间传送消息。SOAP是Web服务的默认机制，其他的技术为可以服务实现其他类型的绑定。

用户可以在UDDI注册表（registry）查找服务，取得服务的WSDL描述，然后通过SOAP来调用服务。

 

何调用WebServices

客户端：:取得服务端的服务描述文件WSDL，解析该文件的内容，了解服务端的服务信息，以及调用方式。根据需要生成恰当的SOAP请求消息(指定调用的方法，已经调用的参数)，发往服务端。等待服务端返回的SOAP回应消息，解析得到返回值。

服务端：生成服务描述文件，以供客户端获取。接收客户端发来的SOAP请求消息，解析其中的方法调用和参数格式。根据WSDL和WSML的描述，调用相应的COM对象来完成指定功能，并把返回值放入SOAP回应消息返回给用户。