SOA and Web Services 新手入门.docx

developerWorks 的 Web Services 专区包含差不多数百篇文章、教程和技巧，可以帮助开发人员进行大多数与 Web 服务有关的应用程序的开发；但是对于那些尝试涉足这个新领域的用户来说，所有这些信息可能会使他们望而却步。本页面为那些想学习 Web 服务但是却又不知道从何处入手的读者提供了相关概述。本页面将 Web 服务技术所有的基础知识都放在适当的背景中，并将其与相关的 developerWorks 文章、教程和技巧、IBM 学习服务教育、网络广播、专题研讨会以及 IBM 产品联系起来，供读者进行 进一步研究。使用 Web 服务技术，应用程序可以与平台和编程语言无关的方式相互通信。Web 服务是一个软件接口，它描述了一组可以在网络上通过标准化的 XML 消息传递访问的操作。它使用基于 XML 语言的协议来描述要执行的操作或者要与另一个 Web 服务交换的数据。在面向服务的体系结构（Service-Oriented Architecture，SOA）中，一组以这种方式交互的 Web 服务定义了特定的 Web 服务应用程序。实际上，Web Service 最基本的组成部分为服务的提供者（Service Provider）和服务的请求者（Service Requester）。这看起来很像 C/S 架构的软件，与之不同的是，Web Service 两端的应用是通过基于标准的 XML 格式的协议进行通信的，这种最常用的协议就是 SOAP（Simple Object Access Protocol）。当然，Web Services 不简单地只是按这种方式进行通信。按照 Web Service 的相关标准描述，服务的提供者应该首先通过 WSDL（Web Service Definition Language）和 UDDI （Universal Description, Discovery, and Integration）发布它所提供的服务到一个统注册这些服务信息的存储库中去。这样，服务的请求者就也可以通过 WSDL 和 UDDI 发现到服务提供者提供的服务，并可以通过应用的调用方法来使用这个服务了。软件业最终会接受这样的事实：跨多个操作系统、编程语言和硬件平台集成软件应用程序不可能由任何一种专门的环境来解决。传统上，这个问题一直是一个紧耦合问题，调用远程网络的应用程序通过自己发出的函数调用和请求的参数与远程网络紧密地联系在一起。在 Web 服务出现之前，在大多数系统上，采用的是固定的接口，但对于不断变化的环境或需求，这样做缺乏灵活性或适用性Web 服务所使用的 XML 可以用真正与平台无关的方式来描述任何（所有）数据，以跨系统交换数据，因此转向了松耦合应用程序。而且，Web 服务可以在较抽象的层面上工作，较抽象层面可以按照需要动态地重新评估、修改或处理数据类型。所以，从技术层面上讲，Web 服务可以更方便地处理数据，并且允许软件更自由地进行通信。从更高的概念层面上讲，我们可以将 Web 服务视为一些工作单元，每个单元处理特定的功能任务。再往上一步，可以将这些任务组合成面向业务的任务，以处理特定的业务操作任务，从而使非技术人员可以考虑一些应用程序，这些应用程序能够在 Web 服务应用程序工作流中一起处理业务问题。因此，一旦由技术人员设计并构建好 Web 服务之后，业务流程架构师就可以聚集这些 Web 服务来解决业务层面上的问题。这里借用汽车引擎来作类比，业务流程架构师考虑将整个汽车引擎与汽车框架、车身、变速器和其他系统组合在一起，而不是研究每个引擎内的各个部件。而且，动态平台意味着引擎可以与其他汽车制造商的变速器或部件一起工作。最后一个方面是，Web 服务有助于在组织内的业务人员和技术人员之间架起一座桥梁。Web 服务使业务人员更容易理解一些技术上的操作。业务人员可以描述一些事件和活动，然后技术人员可以将这些事件和活动与相应的服务相关联。有了通用定义的接口和设计良好的任务，重用这些任务就变得更容易了，因而重用这些任务所代表的应用程序也就变得容易了。应用程序软件的可重用性意味着在软件上的投资有了更好的回报，因为可以从同一资源产生更多收益。可重用性使业务人员可以考虑以一种新的方式来使用现有的应用程序，或者以一种新的方式将应用程序提供给合作伙伴，因此可能增加合作伙伴间的业务交易。所以，Web 服务试图解决的主要问题是数据和应用程序集成的问题，以及将技术性的功能转换为面向业务的计算任务的问题。这两个方面使企业可以就流程或应用程序层面与他们的合作伙伴进行交流，同时为适应新形势或按照需要与不同合作伙伴进行合作留有动态的余地。获得更多相关信息 要了解 Web 服务，您应该首先知道可扩展标记语言（Extensible Markup Languageservices，XML）的工作原理。XML and how it will change the Web 和 Introduction to XML 是两篇很好的文章，您可以从这两篇文章开始了解 XML。虽然 Web 服务技术本身是语言无关的，但是在 Java 技术中还可以获得许多工具和软件实现。 如果您是一位想要了解 Web 服务的软件架构师或业务人员，An Executives Guide to Web Services 提供了许多关于 Web 服务的商业价值方面的有用想法。我可以用 Web 服务做什么？虽然 Web 服务支持所有这些将多个服务组合到应用程序中的动态功能，但您仍然必须首先构建这些服务。编程语言和计算机科学在不断发展。我们在几十年前就有了函数的想法，通过给它提供一些参数，由它根据这些参数执行某个操作，然后根据它的计算返回值。最终，这个首先提出来的概念演变成了对象，每个对象不仅有一些它可以执行的函数，而且还有自己的专用数据变量，而不是依赖于以前所采用的使开发应用程序更为复杂的外部系统范围内的数据变量。当应用程序进入了网络时代，对于对象，定义通用接口的概念变得更为重要，即使位于其他平台上的对象是用另外的编程语言编写的并且运行在其他操作系统上，也可以使这些对象进行通信。在最近的发展中，Web 服务转向了基于 XML 的接口和通信这一概念，只要将 Web 服务设计成相应的接口，最终都可以将任何一种应用程序与另一种应用程序组合在一起，并可以随时间的流逝自由地更改和发展应用程序。XML 的通用性使得 Web 服务不同于前一代组件技术。它允许语法结构（句法）与语法意义（语义）分离，每个服务处理和理解它的方式与它所存在的环境分离。因此，现在可以将对象定义为服务，它可以与其他采用 XML 定义的语法的服务进行通信，从而每个服务又可以根据其本地实现和环境来转换和分析消息。因而，网络应用程序实际上可以由各种构造和设计的实体组成，只要这些实体符合它们面向服务的体系结构就可以了。因此，如果掌握了这一能力，Web 服务将使您能够： 让任何平台上的用任何语言编写的服务进行交互。 将应用程序功能概念化成任务，从而形成面向任务的开发和工作流。这使得更抽象的软件能够为工作在业务层面具有较少软件分析技术的用户所用。 允许松耦合，这意味着，每当其中某个或多个服务在设计或实现中发生改变时，服务应用程序之间的交互不会因此而中断。 使现有的应用程序能适应不断变化的业务条件和客户需求。 向现有或遗留软件应用程序提供服务接口，而无需改变原来的应用程序，从而使这些应用程序完全可以运行在这种服务环境下。 引入其他一些与原有功能无关的管理或操作管理功能，比如可靠性、责任性和安全性等等，从而在业务计算环境中增加其通用性和实用性。获得更多相关信息 在 Web 服务世界中的业务流程 解释了如何用 Web 表示工作流和业务流程。 Security in a Web services world 探究了 Web 服务中安全模式是如何发展演变的。 网格与 Web 服务的结合 讨论了网格计算如何在一个内聚的分布式面向服务的体系结构中使用 Web 服务。 An e-mail user interface to Web services 描述了移动设备如何通过简单的协议（比如 email）与企业 Web 服务进行交互。 学习 Web 服务如何在 J2EE 模型中工作（请参见 用 Web 服务和 J2EE 集成企业应用程序）和了解不同的通信机制（请参见 为 EAI 选择 JCA、JMS 或 Web 服务 ）。构成 Web 服务的技术是什么？Web 服务采用一系列相关协议来描述、传递服务和与服务交互。根据其通常的功能和使用，可以将这一系列协议进一步划分为组。第一组处理消息传递、接口描述、寻址和交付的问题。最有名的是消息传递协议，称为简单对象访问协议（Simple Object Access Protocol，SOAP）。此协议对消息进行了编码，这样就可以通过传输协议（如 HTTP、IIOP、SMTP 或其他协议）在网络上传递它们。Web 服务描述语言（Web Services Description Language，WSDL）表示为一系列 XML 语句，这些语句组成了每个服务的接口的定义。另一个正在制订的规范是 Web 服务寻址 (WS-Addressing)，它定义了如何在分布式体系结构中唯一地进行 Web 服务寻址和标识 Web 服务。另一个流行的规范是 Web 服务调用框架（Web Services Invocation Framework），在这种框架中，您可以定义任何类型的组件的 WSDL 接口，即使它们没有使用相同的消息传递协议。下一组协议和规范定义了服务如何公开它们自己以及如何在网络上相互发现。对于要相互查找的服务，统一描述、发现和集成（Universal Description, Discovery and Integration，UDDI）为查找和访问服务定义了注册中心和相关协议。Web 服务检查语言（Web Services Inspection Language）是 UDDI 在不使用注册中心的情况下采用的一种可选机制。用于 Web 服务的安全性协议是从 Web 服务安全性 (WS-Security) 规范开始的，该规范为安全通信定义了基于令牌的体系结构。以此为基础，有六个主要的组成规范： Web 服务策略 (WS-Policy) 和相关的规范，定义了关于服务交互方式的策略规则。 Web 服务信任(WS-Trust)，定义了安全交换的信任模型。 Web 服务隐私 (WS-Privacy)，定义了如何维护信息的隐私。 Web 服务安全会话 (WS-Secure Conversation)，定义了如何使用在Web 服务策略 (WS-Policy)、Web 服务信任 (WS-Trust) 和 Web 服务隐私 (WS-Privacy) 中定义的规则，以在用于交换数据的服务之间建立安全会话。 Web 服务联盟 (WS-Federation)，定义了分布式标识的规则以及如何对其进行管理。 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 Services Conceptual Architecture解释了 Web 服务背后的技术思想及其工作方式。 （英文原文） 在 developerWorks Web Services 标准 页面中可以找到许多重要的 Web 服务规范和协议标准。 有关规范和标准的详细信息，请访问 W3C 站点和 OASIS 站点。 通过阅读 初识 WS-I 基本概要 1.0 和 了解 WS-I 测试工具，您可以了解 WS-I 所做的工作。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 服务的应用程序。获得更多相关信息 Java 是 Web 服务的基石，而实际上，developerWorks 站点上的 Web Services 专区中的大部分文章都侧重于基于 java 的开发。例如，开发者关于 JAX-RPC 的介绍，第 1 部分: 了解 JAX-RPC 类型映射系统的各个方面 和 开发者关于 JAX-RPC 的介绍，第 2 部分: 研究 JAX-RPC 的规范提高 Web 服务互操作性 专门讨论与 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 服务协同工作。我可以如何在应用程序中使用 Web 服务？在构建应用程序时有很多考虑 Web 服务的方式。在最基本的层次上，高级通信协议允许应用程序相互交谈。在过去几年里，这一层次已经取得了巨大的进展，出现了许多工具，通过使用这些工具，软件开发人员可以编写交互的 Web 服务并构建复杂的应用程序。通常，这一层次的特点是服务之间的一对一直接交互或比较少的服务相互交互。然而，如果只是将 Web 服务作为通信协议就未能实现真正的面向服务的体系结构 (SOA)。 SOA 描述了服务的整个系统如何动态地相互查找，如何聚集在一起执行某些应用程序，以及如何按照多种方式进行组合。该模型鼓励技术和软件的重用，从而发展了设计、开发和使用应用程序的方式。它使分布式计算更接近于现实。在这一层次上，软件开发人员需要考虑 SOA 模型并通过此模型来设计他们的分布式应用程序。这一层的特点是使用各种技术来支持服务的分布式计算，比如 企业服务总线 (ESB)，它是一个通用的分布网络，可以与服务一起协同工作。而最高的层次是把 SOA 模型和许多组件服务看作是构件，这些构件可以装配成作为一个整体的某些部分并放入完整的应用程序中，而不是用传统的方法来编写一行一行的代码。通过检验连接接口，我们可以在不曾真正编写一行代码的情况下构建整个应用程序。事实上，按照这种方式，甚至还可能得到直接代码，因为服务可以通过多种不同的语言和平台进行编写。可以将构件放在一起来组成定义应用程序的执行方式的操作工作流，而且还可以用其他工具来监控每个服务或服务组的工作流的有效性。在这一层次上，开发人员可以把常规编程语言放在一边，而使用模型驱动的体系结构 (Model-Driven Architecture) 来帮助他们构建设计更精确的应用程序。然后，这样设计的应用程序就可以运行在分布式系统（如 ESB）之上。获得更多相关信息 Java 2 Enterprise Edition (J2EE) 是用 Java 编程语言开发 Web 服务的主流模型。您应该阅读关于 J2EE 的文章并且了解它的工作方式，从而理解 Web 服务开发的第一层次。 Building a Web service from SOAP to nuts 和 创建、部署、发布和使用一个简单的 Web 服务 是两篇关于构建交互 Web 服务的入门文章。 用 Web 服务来访问 DB2：在 Windows 上创建 Web 服务以访问 DB2 和 用 SQL 调用 Web 服务：将关系数据和 Web 服务集成在一起提供了关于构建数据库 Web 服务的见解。 Business processes and workflow in the Web services world 描述了业务流程