本文主要是介绍WSDL、SOAP、UDDI，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
纵观计算机和软件领域，我们不难了解为什么会产生Web服务。在因特网上有许多系统和平台，在这些系统和平台上又有更多的应用程序。说得更明白些就是，存在着许多技术，把客户端连接到服务器，这其中包括DCOM、CORBA和其它各种技术；而Web服务则是在HTTP、XML和SOAP这样的开放标准上形成的，它具有更新和更简单的连接类型。
我们可以把Web服务想象为通过因特网或企业内部网连接调用其方法的组件，或者把它想象为通过Web提供其接口的组件。Web服务建立在对开放标准XML广泛接受的基础上，Web服务使用XML序列化其客户端收发的数据。即使客户端和Web服务主机使用不同的操作系统，或者应用程序使用不同的程序语言开发，只要客户端程序可以解析XML，那么它就可以使用Web服务返回的数据。
Web服务体系结构概述
XML Web服务体系结构最重要的优点之一就是允许在不同平台上使用不同编程语言以一种基于标准的技术开发程序，来与其它应用程序通讯。有两种使用Web服务的方法，允许访问内部系统功能，把它们向外部世界展示并且作为一个外部Web服务的客户端或者使用者。在这个模型中，Web服务可用来访问一个应用程序中任一层的应用功能。这样，因特网上的任何分布式系统就有可能被整合到一个用户定制的应用程序中。
通常，一个Web服务被分为五个逻辑层：数据层（Data Layer）、数据访问层(Data Access Layer)、业务层(Business Layer)、业务面(Business Facade)和监听者(Listener)。离客户端最近的是监听者，离客户端最远的是数据层。业务层更进一步被分为两个子层：业务逻辑（Business logic）和业务面（Business facade）。Web服务需要的任何物理数据都被保存在数据层。在数据层之上是数据访问层，数据访问层为业务层提供数据服务。数据访问层把业务逻辑从底层数据存储的改变中分离出来，这样就能保护数据的完整性。业务面提供一个简单接口，直接映射到Web服务提供的过程。
业务面模块被用来提供一个到底层业务对象的可靠的接口，把客户端从底层业务逻辑的变化中分离出来。
业务逻辑层提供业务面使用的服务。所有的业务逻辑都可以通过业务面在一个直接与数据访问层交互的简单Web服务中实现。Web服务客户应用程序与Web服务监听者交互，监听者负责接收带有请求服务的输入消息、解析这些消息，并把这些请求发送给业务面的相应方法。
这种体系结构与Windows DNA定义的n层应用程序体系结构非常相似。Web服务监听者相当于Windows DNA应用程序的表现层。如果服务返回一个响应，那么监听者负责把来自业务面的响应封装到一条消息中，然后把它发回客户端。监听者还处理对Web服务协约和其他Web服务文档的请求。开发者可以添加一个Web服务监听者到表现层中，并且提供到现有业务面的访问权限，这样酒能够很容易地把一个Windows DNA应用程序移植到Web服务中。虽然Web浏览器可以继续使用表现层，但是Web服务客户应用程序将与监听者交互。
Web服务堆栈
使用HTTP通信协议，我们可以从因特网上的一个地方向另一个地方发送消息。通过网络发送的消息可以使用XML结构化，XML协议定义这条消息的格式和语义。SOAP（简单对象访问协议）是定义如何从不同环境中的对象调用函数。使用SOAP，就能够整合不同的操作系统、对象模型和编程语言，使简化整合不同种类的业务处理过程成为可能。
HTTP、XML和SOAP可以看做是Web服务的核心层。这些层定义了Web服务之间交互的方法和途径。这三个协议已经被W3C（World Wide Web联盟）接受做为标准。
WSDL协议（Web服务描述语言）描述如何与一个Web服务通讯。在WSDL定义中，允许不同类型的通讯（绑定）。它可以用来开发Web服务，同时也可以用来赚钱。为了实现这个目的，我们需要一个Web服务门户，我们可以在那里发布我们的Web服务，其他的人也能在那里找到它并使用它。这就需要使用UDDI（Universal Description, Discovery and Integration，统一描述、发现和整合规范）。
（图1、Web 服务体系结构堆栈）
Web服务技术通常可以分为三个关键组成部分：描述堆栈(Description Stack)、发现堆栈（Discovery Stack）和线堆栈(Wire Stack)。描述堆栈处理描述Web服务的各种技术，以便促进B2B关系中的业务处理模型和工作流程结构的通用性。发现堆栈处理那些供目录、发现和审查服务使用的技术。线堆栈由为Web服务运行期引擎提供信息流的技术组成。
Web服务的结构单元
Web服务基于开放的因特网标准，它的结构单元是SOAP、WSDL和UDDI。
SOAP
SOAP是序列化调用位于远程系统上的服务所需信息的标准方法，这些信息可以使用一种远程系统能够读懂的格式通过网络发送到远程系统，而不必关心远程系统运行于何种平台或者使用何种语言编写。SOAP以XML格式提供了一个简单、轻量的用于在分散或分布环境中交换结构化和类型信息的机制。SOAP本身并没有定义任何应用程序语义，如编程模型或特定语义的实现；实际上它通过提供一个有标准组件的包模型和在模块中编码数据的机制，定义了一个简单的表示应用程序语义的机制。这使SOAP可用于联合各种现有的网络协议和格式，包括HTTP、SMTP和MIME，并可被用于消息传递到RPC的各种系统。
SOAP解决了通过防火墙传送往返于远程应用程序的消息的问题。除了通过某些预先设定的作为特定用途的端口，防火墙通常禁止通过其它端口进行远程通讯。这就出现了一个问题，大部分分布式协议不使用分配的端口，而是动态地选择端口。微软SOAP技术实现的解决方案是通过HTTP的80端口传送对远程进程的调用。这个远程调用使用XML定义消息请求或响应的格式，把调用附加到HTTP协议的顶部。这个技术的优点之一就是降低通过防火墙传送消息的复杂性。但是80端口通常还用来作为Web通信之用，所以可能会降低其效率。
SOAP可以用来解决因特网应用程序的交互性问题。你可以使用一种平台无关性方式在远程（或本地）服务器上访问对象和服务。现在的互联网世界由不同的操作系统、不同的防火墙、不同的产生远程过程调用的方法和平台组成。为了跨因特网交互，客户机和服务器都需要了解彼此的安全类型和信任、服务部署模式和实现细节以及平台语言。使用SOAP，这种平台特定性的混乱局面就会结束。基于已被业界广泛接受的HTTP标准和XML标准，SOAP也可与其竞争对象RPC技术连通，并提供用于任何操作系统、程序语言和平台的轻量级消息格式。
在SOAP体系结构有四个主要的部分：
SOAP信封（envelope），用于描述消息内容和处理方法。
SOAP编码规则：定义了一个编码机制用于交换应用程序定义的数据类型的实例。
SOAP RPC表示，定义了一个用于表示远程过程调用和响应的约定。
SOAP绑定，定义了一个使用底层传输协议来完成在结点间交换SOAP信封的约定。
简单的说，SOAP提供了使用完全独立于平台的访问服务、对象和服务器的技术。通过SOAP，你将能够查询服务、调用服务、与服务通讯并处理服务，而不用去关心远程系统的位置、所在的操作系统或平台到底是什么样的。
SOAP本身提供了与Web服务交换信息的方法，但是它没有提供查找Web服务消息的方法。而且它还不提供查找Web服务或与之交涉的方法。
WSDL
Web服务描述语言（WSDL）和SOAP一起构成了Web服务的核心结构单元。WSDL基于XML格式，用来描述Web服务。它描述了Web服务可以执行的操作以及Web服务可以发送或接收的消息格式。WSDL文档可以看成是客户端和服务器之间的一个协约。使用WSDL工具，你可以自动处理这个过程，几乎不用手工编写代码就能够让应用程序整合新的服务。因此WSDL是Web服务体系结构的基础，因为它提供了一个通用语言，用来描述服务和整合这些服务的平台。
虽然大部分WSDL文档使用RPC风格的要求/应答语句对，但是WSDL也支持单向的消息。WSDL支持四种SOAP消息操作：
单向 (One-way)：端点接收消息。
请求响应 (Request-response)：端点接收消息，然后发送相关消息。
要求响应 (Solicit-response)：端点发送消息，然后接收相关消息。
通知 (Notification)：端点发送消息。
UDDI
UDDI（统一描述、发现和整合）建了一个平台独立、开放的框架，通过因特网来描述服务，发现业务，并且整合业务服务。它是一套基于Web的、分布式的、为Web服务提供的信息注册中心的实现标准规范，同时也包含一组使企业能将自身提供的Web服务注册以使得别的企业能够发现的访问协议的实现标准。
通过使用UDDI的发现服务，企业可以单独注册那些希望被别的企业发现的自身提供的Web服务。企业可以通过UDDI商业注册中心的Web界面，或是使用实现了"UDDI Programmer's API标准"所描述的编程接口的工具，来将信息加入到UDDI的商业注册中心。UDDI商业注册中心在逻辑上是集中的，在物理上是分布式的，由多个根节点组成，相互之间按一定规则进行数据同步。当一个企业在UDDI商业注册中心的一个实例中实施注册后，其注册信息会被自动复制到其它UDDI根节点，于是就能被任何希望发现这些Web服务的人所发现。
这篇关于WSDL、SOAP、UDDI的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
