服务的性质

什么是服务？如前所述，在一个典型的业务环境里，服务意味着业务函数、业务事务和系统服务。业务函数可能是 getStockQuote、getCustomerAddress 或 checkCreditRating。业务事务可能是 commitInventory、sellCoveredOption 或 scheduleDelivery。系统服务可能是 logMessageIn、getTimeStamp 或 openFile。请注意各种类型服务之间的区别。从应用程序的角度来看，业务函数实际上是原子的非系统函数。业务事务很像是调用应用程序的简单函数，但是它们可能是作为自己的事务的上下文所包含的复合函数来实现的。它们可能包括多个底层函数，这些底层函数对调用者来说是透明的。系统函数是能够从诸如 Windows 或者 Linux 这样的特定平台中抽象出来的广义函数。应用程序框架可能提供像 openFile 这样的广义函数来有效地虚拟化数据源，从而可以在不考虑真实数据源的类型和位置的情况下使用这类函数。

这看起来像人为地规定服务之间的区别；您可以从应用程序的角度断言，所有的服务都是原子的，而与它是业务服务还是系统服务无关。做出这样的区别仅仅是为了引入粒度这个重要的概念。将业务程序分解成服务不仅仅是一个抽象的过程；它具有非常真实的现实含义。根据定义，服务可能是低级（细粒度的）函数，也可能是复杂的高级（粗粒度的）函数，并且在性能、灵活性、可维护性和可重用性方面都有很现实的折衷选择。定义服务的过程通常是在更大的作用域（应用程序框架的作用域）内完成的。这才是必须做的实际工作：也就是开发基于组件的应用程序框架，其中，服务定义为一组可重用的组件，而这些组件又可以用来构建新的应用程序或集成现有的软件资产。

现在，可以获得很多这样的框架；在 IBM，一些像 EWA、JADE 和 Struts （来自 Jakarta）的这样的框架正用在客户集成场景中。以 EWA （读作“Eva”） 为例（它来自 IBM Software Group Advanced Technology Solutions 组），在一个较高的层次上，框架看起来如 图 1 所示。在这个框架中，配置定义了一个应用程序，描述了该应用程序的组件以及它们调用的顺序和方法。以源中立的方式接收输入并将其传送到应用程序。因此，举例来说，用现有的 ATM 访问将因特网连接添加到一个银行应用程序，对应用程序逻辑来说是透明的。前端设备和协议处理程序使其成为可能。核心提供系统级服务，而特定用途的使得能够连接后端企业应用程序，这样它们就可以保持原来的状态，或者在一段时间以后进行迁移。虽然 EWA 是完全遵循 J2EE，但是它可以连接到外部基于 DCOM 或 CORBA 组件的系统。

现在，EWA 包括超过 1500 个的常规和特定用途的组件，从而大大地减少了编写新的应用程序所需的代码数量。本系列的另一篇文章将详细地研究应用程序框架以及用户在开发这样一个应用程序框架的过程中需要什么。

回页首

解决前面的问题

现在，让我们回到讨论第一个集成场景，寻找一个将所需的接口数量减到最少的 Scheme，如 图 2 所示。

这张图看起来可能过于简化，但是现在可以很清楚地看出，在像 EWA 这样的框架中，这张图是一个起点。现在，添加属于体系结构概念范围的服务总线（Service Bus）（在 图 3 中用深色的中线表示）和服务或流管理器来连接服务和提供服务请求的路径。流管理器处理定义好的执行序列或服务流，它们将按照适当的顺序调用所需的服务来产生最后的结果。业务流程执行语言（Business Process Execution Language，BPEL）就是这种将流程定义为一组服务调用的技术的例子。

在这里，您需要确定如何调用服务，因而您将添加应用程序配置。接着，虚拟化输入和输出。最后，提供到后端流程的连接，以便使它们可以按“仅此状态”运行，并且还可以在将来进行迁移。现在，这个高层次的图至少在结构上是完整的了，如 图 4 所示。

这张图与 EWA 框图有一些类同之处是毫不奇怪的；在最高的层次上，任何健壮的应用程序框架都必须提供这些功能。然而，从现在起，真正的工作开始了——构建 1500 个组件来丰富这个骨架。这就是为什么很多 IT 架构师选择在一个现有的框架中进行实现的原因；把现有的应用程序分解成用于框架的组件就够了，而不必重新开发所有其他已知将要用到的通用用途组件和系统组件。无论您如何使用它，您都可以使用现有的技术和框架来实现该体系结构，所以您绕了一整圈，现在又回到了开始的地方，在这里，流程首先分析必须解决的业务问题。如果您敢肯定您的体系结构事实上是可实现的，您现在就可以这样做。

回页首

体系结构中的集成需求

讨论至此，集成已限定为通过基于组件的服务进行的应用程序的集成，但是集成这个主题比这要宽泛得多。在估计一个体系结构的需求时，必须考虑一些集成的类型或“方式”。您必须考虑如下几方面：

• 应用程序集成
• 终端用户界面集成
• 应用程序连接
• 流程集成
• 信息集成
• 构建集成开发模型。

终端用户界面集成涉及如何集成特定用户访问的全部应用程序和服务来提供可用、高效、一致的界面。它是一个正在发展的主题，而新的发展在近期将主要取决于 Portal 服务器使用方面的进展。虽然 Portlet 已经可以通过 Web 服务调用本地服务组件，但是新技术（比如用户远程 Portlet 的 Web 服务）将使内容和应用程序提供者能够创建交互式服务，这些服务在因特网上可以通过 Portal 即插即用，从而为很多新的集成提供了可能。

应用程序连接是一种集成方式，它涉及体系结构必须支持的所有类型的连接。在一个层次上，这意味着数据的同步和异步通信、路由、转换和高速分布、以及网关和协议转换器等等。而在另一个层次上，它还与输入和输出或源（sources）和汇（sinks）的虚拟化有关，正如您在 EWA 的通道（Channel）和协议转换程序（Protocol Handlers）中所看到的。这里的问题在于数据移入、移出以及在实现体系结构的框架中移动的方式。

流程集成涉及开发映射到业务流程和为业务流程提供解决方案的计算流程、将应用程序集成到流程以及集成一些流程与其他一些流程。虽然第一项需求可能看起来似乎无关紧要，不过就是体系结构提供一个模拟基本业务问题的环境，但是，如果在这一层中不进行充分的分析，体系结构的任何实现注定都将失败，不管它采用的技术是多么的巧妙。将应用程序集成到流程可能包括企业中的应用程序，也可能涉及调用远程系统中的应用程序或服务，而这些远程系统多半属于业务合作伙伴。同样地，流程层集成可能涉及整个流程的集成而不仅仅是来自外部源的单个服务，比如供应链管理或金融服务这样横跨多个机构的流程。为了满足这样的应用程序和流程的集成需求，可以使用像 BPEL4WS 这样的技术，而应用程序框架也可以使用程序配置 Scheme（比如在 EWA 中看到的）。实际上，可以在底层使用 BPEL4WS 来构造一个高层配置 Scheme，然后通过一个引擎来驱动，这个引擎不仅提供流管理，而且还提供其他功能。然而，在构建这一切之前，您应该首先了解体系结构方面的需求，然后，再构建合适的基础架构。

信息集成是一个流程，其作用在于为所有需要它的应用程序提供对企业中全部数据的一致访问，而不管这些应用程序是以什么形式需要它，也不受数据的格式、来源或位置的限制。在实现时，这项需求可能包括 适配器和转换引擎，不过它通常要比这复杂。而关键的概念往往是数据的虚拟化，这可能包括 数据总线（Data Bus）的开发，企业中的所有应用程序都通过标准服务或接口从数据总线中请求数据。因此，不管数据是来自电子数据表、本地文件、SQL 或 DL/I 数据库，还是来自内存中的数据存储，都可以将数据提供给应用程序。永久存储中的数据格式可能还不为应用程序所知。应用程序更不知道管理数据的操作系统，因而访问 AIX 或 Linux 系统中的本地文件的方式与这些文件放在 Windows、OS/2、ZOS 或其他系统中时访问它们的方式相同。同样地，数据的位置也是透明的；由于它是由共同的服务提供的，所以是由访问服务而不是由应用程序来负责查询数据（无论是本地的还是远程的），然后按照请求的格式提供数据。

应用程序开发环境的最后一项需求是，必须考虑可能在企业中实现的集成的所有方式和层次，并且为它们的开发和部署做好准备。要想真正做到健壮，开发环境必须包括（和执行）一种方法来明确地规定如何设计和构建服务和组件，以便促进重用、消除冗余和简化测试、部署和维护。

上面列出的所有集成方式在任何企业中都有一定程度的体现，尽管在某些情况下它们可能是简化的，或者没有明确地进行定义；因而，在着手设计新的体系结构框架时，您必须全面的考虑它们。特定的 IT 环境可能只有很少的数据源类型，因此，消息集成可能会很简单。同样地，应用程序连接的作用域可能也很有限。虽然如此，如果希望框架能够随着企业的成长和变化成功地继续得以保持，则框架中的集成功能仍然必须由服务提供，而不是由特定的应用程序来完成。

回页首

部署面向服务的体系结构的好处

面向服务的体系结构可以基于现有的系统投资来发展，而不需要彻底重新创建系统。如果组织将开发力量集中在创建服务、利用现有的技术、结合基于组件的方法来开发软件上，将获得如下几方面好处：

• 利用现有资产 —— 这是首要的需求。通过使用适当的 SOA 框架并使其可用于整个企业，可以将业务服务构造成现有组件的集合。使用这种新的服务只需要知道它的接口和名称。服务的内部细节以及在组成服务的 组件之间传送的数据的复杂性都对外界隐藏了。这种组件的匿名性使组织能够利用现有的投资，从而可以通过合并构建在不同的机器上、运行在不同的操作系统中、用不同的编程语言开发的组件来创建服务。遗留系统可以通过 Web 服务接口来封装和访问。
  
• 商品化基础架构 —— 在所有不同的企业应用程序之间，基础架构的开发和部署将变得更加一致。现有的组件、新开发的组件和从厂商购买的组件可以合并在一个定义良好的 SOA 框架内。这样的组件集合将被作为服务部署在现有的基础构架中，从而使得可以更多地将基础架构作为一种商品化元素来加以考虑
  
• 更快的产品上市速度 —— 组织的 Web 服务库将成为采用 SOA 框架的组织的核心资产。使用这些 Web 服务库来构建和部署服务将显著地加快产品的上市速度，因为对现有服务和组件的新的创造性重用缩短了设计、开发、测试和部署产品的时间。
  
• 减少成本 —— 随着业务需求的发展和新的需求的引入，通过采用 SOA 框架和服务库，为现有的和新的应用程序增强和创建新的服务的成本大大地减少了。同样，开发团队的学习难读也降低了，因为他们可能已经熟悉了现有的组件。
  
• 降低风险 —— 重用现有的组件降低了在增强或创建新的业务服务的过程中带来的风险。如前所述，这也减少了维护和管理支持服务的基础架构的风险。
  
• 持续改进业务过程 —— SOA 允许清晰地表示流程流，这些流程流通过在特定业务服务中使用的组件的顺序来标识。这给商业用户提供了监视业务操作的理想环境。业务建模反映在业务服务中。流程操纵是以一定的模式重组部件（构成业务服务的组件）来实现的。这将进一步允许更改流程流，而同时监视产生的结果，因此促进了持续改进。
  
• 以流程为中心的体系结构—— 现有的体系结构模型和实践往往是以程序为中心的。应用程序是为了程序员的便利而开发的。通常，流程信息在组件之间传播。应用程序很像一个黑匣子，没有粒度可用于外部。重用需要复制代码、合并共享库或继承对象。在以流程为中心的体系结构中，应用程序是为过程开发的。流程可以分解成一系列的步骤，每一个步骤表示一个业务服务。实际上，每个过程服务或组件功能都相当于一个子应用程序。将这些子应用程序链接在一起可以创建能够满足业务需求的流程流。这种粒度允许利用和重用整个组织中的子应用程序。

回页首

未来 —— 新模型，新需求

到目前为止，讨论集中在满足现有业务的需求、更好地利用和重用资源以及集成现有的和新的应用程序的相关概念上。但是，一个全新的应用程序模型究竟是什么样的呢？面向服务的体系结构的观念是否仍然有意义或者是必不可少的呢？实际上，两种新的概念已经开始实现了：网格计算（Grid Computing）和按需计算（On-demand Computing）。虽然这两个模型是截然不同的，并且是独立开发的，但是它们之间的关系又是非常的紧密，而每个模型都使 SOA 的发展更加势在必行。

网格计算

深入讨论网格计算超出了本文的范围，但是有几个要点值得提及的。其一，网格计算不仅是使用拥有大量 MIPS 的应用程序来进行计算的解决方案，它还涉及包括硬件、应用程序和数据在内的所有系统资源的虚拟化，因此，在网格中，无论在什么地方，用什么方法，只要需要就可以利用这些资源。其二，前面的章节已经讨论了虚拟化数据源和将应用程序分解成基于组件的服务的重要性，所以很容易理解在网格环境中，一个真正的 SOA 应该更好地获得最多的资源。

按需计算

On-demand 也不在我们讨论的范围之内，但是如果在这里不简要地介绍一下 On-demand 和 SOA 之间的关系，那将是不负责任的。Web 服务是实现 SOA 的技术，而 SOA 是实现 On-demand 应用程序的体系结构。应用程序必需运行在 SOA 框架内，以便获得 on-demand 的好处。

On-demand Web 服务 On-demand 是涵盖宽谱系的 On-demand 消息的一部分。谱系的一端集中于应用程序环境，而另一端则集中于包括像基础架构和自主计算在内的操作环境。业务转换利用应用程序和操作环境来创建 On-demand 业务。On-demand 业务最核心的是 On-demand Web 服务，应用程序层的服务可以按照准时制（just-in-time）集成能力的要求来发现、重构、装配和交付。

Web 服务作为一项切实可行的技术的希望在于，它将通过提供诸如按需服务这样的能力提高业务价值，并且随着时间的推移将转变 IT 组织开发软件的方式。它甚至完全有可能通过 Web 转变在利益共同体（包括贸易合作伙伴、客户和其他类型的合作关系）中经营业务以及提供产品和服务的方式。如果您所有的应用程序共享相同的传输层协议？如果它们都理解相同的接口？如果它们能够参与并理解相同的事务模型？如果您的伙伴也一样？当这一些都实现的时候，展现在您面前的将是什么样的场景呢？相信到那时，您将拥有应用程序和基础架构来支持不断变化的业务情况；您将获得 On-demand 。而 Web 服务和 SOA 会使这一切对应用程序成为可能。

回页首

总结

面向服务的体系结构是下一步应用程序开发的重点。服务和面向服务的体系结构都是关于使用异构网络可寻址的软件组件来设计和构建系统的。面向服务的体系结构是一种具有特殊性质的体系结构，它由强调互操作性和位置透明度的组件互连而成。它常常是在现有系统投资的基础上发展起来的，并不需要彻底重新开发全部的系统；它通过利用当前的资源（包括开发人员、软件语言、硬件平台、数据库和应用程序）来利用组织现有的投资，从而在提高生产力的同时降低成本和风险。这种可适应的、灵活的体系结构类型为在开发和维护中缩短产品上市时间以及降低成本和风险提供了基础。Web 服务是一些实现 SOA 的技术，而 SOA 正在成为开发响应性好、可适应的新型应用程序所选择的体系结构。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
  
  
• 查阅 IBM developerWorks Web services 专区来获得 Web 服务白皮书和工具。
  
  
  
  
• 阅读“迁移到面向服务的体系结构”的 ?1 部分（ developerWorks，2003 年 12 月）。
  
  
  
  
• 要查找 Web 服务和面向服务的体系结构方面的客户项目案例，请参阅 IBM jStart Web 站点。
  
  
  
  
• 阅读关于在面向服务的体系结构中确定服务粒度的合适级别的最佳实践方面的文章，“ Web Services 体系结构和最佳实践"”（ developerWorks，2003年10月）。
  
  
  
  
• 阅读 Accessing CICS transactions as services within a SOA（IBM）。
  
  
  
  
• Zackman Framework for Enterprise Architecture将是这一系列关于 SOA 的文章中另一篇的主题。在 Zachman 框架以外，还开发了几个主要的体系结构框架，其中包括：
  • 联邦企业体系结构框架（FEAF）
  • 用于命令、控制、通信、计算机、智能、监视和侦查（C4ISR）体系结构
  • 开放组织体系结构框架（TOGAF）
  
  
  
  

作者简介

为本文评分

评论

回页首

内容

• 服务的性质
• 解决前面的问题
• 体系结构中的集成需求
• 部署面向服务的体系结构的好处
• 未来 —— 新模型，新需求
• 总结
• 参考资料
• 作者简介
• 建议