• 用户交互：实现应用用户界面统一的接入与安全机制，利用门户技术进行构建。
• 应用连接：通过 HUB 或总线架构，实现应用与应用之间的连接，完成相关的数据路由与数据格式转换。
• 业务流程整合：实现业务流程管理，包括工作流管理和自动化流程两个方面。
• 构建整合：这个层面包含两个部分，一部分是构建与现有应用兼容的新应用，另一部分是对现有资源进行重用以适应新环境的需要。
• 信息集成：实现数据集成，在异构的数据源之间实现数据层的直接整合。

EAI(Enterprise Application Integration)，顾名思义是企业应用集成。但是企业应用集成解决什么问题？企业在建设EAI时需要注意什么？

EAI的发展经历了从不完善到逐渐完善的坎坷历程，但是不同的EAI技术给企业选择带来了迷惑，所以我们从EAI产生的背景开始，回顾EAI技术的发展过程，展望EAI技术未来的发展，帮助我们认识EAI技术本身，进而探讨EAI的层次和对EAI技术的选择，并有效指导EAI项目实施
1>  EAI产生的背景

据IDC统计，在过去的10年中，全球企业在信息系统上一共投资18万亿美元。巨大的投资为企业建立了众多信息系统，以帮助企业进行内外部业务的处理和管理工作。现代企业在IT系统的帮助下不断提升自身发展，同时也越来越依赖于IT系统，造成了“IT就是企业，企业就是IT” [1] 的现状，IT系统的复杂化、更新缓慢严重制约了企业业务的发展。

根据META Group的统计，经过相当一个时期不断的IT系统建设，一家典型的大型企业平均拥有49个应用系统，33%的IT预算是花在传统的集成上，通过零星的“点对点”连接，使众多的“信息孤岛”联系起来，以便让不同的系统之间交换信息。这使得企业的应用系统看起来像下图一样，构成了一张复杂的蛛网。

孤立的信息系统无法有效地提供跨部门、跨系统的综合性的信息，诸如：某个主要的订单的状况怎样？谁是我的最重要的客户？这个季度的任务能否完成？等等。

孤立的信息系统也无法实现实时的信息存取和对业务流程的透视，无法实现对客户、供应商、项目、订单、资产等的全面掌控，无法实现企业价值链的全面的、彻底的透视和控制。

于是，企业对应用整合的需求应运而生。具体来说，主要的内、外在的驱动力如下：

Ø         Web-based & Packaged应用系统的流行，如SAP，Intranet

Ø         追求效率和控制成本

Ø         兼并和收购

Ø         技术的不断创新

Ø         XML技术的兴起

根据《CIO Magazine》在2002年的对大企业CIO的调查，在这些主管企业信息化人士所关心的问题中，如何将众多的企业应用系统集成起来，是他们最为关注的热点。如下图所示：

20世纪50年代末到60年代初，企业具备了早期应用。这些应用大多是用来替代重复性劳动的一些简单设计。这时的应用范围为账户支付、工资单管理等类似的内容。当时并没有考虑到企业数据的集成，企业应用惟一的目标就是用计算机代替一些孤立的、体力性质的工作环节。

20世纪60年代中期，继第一代应用之后，更深入辅助企业生产的应用出现，诸如库存管理、生产控制和早期的财务管理等。这些应用远比第一代的企业应用复杂，但这些应用的思想还仅仅是支持企业业务的一部分，并且企业数据的访问控制技术还不完善，仍然没有企业数据集成的概念。

20世纪60年代末到70年代初，数据库的技术开始出现，对企业数据的检索不再是贯穿文件的操作。磁盘存储和数据库技术使企业能够直接访问数据，这让企业应用上升到了一个全新的阶段——在线联机处理应用。在线联机处理把计算机变成了一个在企业中前所未有的完全革新的角色，计算机应用不再是一个后台的、无足轻重的应用，它现在是企业中前台的、中心位置的角色。这些在线联机应用是根据局部需求开发的，在不同的部门或企业间开始出现早期电子数据交换(EDI)，即企业数据集成的概念开始出现。但这些数据集成还仅仅是小范围的小火花，距离企业应用集成还很遥远。

进入到20世纪80年代，好像所有的企业应用都不能满足企业新的需求。但是企业并没有能力开发新功能，因为IT人员绝大多数的精力都花在对已有系统的维护上。最初这些维护的工作事实上是对应用系统的集成工作，这是一个巨大挑战，很多公司的技术人员都试图在企业系统整体概念的指导下对已经存在的应用进行重新设计，以便让它们集成在一起。然而这种努力收效甚微。于是维护变成为对已有系统添加补丁，以使其具备最初时并未设计的功能。

传统的企业由于缺少不同系统相互集成的技术，导致很多关键的信息被封闭在相互独立的系统中，部门间重复着冗余的工作，这直接导致了企业工作效率的降低和运营成本的上升。

80年代中期，C/S结构的应用开始出现。用于处理C/S结构下联机事务处理的中间件(TUXEDO)出现。企业应用集成软件本身就是一种中间件的技术，当中间件技术出现，企业应用集成具备了发展的可能——思想上的基础。

这段时间诞生了信息总线软件，信息总线软件提供了企业应用集成最基础的内容——信息交换。这一层次的EAI的系统集成框架，主要解决的是企业内部应用系统间的信息共享的问题。解决方案的构建的出发点是整体考虑企业应用系统IT建设，统一建设信息交换基础，消除了点对点集成企业应用的混乱局面。

90年代，ERP应用开始流行的时候，同时也要求它们能够支持已经存在的应用和数据，这就必须引入EAI。对EAI的需求首先来自与企业将它们的主机系统转换成C/S结构系统的过程中，其次是利用ERP建立企业骨干信息系统。企业迫切需要一种方法，让它们少写程序，无须巨大的费用，就可以将各种旧的应用系统和新的系统集成起来。其他推动EAI市场的因素还有供应链管理(B2B集成)、基于流程的业务处理以及Web应用集成。

随着企业各种应用的迅速增加以及更多地把自己的业务转向电子商务，EAI方案对企业的重要性也日益显现。越来越多的企业开始采用EAI解决方案将企业内部的应用软件与外部客户和供应商的应用软件进行链接，实现数据流和业务运作的自动化，从而达到业务的实时与快速。

EAI与电子商务的结合为企业快速实现业务的自动化提供了可靠的保证，呈现在我们面前的将是一个同时具有数据自动化和业务流程高度可塑的企业管理框架，从而进一步加快端到端的电子商务应用集成，包括供应链管理、客户关系管理和ERP系统相关联的门户网站、前端应用、后端应用等。

企业对EAI需求的增长，给软件行业提供了发展的空间。90年代诞生了大量的EAI产品和供应商。其中比较有代表的包括Vitria、webMethods等，他们在EAI的发展过程中积极思考，完善EAI的理论领域并在实践上做出了积极的探索。

90年代初，CORBA作为开放的分布式应用组件技术诞生，催生了一批中间件。但是，由于CORBA并没有很严格的约束，开放的理想并没有完全实现：每个不同的CORBA实现之间不能良好兼容。CORBA在一些缺乏其他技术有力支持的领域得到了发展，具备了相当数量的应用。但是CORBA并没能参与到企业应用集成的发展。

90年代中后期到现在，Java技术和J2EE的诞生，发动了软件行业新一波的发展。基于J2EE的中间件技术(应用服务器)在吸取传统的私有中间件的经验和CORBA的教训的基础上，定义了宽严适度的规范，诞生了一批J2EE应用服务器。基于J2EE的JCA成为了EAI范畴的第一个正式的规范，用于解决应用与应用的互相访问，结束了EAI领域没有开放标准的历史。

当前EAI的主流技术在向以成熟的应用服务器技术为基础发展，J2EE

从技术上看，基于成熟应用服务器的EAI可以为企业提供以下好处：

Ø       可靠性：提供一个坚固的系统运行环境，具有强大的故障恢复能力、系统重新启动和恢复能力、数据可靠传输能力等。

Ø       可扩展性：提供动态部署能力，涉及交易方式、应用程序配置、对象服务嵌入等。

Ø       可管理性：系统要实现有效的管理，管理内容包括应用服务器、操作系统进程和线程、数据库连接，以及网络会话等。

Ø       数据一致性：交易完整性保障。

Ø       应用安全性：包括最终用户身份认证、节点连接的安全认证、应用程序的安全认证、管理界面的访问权限控制、数据加密／解密功能、安全事件报警等。

从业务上看，EAI可以为企业提供以下好处：

Ø       EAI可以通过使企业提高业务流程效率、快速响应客户需求、改善客户服务、增加对客户的了解、强化客户忠诚度来改善客户关系、增加市场份额，从而增加收入。

Ø       EAI可以通过使企业增加管理层对业务的可视性和全面监控、减少IT开销、降低运营成本和重复性消耗、降低销售和售后服务成本来起到降低各种成本的作用。

XML、J2EE、Web Service和BPEL相继走上EAI的舞台。沿着EAI发展的轨迹，我们看到EAI是从私有走向开放，从单一走向融合，不断完善的开放标准必然成为EAI的主角。

IDC认为，EAI服务市场将会是未来3～5年内IT行业中增长最快的部分。根据IDC的调查，“这个市场上全球的营业收入会从2000年的50亿美元上升到2005年的210亿美元，这意味着综合年增长率(CAGR)超过了30%。与此相对应，整个IT服务产业的同期综合年增长率预计为11%。”

事实上，企业运作效率越来越依赖于各部门、各类不同应用的协同，而不是单一部门、单一应用的水平。在这种情况下，20世纪90年代后期，EAI市场逐步形成。先期采用EAI技术的主要是一些大型企业，它们通过更好的应用集成极大地增加了每个单一应用系统的价值。

专业的EAI厂商不会再使用自己的专有技术，而是从一些基于开放标准的EAI工具中选择最适合于当前客户的一种。它们在应用集成方面的知识积累以及与应用软件厂商的良好协作将使它们的EAI解决方案更加经济、更加可靠、更加有能力适应客户不断变化的集成需求。

传统的EAI并不能够满足企业最根本的需要——快速构建IT系统以支撑企业业务的发展。当今的企业级分布式IT系统都在向共享服务方向发展，企业对传统EAI的需求仅限于将已经构建但并不支持服务共享的IT系统变成能够共享服务的IT系统，但是这一过程不应以放弃与未来的新应用共享服务为代价。

APS是什么？APS的目的是集成已有系统的同时，通过企业级的分布式体系达成新旧系统间的服务共享。并且对于企业来讲，IT应用不应是垂直独立的，而应是融合贯通并在全企业范围形成大的结构化体系，即企业有统一的业务核心服务层提供企业资源的访问，并通过统一的访问与安全平台提供给所有企业内部员工和外部合作伙伴以恰当的访问。

我们可以看到，如果今天企业还仅仅看到传统的EAI，明天还需要不断地EAI，而APS的方向帮我们构建一个完善的基础架构，在提供今天集成的能力的同时帮助我们完成明天IT的融合。

文档目的

本指南描述了用于改进信息技术 (IT) 基础结构中 Microsoft® Active Directory® 目录服务管理的过程和步骤。

面向对象

本材料将有助于规划部署该产品至现有的 IT 基础结构，尤其是基于 IT 基础结构库 (ITIL)（一整套 IT 服务管理的最佳做法）和微软操作框架 (MOF) 的部署。本材料主要针对于两个主要组：IT 经理和 IT 支持职员（包括分析和服务台专家）。

使用本指南

本指南分为五个章节。第一章提供了基本的背景信息。第二章提供了维护本产品所需要的高级过程表。第三章对维护章节中所描述的过程进行了详细研究，并使其与构成每个过程的步骤和任务相对应。第四章依据每个过程的角色对过程进行了组织。第五章包含了提供步骤详细信息的附录，其中包括需求和步骤。

本指南可作为单独的一卷进行阅读，包括详细的维护和疑难解答部分。这种阅读方式可提供必要的上下文，如此可更容易理解本文档之后的材料。不过，某些读者愿意将此文档作为参考材料，仅在需要时用于查找信息。

背景

本指南基于 Microsoft Solutions for Management (MSM)。MSM 提供了最佳做法、最佳实施服务以及最佳自动化操作，所有这些均有助于客户实现操作的卓越表现，高质量服务、行业可靠性、可用性、安全性以及较低的总拥有成本 (TCO) 可证明这一切。

这些 MSM 最佳做法均基于以 ITIL 为中心的结构化、而又灵活的 MOF 方法。MOF 包括如何规划、部署和维护 IT 操作过程的指导，以便支持关键的服务解决方案。

MOF 中心（为了理解本指南的结构）是 MOF 过程和小组模型。过程模型及其根本的服务管理功能 (SMF) 是基于过程的方法的基础，该方法是维护本产品的指南建议。组队模型及其角色群为确保将正确的人员分配至操作角色提供了指导。

图 1 显示了与构成过程模型每个象限的 SMF 相结合的 MOF 过程模型。

点击放大

图 2 显示了该 MOF 组队模型以及可能存在于服务管理组织中的很多功能角色或功能小组。这些角色和功能小组均显示为其所属的 MOF 角色群的映射。

点击放大

该 MOF 组队模型建立在六个质量目标上，表 1 对其进行了描述并与适用的小组角色群相匹配。

表 1 MOF 组队模型质量目标和角色群

参与人员

程序经理
Jeff Yuhas，Microsoft Corporation

Chris Macaulay，Microsoft Corporation

主要参与人员
Nigel Cain，Microsoft Corporation

Arren Conner，Microsoft Corporation

Dmitry Dukat，Microsoft Corporation

Levon Esibov，Microsoft Corporation

Khushru Irani，Microsoft Corporation

Kamal Janardhan，Microsoft Corporation

Gregory Johnson，Microsoft Corporation

William Lees，Microsoft Corporation

Andreas Luther，Microsoft Corporation

Kevin Sims，Microsoft Corporation

Jeromy Statia，Microsoft Corporation

测试经理
Greg Gicewicz，Microsoft Corporation

QA 经理
Jim Ptaszynski，Microsoft Corporation

首席技术作者
Jerry Dyer，Microsoft Corporation

首席技术编辑
Laurie Dunham，Microsoft Corporation

技术编辑
Patricia Rytkonen，Volt Technical Services

产品编辑
Kevin Klein，Volt Technical Services

文档所包含的信息代表了在发布之日，Microsoft Corporation 对所讨论问题的当前看法。因为 Microsoft 必须顺应不断变化的市场条件，故不应将本文档理解为 Microsoft 一方的承诺，Microsoft 不保证所给出的信息在发布之日以后的准确性。

本文档仅用于提供信息。Microsoft 对本文档中的信息不做任何明示、默示或法定的担保。

遵守所有适用的版权法律是用户的责任。在不对版权法所规定的权利加以限制的情况下，未得到 Microsoft 公司明确的书面许可，不得为任何目的、以任何形式或手段（电子的、机械的、影印、录制等等）复制、传播本文的任何部分，也不得将其存储或引入到检索系统中。

本文档可能涉及 Microsoft 的专利、专利申请、商标、版权和其它知识产权。除非 Microsoft 通过书面许可协议明确提供，此文档并没有授予您对这些专利，商标，版权或其他知识产权的任何许可。

除非特别说明，此处所述作为范例的公司、组织、产品、域名、e-mail 地址、徽标、人员、地点和事件均为虚构，不与任何真实的公司、单位、产品、域名、e-mail 地址、徽标、人员、地点和事件有联系，也不应从中做任何此类联系方面的推断。

© 2003 Microsoft Corporation 版权所有。保留所有权利。

Microsoft、Active Directory、Windows、Windows NT 和 Windows Server 是 Microsoft Corporation 在美国和/或其他国家（地区）的注册商标或商标。

此处所涉及的真实的公司和产品名称可能是其各自所有者的商标。

第 2 章 — 维护 Active Directory 的高级过程

第 3 章 — 详细的维护操作

第 4 章 — MOF 角色群的过程

第 5 章 — 附录

Web 服务概念性体系结构（Web Services Conceptual Architecture）

WSCA 1.0 第 1 部分

Heather Kreger, , 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 之类的产品中已经有了一些功能。将来这些产品以及其它产品会实现另外的功能。但是，组件、功能或要求在本文中出现并不保证会在未来的 IBM 产品中实现。

目标读者

Web 服务的早期采用者和实现者。

IBM 公司以外的评估 IBM Web 服务方法的技术评论家。

Web 服务概览

这一部分对 Web 服务作为一种应用集成技术加以简要评论，定义 web 服务一词并描述 Web 服务模型。

Web 服务：电子商务的新天地

Web 是为了程序到用户的交互，而 Web 服务是为程序到程序的交互做准备。Web 服务使公司可以降低进行电子商务的成本、更快的部署解决方案以及开拓新机遇。达到这个新天地的关键在于通用的程序到程序通信模型，该模型应建立在现有的和新兴的标准之上，例如，HTTP、可扩展标记语言（Extensible Markup Language，XML）、简单对象访问协议（Simple Object Access Protocol，SOAP）、Web 服务描述语言（Web Service Description Language，WSDL）以及通用描述、发现和集成（Universal Description Discovery and Integration，UDDI）。

Web 服务使应用程序的集成比以前更快、更容易而且更便宜。集成在协议栈中较高层发生，它基于更注重服务语义而不那么注重网络协议语义的消息，从而实现了业务功能的松散集成。这些特性对于在企业之间和企业内部通过 Web 连接业务功能是非常理想的。它们提供一种一致化编程模型，从而在企业内外都可以利用通用的基础设施并以一种通用的方法进行应用程序集成。利用现有的语言和平台以及旧应用程序，可以以一种增量的方式来集成和应用 Web 服务。此外，Web 服务遵循 Java 2 平台，企业版（Java 2 Platform，Enterprise Edition，J2EE）、通用对象请求代理体系结构（Common Object Request Broker Architecture，CORBA）以及其它针对与耦合较紧的分布式或非分布式应用程序集成的标准。Web 服务是部署并提供通过 Web 访问业务功能的技术；J2EE、CORBA 和其它标准是实现 Web 服务的技术。

尽管 Web 服务早先是类似对等的并且是专用的，但它仍能解决程序到程序通信的整个问题，包括描述、发布和查找接口。而且，随着 Web 服务的使用越来越多以及行业的成熟，将会有更多的应用程序集成的动态模型发展起来。最终，通过 Web 服务进行系统集成将会在运行时动态发生。即时集成将宣布通过因特网进行企业到企业集成的新纪元的到来。

Web 服务的定义

Web 服务是描述一些操作（利用标准化的 XML 消息传递机制可以通过网络访问这些操作）的接口。Web 服务是用标准的、规范的 XML 概念描述的，称为 Web 服务的服务描述。这一描述囊括了与服务交互需要的全部细节，包括消息格式（详细描述操作）、传输协议和位置。该接口隐藏了实现服务的细节，允许独立于实现服务基于的硬件或软件平台和编写服务所用的编程语言使用服务。这允许并支持基于 Web 服务的应用程序成为松散耦合、面向组件和跨技术实现。Web 服务履行一项特定的任务或一组任务。Web 服务可以单独或同其它 Web 服务一起用于实现复杂的聚集或商业交易。

Web 服务模型

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

图 1. Web 服务角色、操作和构件

Web 服务体系结构中的角色

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

Web 服务体系结构中的操作
对于利用 Web 服务的应用程序，必须发生以下三个行为：发布服务描述、查询或查找服务描述以及根据服务描述绑定或调用服务。这些行为可以单次或反复出现。这些操作具体为：

• 发布。为了使服务可访问，需要发布服务描述以使服务请求者可以查找它。发布服务描述的位置可以根据应用程序的要求而变化（请参阅“服务发布”以了解更多细节）。
• 查找。在查找操作中，服务请求者直接检索服务描述或在服务注册中心中查询所要求的服务类型（请参阅“服务发现”以了解更多细节）。对于服务请求者，可能会在两个不同的生命周期阶段中牵涉到查找操作：在设计时为了程序开发而检索服务的接口描述，而在运行时为了调用而检索服务的绑定和位置描述。
• 绑定。最后需要调用服务。在绑定操作中，服务请求者使用服务描述中的绑定细节来定位、联系和调用服务，从而在运行时调用或启动与服务的交互。

Web 服务的构件

• 服务。在这里，Web 服务是一个由服务描述来描述的接口，服务描述的实现就是该服务。服务是一个软件模块，它部署在由服务提供者提供的可以通过网络访问的平台上。服务存在就是要被服务请求者调用或者同服务请求者交互。当服务的实现中利用到其它 的Web 服务时，它也可以作为请求者。
• 服务描述。服务描述包含服务的接口和实现的细节。其中包括服务的数据类型、操作、绑定信息和网络位置。还可能包括可以方便服务请求者发现和利用的分类及其它元数据。服务描述可以被发布给服务请求者或服务注册中心。

Web 服务体系结构解释了如何实例化元素和如何以一种可以互操作的方式实现这些操作。

Web 服务开发生命周期

Web 服务开发生命周期包括了设计和部署以及在运行时对服务注册中心、服务提供者和服务请求者每一个角色的要求。每个角色对开发生命周期的每一元素都有特定要求。服务注册中心的开发和部署不在本文的范围以内。

开发生命周期有以下四个阶段：

1. 构建
生命周期的构建阶段包括开发和测试 Web 服务实现、定义服务接口描述和定义服务实现描述。可以通过创建新的 Web 服务、把现有的应用程序变成 Web 服务和由其它 Web 服务和应用程序组成新的 Web 服务提供 Web 服务的实现。

2. 部署
部署阶段包括向服务请求者或服务注册中心发布服务接口和服务实现的定义，以及把 Web 服务的可执行文件部署到执行环境（典型情况下，Web 应用程序服务器）中。

3. 运行
在运行阶段，可以调用 Web 服务。在此，Web 服务完全部署、可操作并且服务提供者可以通过网络访问服务。现在服务请求者可以进行查找和绑定操作。

4. 管理
管理阶段包括持续的管理和经营 Web 服务应用程序。安全性、可用性、性能、服务质量和业务流程问题都必须被解决。

体系结构概览

我们可以在几个层中讨论 IBM Web 服务。首先，我们将看看 Web 服务的一个概念性协议栈以及这个协议栈的细节。然后我们将讨论选择网络协议的标准。我们还将回顾一下基本的基于 XML 的消息传递分布式计算。我们将用服务描述扩展基本的 XML 消息传递，而服务描述是根据它的协议栈来解释的。接下来，我们将讨论服务描述在 Web 服务体系结构中的角色，说明支持静态和动态 Web 服务应用程序的服务发布技术的范围。我们还将围绕服务发布讨论服务发现的角色。最后，我们将描述基本 Web 服务体系结构的扩展，电子商务需要这些扩展才能使用 Web 服务。

Web 服务协议栈

要以一种可互操作的方式执行发布、发现和绑定这三个操作，必须有一个包含每一层标准的 Web 服务协议栈。图 2 展示了一个概念性 Web 服务协议栈。上面的几层建立在下面几层提供的功能之上。垂直的条表示在协议栈中每一层必须满足的需求。左面的文本表示协议栈的那一层所应用的标准技术。

概念性 Web 服务协议栈

图2. Web 服务概念性协议栈

Web 服务协议栈的基础是网络层。Web 服务要被服务请求者调用，就必须是可以通过网络访问的。因特网上可以公用的 Web 服务使用普遍部署的网络协议。HTTP 凭借其普遍性，成为了因特网可用的 Web 服务真正的标准网络协议。Web 服务还可以支持其它因特网协议，包括 SMTP 和 FTP。内部网域可以使用可靠消息传递和调用基础结构，如 MQSeries 和 CORBA 等等。本文的“网络层”部分将更详细地描述这个层。

下一层是基于 XML 的消息传递，它表示使用 XML 作为消息传递协议的基础。选择 SOAP 作为 XML 消息传递协议有很多原因：

• 它是使用 XML 传送以文档为中心的消息以及远程过程调用的标准化封装机制。
• SOAP 很简单；它基本上是一个用 XML 信封作为有效负载的 HTTP POST。
• SOAP 比对 XML 简单的 HTTP POST 更受青睐，因为它定义了一个标准机制，这个机制将正交扩展（orthogonal extension）合并为使用 SOAP 报头和对操作或函数进行标准编码的消息。
• SOAP 消息支持 Web 服务体系结构中的发布、查找和绑定操作。“基于 XML 消息传递的分布式计算”部分将更详细地描述这一层。

服务描述层实际上是描述文档的一个协议栈。首先，WSDL 是基于 XML 的服务描述的真正标准。这是支持可互操作的 Web 服务所需的最小标准服务描述。WSDL 定义了服务交互的接口和结构。要指定业务环境、服务质量和服务之间的关系，我们还需要另外的描述。WSDL 文档可以由其它服务描述文档来补充，从而描述 Web 服务的这些更高级的方面。例如，描述业务环境除了使用 WSDL 文档，还要使用 UDDI 数据结构。Web 服务流程语言（Web Services Flow Language，WSFL）文档中则描述了服务组成和流程。“服务描述：从 XML 消息传递到 Web 服务”部分更详细地描述了这一层。

因为 Web 服务被定义为可以通过 SOAP 从网络进行访问，并由服务描述表示，所以该协议栈中的前三层需要提供或使用 Web 服务。最简单的协议栈将包括网络层的 HTTP、XML 消息传递层的 SOAP 协议以及服务描述层的 WSDL。所有企业间或公用 Web 服务都应该支持这种可互操作的基础协议栈。Web 服务，特别是企业内部或专用 Web 服务，能够支持其它的网络协议和分布式计算技术。图 3 描述了可互操作的基础协议栈。

图 3. 可互操作的基础 Web 服务协议栈

图 3 中描述的协议栈提供了互操作性，它使 Web 服务能够利用现有的因特网基础结构。这将使进入普遍存在的环境的成本非常低。灵活性并不会因为互操作性需求而有所降低，因为我们可以为选择性和增值的技术提供另外的支持。例如，我们必须支持 HTTP 上的 SOAP，但也可以同时支持 MQ 上的 SOAP。

协议栈的最下面三层确立了保证一致性和互操作性的技术，而它们上面的两层，即服务发布和服务发现，可以用多种解决方案来实现。

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

因为 Web 服务如果没有被发布就不能被发现，所以说服务发现依赖于服务发布。该层的各种发现机制和一组发布机制互相平行。任何允许服务请求者获得对服务描述的访问权，并在运行时使应用程序能够使用该服务描述的机制都符合服务发现的标准。最简单、最静态的发现的示例是静态发现，其中服务请求者从本地文件获取 WSDL 文档。这通常都是通过直接发布获取的 WSDL 文档，或者前面查找操作的结果。另外，也可以通过使用本地 WSDL 注册中心、专用 UDDI 注册中心或 UDDI 运营商节点在设计时或运行时发现服务。我们将在“服务发现”部分更详细地讨论各种不同的服务发现机制。因为 Web 服务实现是一种软件模块，所以通过组建 Web 服务来产生 Web 服务是很自然的。Web 服务的组合可以扮演很多角色之一。企业内部的 Web 服务可能会相互合作，从而对外显示出一个单独的 Web 服务接口，或者，来自不同企业的 Web 服务可以相互合作，从而执行机器到机器、企业到企业的事务。另外，工作流程管理者还可以在参与业务流程的时侯调用每个 Web 服务。最上面一层，即服务流程，描述了如何执行服务到服务的通讯、合作以及流程。WSFL 用于描述这些交互。Web 服务这个主题在它自己那一部分，即“业务流程、工作流程和 Web 服务”中有所描述。

要使 Web 服务应用程序满足当今电子商务的迫切需求，就必须提供企业级基础结构，包括安全性、管理和服务质量。这几个垂直条在协议栈的每一层都必须得到解决。每一层的解决方案可以彼此独立。随着 Web 服务范例的采用和发展，将会出现更多此类垂直条。我们将在“真正电子商务的 Web 服务”部分讨论这些垂直条。

该协议栈的最下面几层表示基础 Web 服务协议栈，它们相对于协议栈中上面几层来说更成熟，也更标准。Web 服务的成熟和采用将会带动协议栈中上面几层和垂直条的开发和标准化。

网络层

Web 服务协议栈的最底层是网络层。该层可表示任意多个网络协议：HTTP、FTP、SMTP、消息排队（Message Queuing）、因特网 ORB 间协议（Internet Inter ORB Protocol，IIOP）上的远程方法调用（Remote Method Invocation，RMI）、电子邮件等等。在任何给定的情况下使用的网络协议都依赖于应用程序需求。

对于可以从因特网访问的 Web 服务，人们选择网络技术的时侯通常会倾向于选择普遍部署的协议，如 HTTP。对于内部网中提供和使用的 Web 服务，使用另外的网络技术也会被认同。我们可以根据其它需求选择网络技术，包括安全性、可用性、性能以及可靠性。这使得 Web 服务可以利用已有的功能更高级的联网基础结构和面向消息的中间件，如 MQSeries。在有多种网络基础结构的企业中，HTTP 可以用来在这些基础结构之间搭建桥梁。

Web 服务的好处之一在于，它为专用内部网和公用因特网服务的开发和使用提供了统一的编程模型。所以，网络技术的选择对服务开发者来说是透明的。

基于 XML 消息传递的分布式计算

IBM Web 服务体系结构最基础的支柱是 XML 消息传递。当前 XML 消息传递的行业标准是 SOAP。IBM、Microsoft 以及其它企业都向 W3C 建议 SOAP 作为 XML 协议工作组（XML Protocol Working Group）的基础。XML 协议将代替 SOAP 作为行业标准 XML 消息传递协议的位置。当 W3C 发布 XML 协议的草案标准时，IBM Web 服务体系结构就会从 SOAP 迁移到 XML 协议。

SOAP 是一种简单的、轻量级的基于 XML 的机制，用于在网络应用程序之间进行结构化数据交换。SOAP 包括三部分：一个定义描述消息内容的框架的信封、一组表示应用程序定义的数据类型实例的编码规则，以及表示远程过程调用（remote procedure calls，RPC）和响应的约定。SOAP 可以和各种网络协议（如 HTTP、SMTP、FTP 和 IIOP 或 MQ 上的 RMI）相结合使用，或者用这些协议重新封装后使用。

虽然理解这个基础很重要，但多数 Web 服务开发者不必直接处理这个基础结构。大多数 Web 服务都会使用从 WSDL 生成的经过优化的特定于编程语言的绑定。当服务提供者和服务请求者都在类似的环境中执行时，这种优化可能尤为重要。

图 4 展示了 XML 消息传递（即 SOAP）和网络协议如何组成 IBM Web 服务体系结构的基础。

图 4. 使用 SOAP 的 XML 消息传递

网络节点在基于 XML 消息传递的分布式计算中扮演提供者和请求者的角色的基本要求是构建、解析 SOAP 消息的能力（或两者），以及在网络上通信的能力（接收、发送消息，或两者）。

通常，在 Web 应用程序服务器中运行的 SOAP 服务器将执行这些功能。另外，我们也可以使用在 API 中封装这些功能的特定于编程语言的运行库。应用程序与 SOAP 的集成可以通过使用四个基本步骤来实现：

1. 在图 4 中，服务提供者的应用程序在（1）创建一条 SOAP 消息。这条 SOAP 消息是调用由服务提供者提供的 Web 服务操作的请求。消息主体中的 XML 文档可以是一个 SOAP RPC 请求，也可以是一个服务描述中所描述的以文档为中心的消息。服务请求者将此信息和服务提供者的网址一起提供给 SOAP 基础结构（例如一个 SOAP 客户机运行时）。SOAP 客户机运行时与一个底层网络协议（例如 HTTP）交互，然后在网络上将 SOAP 消息发送出去。
2. 网络基础结构在（2）将消息传送到服务提供者的 SOAP 运行时（例如一个 SOAP 服务器）。SOAP 服务器将请求消息路由到服务提供者的 Web 服务。如果应用程序需要，SOAP 运行时负责将 XML 消息转换为特定于编程语言的对象。这个转换由消息中可以找到的编码模式所控制。
3. Web 服务负责处理请求信息并生成一个响应。该响应也是一条 SOAP 消息。响应的 SOAP 消息在（3）被提供给 SOAP 运行时，其目的地是服务请求者。在 HTTP 上的同步请求／响应的情况中，联网协议的底层请求／响应本质用于实现消息传递的请求／响应本质。SOAP 运行时将 SOAP 消息响应发送到网络上的服务请求者。
4. 响应消息在（4）由服务请求者节点上的联网基础结构接收。消息会经过整个 SOAP 基础结构；可能会将 XML 消息转换为目标编程语言中的对象。然后，响应消息被提供给应用程序。

本示例使用了请求／响应传送基本原理，这种原理在大多数分布式计算环境中都很常见。请求／响应交换可以是同步的，也可以是异步的。其它传送基本原理，如单向消息传递（无响应），通知（推动式响应）以及发布／订阅，也可能用到 SOAP。

那么，服务请求者如何知道请求消息应该使用什么格式呢？这个问题在下面一部分中会得到回答。

WSCA 1.0 第 2 部分

Heather Kreger, , IBM Software Group

2002 年 4 月 01 日

本文从组件、交互和应用程序开发模式的观点描述了 Web 服务体系结构。这个体系结构是 IBM 对 Web 服务方法进行实例化的一张蓝图。它是构建和部署 Web 服务应用程序的框架。

在本系列文章的 第一部分，我们介绍了Web服务的定义，Web服务的模型， 讨论了Web 服务的一个概念性协议栈以以及选择网络协议的标准，同时回顾了基本的基于 XML 的消息传递分布式计算。接下来，我们将讨论服务描述在 Web 服务体系结构中的角色，说明支持静态和动态 Web 服务应用程序的服务发布技术的范围。我们还将围绕服务发布讨论服务发现的角色。

服务描述：从 XML 消息传递到 Web 服务

服务提供者是通过服务描述将所有用于调用 Web 服务的规范传送给服务请求者的。要实现 Web 服务体系结构的松散耦合，并减少服务提供者和服务请求者之间所需的共识的程度和定制编程与集成的量，服务描述就是关键。例如，不管是请求者还是提供者，都不必了解对方的底层平台、编程语言或分布式对象模型（如果有的话）。服务描述与底层 SOAP 基础结构相结合，足以封装服务请求者的应用程序和服务提供者的 Web 服务之间的这个细节。

基本服务描述

IBM Web 服务体系结构使用 WSDL 作为基本服务描述。WSDL 已经被提交到 W3C 作为标准。WSDL 是一种 XML 文档，它将 Web 服务描述为一组端点，这些端点会处理包含面向文档或面向过程的（RPC）消息的消息。操作和消息都是被抽象描述的，然后它们会被绑定到一个具体的网络协议和消息格式，用来定义端点。相关的具体端点被合并到抽象的端点或服务中。WSDL 可以扩展为允许端点和其消息的描述，不管使用哪种消息格式或网络协议进行通讯都可以。然而，目前经过描述的绑定只能用于 SOAP 1.1、HTTP POST 以及多用途因特网邮件扩展（Multipurpose Internet Mail Extensions，MIME）。

IBM Web 服务体系结构中对 WSDL 的使用按照常规将基本的服务描述分成了两部分：服务接口和服务实现。这使每个部分都可以被分开独立定义，并可以由另一部分重新使用。

图 5. 基本服务描述

服务接口定义是一种抽象或可重用的服务定义，它可以被多个服务实现定义实例化和引用。您可以将服务接口定义想象成接口定义语言（Interface Definition Language，IDL）、Java 接口或 Web 服务类型。这使常见的行业标准服务类型可以被多个服务实现者定义和实现。这类似于在编程语言中定义抽象接口然后得到多个具体实现。服务接口可以由行业标准组织定义，如 RosettaNet，或保健行业的 HL7。

服务接口包含 WSDL 元素，它们组成了服务描述中的可重用部分，这些元素有：WSDL: binding、WSDL: portType、WSDL: message 和 WSDL: type 元素，如图 5 中所描述。WSDL: portType 元素中定义了 Web 服务的操作。操作定义了输入和输出数据流中可以出现的 XML 消息。您可以将操作想象成编程语言中的方法说明。WSDL: message 元素指定哪些 XML 数据类型组成消息的各个部分。WSDL: message 元素用于定义操作的输入和输出参数。WSDL: types 元素中描述消息中复杂数据类型的使用。WSDL: binding 元素描述特定服务接口（WSDL: portType）的协议、数据格式、安全性和其它属性。

服务实现定义是一个描述给定服务提供者如何实现特定服务接口的 WSDL 文档。Web 服务被建模成 WSDL: service 元素。服务元素包含一组（通常是一个）WSDL: port 元素。端口将端点（例如网址位置或 URL）与来自服务接口定义的 WSDL: binding 元素关联起来。

为了说明职责的安排，开放应用程序组（Open Applications Group，OAG）可能会为开放应用程序组集成规范（Open Applications Group Integration Specification，OAGIS）购买标准定义一个服务接口定义。这个服务接口定义会定义 WSDL: type、WSDL: message、WSDL: portType 和 WSDL: binding。该规范可能会在一些知名网站上被发布（例如 http://www.openapplications.org/）。

服务提供者可以选择开发实现 OAGIS 购买订单服务接口的 Web 服务。服务提供者会开发一个服务实现定义文档，描述 WSDL 设备、端口和地址位置元素，这些元素描述提供者的 Web 服务的网址及其它特定于实现的细节。

服务接口定义和服务实现定义结合在一起，组成了服务完整的 WSDL 定义。这两个定义包含为服务请求者描述如何调用以及与 Web 服务交互的足够信息。服务请求者可以要求获得其它关于服务提供者端口的信息。此信息由服务完整的 Web 服务描述提供。

完整的 Web 服务描述

完整的 Web 服务描述建立在服务基本的 WSDL 定义之上。完整的 Web 服务描述可以解决这样的问题：什么企业在托管这个服务？它是何种类型的企业？与服务相关联的产品有哪些？各种公司和产品类别中与该企业或其 Web 服务相关联的分类有哪些？有没有服务的其它方面（如服务质量）会影响到请求者是否选择调用服务？为了使查找该服务更容易，可以提供哪些关键字？

图 6 中描述了一个完整的 Web 服务描述。

图 6. 完整的 Web 服务描述协议栈

UDDI 提供了一个保存 Web 服务描述的机制。虽然 UDDI 通常会被认为是一种目录机制，但是它也定义了一个用 XML 表示服务描述信息的数据结构标准。UDDI 条目中有四种基本数据结构，如图 7 中所示。

图 7. 基本 UDDI 数据结构

UDDI 条目由 businessEntity 开始。businessEntity 元素对关于企业的信息进行建模，包括基本的企业信息（例如企业名称和联系方式信息是什么？）、分类信息（例如这是何种类型的企业？）以及标识信息（即 Dunn and Bradstreet 编号是什么？）。businessEntity 包含一组 businessService 元素，每个元素对应于企业希望发布的每个 Web 服务。每个 businessService 元素都包含和 businessEntity 元素的 Web 服务有关的技术性和描述性信息。businessService 包含一组 bindingTemplate 元素。bindingTemplate 描述访问信息（例如端点地址），还描述 businessService 如何使用各种不同的技术规范。技术规范在这里的模型是 tModel。tModel 可以为很多不同概念建模，如：一种服务、一个诸如 HTTPS 之类的平台技术或一个类别。与 businessService 相关联的那一组 bindingTemplate 元素代表了 businessService 所使用的技术的印记。

在 IBM Web 服务体系结构中，完整的 Web 服务描述包括用于端点描述的一层，这个端点描述使用 UDDI 条目向服务描述添加企业和实现环境。

端点描述遵循 IBM 提出的结合 WSDL 使用 UDDI 的约定。端点描述使用 UDDI 提供企业信息和类别的标准表示。这个 UDDI-WSDL 约定规定了如何从和 Web 服务相关联的 UDDI 条目中得出服务接口定义和服务实现定义的 WSDL 描述。这个约定对于在 IBM Web 服务体系结构中使用 UDDI 作为基于 WSDL 的服务的服务注册中心来说至关重要。

端点描述向应用到服务的特定实现的服务描述添加了另外的语义。安全属性可以定义对 Web 服务的访问进行控制的策略。服务质量属性指定面向性能的能力，例如服务在一定时间内作出响应的能力，或所支持的可靠消息传递的级别。服务开销属性描述服务的资源需求。还可以定义支持哪些对话语义。

服务描述协议栈中的最后一层是协议描述。协议描述反映两个企业伙伴之间为了完成一个多步企业交互而进行的 Web 服务调用的一个简单的编排。例如，“协议定义”定义了购买协议中诸如购买者和出售者之类的角色。协议定义规定了每个角色必须达到的要求。例如，出售者必须有接受报价请求（request for quote，RFQ）消息、购买订单（purchase order，PO）消息和付款消息的 Web 服务。购买者的角色必须有接受报价（RFQ 响应信息）、发票消息和帐户摘要信息的 Web 服务。这个简单的 Web 服务到企业角色的编排对于在企业伙伴之间建立多步的、面向服务的交互来说至关重要。在很多不同的企业协议标准下，一个给定的服务请求者或服务提供者也许能够扮演购买者或出售者的角色。通过显式地建模企业协议和每个节点在企业协议中扮演各种角色的能力，请求者可以选择在面对各种提供者企业伙伴时加入哪种企业协议。

这个领域充满了创新。对于企业协议定义来说，目前还没有一个单独的标准。ebXML 协作-协议概要和协定规范（ebXML Collaboration-Protocol Profile and Agreement Specification）描述了这些概念，但不是根据作为该体系结构的一部分描述的 Web 服务技术而描述的。Web 服务流程描述和 Web 服务端点描述这两层正处于开发中，它们可以提供这个级别的服务描述。

服务描述的发布和发现

服务发布

Web 服务的发布包括服务描述的生成和之后的发布。发布可以使用各种不同机制。

生成服务描述
我们可以生成、手工编码服务描述，也可以根据已有的服务接口定义组成服务描述。开发者可以手工编码整个服务描述，包括 UDDI 条目。有些工具可以从编程模型和可执行 Web 服务的部署生成 WSDL，还有可能生成来自元数据构件的部分 UDDI 条目。部分服务描述可能已经存在（例如，Web 服务可以基于一个行业标准服务接口定义），这样就只须进一步生成一小部分就可以了。

发布服务描述
服务描述可以使用各种不同机制来发布。根据应用程序将使用服务的动态程度，这些不同的机制提供不同的能力。服务描述可以使用多种不同机制发布到多个服务注册中心。

最简单的情况是直接发布。直接发布意味着服务提供者直接将服务发布给服务请求者。这可以通过使用电子邮件附件、FTP 站点甚至光盘分发来实现。直接发布可以在企业伙伴双方就在 Web 上使用电子商务的条款达成一致后进行，或在请求访问服务的服务请求者支付了费用之后进行。在这种情况下，服务请求者可以保留服务描述的一份本地副本。

稍微更动态一点的发布使用 DISCO 或 ADS。DISCO 和 ADS 两者都定义了一个从给定 URL 获取 Web 服务描述的简单的 HTTP GET 机制。增强的服务描述资源库会提供服务描述的一个本地高速缓存，不过还提供了附加的搜索能力。对于在企业内部跨越主机的服务描述资源库来说，服务提供者会向专用的 UDDI 节点发布。我们可以根据发布到节点的 Web 服务的域的范围，使用几种专用的 UDDI 节点。

• 内部企业应用程序 UDDI 节点（Internal Enterprise Application UDDI node）节点：公司内部为了进行内部企业应用程序集成而使用的 Web 服务应该被发布到这一类 UDDI 节点。此类 UDDI 节点的范围可以是部门的或公司的单独的应用程序。这些 UDDI 位于防火墙之后，允许服务发布者对他们的服务注册中心和它的访问权、可用性以及发布要求有更多的控制。
• 门户网站 UDDI 节点（Portal UDDI node）节点：由公司发布以供外部伙伴查找和使用的 Web 服务可以使用门户网站 UDDI 节点。门户网站节点运行在服务提供者的防火墙之外或之间。这种专用 UDDI 节点只包含公司希望向来自外部伙伴的请求者提供的那些服务描述。这允许公司保留对他们服务描述的控制、UDDI 节点的访问以及 UDDI 节点的服务质量。此外，通过使用门户网站中固有的基于角色的可见性，企业将服务描述的可见性局限在允许看到它们存在的伙伴中。
• 伙伴目录 UDDI 节点（Partner Catalog UDDI node）节点：由特定公司使用的 Web 服务可以被发布到伙伴目录 UDDI 节点。伙伴目录 UDDI 节点位于防火墙之后。此类专用 UDDI 节点只包含来自合法企业伙伴的经过允许的、测试过的、有效的 Web 服务。此类 Web 服务的业务环境和元数据可以被定位到特定的请求者。
• 电子市场 UDDI 节点（E-Marketplace UDDI node）节点：对于服务提供者打算用来与其它 Web 服务竞争请求者的业务的 Web 服务来说，服务描述应该被发布到电子市场 UDDI 节点或 UDDI 运营商节点。电子市场 UDDI 节点由一个行业标准组织或社团托管，包含特定行业中的企业的服务描述。我们可以要求这些服务支持特定的标准、可搜索元数据、接口或数据类型。电子市场 UDDI 节点一般会过滤掉某些非法的条目，并提供有保证的服务质量。

UDDI 运营商节点：如果您希望 Web 服务可以被潜在的新的企业伙伴或服务用户发现，还可以将其发布到 UDDI 运营商节点。IBM、Microsoft 和 Ariba 都支持、复制和托管 UDDI 运营商节点。在发布 UDDI 运营商节点的时侯，如果要让潜在的服务请求者发现服务的话，完整的业务环境和经过深思熟虑的分类法是很必要的。

图 8. 服务发现连续体

图 8 展示了从发布和发现中最静态、最简单的技术到最动态、更复杂的技术的连续体。Web 服务的用户或实现者不必严格遵循这个发展顺序。

服务发现

Web 服务的发现包括获取服务描述和使用描述。获取过程可以使用各种不同机制。

获取服务描述

和发布 Web 服务描述一样，根据服务描述如何被发布以及 Web 服务应用程序可能达到的动态程度，获取 Web 服务描述也会有所不同。服务请求者将在应用程序生命周期的两个不同阶段，即设计时和运行时查找 Web 服务。在设计时，服务请求者按照他们支持的接口类型搜索 Web 服务描述。在运行时，服务请求者根据他们通讯的方式或公告的服务质量搜索 Web 服务。

使用直接发布方法时，服务请求者在设计时对服务描述进行高速缓存，以在运行时使用它。服务描述可以被静态地用程序逻辑表示，并存储在文件或简单的本地服务描述资源库中。

服务请求者可以在设计时或运行时在服务描述资源库（简单的服务注册中心或 UDDI 节点）中检索一条服务描述。查找机制需要支持一种查询机制，它提供按接口类型（基于 WSDL 模板）、绑定信息（即协议）、属性（如 QOS 参数）、所需的中介类型、服务分类法、企业信息等等的查找。

不同类型的 UDDI 节点会显示可以选择的运行时绑定 Web 服务的数目、多选一的策略，或者调用服务之前必须由请求者作出预选的量。

内部企业应用程序 UDDI 节点和伙伴目录 UDDI 节点将不需要预选来建立对服务的信任。服务选择可以建立在绑定支持、历史性能、服务质量分类、相似性或负载平衡的基础之上。

电子市场 UDDI 节点将有更多的运行时服务可以选择。必须执行某种预选以保证 Web 服务提供者是有价值的伙伴。我们可以根据价格承诺、开销、经过允许的伙伴列表的出席情况，同样还有绑定支持、历史性能、服务质量分类和相似性来选择服务。

如果服务请求者从 UDDI 运营商节点查询 Web 服务提供者，他们在预选可能的服务提供者时就必须尽可能谨慎和认真。应该有一个有效和准确的机制就位，过滤掉无用的服务描述和没有价值的服务提供者。

使用服务描述
在获取了服务描述之后，服务请求者需要处理它以调用服务。服务请求者使用服务描述生成对 Web 服务的 SOAP 请求或特定于编程语言的代理。该生成可以在设计时或运行时进行，从而对 Web 服务的调用进行格式化。我们在设计时和运行时可以使用各种工具从 WSDL 文档生成编程语言绑定。这些绑定表示应用程序的 API，并封装了来自应用程序的 XML 消息传递的细节。

在下一部分，我们将描述基本 Web 服务体系结构的扩展，电子商务需要这些扩展才能使用 Web 服务。

Web Service是构建互联网分布式系统的基本部件。Web Services 正成为企业应用集成（Enterprise Application Integration）的有效平台。你可以使用互联网中提供的Web Service构建应用程序，而不必考虑这些Web Service是怎样运行的。

n          Web Service 三个基本技术

²          Web Service通过标准通信协议，在互联网上发布有用的程序模块（以服务的方式），目前大部分是用SOAP来作通信协议。

²          Web Service提供一份详细的接口说明书，来帮助用户构建应用程序，这个接口说明书叫作WSDL（Web Service Description Language）。

²          通常已发布的Web Service要注册到管理服务器，这样便于使用者查询和使用。这个是通过UDDI（Universal Discovery Description and Integration）来完成的。

n          为什么要用 Web Service ？

Web Servcie 最主要的优点是，使用不同程序和在不同系统平台上开发出来的程序，都可以相互通信。现在很多人在问：“不是 CORBA 和 DCE 也有那些优点吗？跟它们有什么不同呢？”。第一个不同点是， SOAP 作为 Web Service 的基本通信协议，比它们简单地多，所以投入和使用的代价也是小的。现在不仅有很多大公司发布的 Web Service ，也有个人发布的。另一个不同点是， Web Service 使用标准的互联网协议 -XML 、 HTTP 和 TCP/IP 。很多公司已经从实践当中对这些协议积累了丰富的经验，所以相比 CORBA 和 DCE 要交的学费要少地多。

如果把现有的应用程序以 Web Service 部件形式发布，可以帮助其他的公司（人）构件功能强大的应用程序。举个例子，你要开发一个采购系统，可以自动地获得供应商的报价，而且可以实时追踪送货过程。如果供应商已经发布了报价和送货这两个 Web Service ，那么你就可以直接使用它们，而不必自己开发这些功能了。

在未来，会出现更有趣的 Web Service （现在做不到的），来帮助我们构建应用程序。

²         SOAP

SOAP 是 Web Service 的基本通信协议。因为 SOAP 与 DCOM 和 CORBA 在概念上有相同之处，所以很多人在问：“ SOAP 是怎样激活对象的？”或“ SOAP 在使用什么命名服务（ Naming Service ）？”。或许在执行 SOAP 的过程当中会用到这些，但这些并不在 SOAP 规范要考虑的范畴之内。 SOAP 只是定义 SOAP 消息的 XML 格式（ XML Format ），如果你用一对 SOAP 标记（ SOAP Elements ）把 XML 文档括起来，那么这个就是一个 SOAP 消息，这不是很简单吗？

SOAP 规范还定义了怎样用 XML 来描述程序数据（ Program Data ） , 怎样执行 RPC （ Remote Procedure Call ）。这些可选的规范是为了构建 RPC-style 的应用程序（客户端 SOAP 消息包含函数名和在函数中用到的参数，而服务器端 SOAP 消息包含执行函数之后的结果）。大多数 SOAP 解决方案都支持 RPC-style 应用程序，因为很多程序员已对 DCOM 或 CORBA 熟悉。 SOAP 还支持 Document-style 应用程序（ SOAP 消息只包含 XML 文本信息）。 Document-style 应用程序有很好的灵活性，所以很多用 RPC 很难构建的 Web Service 用这种方式构建。

最后 SOAP 规范还定义了 HTTP 消息是怎样传输 SOAP 消息的。这并不代表 SOAP 只能用 HTTP 来作为传输协议， MSMQ 、 SMTP 、 TCP/IP 都可以做 SOAP 的传输协议。

很多大公司根据 SOAP 规范，都开发出了自己的 SOAP 解决方案。这些解决方案都是相对于某种语言。比如说 Microsoft SOAP toolkit2.0 把 COM 函数转换成 SOAP 消息，而 Apache toolkit 把 JAVA 函数转换成 SOAP 消息。这样难免带来一些兼容性问题。

现在 SOAP 的很多另人瞩目的特性已成为现实（ SOAP 已经运行于不同的硬件和软件平台），而且有 70 多个解决方案。之所以 SOAP 被人们所爱戴，是因为 SOAP 比其他同类技术（ CORBA 、 DCE ）简单易用。

安全性对于应用程序来说是很重要的。那么 SOAP 的安全性如何呢？对于把 HTTP 作为传输协议的 SOAP 来说是没有问题的，因为 HTTP 协议已经有很好的安全构架。那么用其他传输协议会出现安全问题吗？不是的，你不必担心，因为已经有这方面的规范了（ http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-security.asp ）。

n          WSDL

WSDL 是一种 XML 文档，它定义 SOAP 消息和这些消息是怎样交换的。 IDL （ Interface Description Language ）是用于 COM 和 CORBA 的， WSDL 是用于 SOAP 的。 WSDL 是一种 XML 文档，所以我们可以阅读和编辑，但很多时候是用工具来创建、由程序来阅读。

举个例子，你要使用供应商的 Web Service 构建应用程序。你可以向供应商索取使用 Web Service 的范例，然后按照范例来构建应用程序。这样可能出现意料不到的错误，比如说，你在程序中使用的客户代码的数据类型是 integer ，而供应商使用的数据类型是 string. 。 WSDL 详细定义客户端消息的格式，需要什么样的参数，这样可以避免不必要的错误。

n          UDDI

UDDI 可以比喻成电话本，电话本里记录的是电话信息，而 UDDI 记录的是 Web Service 信息。你可以不把 Web Service 注册到 UDDI 。但如果要让全球的人知道你的 Web Service ，最好还是注册到 UDDI 。

UDDI 目录说明文件也是一个 XML 文档，它包括三个部分。“白页（ White Paper ）”说明提供 Web Service 的公司（人）信息，比如说名称、地址和联系方式等等。“黄页（ Yellow Paper ）”说明 UDDI 目录的分类，比如说金融、服务和印刷等等。“绿页（ green Paper ）”说明接口（ Web Service 提供的）的详细信息。

UDDI 提供多种查询方式，来帮助你找到需要的 Web Service 。如果你查询与财务有关的 Web Service ，那么 UDDI 会提供详细的信息。

n          参考资料

※本文是翻译了下面的文章

XML Web Service basics, Roger Wolter ， Microsoft Corporation ， 2001 年 12 月

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebsrv/html/webservbasics.asp

SOA 是一种 IT 体系结构样式，支持将您的业务作为链接服务或可重复业务任务进行集成，可在需要时通过网络访问这些服务和任务。这个网络可能完全包含在您的公司总部内，也可能分散于各地且采用不同的技术，通过对来自纽约、伦敦和香港的服务进行组合，可让最终用户感觉似乎这些服务就安装在本地桌面上一样。需要时，这些服务可以将自己组装为按需应用程序——即相互连接的服务提供者和使用者集合，彼此结合以完成特定业务任务，使您的业务能够适应不断变化的情况和需求（在有些情况下，甚至不需要人工干预）。

这些服务是自包含的，具有定义良好的接口，允许这些服务的用户——称为客户机或使用者——了解如何与其进行交互。从技术角度而言，SOA 带来了“松散耦合”的应用程序组件，在此类组件中，代码不一定绑定到某个特定的数据库（甚至不一定绑定到特定的基础设施）。正是得益于这个松散耦合特性，才使得能够将服务组合为各种应用程序。这样还大幅度提高了代码重用率，可以在增加功能的同时减少工作量。由于服务和访问服务的客户机并未彼此绑定，因此可以完全替换用于处理订单的服务，下订单的客户机-服务将永远不会知道这个更改。所有交互都是基于“服务契约”进行的；服务契约用于定义服务提供者和客户机之间的交互。通常，您将通过创建“基于消息的”系统来实现此目标。

从业务的角度来说，面向服务的体系结构的重点在于开发能帮助您完成业务任务的技术，而不是通过技术约束来规定您的行动。例如，销售过程（制造、运输和收到货款）可能会涉及数十个步骤和若干不同的数据库和计算机系统。但就其实质而言，此过程包含一系列人工活动，例如：

• 销售人员找到潜在客户
• 客户订购产品
• 生产部门制造产品
• 生产部门发出产品
• 收款部门开具产品帐单
• 客户支付产品货款

面向服务的体系结构基于这些实际活动或业务服务进行组织，而不是形成公司所维护的不同的信息竖井 (Silo)。

通过实现 SOA，可以带来大量好处，包括以下各个方面：

• 更高的业务和 IT 一致性
• 基于组件的系统
• 松散耦合的组件和系统
• 基于网络的基础设施，允许分散于各地且采用不同技术的资源协同工作
• 动态构建的按需应用程序
• 更高的代码重用率
• 更好地标准化整个企业内的流程
• 更易于集中企业控制

本文来自/更多信息：http://www.ibm.com/developerworks/cn/webservices/newto/index.html