Web服务使用基于XML的消息处理作为基本的数据通信方式，消除使用不同组件模型、操作系统和编程语言的系统之间存在的差异，使异类系统能够作为单个计算网络协同运行。开发人员可以用像过去在创建分布式应用程序时使用组件一样的方式，将来自各种源的Web服务组合在一起，从而创建应用程序。
Web 服务所实现的最基本方案是向它的客户端提供某个基本功能以供其使用。它可以复合方式使用Web服务集成一组似乎完全不同的现有应用程序，以及创建端对端工作流解决方案的应用程序（如企业到企业交易中的解决方案）。
Web服务是建立在一些通用协议基础上的，如HTTP、SOAP、XML、WSDL、UDDI等。这些协议在涉及到操作系统、对象模型和编程语言的选择时，没有任何倾向，因此有很强的生命力。在Web服务的模型中，厂商将其服务封装成一个个相对独立的Web服务，每个服务提供某类功能。客户或其它厂商可以通过绑定到HTTP的SOAP来访问这些服务。
Web服务是一种不涉及具体平台和语言的软件架构，但是开发人员必须选择一种语言来具体开发Web服务。本文选用Java语言说明J2EE的Web服务体系结构。
Web服务构架由三个参与者和三个基本操作构成。三个参与者分别是服务提供者（Service Provider）、服务请求者（Service Requester）和服务代理（Service Broker）；三个基本操作分别为发布（Publish）、查找（Find）和绑定（Bind）。如图1所示。
Web服务体系结构的三个基本组件执行这三个基本操作：
◆ 服务提供者通过在服务代理者那里注册来配置和发布服务；
◆ 服务请求者通过查找服务代理者，以及那里的被发布服务登记记录来找到服务；
◆ 服务请求者绑定服务提供者，并使用可以请求的服务。
在Web服务里，三个操作都包含三个受到称赞的和截然不同的技术：
◆ 发布服务使用通用描述、发现和集成（UDDI）API；
◆ 查找服务使用UDDI和Web服务描述语言（WSDL）的组合；
◆ 绑定服务处理WSDL和简单对象访问协议（SOAP）。
描述Web服务的标准方法——WSDL，它是用XML格式来描述Web服务的标准。基本上，某项Web服务的WSDL文档都会指定Web服务中使用的方法、数据类型、使用的传输协议和Web服务宿主的终点URL。
发布和查找Web服务的标准协议——UDDI标准提供了一种方法，使服务提供者把他们机构的详细资料和所提供的Web服务的详细情况发布到中心注册表，这就是UDDI中“描述”部分。它也提供了一个服务消费者的标准，可以使他们找到服务提供者和关于他们Web服务的详细资料。这就是在UDDI中“发现(Discovery)”的部分。
绑定到Web服务的标准应用程序协议——SOAP是一个不管使用哪种操作系统、不管用什么程序语言或对象模型，都可以用于在应用程序之间交换信息的轻型XML机制。
从最基础的层次上来看，绑定操作是三者中最重要的。它包含服务的实际使用，这也是发生大多数互操作性问题的地方。简单地说，是服务提供者和服务请求者对SOAP规范的全力支持解决了这些问题，并实现了无缝互操作性。
在Web服务体系中，使用WSDL来描述服务，UDDI来发布、查找服务，而SOAP用来执行服务调用。Web服务流语言（Web Services Flow Language，WSFL）则将分散的、功能单一的Web服务组织成一个复杂的有机应用。
目前访问Web服务的基础结构由SOAP、WSDL和UDDI构成。
1、 WebServices.org 公司定义的Web 服务架构栈
图2堆栈中的顶层是服务浏览层，它包括两个或多个同意聚合Web 服务协议的贸易合作伙伴。这一层也叫进程定义层，包括文档、工作流程、交易和处理流程。
下一层是工作流程、服务发现和注册层，它使用了WSFL和MS XLANGE（一种基于XML的语言）来描述工作流程的创建和功能。有了WSFL，你可以决定Web服务应该被当成工作流程中的一个活动还是一系列活动。WSFL特别适合业务模型的表示，而MS XLANGE适合于Web服务组件的长期交互过程。MS XLANG在BizTalk里被实现，它是微软制作的XML集成服务器。
栈的第二层还定义了Web服务与公共路径和服务的交互过程。可以被公开的Web服务能够从公共路径或者注册表来获得身份验证过程的信息。EbXML（电子商务可扩展语言）、E-Services
Village公司和BizTalk.org是另外可以通过UDDI与Web服务一道使用，从而为B2B交易过程提供服务的站点。
第三层是Web服务描述语言层，需要用栈中定义的WSDL来描述如何连接到一个Web服务。使用WSDL，服务的请求方可以通过UDDI查找到Web服务的信息。Web服务合同语言（WSCL）能够帮助开发者使用XML方案，以一种更通用的格式来更好地描述和建立数据的格式。
这个栈的第四层是消息发送层，SOAP扮演了基于XML消息的封装器的角色，并包含了消息封装、路由、可靠投递和安全性方面的内容。随着处理过程的进行，比如客户定单从仓库中发出货物等，消息在这个过程中被反复的进行传递。
当一系列的消息处理完成以后，这个栈就进入了第五层的处理—传输协议层，它使用HTTP、安全的HTTP（HTTPS）、可靠的HTTP（HTTPR）、FTP或者SMTP。然后每个Web
服务向服务请求方提供服务，或者将状态报告给服务提供者或者是中间件。
最后，栈的第六层是商务处理层，列出了Web
服务使用和增长重要性的其它关键部分。
J2EE在消息发送层（SOAP）和传输协议层（HTTP）的工作过程
图3可以说明，在具有Web服务功能的应用程序服务器上，运行着一个标准的J2EE应用程序。在图3中的左上角是Java、C++或C#客户机，这个应用程序发出SOAP请求。该SOAP请求把Web服务操作封装在一个XML有效载荷中，然后，通过HTTP协议传送。在Web服务端，传输层继续把该请求输送给SOAP服务端，随后服务器就调用相应的、已经展现为Web服务的J2EE功能。Web服务产生的任何响应都会被再编码成为一个SOAP响应，并通过HTTP协议传输回客户机去。
从图3中也可以清楚地看出，利用SOAP和HTTP可以完成应用程序内部的通信。应用程序内部通信的问题，通过一些销售商的专有技术(例如CORBA和DCOM等)以前就已经解决了，这些技术操作起来很麻烦，并且，也不能通过防火墙。因此，现在我们用SOAP，通过简单的XML这个开放式的标准，就可以有效地实现应用程序内部的通信，不会使自己锁定在某个销售商的专有机制上。
J2EE在消息发送层（SOAP）、传输协议层（HTTP）和Web服务描述（WSDL）的工作过程
图4显示的是对前面所介绍的Web服务模式的简单扩展。在图3中，只需要在两个应用程序之间及传递的SOAP消息之间存在着紧密的耦合。现在，有了一个附加的Web服务描述层，服务提供者就可以用建立和发行WSDL文档的方法，来描述他们的Web服务。WSDL文档中不仅包含该Web服务的抽象定义，而且也包含实现(绑定)该Web服务的细节。这意味着服务消费者(即例子中的客户应用程序)需要得到WSDL文档。不仅可以从WSDL文档中得到包括Web服务的消息和数据类型的不同操作，而且还能够重新得到该Web服务的终端(例如URL)。如果J2EE服务是通过SMTP消息展示功能的，那么WSDL文档也会描述这一点。
J2EE使用UDDI、WSDL和SOAP三种技术的工作过程
在图5中，假设服务提供者已经决定把某项商业功能展示成Web服务，那么该Web服务驻留在一个基于Java的Web服务系统中。通过如下步骤看一下Web服务的工作机制。
◆ 服务提供者的第一步是编写WSDL文件。当前市场上有几种工具，可以帮助我们用现有的对象定义产生出WSDL文件。然后，发布该WSDL文件信息，把商业信息和这项Web服务的技术规范，作为—个WSDL文件发布到中心UDDL注册表。这样，通过写WSDL文件的方法，使得Web服务的描述占据了服务描述层。但是，在图2Web服务栈中我们看到，发布的商业信息和WSDL文件表现的是Web服务栈中的服务发布层。
◆ 服务消费者应用程序可以发现有兴趣使用的Web服务。发现不仅涉及到要搜索商业和它的服务，而且还包括下载WSDL文件中所提到的技术规范。发现的步骤对应于图2
Web服务栈中的服务发现层。
◆ 最后，服务消费者应用程序通过WSDL文件来确定，为了与服务提供者的Web服务通信，需要传送哪些消息，并且它还要决定绑定信息。为了达到这个目的，绑定信息就是HTTP上的SOAP。这个步骤对应于图2Web服务栈中的XML消息和传输层。
图6是J2EE系统的Web服务体系结构整体描述。
◆ 商业功能性
图6也是一个Web服务提供者展示Web服务的功能图。重要的是要理解，商业机构不会选择现有的基于J2EE的应用程序，也不会把他们的EJB展示为Web服务的。虽然用Web服务平台或目前市场上出售的工具，在技术上是可行的，但是在商业上这样做是没有现实意义的。因为商业不在组件中展示方法调用，展示的是商业功能，这些功能会转换成一系列执行该商业功能所需要的协调动作。在即时返回服务消费者的响应中，可能有也可能没有结果，也可能需要几天的时间才能完成。商业也需要通过多层开发系统的功能性，记住几个安全性等级和由不同的内部应用程序使用的记录。例如，假设有一个在因特网上售书的商业机构G，他们决定在因特网上把一项在线订书服务展示为Web服务。当顾客下订单的时候，订单信息在G内部启动了一个交易过程。这个交易过程需要执行多项行动，例如，检查图书订单的总量或执行一个财务事务处理过程等。这样顾客就需要把钱划到G账户上，最后，给运输部门送一条消息，让他们把书送给顾客。从图6中的J2EE系统功能图可以看出，这个交易过程可能需要与各种EJB发生交互作用，而这反过来又与企业信息系统或跨机构的数据库产生交互作用。在所有这些交易过程中，交易的完整性及顾客想从任何企业级的交易过程中得到的任何其它标准服务都需要保存起来。
◆ Web服务系统
Web服务系统类似于J2EE中容器(Container)的概念，它给Web服务提供了一个运行时间环境。可以说在较高的级别上，Web服务系统会包含一个Web服务运行时间环境，该运行时间环境能接受SOAP请求，并把它们映射到对应的Java组件，即在商业功能性中共享的Java类或EJB。同时，从该商业过程中收集的所有结果都是可靠的，并被封装在SOAP响应中，最后送回Web服务的客户机。
◆ Web服务器
Web服务器是从Web服务客户机发出SOAP请求，到服务提供者收到这个请求的过程中最主要的网关。Web服务器通过HTTP协议进行通信，通常在端口80收听。因为SOAP消息需要在HTTP上传输，所以它很适合进入XML消息层和传输层。我们通过图6应当注意到的一件重要事情是，事实上WSDL文件是存放在Web服务器上的，因为它给服务的消费者提供了全球性的可访问机制，使他们能查阅WSDL技术规范。因此，如果我们提供了一个UDDI注册表，然后将它作为URL引用的WSDL文件，服务消费者就可以很容易地通过URL找到该WSDL，并对它进行转换，以确定该机构支持的服务和服务的终端。
Web服务器还在整个系统中执行另外一种重要功能。这种功能会把适当的SOAP请求转送到Web服务系统去。
◆ Web服务客户机
Web服务客户机是Web服务的消费者。由于Web服务是不确定平台的，因此用目前任何一种主流编程语言写成的客户机都可以调用Web服务。例如，它可能是一个Java程序、一个Visual
Basic程序或者一个C++程序。Web服务客户机要做的第一步工作是查阅UDDI信息，以便查找到它感兴趣的Web服务的商业信息。它也可以从UDDI信息中重新得到WSDL
URL引用，并从可公开访问的URL下载WSDL文档。通常，URL指的就是图6中的Web服务器。一旦得到了WSDL文件，服务消费者就有了调用该Web服务所需要的技术信息。技术信息指的是该Web服务中的方法，该方法需要的参数，以及该方法的数据类型和终端信息。可以根据WSDL文件产生SOAP客户代码，然后再把产生的SOAP客户代码嵌入到客户机中，以便调用该Web服务。