eb服务（Web Services）是目前程序设计领域中的一项新技术，是一个崭新的分布式计算模式，在不同系统平台之间具有互操作性，通过因特网，实现不同应用程序之间的远程过程调用。Web服务使用基于XML 的消息处理作为基本的数据通讯方式，消除使用不同组件模型、操作系统和编程语言的系统之间存在的差异，使异类系统能够作为单个计算网络协同运行。开发人员可以用象过去在创建分布式应用程序时使用组件一样的方式创建将来自各种源的Web服务组合在一起的应用程序。 Web服务是建立在一些通用协议的基础上，如HTTP，SOAP，XML，WSDL，UDDI等。这些协议在涉及到操作系统、对象模型和编程语言的选择时，没有任何倾向，因此将会有很强的生命力。
J2EE的Web服务工作原理
1.J2EE的Web服务模型
大家知道，普通Web服务的系统架构是面向服务的，服务的发布的发现是Web系统架构中首先要解决的主要问题。在java编程环境下，Web 服务通过JAXR（java API for XML Registries）实现自身的发布。客户使用同样的JAXR API寻找服务，使用JAX-RPC绑定和调用Web服务。如下图1所示：
图 1
2.J2EE在消息发送层（SOAP）和传输协议层（HTTP）的工作过程
用下图2可以说明，在具有Web服务功能的应用程序服务器上运行着一个标准的J2EE应用程序。在图中的左上角是Java，C++或C#客户机，现在，这个应用程序发出SOAP请求。该SOAP请求把Web服务操作封装在一个XML有效载荷中，然后，通过HTTP协议传送。在Web服务端，传输层继续把该调用输送剑SOAP服务端，然后，服务器就调用相应的已经展现为Web服务的J2EE功能。Web服务产生的任何响应都会被再编码成为一个SOAP响应，并通过HTTP协议传输回客户机去。
图 2
从图2中可以清楚地看出，利用消息发送层(Messaging layer) (SOAP)和传输协议层(Transoort Network laver) (HTTP)就可以完成应用程序内部的通信。应用程序内部通信的问题通过一些销售商的专有技术(例如CORBA和DCOM等)以前就已经解决了。这些技术操作起来很麻烦，并且，也不能通过防火墙。因此，现在我们用SOAP，通过简单的XML这个开放式的标准，就可以有效地实现应用程序内部的通信，不会使自己锁定在某个销售商的专有机制上。
3.J2EE在消息发送层（SOAP）、传输协议层（HTTP）和Web服务描述（WSDL）的工作过程
图3显示的是对前面所介绍的Web服务模式的简单扩展；在图3中只需要在两个应用程序之间传递的SOAP消息之间存在着紧密的耦合。现在，有了一个附加的Web服务描述层，服务提供者就可以用建立和发行WSDL文档的方法来描述他们的Web服务。WSDL文档中不仅包含有该Web服务的抽象定义，而且也包含有实现(绑定)该Web服务的细节。这意味着服务的消费者(即例子中的客户应用程序)需要得到WSDL文档，它不仅可以从这个文档中得到包括Web服务的消息和数据类型的不同操作，而且还能够重新得到该Web服务的终端(例如URL)，SOAP消息可以在终端上交换。如果J2EE服务是通过SMTP消息展示功能的，那么WSDL文档也会描述这一点。
图 3
4.J2EE使用UDDI、WSDL和SOAP三种技术的工作过程
在图4中假设服务提供者已经决定把某项商业功能展示成Web服务。该Web服务驻留在一个基于Java的Web服务系统中。通过图中的顺序步骤看一下整个的工作机制。
图 4
1）服务提供者的第一步是编写WSDL文件。当前市场上有好几种工具，可以帮助我们用现有的对象定义产生出WSDL文件。然后，需要发布关于它自己的信息，把商业和这项Web服务的技术规范作为-个WSDL文件发布到中心UDDL注册表。这样，用写WSDL文件的方法使得Web服务的描述占据了服务描述层。但是，在Web服务栈中我们看到，发布的商业信息和WSDL文件表现的是Web服务栈中的服务发布层。
2）服务消费者应用程序可以发现它有兴趣使用的Web服务。发现不仅涉及到要搜索商业和它的服务，而且还要下载WSDL文件中所提到的技术规范。发现的步骤对应于Web服务栈中的服务发现层。
3）最后，服务消费者应用程序用WSDL文件来确定，为了与服务提供者的Web服务通信，需要传送哪些消息，并且它还要决定绑定信息。为了达到这个目的，绑定信息就是HTTP上的SOAP。这个步骤对应于Web服务栈中的XML消息和传输层。
J2EE的基本Web服务体系结构
下图5是对J2EE系统的Web服务体系结构整体描述。
图 5
商业功能性
上图是一个Web服务提供者展示他们Web服务的功能。重要的是要理解，商业机构不会选择他们现有的基于J2EE应用程序，并把他们的EJB展示为Web服务的。虽然用Web服务平台或目前市场上出售的工具在技术上是可行的，但是在商业上这样做是没有现实意义，因为商业不在组件中展示方法调用。在商业上他们展示的是商业功能，这些功能会转换成一系列执行该商业功能所需要的协调动作。在即时返回服务消费者的响应中可能有也可能没有结果，还可能需要几天的时间才能完成。商业也需要通过多层开发系统的功能性，需要记住几个安全性等级和由不同的内部应用程序使用。例如，假设有一个在因特网上售书的商业机构G，比方说，他们决定在因特网上把一项在线订书服务展示为Web服务。当顾客下订单的时候，订单信息在商业企业G内部启动了一个交易过程。这个交易过程需要执行多项行动，例如，检查图书订单的总量或执行一个财务事务处理过程。这涉及到顾客把钱划到商业G账上，最后，给运输部门送一份消息，让他们把书送给顾客。从图5中的J2EE系统功能图可以看出，这个交易过程可能需要与各种EJB发生交互作用，而这反过来又与企业信息系统或跨机构的数据库产生交互作用。在所有这些交易过程中，交易的完整性以及顾客想从认真企业级的交易过程中得到的任何其他标准都需要保存起来。
Web服务系统
Web服务系统类似于J2EE中的容器(container)的概念。它给执行Web服务提供了一个运行时间环境。为了进行讨论的目的，完全可以说在较高的级别上Web服务系统会包含一个Web服务运行时间环境，该运行时间环境能接受SOAP请求并把它们映射到对应的Java组件，即在商业功能性中共享的Java类或EJB。同时，从该商业过程中收集的所有结果都是可靠的，并被封装在SOAP响应中，送回Web服务的客户机。
Web服务器
Web服务器是从Web服务客户机发出SOAP请求到服务提供者收到这个请求的过程中最主要的网关。Web服务器通过HTTP协议进行通信，通常在端口80收听。因为SOAP消息需要在HTFP上传输，所以它很适合进入我们的XML消息层和传输层。我们在图5上应当注意到的一件重要事情是，事实上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指的就是从图5中的Web服务器。一旦得到了WSDL文件，服务消费者就有了调用该Web服务所需要的技术信息。技术信息我们指的是该Web服务中的方法。该方法需要的参数，该方法的数据类型和终端信息。可以根据WSDL文件产生SOAP客户代码，然后再把产生的SOAP客户代码嵌入到客户机巾，以便调用该Web服务。
