基于J2EE的多层服务体系架构

1、面向服务的体系结构（service-oriented architecture，SOA）因其固有的松散耦合与互操作性，成为许多企业应用的自然选择。在本文中您将看到，使用 J2EE 1.4 提供的 Web 服务功能可以很容易地构建能够访问现有业务流程的 SOA 系统。在本文中，您将学习如何利用 Java 2 Platform, Enterprise Edition (J2EE) 设计和开发 面向服务的体系结构（SOA）框架。通过采用 SOA 框架，企业可以最大程度地减少系统间的耦合，从而提高可重用性。本文从一个较高的层面概述了在 SOA 框架上进行的几次迭代过程，这个框架将满足一家虚构企业的需求

2、。这里开发的示例框架可以很容易地进行修改以适合您的商业需求。 SOA 和 Web 服务：简介SOA 是一种分布式的软件模型。SOA 的主要组件包括 服务、动态发现和 消息。 服务是能够通过网络访问的可调用例程。服务公开了一个接口契约，它定义了服务的行为以及接受和返回的消息。术语 服务常与术语 提供者互换使用，后者专门用于表示提供服务的实体。 接口通常在公共注册中心或者目录中发布，并在那里按照所提供的不同服务进行分类，就像电话簿黄页中列出的企业和电话号码一样。客户（服务消费者）能够根据不同的分类特征通过动态查询服务来查找特定的服务。这个过程被称为服务的 动态发现。 服务消费者或者客户通过 消息来

3、消费服务。因为接口契约是独立于平台和语言的，消息通常用符合 XML 模式的 XML 文档来构造。 下面的 HYPERLINK /developerworks/cn/webservices/ws-designsoa/index.html l figure1#figure1 图 1说明了 SOA 中的不同角色。 Web 服务作为 SOAWeb 服务建立在开放标准和独立于平台的协议的基础之上。Web 服务通过 HTTP 使用 SOAP（一种基于 XML 的协议），以便在服务提供者和消费者之间进行通信。服务通过 WSDL（Web Service Definition Language）定义的接口来公开

4、，WSDL 的语义用 XML 定义。UDDI 是一种语言无关的协议，用于和注册中心进行交互以及查找服务。所有这些特性都使得 Web 服务成为开发 SOA 应用程序的优秀选择。 HYPERLINK /developerworks/cn/webservices/ws-designsoa/index.html l main#main 回页首使用 J2EE 1.4 平台开发 SOA/Web 服务框架1.4 版的 J2EE 平台通过新的 JAX-RPC 1.1 API 提供了完整的 Web 服务支持，这种 API 支持基于 servlet 和企业 bean 的服务端点。JAX-RPC 1.1 基于 WS

5、DL 和 SOAP 协议提供了与 Web 服务的互操作性。J2EE 1.4 平台也支持 Web Services for J2EE 规范(JSR 921)，后者定义了 Web 服务的部署需求并利用了 JAX-RPC 编程模型。除了几种 Web 服务 API 之外，J2EE 1.4 平台还声称支持 WS-I Basic Profile 1.0。WS-I Basic Profile 标准让 Web 服务克服了不同编程语言、操作系统和供应商平台之间的障碍，从而使多种应用程序之间能够交互（关于 WS-I 的更多信息，请参阅 HYPERLINK /developerworks/cn/webservice

6、s/ws-designsoa/index.html l 6#6 参考资料部分。）这意味着除了平台独立性和完整的 Web 服务支持之外，J2EE 1.4 还提供了跨平台的 Web 服务互操作性。 在 J2EE 1.4 下，Web 服务客户可以通过两种方式访问 J2EE 应用程序。客户可以访问用 JAX-RPC API 创建的 Web 服务；在幕后 JAX-RPC 使用 servlet 来实现 Web 服务。Web 服务客户也可以通过 bean 的服务端点接口访问无状态会话 bean。Web 服务客户不能访问其他类型的企业 beans。第二种选择公开无状态 EJB 组件作为 Web 服务有很多优势

7、：利用现有的业务逻辑和流程：在许多企业中，现有的业务逻辑可能已经使用 EJB 组件编写，通过 Web 服务公开它可能是实现从外界访问这些服务的最佳选择。EJB 端点是一种很好的选择，因为它使业务逻辑和端点位于同一层上。 并发支持：作为无状态会话 bean 实现的 EJB 服务端点不必担心多线程访问，因为 EJB 容器必须串行化对无状态会话 bean 任何特定实例的请求。 对服务的安全访问：企业 beans 允许在部署描述符中声明不同方法级别的安全特性。方法级别角色被映射到实际的主体域（principal domain）。使用 EJB 组件作为 Web 服务端点，把这种方法级别的安全性也带给了

8、Web 服务客户。 事务问题：EJB 服务端点在部署描述符规定的事务上下文中运行。容器处理事务，因此 bean 开发人员不需要编写事务处理代码。 可伸缩性：几乎所有 EJB 容器都提供了对无状态会话 bean 群集的支持。因此当负载增加时，可以向群集中增加机器，Web 服务请求可以定向到这些不同的服务器。通过把 Web 服务模型化为 EJB 端点，可以使服务具有可伸缩性，并增强了可靠性。 池与资源管理：EJB 容器提供了无状态会话 bean 池。这改进了资源利用和内存管理。通过把 Web 服务模型化为 EJB 端点，这种特性很容易扩展，使 Web 服务能够有效地响应多个客户请求。 记住所有这些

9、优点，下一节将展示如何在体系结构中将无状态 EJB 组件公开为 Web 服务。 HYPERLINK /developerworks/cn/webservices/ws-designsoa/index.html l main#main 回页首设计 SOA/Web 服务框架比方说有一家公司，它的各种系统（比如支付、财务和发票系统）需要彼此交互。此外，其中一些应用程序还需要对外界公开，以便不同的业务合作伙伴与它们进行交互。您还需要为各种应用程序（如输入发票的各种数据输入操作或者查看支付的状态）设计基于 Web 的解决方案。最佳选择就是设计一种松散耦合的基于服务的系统。这些服务应该得到开放标准的支持，

10、这样任何业务合作伙伴都可以调用它们。这些方面的考虑将使您转向 Web 服务 /SOA 框架，通过无状态 EJB 组件把各种服务和业务流程公开为 Web 服务。下面的 HYPERLINK /developerworks/cn/webservices/ws-designsoa/index.html l figure2#figure2 图 2说明了企业内部应用的 SOA 框架。 下面列出了 SOA 框架中进行交互的各种组件。这是一种典型的 MVC 2 框架。客户（Client）：用户通过 Web 浏览器与不同的应用程序交互，浏览器作为应用程序的客户。比如，出纳部门的用户可能要输入帐单细节并把信息提交

11、给应用程序。可以使用 JSP 页面和 XHTML 来呈现客户页面。 应用程序控制器（Application controller）：应用程序控制器是您的主控制器 servlet。它负责初始化、委派请求和响应请求处理程序。 请求处理程序（Request processor）：这是一个 Java 类，通过调用相应的请求执行程序完成要求的处理，对请求进行预处理。这种调用采用命令模式。 请求执行程序（Request handlers）：请求执行程序完成具体请求的活动，比如与服务交互，向不同的企业信息系统（enterprise information systems，EIS）增加或检索信息。请求执行程序

12、依靠业务定位程序发现相应的服务，然后通过这些服务访问需要的 EIS 信息。 业务定位程序（Business locators）：这些程序负责隐藏查找服务的复杂性，并提供缓存逻辑。业务定位程序可以采用多种形式，比如 Web 服务定位程序、EJB 组件定位程序或者 JMS 定位程序。 会话 Facades（Session Facades）：通过聚合来自多个系统或服务的方法，简化复杂对象的视图。会话 facades 是 EJB Web 服务方法的包装器。 EJB Web 服务（EJB Web services）：根据 EJB 1.4 规范，Web 服务端点可以模型化为无状态的会话 bean。如前所述

13、，这种技术有许多优势。 数据访问接口（Data access interfaces）：使用不同的技术（比如 EJB-CMP、JDO、DAO）和不同的持久性技术访问 EIS，所使用的访问技术取决于接口需求以及获取、插入或更新的数据量。这一层负责与 EIS 进行交互，并以相应的 EJB Web 服务方法所期望的格式把数据返回给这些方法。 MQSeries/JCA/CCF：现有的基于主机的服务可以公开为 Web 服务，从而向外界展示它们。Web 服务客户使用基于 HTTP 的 SOAP 协议与 EJB Web 服务交互。EJB 方法通过 JMS 协议向 MQSeries 队列发送请求。（使用 MQS

14、eries 是与基于主机的应用程序交互的一种方式。）主机端的 MQSeries 服务器触发相应的基于 COBOL 的程序，后者为与后台系统（比如 IMS DC）进行交互提供必要的逻辑。然后这些程序把响应返回到队列中，应用程序逻辑检索这些响应并返回给 EJB 方法。SOAP 消息可以通过不同协议进行传输，比如 HTTP、HTTPS 和 JMS，但为了统一起见，本例子只使用 HTTP 和 HTTPS。 这些组件提供了企业内部应用程序面向服务体系结构的基础。接下来讨论把服务向外界公开。 HYPERLINK /developerworks/cn/webservices/ws-designsoa/ind

15、ex.html l main#main 回页首向外界公开服务如果准备向外部用户公开服务，您需要某种安全约束来保证只有授权的用户才能访问服务。一种方法是提供另外的 Web 服务层，过滤掉禁用的 Web 服务请求，并提供登录和安全约束。这种过滤方式还应提供一种工具，向每一客户只公开授权给该用户的服务子集。 HYPERLINK /developerworks/cn/webservices/ws-designsoa/index.html l figure3#figure3 图 3说明了企业外部应用的面向服务体系结构。它向外界公开了细粒度的服务。 以下是这种体系结构的基本功能单元：外部客户（Extern

16、al clients）：可以包括基于 Web 的客户、移动客户或者使用 .NET 环境、Perl 或其他编程语言编写的客户。所有这些客户都为不同的服务发送请求。只要遵循 WS-I Profiles 就不会出现互操作性的问题。 企业防火墙（Corporate firewall）：根据其安全策略，这家公司在 intranet 和 Internet 之间架起了防火墙，对收到的分组信息进行限制。 Web 服务网关（Web Services Gateway）：本例中，我选择使用 WebSphere Application Server 5.0 中的 Web Services Gateway 产品作为公开

17、外部服务的网关。（关于该产品的更多信息，请参阅 HYPERLINK /developerworks/cn/webservices/ws-designsoa/index.html l 6#6 参考资料。） Web Services Gateway 是一种中间件产品，在调用 Web 服务时提供了 Internet 和 intranet 之间的中间框架。使用 Web Services Gateway，开发人员和 IT 经理可以安全地对外公开 Web 服务，防火墙之外的客户也能调用这些服务。它包括一个服务管理模型（部署、取消部署，等等）和过滤器（对流经网关的请求和响应起作用的自定义代码）。它只处理收到

18、的 SOAP/HTTP 请求，通过网关的请求可能发送给 Java 类、EJB 组件或者 SOAP 服务器（该服务器甚至还可能是另一个网关）。它可以为单个的 Web 服务方法提供保护（基本授权），也可以保护整个网关。使用 Web Services Gateway，来自客户的请求可以被转换成服务所要求的任何消息协议。例如，客户的请求可能是 HTTP 上的 SOAP，但在内部可以使用 JMS 协议上的 SOAP，Web Service Gateway 能够提供从一个协议到另一个协议的转换。 EJB 服务（EJB services）：EJB 服务没有任何变化。过程的其他部分和 HYPERLINK /d

19、eveloperworks/cn/webservices/ws-designsoa/index.html l figure2#figure2 图 2所示体系结构提供的基于 intranet 的服务类似。 HYPERLINK /developerworks/cn/webservices/ws-designsoa/index.html l main#main 回页首使用 EJB 组件实现粗粒度的服务迄今所见到的过程都是向客户公开细粒度的 Web 服务。只要每个业务服务作为单个业务过程执行，这种设置就能很好地工作。但是假设客户要进行在线资金转移，这种情况下提供单一的、粗粒度的接口显然更加合理，让用户

20、提供所有必要的信息，包括传输的金额、发出和接收的银行信息，等等。此外，这类情形中验证必须在执行任何业务逻辑之前完成。在设计 Web 服务方法时必须考虑到这些问题，还要记住除了网络调用之外还有解析与规划 XML 请求和响应的开销。考虑到这些因素，可以把 Session Facades 模型化为 EJB Web 服务端点。Session Facades 可以在把请求委派给相应的 Web 服务方法之前首先验证请求。这样，您就可以向 Web 服务客户提供粗粒度的服务。下面的 HYPERLINK /developerworks/cn/webservices/ws-designsoa/index.html

21、 l figure4#figure4 图 4说明了企业外部应用的面向服务体系结构的下一次迭代过程。这个版本的体系结构向外界公开粗粒度的服务。 这里，主要的实现仍然和 HYPERLINK /developerworks/cn/webservices/ws-designsoa/index.html l figure3#figure3 图 3 中所示的相同。唯一的区别在于已经公开了 Session Facades 作为 Web 服务端点。EJB Web 服务可以模型化为本地接口而不是远程接口。使用会话 facades 和方法级安全性，可以限制要执行的服务。使用 Web Service Gateway

22、 也能为 Web 服务客户施加安全措施。根据需要，可以实现粗粒度服务和细粒度服务的某种结合，通过调整 Web 服务网关中间件来向外部客户公开两种服务。（关于使用 Session Facades 与企业 Web 服务的更多信息，请参阅 HYPERLINK /developerworks/cn/webservices/ws-designsoa/index.html l 6#6 参考资料。） HYPERLINK /developerworks/cn/webservices/ws-designsoa/index.html l main#main 回页首结束语采用 WSDL 文件形式的 Web 服务接口

23、可以发布到商业注册中心，从而使客户能够动态查找这些接口。如果交易伙伴已经知道这些服务，也不一定要进入商业注册中心，但是全球服务需要公共注册中心，以便客户能够查找可用的服务。例如，各个航空公司可以把它们的机票价格服务放在注册中心，普通客户可以发现所有这类服务，并查找航空公司所提供的最低票价。我希望本文能够有助于您开始使用 Web 服务和新的 J2EE 1.4 规范所提供的特性构建面向服务的体系结构。您可以修改和调整本文所述的 SOA Web 服务框架以适应您的业务需要。J2EE的Web服务原理和体系结构慨述作者：佚名 来源：不详 更新时间：2006-10-18 22:41:59 等级： Web服

24、务（Web Services）是目前程序 HYPERLINK /keywords/photoshop_e.html t _blank 设计领域中的一项新技术，是一个崭新的分布式计算模式，在不同系统平台之间具有互操作性，通过因特网，实现不同应用程序之间的远程过程调用。 Web服务使用基于 HYPERLINK /keywords/xml.html t _blank HYPERLINK /webemp/XML/Index.html XML 的消息处理作为基本的数据通讯方式，消除使用不同组件模型、 HYPERLINK /keywords/operating-system.html t _blank 操

25、作系统和 HYPERLINK /program/ 编程语言的系统之间存在的差异，使异类系统能够作为单个计算网络协同运行。 HYPERLINK /program/ 开发人员可以用象过去在创建分布式应用程序时使用组件一样的方式创建将来自各种源的Web服务组合在一起的应用程序。 Web服务是建立在一些通用 HYPERLINK /z/protocol/index.html t _blank 协议的基础上，如HTTP， HYPERLINK /keywords/soap.html t _blank SOAP， HYPERLINK /webemp/XML/Index.html XML，WSDL，UDDI等。

26、这些协议在涉及到操作系统、对象模型和 HYPERLINK /program/ 编程语言的选择时，没有任何倾向，因此将会有很强的生命力。Web服务是一种不涉及具体平台和语言的 HYPERLINK /program/ 软件架构，但是 HYPERLINK /program/ 开发人员必须选择一种语言来具体 HYPERLINK /program/ 开发Web服务。本文选用 HYPERLINK /keywords/java.html t _blank Java语言，说明 HYPERLINK /keywords/j2ee.html t _blank J2EE的Web服务体系结构。一、J2EE的Web服务工

27、作原理1、J2EE的Web服务模型大家知道，普通Web服务的系统架构是面向服务的，服务的发布的发现是Web系统架构中首先要解决的主要问题。在java HYPERLINK /program/ 编程环境下，Web 服务通过JAXR（java API for HYPERLINK /webemp/XML/Index.html XML Registries）实现自身的发布。客户使用同样的JAXR API寻找服务，使用JAX-RPC绑定和调用Web服务。如下图1所示：图12、J2EE在消息发送层（SOAP）和传输协议层（HTTP）的工作过程用下图2可以说明，在具有Web服务功能的应用程序 HYPERLIN

28、K /hardware/server/index.html t _blank 服务器上运行着一个标准的J2EE应用程序。在图中的左上角是Java， HYPERLINK /keywords/cpp.html t _blank HYPERLINK /program/cc/Index.html C+或C#客户机，现在，这个应用程序发出SOAP请求。该SOAP请求把Web服务操作封装在一个 HYPERLINK /webemp/XML/Index.html XML有效载荷中，然后，通过HTTP协议传送。在Web服务端，传输层继续把该调用输送剑SOAP服务端，然后，服务器就调用相应的已经展现为Web服务的

29、J2EE功能。Web服务产生的任何响应都会被再编码成为一个SOAP响应，并通过HTTP协议传输回客户机去。图2从图2中可以清楚地看出，利用消息发送层(Messaging layer) (SOAP)和传输协议层(Transoort Network laver) (HTTP)就可以完成应用程序内部的通信。应用程序内部通信的问题通过一些销售商的专有技术(例如CORBA和DCOM等)以前就已经解决了。这些技术操作起来很麻烦，并且，也不能通过 HYPERLINK /security/firewall/index.html t _blank 防火墙。因此，现在我们用SOAP，通过简单的 HYPERLINK

30、 /webemp/XML/Index.html XML这个开放式的标准，就可以有效地实现应用程序内部的通信，不会使自己锁定在某个销售商的专有机制上。3、J2EE在消息发送层（SOAP）、传输协议层（HTTP）和Web服务描述（WSDL）的工作过程图3显示的是对前面所介绍的Web服务模式的简单扩展；在图3中只需要在两个应用程序之间传递的SOAP消息之间存在着紧密的耦合。现在，有了一个附加的Web服务描述层，服务提供者就可以用建立和发行WSDL文档的方法来描述他们的Web服务。WSDL文档中不仅包含有该Web服务的抽象定义，而且也包含有实现(绑定)该Web服务的细节。这意味着服务的消费者(即例子中

31、的客户应用程序)需要得到WSDL文档，它不仅可以从这个文档中得到包括Web服务的消息和数据类型的不同操作，而且还能够重新得到该Web服务的终端(例如URL)，SOAP消息可以在终端上交换。如果J2EE服务是通过SMTP消息展示功能的，那么WSDL文档也会描述这一点。图34、J2EE使用UDDI、WSDL和SOAP三种技术的工作过程在图4中假设服务提供者已经决定把某项商业功能展示成Web服务。该Web服务驻留在一个基于Java的Web服务系统中。通过图中的顺序步骤看一下整个的工作机制。图41）服务提供者的第一步是编写WSDL文件。当前市场上有好几种工具，可以帮助我们用现有的对象定义产生出WSDL

32、文件。然后，需要发布关于它自己的信息，把商业和这项Web服务的技术规范作为-个WSDL文件发布到中心UDDL注册表。这样，用写WSDL文件的方法使得Web服务的描述占据了服务描述层。但是，在Web服务栈中我们看到，发布的商业信息和WSDL文件表现的是Web服务栈中的服务发布层。2）服务消费者应用程序可以发现它有兴趣使用的Web服务。发现不仅涉及到要 HYPERLINK /Search.asp 搜索商业和它的服务，而且还要下载WSDL文件中所提到的技术规范。发现的步骤对应于Web服务栈中的服务发现层。3）最后，服务消费者应用程序用WSDL文件来确定，为了与服务提供者的Web服务通信，需要传送哪些

33、消息，并且它还要决定绑定信息。为了达到这个目的，绑定信息就是HTTP上的SOAP。这个步骤对应于Web服务栈中的 HYPERLINK /webemp/XML/Index.html XML消息和传输层。 二、 HYPERLINK /keywords/j2ee.html t _blank J2EE的基本Web服务体系结构下图5是对J2EE系统的Web服务体系结构整体描述。图5商业功能性上图是一个Web服务提供者展示他们Web服务的功能。重要的是要理解，商业机构不会选择他们现有的基于J2EE应用程序，并把他们的EJB展示为Web服务的。虽然用Web服务平台或目前市场上出售的工具在技术上是可行的，但是

34、在商业上这样做是没有现实意义，因为商业不在组件中展示方法调用。在商业上他们展示的是商业功能，这些功能会转换成一系列执行该商业功能所需要的协调动作。在即时返回服务消费者的响应中可能有也可能没有结果，还可能需要几天的时间才能完成。商业也需要通过多层 HYPERLINK /program/ 开发系统的功能性，需要记住几个安全性等级和由不同的内部应用程序使用。例如，假设有一个在因特网上售书的商业机构G，比方说，他们决定在因特网上把一项在线订书服务展示为Web服务。当顾客下订单的时候，订单信息在商业企业G内部启动了一个交易过程。这个交易过程需要执行多项行动，例如，检查图书订单的总量或执行一个财务事务处理

35、过程。这涉及到顾客把钱划到商业G账上，最后，给运输部门送一份消息，让他们把书送给顾客。从图5中的J2EE系统功能图可以看出，这个交易过程可能需要与各种EJB发生交互作用，而这反过来又与企业信息系统或跨机构的 HYPERLINK /db/Index.html 数据库产生交互作用。在所有这些交易过程中，交易的完整性以及顾客想从认真企业级的交易过程中得到的任何其他标准都需要保存起来。Web服务系统Web服务系统类似于J2EE中的容器(container)的概念。它给执行Web服务提供了一个运行时间环境。为了进行讨论的目的，完全可以说在较高的级别上Web服务系统会包含一个Web服务运行时间环境，该运行

36、时间环境能接受 HYPERLINK /keywords/soap.html t _blank SOAP请求并把它们映射到对应的 HYPERLINK /keywords/java.html t _blank Java组件，即在商业功能性中共享的Java类或EJB。同时，从该商业过程中收集的所有结果都是可靠的，并被封装在SOAP响应中，送回Web服务的客户机。Web服务器Web服务器是从Web服务客户机发出SOAP请求到服务提供者收到这个请求的过程中最主要的网关。Web服务器通过HTTP协议进行通信，通常在端口80收听。因为SOAP消息需要在HTFP上传输，所以它很适合进入我们的 HYPERLIN

37、K /keywords/xml.html t _blank HYPERLINK /webemp/XML/Index.html XML消息层和传输层。我们在图5上应当注意到的一件重要事情是，事实上WSDL文件是存放在Web服务器上的，因为这样它给服务的消费者提供了全球性的可访问机制，使他们能查阅WSDL技术规范。因此，如果我们提供了一个在UDDI注册表作为URL引用的WSDL文件的话，服务消费者就可以很容易地通过URL找到该WSDL，并对它进行转换，以确定该机构支持的服务和服务的终端。Web服务器还在整个系统中执行另外一种重要功能。这种功能会把适当的SOAP请求转送到Web服务系统去。Web服务

38、客户机Web服务客户机是Web服务的消费者。由于Web服务是不确定平台的，因此用目前任何一种主流 HYPERLINK /program/ 编程语言写成的客户机都可以调用Web服务。例如，它可能是一个Java程序，一个Visual Basic程序或者一个 HYPERLINK /keywords/cpp.html t _blank HYPERLINK /program/cc/Index.html C+程序。Web服务客户机要做的第一步工作是查阅UDDI信息， HYPERLINK /Search.asp 查找能提供它感兴趣的Web服务的商业。从UDDI信息中重新得到WSDL URL引用，并从可公开访

39、问的URL下载WSDL文档。通常，URL指的就是从图5中的Web服务器。一旦得到了WSDL文件，服务消费者就有了调用该Web服务所需要的技术信息。技术信息我们指的是该Web服务中的方法。该方法需要的参数，该方法的数据类型和终端信息。可以根据WSDL文件产生SOAP客户代码，然后再把产生的SOAP客户代码嵌入到客户机巾，以便调用该Web服务。进入论坛讨论： HYPERLINK /bbs/ t _blank J2EE的Web服务原理和体系结构慨述Web 服务概念性体系结构（Web Services Conceptual Architecture）WSCA 1.0 第 1 部分 Heather Kr

40、eger, , IBM Software Group 2001 年 5 月 01 日 本文从组件、交互以及应用程序开发模式的观点描述了 Web 服务的体系结构。该体系结构是 IBM 实例化 Web 服务方法的蓝图。它是构建和部署 Web 服务应用程序的框架。本文中提到的体系结构包括对 Web 服务需要的组件和功能的高级描述，以及对实现这些组件和功能的工具和中间件的要求。现在，诸如 IBM XML and Web Service Development Environment、IBM Web Service Toolkit 以及 IBM WebSphere Application Server

41、之类的产品中已经有了一些功能。将来这些产品以及其它产品会实现另外的功能。但是，组件、功能或要求在本文中出现并不保证会在未来的 IBM 产品中实现。 目标读者 Web 服务的早期采用者和实现者。 IBM 公司以外的评估 IBM Web 服务方法的技术评论家。 Web 服务概览 这一部分对 Web 服务作为一种应用集成技术加以简要评论，定义 web 服务一词并描述 Web 服务模型。 Web 服务：电子商务的新天地 Web 是为了程序到用户的交互，而 Web 服务是为程序到程序的交互做准备。Web 服务使公司可以降低进行电子商务的成本、更快的部署解决方案以及开拓新机遇。达到这个新天地的关键在于通用

42、的程序到程序通信模型，该模型应建立在现有的和新兴的标准之上，例如，HTTP、可扩展标记语言（Extensible Markup Language，XML）、简单对象访问协议（Simple Object Access Protocol，SOAP）、Web 服务描述语言（Web Service Description Language，WSDL）以及通用描述、发现和集成（Universal Description Discovery and Integration，UDDI）。 Web 服务使应用程序的集成比以前更快、更容易而且更便宜。集成在协议栈中较高层发生，它基于更注重服务语义而不那么注重网络

43、协议语义的消息，从而实现了业务功能的松散集成。这些特性对于在企业之间和企业内部通过 Web 连接业务功能是非常理想的。它们提供一种一致化编程模型，从而在企业内外都可以利用通用的基础设施并以一种通用的方法进行应用程序集成。利用现有的语言和平台以及旧应用程序，可以以一种增量的方式来集成和应用 Web 服务。此外，Web 服务遵循 Java 2 平台，企业版（Java 2 Platform，Enterprise Edition，J2EE）、通用对象请求代理体系结构（Common Object Request Broker Architecture，CORBA）以及其它针对与耦合较紧的分布式或非分布式

44、应用程序集成的标准。Web 服务是部署并提供通过 Web 访问业务功能的技术；J2EE、CORBA 和其它标准是实现 Web 服务的技术。 尽管 Web 服务早先是类似对等的并且是专用的，但它仍能解决程序到程序通信的整个问题，包括描述、发布和查找接口。而且，随着 Web 服务的使用越来越多以及行业的成熟，将会有更多的应用程序集成的动态模型发展起来。最终，通过 Web 服务进行系统集成将会在运行时动态发生。即时集成将宣布通过因特网进行企业到企业集成的新纪元的到来。 Web 服务的定义 Web 服务是描述一些操作（利用标准化的 XML 消息传递机制可以通过网络访问这些操作）的接口。Web 服务是用

45、标准的、规范的 XML 概念描述的，称为 Web 服务的服务描述。这一描述囊括了与服务交互需要的全部细节，包括消息格式（详细描述操作）、传输协议和位置。该接口隐藏了实现服务的细节，允许独立于实现服务基于的硬件或软件平台和编写服务所用的编程语言使用服务。这允许并支持基于 Web 服务的应用程序成为松散耦合、面向组件和跨技术实现。Web 服务履行一项特定的任务或一组任务。Web 服务可以单独或同其它 Web 服务一起用于实现复杂的聚集或商业交易。 Web 服务模型 Web 服务体系结构基于三种角色（服务提供者、服务注册中心和服务请求者）之间的交互。交互涉及发布、查找和绑定操作。这些角色和操作一起作

46、用于 Web 服务构件：Web 服务软件模块及其描述。在典型情况下，服务提供者托管可通过网络访问的软件模块（Web 服务的一个实现）。服务提供者定义 Web 服务的服务描述并把它发布到服务请求者或服务注册中心。服务请求者使用查找操作来从本地或服务注册中心检索服务描述，然后使用服务描述与服务提供者进行绑定并调用 Web 服务实现或同它交互。服务提供者和服务请求者角色是逻辑结构，因而服务可以表现两种特性。图 1 图示了这些操作、提供这些操作的组件及它们之间的交互。 图 1. Web 服务角色、操作和构件 Web 服务体系结构中的角色 服务提供者。从企业的角度看，这是服务的所有者。从体系结构的角度看

47、，这是托管访问服务的平台。 服务请求者。从企业的角度看，这是要求满足特定功能的企业。从体系结构的角度看，这是寻找并调用服务，或启动与服务的交互的应用程序。服务请求者角色可以由浏览器来担当，由人或无用户界面的程序（例如，另外一个 Web 服务）来控制它。 服务注册中心。这是可搜索的服务描述注册中心，服务提供者在此发布他们的服务描述。在静态绑定开发或动态绑定执行期间，服务请求者查找服务并获得服务的绑定信息（在服务描述中）。对于静态绑定的服务请求者，服务注册中心是体系结构中的可选角色，因为服务提供者可以把描述直接发送给服务请求者。同样，服务请求者可以从服务注册中心以外的其它来源得到服务描述，例如本地

48、文件、FTP 站点、Web 站点、广告和服务发现（Advertisement and Discovery of Services，ADS）或发现 Web 服务（Discovery of Web Services，DISCO）。 Web 服务体系结构中的操作 对于利用 Web 服务的应用程序，必须发生以下三个行为：发布服务描述、查询或查找服务描述以及根据服务描述绑定或调用服务。这些行为可以单次或反复出现。这些操作具体为： 发布。为了使服务可访问，需要发布服务描述以使服务请求者可以查找它。发布服务描述的位置可以根据应用程序的要求而变化（请参阅“服务发布”以了解更多细节）。 查找。在查找操作中，服务

49、请求者直接检索服务描述或在服务注册中心中查询所要求的服务类型（请参阅“服务发现”以了解更多细节）。对于服务请求者，可能会在两个不同的生命周期阶段中牵涉到查找操作：在设计时为了程序开发而检索服务的接口描述，而在运行时为了调用而检索服务的绑定和位置描述。 绑定。最后需要调用服务。在绑定操作中，服务请求者使用服务描述中的绑定细节来定位、联系和调用服务，从而在运行时调用或启动与服务的交互。 Web 服务的构件 服务。在这里，Web 服务是一个由服务描述来描述的接口，服务描述的实现就是该服务。服务是一个软件模块，它部署在由服务提供者提供的可以通过网络访问的平台上。服务存在就是要被服务请求者调用或者同服务

50、请求者交互。当服务的实现中利用到其它 的Web 服务时，它也可以作为请求者。 服务描述。服务描述包含服务的接口和实现的细节。其中包括服务的数据类型、操作、绑定信息和网络位置。还可能包括可以方便服务请求者发现和利用的分类及其它元数据。服务描述可以被发布给服务请求者或服务注册中心。 Web 服务体系结构解释了如何实例化元素和如何以一种可以互操作的方式实现这些操作。 Web 服务开发生命周期 Web 服务开发生命周期包括了设计和部署以及在运行时对服务注册中心、服务提供者和服务请求者每一个角色的要求。每个角色对开发生命周期的每一元素都有特定要求。服务注册中心的开发和部署不在本文的范围以内。 开发生命周

51、期有以下四个阶段： 1. 构建 生命周期的构建阶段包括开发和测试 Web 服务实现、定义服务接口描述和定义服务实现描述。可以通过创建新的 Web 服务、把现有的应用程序变成 Web 服务和由其它 Web 服务和应用程序组成新的 Web 服务提供 Web 服务的实现。 2. 部署 部署阶段包括向服务请求者或服务注册中心发布服务接口和服务实现的定义，以及把 Web 服务的可执行文件部署到执行环境（典型情况下，Web 应用程序服务器）中。 3. 运行 在运行阶段，可以调用 Web 服务。在此，Web 服务完全部署、可操作并且服务提供者可以通过网络访问服务。现在服务请求者可以进行查找和绑定操作。 4.

52、 管理 管理阶段包括持续的管理和经营 Web 服务应用程序。安全性、可用性、性能、服务质量和业务流程问题都必须被解决。 体系结构概览 我们可以在几个层中讨论 IBM Web 服务。首先，我们将看看 Web 服务的一个概念性协议栈以及这个协议栈的细节。然后我们将讨论选择网络协议的标准。我们还将回顾一下基本的基于 XML 的消息传递分布式计算。我们将用服务描述扩展基本的 XML 消息传递，而服务描述是根据它的协议栈来解释的。接下来，我们将讨论服务描述在 Web 服务体系结构中的角色，说明支持静态和动态 Web 服务应用程序的服务发布技术的范围。我们还将围绕服务发布讨论服务发现的角色。最后，我们将描

53、述基本 Web 服务体系结构的扩展，电子商务需要这些扩展才能使用 Web 服务。 Web 服务协议栈 要以一种可互操作的方式执行发布、发现和绑定这三个操作，必须有一个包含每一层标准的 Web 服务协议栈。图 2 展示了一个概念性 Web 服务协议栈。上面的几层建立在下面几层提供的功能之上。垂直的条表示在协议栈中每一层必须满足的需求。左面的文本表示协议栈的那一层所应用的标准技术。 概念性 Web 服务协议栈 图2. Web 服务概念性协议栈 Web 服务协议栈的基础是网络层。Web 服务要被服务请求者调用，就必须是可以通过网络访问的。因特网上可以公用的 Web 服务使用普遍部署的网络协议。HTT

54、P 凭借其普遍性，成为了因特网可用的 Web 服务真正的标准网络协议。Web 服务还可以支持其它因特网协议，包括 SMTP 和 FTP。内部网域可以使用可靠消息传递和调用基础结构，如 MQSeries 和 CORBA 等等。本文的“网络层”部分将更详细地描述这个层。 下一层是基于 XML 的消息传递，它表示使用 XML 作为消息传递协议的基础。选择 SOAP 作为 XML 消息传递协议有很多原因： 它是使用 XML 传送以文档为中心的消息以及远程过程调用的标准化封装机制。 SOAP 很简单；它基本上是一个用 XML 信封作为有效负载的 HTTP POST。 SOAP 比对 XML 简单的 HT

55、TP POST 更受青睐，因为它定义了一个标准机制，这个机制将正交扩展（orthogonal extension）合并为使用 SOAP 报头和对操作或函数进行标准编码的消息。 SOAP 消息支持 Web 服务体系结构中的发布、查找和绑定操作。“基于 XML 消息传递的分布式计算”部分将更详细地描述这一层。 服务描述层实际上是描述文档的一个协议栈。首先，WSDL 是基于 XML 的服务描述的真正标准。这是支持可互操作的 Web 服务所需的最小标准服务描述。WSDL 定义了服务交互的接口和结构。要指定业务环境、服务质量和服务之间的关系，我们还需要另外的描述。WSDL 文档可以由其它服务描述文档来补

56、充，从而描述 Web 服务的这些更高级的方面。例如，描述业务环境除了使用 WSDL 文档，还要使用 UDDI 数据结构。Web 服务流程语言（Web Services Flow Language，WSFL）文档中则描述了服务组成和流程。“服务描述：从 XML 消息传递到 Web 服务”部分更详细地描述了这一层。 因为 Web 服务被定义为可以通过 SOAP 从网络进行访问，并由服务描述表示，所以该协议栈中的前三层需要提供或使用 Web 服务。最简单的协议栈将包括网络层的 HTTP、XML 消息传递层的 SOAP 协议以及服务描述层的 WSDL。所有企业间或公用 Web 服务都应该支持这种可互操

57、作的基础协议栈。Web 服务，特别是企业内部或专用 Web 服务，能够支持其它的网络协议和分布式计算技术。图 3 描述了可互操作的基础协议栈。 图 3. 可互操作的基础 Web 服务协议栈 图 3 中描述的协议栈提供了互操作性，它使 Web 服务能够利用现有的因特网基础结构。这将使进入普遍存在的环境的成本非常低。灵活性并不会因为互操作性需求而有所降低，因为我们可以为选择性和增值的技术提供另外的支持。例如，我们必须支持 HTTP 上的 SOAP，但也可以同时支持 MQ 上的 SOAP。 协议栈的最下面三层确立了保证一致性和互操作性的技术，而它们上面的两层，即服务发布和服务发现，可以用多种解决方案

58、来实现。 任何能够让服务请求者使用 WSDL 文档的操作，不管它处于服务请求者生命周期的哪个阶段，都符合服务发布的标准。该层中最简单、最静态的示例就是服务提供者直接向服务请求者发送 WSDL 文档。这被称为直接发布。电子邮件是直接发布的载体之一。直接发布对静态绑定的应用程序来说很有用。另外，服务提供者还可以将描述服务的文档发布到主机本地 WSDL 注册中心、专用 UDDI 注册中心或 UDDI 运营商节点。我们将在“服务发布”部分更详细地讨论各种不同的服务发布机制。 因为 Web 服务如果没有被发布就不能被发现，所以说服务发现依赖于服务发布。该层的各种发现机制和一组发布机制互相平行。任何允许服

59、务请求者获得对服务描述的访问权，并在运行时使应用程序能够使用该服务描述的机制都符合服务发现的标准。最简单、最静态的发现的示例是静态发现，其中服务请求者从本地文件获取 WSDL 文档。这通常都是通过直接发布获取的 WSDL 文档，或者前面查找操作的结果。另外，也可以通过使用本地 WSDL 注册中心、专用 UDDI 注册中心或 UDDI 运营商节点在设计时或运行时发现服务。我们将在“服务发现”部分更详细地讨论各种不同的服务发现机制。因为 Web 服务实现是一种软件模块，所以通过组建 Web 服务来产生 Web 服务是很自然的。Web 服务的组合可以扮演很多角色之一。企业内部的 Web 服务可能会相

60、互合作，从而对外显示出一个单独的 Web 服务接口，或者，来自不同企业的 Web 服务可以相互合作，从而执行机器到机器、企业到企业的事务。另外，工作流程管理者还可以在参与业务流程的时侯调用每个 Web 服务。最上面一层，即服务流程，描述了如何执行服务到服务的通讯、合作以及流程。WSFL 用于描述这些交互。Web 服务这个主题在它自己那一部分，即“业务流程、工作流程和 Web 服务”中有所描述。 要使 Web 服务应用程序满足当今电子商务的迫切需求，就必须提供企业级基础结构，包括安全性、管理和服务质量。这几个垂直条在协议栈的每一层都必须得到解决。每一层的解决方案可以彼此独立。随着 Web 服务范