专题：SOA_—_面向服务的体系结构.doc

专题：SOA 面向服务的体系结构第一章 SOA and Web services 新手入门1.1 SOA and Web services 新手入门developerWorks 站点上的 Web services 专区包含差不多数百篇文章、教程和技巧，可以帮助开发人员进行大多数与 Web 服务有关的应用程序的开发；但是对于那些尝试涉足这个新领域的用户来说，所有这些信息可能会使他们望而却步。此页为那些想学习 Web 服务但是却又不知道从何入手的读者提供了一份概述。它将 Web 服务技术所有的基础知识都放在适当的背景中，并且把它们与相关的 developerWorks 文章、教程和技巧、IBM 学习服务教育、网络广播、专题研讨会以及 IBM 产品联系起来，供读者进一步地研究。1.1.1 什么是面向服务的体系结构（SOA）？面向服务的体系结构（service-oriented architecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。我们称能够灵活地适应环境变化的业务为按需（On demand）业务，在按需业务中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。虽然面向服务的体系结构不是一个新鲜事物，但它却是更传统的面向对象的模型的替代模型，面向对象的模型是紧耦合的，已经存在二十多年了。虽然基于 SOA 的系统并不排除使用面向对象的设计来构建单个服务，但是其整体设计却是面向服务的。由于它考虑到了系统内的对象，所以虽然 SOA 是基于对象的，但是作为一个整体，它却不是面向对象的。不同之处在于接口本身。SOA 系统原型的一个典型例子是通用对象请求代理体系结构（Common Object Request Broker Architecture，CORBA），它已经出现很长时间了，其定义的概念与 SOA 相似。然而，现在的 SOA 已经有所不同了，因为它依赖于一些更新的进展，这些进展是以可扩展标记语言（eXtensible Markup Language，XML）为基础的。通过使用基于 XML 的语言（称为 Web 服务描述语言（Web Services Definition Language，WSDL）来描述接口，服务已经转到更动态且更灵活的接口系统中，非以前 CORBA 中的接口描述语言（Interface Definition Language，IDL）可比了。Web 服务并不是实现 SOA 的惟一方式。前面刚讲的 CORBA 是另一种方式，这样就有了面向消息的中间件（Message-Oriented Middleware）系统，比如 IBM 的 MQseries。但是为了建立体系结构模型，您所需要的并不只是服务描述。您需要定义整个应用程序如何在服务之间执行其工作流。您尤其需要找到业务的操作和业务中所使用的软件的操作之间的转换点。因此，SOA 应该能够将业务的商业流程与它们的技术流程联系起来，并且映射这两者之间的关系。例如，给供应商付款的操作是商业流程，而更新您的零件数据库，以包括进新供应的货物却是技术流程。因而，工作流还可以在 SOA 的设计中扮演重要的角色。此外，动态业务的工作流不仅可以包括部门之间的操作，甚至还可以包括与不为您控制的外部合作伙伴进行的操作。因此，为了提高效率，您需要定义应该如何得知服务之间的关系的策略，这种策略常常采用服务级协定和操作策略的形式。 最后，所有这些都必须处于一个信任和可靠的环境之中，以同预期的一样根据约定的条款来执行流程。因此，安全、信任和可靠的消息传递应该在任何 SOA 中都起着重要的作用。要获得更多关于这一部分内容的信息：l 参阅 SOA 扩展 Web 服务的前景。 l 阅读 IBM vision of Service Oriented Architectures 以获得更详细的说明。 l Web 服务新手入门 指南回答了许多问题，这对那些还不熟悉 Web 服务技术的人应该会有很大的帮助。 l Web 服务和 WSDK V5.1 介绍 教程很好地介绍了 Web 服务的概念和技术结构。 如果您是一名想要了解 Web 服务的软件架构师或业务人员，An Executives Guide to Web services 提出了许多有用的关于 Web 服务的商业价值的观念。 1.1.2 我可以用面向服务的体系结构做什么？对 SOA 的需要来源于需要使业务 IT 系统变得更加灵活，以适应业务中的改变。通过允许强定义的关系和依然灵活的特定实现，IT 系统既可以利用现有系统的功能，又可以准备在以后做一些改变来满足它们之间交互的需要。下面举一个具体的例子。一个服装零售组织拥有 500 家国际连锁店，它们常常需要更改设计来赶上时尚的潮流。这可能意味着不仅需要更改样式和颜色，甚至还可能需要更换布料、制造商和可交付的产品。如果零售商和制造商之间的系统不兼容，那么从一个供应商到另一个供应商的更换可能就是一个非常复杂的软件流程。通过利用 WSDL 接口在操作方面的灵活性，每个公司都可以将它们的现有系统保持现状，而仅仅匹配 WSDL 接口并制订新的服务级协定，这样就不必完全重构它们的软件系统了。这是业务的水平改变，也就是说，它们改变的是合作伙伴，而所有的业务操作基本上都保持不变。这里，业务接口可以作少许改变，而内部操作却不需要改变，之所以这样做，仅仅是为了能够与外部合作伙伴一起工作。另一种形式是内部改变，在这种改变中，零售组织现在决定它还将把连锁零售商店内的一些地方出租给专卖流行衣服的小商店，这可以看作是采用店中店（store-in-store）的业务模型。这里，虽然公司的大多数业务操作都保持不变，但是它们现在需要新的内部软件来处理这样的出租安排。尽管在内部软件系统可以承受全面的检修，但是它们需要在这样做的同时不会对与现有的供应商系统的交互产生大的影响。在这种情况下，SOA 模型保持原封不动，而内部实现却发生了变化。虽然可以将新的方面添加到 SOA 模型中来加入新的出租安排的职责，但是正常的零售管理系统继续如往常一样。为了延续内部改变的观念，IT 经理可能会发现，软件的新配置还可以以另外的一种方式加以使用，比如出租粘贴海报的地方以供广告之用。这里，新的业务提议是通过在新的设计中重用灵活的 SOA 模型得出的。这是来自 SOA 模型的新成果，并且还是一个新的机会，而这样的新机会在以前可能是不会有的。垂直改变也是可能的，在这种改变中，零售商从销售他们自己的服装完全转变到专门通过店中店模型出租地方。如果垂直改变完全从最底层开始的话，就会带来 SOA 模型结构的显著改变，与之一起改变的还可能有新的系统、软件、流程以及关系。在这种情况下，SOA 模型的好处是它从业务操作和流程的角度考虑问题而不是从应用程序和程序的角度考虑问题，这使得业务管理可以根据业务的操作清楚地确定什么需要添加、修改或删除。然后可以将软件系统构造为适合业务处理的方式，而不是在许多现有的软件平台上常常看到的其他方式。正如您可以看到的，在这里，改变和 SOA 系统适应改变的能力是最重要的部分。对于开发人员来说，这样的改变无论是在他们工作的范围之内还是在他们工作的范围之外都有可能发生，这取决于是否有改变需要知道接口是如何定义的以及它们相互之间如何进行交互。与开发人员不同的是，架构师的作用就是引起对 SOA 模型大的改变。这种分工，就是让开发人员集中精力于创建作为服务定义的功能单元，而让架构师和建模人员集中精力于如何将这些单元适当地组织在一起，它已经有十多年的历史了，通常用统一建模语言（Universal Modeling Language，UML），并且描述成模型驱动的体系结构（Model-Driven Architecture，MDA）。要获得更多关于这一部分内容的信息：学习更多关于面向服务的体系结构的知识。 了解使用 SOA 的好处。 1.1.3 构成 SOA 的技术是什么？SOA 本身是应该如何将软件组织在一起的抽象概念。它依赖于用 XML 和 Web 服务实现并以软件的形式存在的更加具体的观念和技术。此外，它还需要安全性、策略管理、可靠消息传递以及会计系统的支持，从而有效地工作。您还可以通过分布式事务处理和分布式软件状态管理来进一步地改善它。SOA 服务和 Web 服务之间的区别在于设计。SOA 概念并没有确切地定义服务具体如何交互，而仅仅定义了服务如何相互理解以及如何交互。其中的区别也就是定义如何执行流程的战略与如何执行流程的战术之间的区别。而另一方面，Web 服务在需要交互的服务之间如何传递消息有具体的指导原则；从战术上实现 SOA 模型是通过 HTTP 传递的 SOAP 消息中最常见的 SOA 模型。因而，从本质上讲，Web 是实现 SOA 的具体方式之一。尽管我们觉得 Web 服务是实现 SOA 的最好方式，但是 SOA 并不局限于 Web 服务。其他使用 WSDL 直接实现服务接口并且通过 XML 消息进行通信的协议也可以包括在 SOA 之中。正如在别处指出的，CORBA 和 IBM 的 MQ 系统通过使用能够处理 WSDL 的新特征也可以参与到 SOA 中来。如果两个服务需要交换数据，那么它们还会需要使用相同的消息传递协议，但是数据接口允许相同的信息交换。既为了建立所有这些信息的适当控制，又为了应用安全性、策略、可靠性以及会计方面的要求，在 SOA 体系结构的框架中加入了一个新的软件对象。这个对象就是企业服务总线（Enterprise Service Bus，ESB），它使用许多可能的消息传递协议来负责适当的控制、流甚至还可能是服务之间所有消息的传输。虽然 ESB 并不是绝对必需的，但它却是在 SOA 中正确管理您的业务流程至关重要的组件。ESB 本身可以是单个引擎，甚至还可以是由许多同级和下级 ESB 组成的分布式系统，这些 ESB 一起工作，以保持 SOA 系统的运行。在概念上，它是从早期比如消息队列和分布式事务计算这些计算机科学概念所建立的存储转发机制发展而来的。从开发人员的角度来说，他们使用的工具必须知道 SOA 的能力，并允许开发人员有效地使用 SOA 对象。这将设计 SOA 模型、开发服务和服务对象以及测试 SOA 应用程序这些过程包括进来并组成一个整体。因而，开发人员的工作必须为面向服务的应用程序设计/开发（Service-Oriented Application Design/Development，SOAD）做好准备。要获得更多关于这一部分内容的信息：web 服务新手入门页面描述了什么是 Web 服务的技术细节。 Web 服务概念性体系结构（Web Services Conceptual Architecture）解释了 Web 服务背后的技术思想以及 Web 服务如何运行。 在 Web 服务标准数据库中可以找到重要的 Web 服务规范和协议标准。 1.1.4 SOA 与其他技术的关系如何？SOA 可以与许多其他技术结合在一起使用，然而，组件的封装和聚合在其中扮演着重要的角色。如前所述，SOA 可以是一个简单对象、复杂对象、对象的集合、包含许多对象的流程、包含其他流程的流程，甚至还可以是输出单一结果的应用程序的整体集合。在服务之外，它可以看作是单个实体，但是在其自身中，它可以具有任何级别的复杂性（如果必要的话）。出于性能方面的考虑，大多数 SOA 服务并没有下降到单一对象的粒度，并且更适合于大中型组件。除了可能离不开 XML 和 WSDL 之外，SOA 并不是特定于语言的。可以用任何编程语言来实现服务，只要这种编程语言可以生成服务并且可以与 WSDL 结合在一起使用就可以了。SOAP 本身并不是绝对需要的，但它是通用的消息传递系统。因此，可以使用几乎任何一种编程语言和支持 WSDL 的平台来实现 SOA 中的成员服务。基于通用对象请求代理体系结构（Common Object Broker Request Architecture，CORBA）的应用程序有许多组件必须连接到 SOA 中。虽然 CORBA 中的接口描述语言（Interface Description Language，IDL）在概念上类似于 WSDL，但它不是严格的，因而首先需要将其映射到 WSDL。另外，需要使用更高级的 SOA 协议（比如用于流程和策略管理的协议），而不是 CORBA 中的类似的概念。请记住，这是 CORBA 组件（表示为服务）需要与 SOA 服务交互的情况；在 CORBA 模型中，所有的独立子集仍然可以像以前一样工作。由对象管理组（Object Management Group）提出并在许多 IBM Rational 产品中得以实现的模型驱动体系结构在一个更抽象的层次上与 SOA 的概念具有很强的相关性。MDA 基于这样的概念，任何软件流程都可以定义为模型甚至是元模型（即模型的模型），然后可以将这些模型和元模型转换成应用程序的实际组件。因此，MDA 创建了一个模型，这个模型先编译成软件应用程序，而软件应用程序接着又编译成可执行程序，这样就可以在平台上运行了。MDA 并不区分服务和对象这两个概念，但是它确实允许模型由其他子集模型本身组成，这类似于 BPEL（SOA 的一个核心组件）中的流程聚合的概念。SOA 和 Web 服务是独立于编程语言的，但 Java 是主要的开发语言之一。可以使用定义良好的 Java 接口以及各种协议丰富的 Java 实现为正在构建这个模型的开发人员提供了优势。Java 在此担当了开发每个服务的功能、管理数据对象和与其他在逻辑上封装在服务内的对象进行交互的角色。SOA 与 Web 的另一个重要的关系是自主计算和网格计算的概念。自主计算的概念应用于管理分布式服务体系结构的范围，具体来说，就是帮助维护策略和服务级协议以及 SOA 系统的总稳定性。另外，网格计算可以以两个级别与 SOA 系统一起使用。网格是分布式计算的一种形式，它利用分布式特性和服务之间的交互来为 SOA 应用程序提供计算支持。在这种情况下，网格起到了框架的作用，其中实现了一些或所有单独的服务。因此，SOA 应用程序可以是网格服务的消费者。在另一方面，网格本身也可以构建在 SOA 之上。在这种情况下，每个操作系统服务都是构成整个 SOA 应用程序的成员，而 SOA 应用程序就是网格本身。因此，单独的网格组件既可以使用 Web 服务进行通信，又可以以 SOA 的方式进行交互。总而言之，网格系统可以是 SOA 本身，也可以提供服务来在其上构建应用程序级 SOA 模型。要获得更多关于这一部分内容的信息：阅读更多关于面向服务的体系结构的关键组件的内容。 developerWorks 站点上的 Rational 开发者园地包含关于模型驱动的体系结构（Model-Driven Architectures）的信息 developerWorks 站点上的 XML 专区可以解释 XML 在现代编程语言中所扮演的角色。 Java 是最流行的用于 SOA 开发的语言之一。请从 developerWorks Java 技术专区获得更多关于 Java 的信息。 从 developerWorks 自主计算专区获得更多关于自主计算的信息。 开放网格服务架构之旅 解释了现在如何以 Web 服务为基础设计网格计算。请从 developerWorks 网格计算专区获得更多关于网格计算的信息。 1.1.5 我可以如何构建 SOA 系统？利用 SOA 的好处不仅是一个软件开发流程，而且还是一个业务开发流程。采用 SOA 有四个层次，您的实现可以跨越从创建特定的软件服务到将您的业务模型全面转换到按需系统的过程。要获得进一步的信息，您应该阅读这一部分的末尾列出的文章“The Four levels of SOA Adoption”。第一个层次是最简单的，因为它只需创建单独的服务。在这一部分列出的“SOA 新手入门”中对此进行了详细解释，并且提供了更多的资源。在第二个层次中，您不仅可以创建服务，而且可以开始将业务功能集成到 SOA 中。这涉及多个层次的集成，其中包括应用程序集成、信息集成、流程集成和整个系统集成。Migrating to a Service-Oriented Architecture 是一篇重要的文章，介绍了这个层次中的问题。第三个层次涉及将您的企业 IT 基础设施转换到 SOA 模型，而采用 SOA 的第四个层次集中于转换您的业务模型，以使之成为按需就绪的模型。从 IT 专业人员的角度来看（与业务层相比），要创建 SOA 应用程序，您通常将经历四个阶段：构建、部署、使用和管理。在构建阶段中，您可以定义业务模型或流程、软件模型和 SOA 模型。之后，您就可以创建一组服务，这组服务可以与已发布的通用接口一起重用。在部署阶段，您提取创建的服务，并把它们放在一个可执行、可管理的环境之中。在使用阶段，您根据前面所讲的 SOA 和软件模型来装配应用程序，并且测试其软件质量以及非功能性需求，比如性能、可伸缩性等等。应用程序现在已经准备完毕并且可用于用户。最后的管理阶段是一个长期的过程，在这个阶段中，您可以监控并管理安全性和使用，以及在许多与您可能已经为 SOA 制订好的服务级协定或策略相对应的方面比较其性能。这些是 SOA 的生命周期的概念阶段。为了使对应于这些阶段的实际工作角色具体化，有许多角色需要加入到 SOA 应用程序的创建之中。这些角色可能从事相同的工作，也可能跨多个团队成员甚至多个团队。在 Rational Unified Process（RUP）中所划分的角色非常好地表达了角色概念。RUP 角色包括项目经理、分析员、架构师、建模人员、开发人员、测试人员以及部署和操作人员。SOA 几乎完全照搬了这种角色划分方法，惟一不同之处在于，SOA 建模人员角色的工作是提取概念性软件模型，并且根据 IT 基础设施的 SOA 模型和资源来对其进行测试。开发人员角色还可以包括二级角色像装配人员（在使用阶段），装配人员的角色是提取单独的服务，并且根据定义好的模型构建实际的 SOA 应用程序。不管是显式的还是隐式的，这些角色都存在于支持 SOA 的企业之中。要获得更多关于这一部分内容的信息：阅读更多关于采用 SOA 的四个层次的内容。 阅读 Migrating to a Service-Oriented Architecture, Part 1 和 Part 2。 如果您想要了解更多关于 Rational Unified Process 的信息，您就应该阅读它们的 Rational Unified Process: Best Practices for software development teams。 Business processes and workflow in the Web services world 描述了业务流程如何在面向服务的体系结构中工作。 要获得更多关于使用 Web 服务的工作流和业务流程的信息，您应该阅读 BPEL4WS 专栏中关于 BPEL4WS 规范的文章。 From UML to BPEL: Model Driven Architecture in a Web services world 解释了如何适当地将 Web 服务加入到模型驱动的体系结构（Model-Driven Architectures）的世界中。 1.1.6 我可以如何提高我的 SOA 技能？技能的获取取决于您是一个什么类型的专业人员：信息分析员、软件架构师、软件开发人员、软件质量分析员、系统管理员等等。如前所述，SOA 的概念跨越所有这些工作角色。然而，尽力地理解每个工作角色所起的作用是非常有帮助的。接下来，您应该熟悉这每个角色中所包括的技术概念。信息分析员和软件架构师应该熟悉模型驱动的体系结构（Model-Driven Architectures）和 UML V2.0。软件开发人员和程序员应该了解 Web 服务的程序化接口、MQ 和其他协议、程序化地保护交互的方式以及工作流处理的概念。质量分析员和系统管理员应该理解 SOA 流程模型与实际 SOA 功能性体系结构实现，以及分别开发单独的服务如何影响这样的分布式应用程序的整体性能。系统管理员还应该知道应用程序安全性和信任模型如何工作，以及应用程序使用策略如何影响操作系统平台和网络系统。要获得更多关于这一部分内容的信息：由 Olaf Zimmerman 划分的 Web 服务项目角色最初是为 Web 服务而描述的，但是实际上跨越了 SOA 的整个团队。 我们提供了许多关于 Level 1 SOA Adoption: Implementing Individual Web services 的入门和提高技能的信息。其中还包括关于技术简报、课程和专题讨论会的信息。 我们还提供了更多关于 Level 2 SOA Adoption: Service Oriented Integration 的入门和技能提高信息。 An introduction to Model-Driven Architecture 将帮助您熟悉这个软件开发的体系。 SOA and Web services 专区通常会增加一些新教程，这些教程详细解释了如何执行 SOA 和 Web 服务的有用任务。 要了解更多关于 UML 的信息，请转到 Rational UML Resource 中心。 1.1.7 IBM 的什么工具和产品可用于 SOA？IBM 是第一个为构建、部署和关于基于 SOA 的 IT 系统提供一系列全面的工具、教育和服务路线的大型厂商。它们涵盖了 SOA 生命周期的所有方面，其中包括用于前面所讲的采用 SOA 的各个层次构建、部署、使用和管理服务的工具。每个层次都包括更低的采用层次及其工具。由于流程可以扩展，所以并不是各个采用层次上所有的生命周期阶段都是必要的。最后，按需业务转换（On Demand Business Transformation）的第四个层次是面向业务的层次而不是技术流程，并且需要更低层次上的相同软件。在第一个用于实现独立 Web 服务（Implementing Individual Web services）的 SOA 采用层次中，图 1 所示的工具主要用于帮助开发人员创建和操作比较简单的 Web 服务。图 1. 实现单独的 Web 服务核心组件在第二个层次，面向服务的集成（Service Oriented Integration），工具转向提供发现多个服务并与其交互的方式，以及创建 SOA 模型的基础。图 2a 展示了层次 2 采用的核心组件，而图 2b 展示了可以为层次 2 提供帮助的附加组件。图 2a. 面向服务的集成核心组件图 2b. 面向服务的集成附加组件在层次 3，企业范围内的 IT 转换，IBM 提供了各种各样的 SOA 和 Web 服务现成产品，这样就可以支持所有的 IT 系统功能，并提供 SOA 系统的企业范围内的管理。图 3a 展示了层次 2 中的核心组件，而图 3b 展示了附加组件。图 3a. 企业范围内的 IT 转换核心组件图 3b. 企业范围内的 IT 转换附加组件要获得更多关于这一部分内容的信息：阅读 benefits of having an SOA。 关于 Level 1 SOA Adoption 的所有软件产品的信息都可以在 IBM Web 服务站点：实现 Web 服务中找到。 关于 Level 2 SOA Adoption 的所有软件产品的信息都可以在 IBM Web 服务站点：面向服务的集成中找到。 关于 Level 3 SOA Adoption 的所有软件产品的信息都可以在 IBM Web 服务站点：企业范围内的 IT 转换中找到。 1.2 Web 服务新手入门什么是 Web 服务？我可以用 Web 服务做什么？构成 Web 服务的技术是什么？Web 服务与其他技术的关系如何？我可以如何在应用程序中使用 Web 服务？我可以如何提高我的 Web 服务技能？IBM 的什么工具和产品可用于 Web 服务？developerWorks 中的 Web services 专区包含差不多数百篇文章、教程和技巧，可以帮助开发人员进行大多数与 Web 服务有关的应用程序的开发；但是对于那些尝试涉足这个新领域的用户来说，所有这些信息可能会使他们望而却步。此页为那些想学习 Web 服务但是却又不知道从何入手的读者提供了一份概述。它将 Web 服务技术所有的基础知识都放在适当的背景中，并且把它们与相关的 developerWorks 文章、教程和技巧、IBM 学习服务教育、网络广播、专题研讨会以及 IBM 产品联系起来，供读者进一步地研究。1.2.1 什么是 Web 服务？Web 是使应用程序可以以与平台和编程语言无关的方式进行相互通信的一项技术。Web 服务是一个软件接口，它描述了一组可以在网络上通过标准化的 XML 消息传递访问的操作。它使用基于 XML 语言的协议来描述要执行的操作或者要与另一个 Web 服务交换的数据。一组以这种方式交互的 Web 服务在面向服务的体系结构（Service-Oriented Architecture，SOA）中定义了特殊的 Web 服务应用程序。软件业最终会接受这样的事实：跨多个操作系统、编程语言和硬件平台集成软件应用程序不可能由任何一种专门的环境来解决。传统上，这个问题一直是一个紧耦合问题，调用远程网络的应用程序通过自己发出的函数调用和请求的参数与远程网络紧密地联系在一起。在 Web 服务出现之前，在大多数系统上，采用的是固定的接口，但对于环境或需要的改变，这缺乏灵活性或适用性。Web 服务所使用的 XML 可以用真正与平台无关的方式来描述任何（所有）数据，以跨系统交换数据，因此转向了松耦合应用程序。而且，Web 服务可以在较抽象的层面上工作，较抽象层面可以按照需要动态地重新评估、修改或处理数据类型。所以，从技术层面上讲，Web 服务可以更方便地处理数据，并且允许软件更自由地进行通信。从更高的概念层面上讲，我们可以将 Web 服务视为一些工作单元，每个单元处理特定的功能任务。再往上一步，可以将这些任务组合成面向业务的任务，以处理特定的业务操作任务，从而使非技术人员去考虑一些应用程序，这些应用程序可以在 Web 服务应用程序工作流中一起处理业务问题。因此，一旦由技术人员设计并构建好 Web 服务之后，业务流程架构设计师就可以聚集这些 Web 服务来解决业务层面上的问题。这里借用汽车引擎来作类比，业务流程架构设计师考虑将整个汽车引擎与汽车框架、车身、变速器和其他系统组合在一起，而不是研究每个引擎内的各个部件。而且，动态的平台意味着引擎可以与其他汽车制造商的变速器或部件一起工作。最后一个方面是，Web 服务可以有助于在组织内的业务人员和技术人员之间架起一座桥梁。Web 服务使业务人员能更容易理解一些技术上的操作。业务人员可以描述出一些事件和活动，然后技术人员可以将这些事件和活动与相应的服务相关联。有了通用定义的接口和设计良好的任务，重用这些任务就变得更容易了，因而重用这些任务所代表的应用程序也就变得容易了。应用程序软件的可重用性意味着在软件上的投资有了更好的回报，因为可以从同一资源产生更多收益。可重用性使业务人员可以考虑以一种新的方式来使用现有的应用程序，或者以一种新的方式将应用程序提供给合作伙伴，因此可能增加合作伙伴间的业务交易。所以，Web 服务试图解决的主要问题是数据和应用程序集成的问题，是将技术性的功能转换成面向业务的计算任务的问题。这两个方面使业务人员可以就流程或应用程序层面与他们的合作伙伴进行交流，同时为适应新形势或按照需要与不同合作伙伴进行合作留有动态的余地。获得更多有关 Web 服务的信息：要了解 Web 服务，您应该首先知道可扩展标记语言（Extensible Markup Languageservices，XML）是如何工作的。XML and how it will change the Web 和 XML 入门是两篇很好的文章，您可以从这两篇文章开始了解 XML。虽然 Web 服务技术本身是语言无关的，但是在 Java 技术中还可以获得许多工具和软件实现。 Web 服务和 WSDK V5.1 介绍教程很好地介绍了 Web 服务的概念和技术结构。 如果您是一位想要了解 Web 服务的软件架构设计师或业务人员，An Executives Guide to Web services提供了许多关于 Web 服务的商业价值方面的有用想法。 1.2.2 我可以用 Web 服务做什么？虽然 Web 服务支持所有这些动态将多个服务组合到应用程序中，但您仍然必须首先构建这些服务。编程语言和计算机科学在不断发展。我们在几十年前就有了函数这个想法，通过给它提供一些参数，由它根据这些参数执行某个操作，然后根据它的计算返回值。最终，这个首先提出来的概念演变成了对象，每个对象不仅有一些它可以执行的函数，而且还有自己的专用数据变量，而不是依赖于以前所采用的使开发应用程序更为复杂的外部系统范围内的数据变量。当应用程序进入了网络时代，对于对象，定义通用接口的概念变得更为重要，即使位于其他平台上的对象是用另外的编程语言编写的并且运行在其他操作系统上，也可以使这些对象进行通信。在最近的步骤中，Web 服务转向了基于 XML 的接口和通信这一概念，只要将 Web 服务设计成符合相应的接口，最终可以将任何一种应用程序与另一种应用程序组合在一起，并可以随时间的流逝自由地更改和发展应用程序。XML 的通用性使得 Web 服务不同于前一代组件技术。它允许语法结构（句法）与语法意义（语义）的分离，每个服务处理和理解它的方式与它所存在的环境的分离。因此，现在可以将对象定义为服务，它可以与其他采用 XML 定义的语法的服务进行通信，从而每个服务又可以根据其本地实现和环境来转换和分析消息。因此，网络应用程序实际上可以由各种构造和设计的实体组成，只要这些实体符合它们面向服务的体系结构就可以了。 因此，如果掌握了这一能力，Web 服务将使您能够： l 让任何平台上的用任何语言编写的服务进行交互。 l 将应用程序功能概念化成任务，从而形成面向任务的开发和工作流。这使得更抽象的软件能够为工作在业务层面具有较少软件分析技术的用户所用。 l 允许松耦合，这意味着，每当其中某个或多个服务在设计或实现中发生变更时，服务应用程序之间的交互可能不会因此而中断。 l 使现有的应用程序能适应变化中的业务条件和客户需要。 l 向现有或遗留的软件应用程序提供服务接口，而无需改变原来的应用程序，从而使这些应用程序完全可以运行在这种服务环境下。 l 引入其他一些与原有功能无关的管理或操作管理功能，比如可靠性、可计帐性和安全性等等，从而在业务计算环境中增加了其通用性和实用性。获得更多有关 Web 服务的信息：在 Web 服务世界中的业务流程 解释了如何用 Web 表示工作流和业务流程。 Web 服务世界的安全性 探究了 Web 服务中安全模式是如何发展演化的。 网格与 Web 服务的结合 讨论了网格计算如何在一个内聚的分布式面向服务的体系结构中使用 Web 服务。 An e-mail user interface to Web services 描述了移动设备如何通过简单的协议（比如 email）与企业 Web 服务进行交互。 学习 Web 服务如何在 J2EE 模型中工作（请参见 用 Web 服务和 J2EE 集成企业应用程序）和了解不同的通信机制（请参见 为 EAI 选择 JCA、JMS 或 Web 服务）。 1.2.3 构成 Web 服务的技术是什么？Web 服务采用一系列的相关协议来描述、传递服务和与服务交互。根据其通常的功能和使用，可以将这一系列协议进一步再划分为组。第一组处理消息传递、接口描述、寻址和提供的问题。最有名的是消息传递协议，称为简单对象访问协议（Simple Object Access Protocol，SOAP）。此协议对消息进行了编码，这样就可以通过传输协议（如 HTTP、IIOP、SMTP 或其他协议）在网络上传递它们。Web 服务描述语言（Web Services Description Language，WSDL）表示为一系列 XML 语句，这些语句组成了每个服务的接口的定义。另一个正在制订的服务是 Web 服务寻址，它定义了如何在分布式体系结构中唯一地进行 Web 服务寻址和标识 Web 服务。另一个流行的规范是 Web 服务调用框架（Web Services Invocation Framework），在这种框架中，您可以定义任何类型的组件的 WSDL 接口，即使它们没有使用相同的消息传递协议。下一组协议和规范定义了服务如何公开它们自己以及如何在网络上相互发现。对于要相互查找的服务，统一描述、发现和集成（Universal Description, Discovery and Integration，UDDI）为查找和访问服务定义了注册中心和相关的协议。Web 服务检查语言（Web Services Inspection Language）是 UDDI 在不使用注册中心的情况下采用的一种可选的机制。用于 Web 服务的安全性协议是从 Web 服务安全性（WS-Security）规范开始的，该规范为安全通信定义了基于令牌的体系结构。以此为基础，有六个主要的组成规范：l Web 服务策略（WS-Policy）和相关的规范，定义了关于服务交互方式的策略规则。 l Web 服务信任（WS-Trust），定义了安全交换的信任模型。 l Web 服务隐私（WS-Privacy），定义了如何维护信息的隐私。 l Web 服务安全会话（WS-Secure Conversation），定义了如何使用在Web 服务策略（WS-Policy）、Web 服务信任（WS-Trust）和 Web 服务隐私（WS-Privacy）中定义的规则，来在用于交换数据的服务之间建立安全会话。 l Web 服务联盟（WS-Federation），定义了分布式标识的规则以及如何对其进行管理。 l Web 服务授权（WS-Authorization），定义了如何处理对访问和交换数据的授权。在安全性模型之外的是特定于应用程序的规范，其中包括 Web 服务的业务流程执行语言（Business Process Execution Language for Web Services，BPEL4WS），它定义了一起进行分布式事务处理的工作流操作、Web 服务事务（WS-Transaction）、Web 服务协调（WS-Coordination）。目前计划制订的规范是 Web 服务分布式管理（Web Services Distributed Management），用于对所有的服务和面向服务的体系结构进行软件管理。最后，还有一些用于用户界面（Web 服务交互应用程序（WS-InteractiveApplications）和 Web 服务的远程访问（Web 服务远程门户（WS-RemotePortals）的规范。在写作本文时，用于 Web 服务的规范还处在不断地制订的过程中，而且它们仅仅是开始解释服务之间应该如何交互。然而，它们无法包括每一种方案和这些方案的可能组合。因此，Web 服务互操作性组（Web Services Interoperability Group，WS-I）的组成成员几乎来自所有从事 Web 服务开发的大大小小的厂商，它已经肩负起开发用况研究、样本应用程序、实现方案和测试工具的重任，目的是确保这些标准和规范能够真正地协同工作，而不考虑厂商的产品实现。WS-I 已经定义了他们第一个用于 Web 服务的基本概要（Basic Profile 1.0），并且还发布了他们的方案、样本应用程序和测试工具，以便根据方案评估和比较各种实现的结果。 除了 WS-I 之外，Organization for the Advancement of Structured Information Standards (OASIS) 、World Wide Web Consortium (W3C) 和 Internet Engineering Task Force (IETF) 也在进行大量的标准制订工作。获得更多有关 Web 服务的信息：Web 服务概念性体系结构解释了 Web 服务背后的技术思想及其工作方式。 在 Web 服务标准数据库中可以找到许多重要的 Web 服务规范和协议标准。 更多关于规范和标准的信息可以在 W3C 站点 和 OASIS 站点中找到。 您可以在 初识 WS-I 基本概要 1.0、First look at the WS-I Usage Scenarios 和 了解 WS-I 测试工具 中读到对 WS-I 所做的工作的介绍。 1.2.4 Web 服务与其他技术的关系如何？Web 服务主要是技术的集成。不过，它本身是独立于形式的。如前所述，组成 Web 服务的技术通常是用 XML 进行定义和交互的。然而，由于 XML 本身是一种独立的语言，所以 Web 服务也是独立的。因此，可以用许多编程语言（其中包括 Java、Python、Perl、C#、Basic 等等）来开发 Web 服务。Web 服务的初衷是努力为 Internet 和 Web 应用程序的体系结构找到一种更好的方法，以便更好地进行通信和相互交互。因而，当今的大多数 Web 是基于在应用程序服务器环境（如 WebSphere、Apache 及其他）中运行的程序的。虽然它们不是必需的，但是一些最优秀的 Web 服务工具是为这样的环境而设计的。通过提供更简单的统一接口，Web 服务还有助于改进普及计算模型为移动环境和可移植环境工作的方式。移动计算软件将很快采用 Web 服务通信模型，而这有助于改进可视化 Web 服务的接口问题。网格计算已经采用 Web 服务作为开放网格服务体系构架（Open Grid Services Architecture）的一部分，这是一种用于这种类型的分布式计算的新模型，它使用 Web 服务来沟通网格如何操作。自主计算是一种很有意义的新方法，通过这种计算方法，计算机可以维护和管理它们自己，它有一些用于 Web 服务的应用程序。获得更多有关 Web 服务的信息：Java 是 Web 服务的基石，而实际上，developerWorks 中的 Web services 专区中的大部分文章都侧重于基于 java 的开发。例如，开发者关于 JAX-RPC 的介绍，第 1 部分 和 开发者关于 JAX-RPC 的介绍，第 2 部分 专门讨论与 Web 服务开发有关的 J2EE API。 开发一个用于与 WebSphere Web 服务交互的 .Net 客户端 和 A Demonstration of Web Services Interoperability Between the WebSphere and .Net 提供了关于 Web 服务如何在不同的 Web 体系结构中跨平台工作的示例。 开放网格服务架构之旅 解释了现在网格计算是如何以 Web 服务为基础进行设计的。 Cross-platform programming with the WSTK for Mobile Devices 介绍了一些用于移动计算的 Web 服务编程工具。 ETTK 自愈合和自优化演示 展示了自主计算如何与 Web 服务协同工作。 1.2.5 我可以如何在应用程序中使用 Web 服务？在构建应用程序时有很多考虑 Web 服务的方式。在最基本的层次上，高级通信协议允许应用程序相互交谈。在过去几年里，这一层已经取得了巨大的进展，出现了许多工具，通过使用这些工具，软件开发人员可以编写交互 Web 并构建复杂的应用程序。通常，这一层的特点是服务之间的一对一直接交互或比较少的服务相互交互。然而，如果只是将 Web 服务作为通信协议就未能实现面向服务的体系结构（SOA）。SOA 描述了服务的整个系统如何动态地相互查找，如何聚集在一起执行某些应用程序，以及如何按照多种方式进行组合。该模型鼓励技术和软件的重用，从而发展了设计、开发和使用应用程序的方式。它使分布式计算更接近于现实。在这一层次上，软件开发人员需要考虑 SOA 模型并通过此模型来设计他们的分布式应用程序。这一层的特点是使用各种技术来支持服务的分布式计算，比如 Enterprise Service Bus (ESB)，它是一个通用的分布网络，可以与服务一起协同工作。而最高的层次是把 SOA 模型和许多组件服务看作是构件，这些构件可以装配成一个整体的部分并放入完整的应用程序中，而不是用传统的方法来编写一行一行的代码。通过检验连接接口，我们可以在不曾真正编写一行代码的情况下构建整个应用程序。说实在的，按照这种方式，甚至还可能得到直接代码，因为服务可以通过多种不同的语言和平台进行编写。可以将构件放在一起来组成定义应用程序的执行方式的操作工作流，而且还可以用其他的工具来监控每个服务或服务组的工作流的有效性。在这一层次上，开发人员可以把常规编程语言放在一边，而使用模型驱动的体系结构（Model-Driven Architecture）来帮助他们构建设计更精确的应用程序。然后，这样设计的应用程序就可以运行在分布式系统（如 ESB）之上。获得更多有关