迁移到面向服务的体系结构

迁移到面向服务的体系结构

撰文/Kishore Channabasavaiah, Kerrie Holley, Edward M.Tuggle, Jr.

本文旨在帮助您更好地理解面向服务的体系结构（SOA）的价值，制订出一个实际的计划来评估您现在的基础架构，并把它转变成一个真正的面向服务的体系结构。其目的在于，当您读完本文时，您将理解为什么声称SOA是把现有资产带到未来的最好的平台，同时也使得迅速而正确地开发未来的程序成为可能。另外，您将对在计划这样一次迁移的过程中主要考虑的事项有更好的理解。

开发面向服务的体系结构的情况
在过去的40年里，软件体系结构试图处理日益增长的软件复杂性。但是，复杂性仍在继续增加，传统的体系结构好像已经达到了它们处理此类问题的极限。同时，IT组织的传统需要仍然继续存在；比如，需要对新的业务需求进行快速的反应，需要不断地减少业务中IT的成本，以及吸收、集成新的业务伙伴和新的客户群。作为一个产业，我们经历了能够提供完全的分布式处理的多种计算体系结构和能够运行在任何平台上的编程语言，从而大大缩短了实现的时间表，我们还经历了无数的连接性产品，这些产品能够更快更好地集成应用程序。然而，我们还是没有找到完全的解决方案。现在，业界提出面向服务的体系结构（SOA）作为软件体系结构中下一个发展的阶段来帮助IT组织满足他们面临的越来越多的复杂性的挑战。可是，这种体系结构现实吗？即使它可以被概括和描述出来，它也能真的被实现吗？本文的论点就是断定SOA是现实的；在所有天花乱坠的宣传尘埃落定之后，所有夸大的期望又回到了现实之中，您将发现至少现在SOA是IT组织可以将其现有的资产带到未来，同时又构建新的应用程序系统最好的基础。本文旨在帮助您更好地理解面向服务的体系结构（SOA）的价值，并且制订出一个切实可行的计划来评估您现有的基础架构，然后将其迁移到一个真正的面向服务的体系结构。
曾几何时，现有的Web服务技术刺激了关于面向服务的体系结构（SOA）的讨论。这个讨论并不新鲜；从CORBA扩展到在完全不同的异类平台上应用程序一直到现在，这个概念已经发展10多年了。集成这样的应用程序的问题不断出现，通常是因为有那么多不同的（非CORBA兼容的）对象模型流行起来；因而，很多架构师和工程师都陷入了解决此类问题的泥淖中，开发一种更健壮的体系结构来实现简单、快速和安全的系统和应用程序集成的承诺并没有兑现。然而，问题却在继续增加，并且日益复杂。基本的业务需求，诸如降低成本、减少开发周期、跨企业集成、企业到企业（B2B）和企业到顾客（B2C）集成、更大的投资回报率（ROI）、创建自适应的和自响应的业务模型等等，使我们不停地寻找更好的解决方案；但是，我们越来越觉得“点解决方案（Point Solutions）”不能解决这样的基本问题。在很多情况下，问题在于缺乏一个一致的体系结构框架，在这种体系结构中，可以快速地开发、集成和重用应用程序。更重要的是，我们需要一个这样的体系结构框架，它能够装配组件和服务，以便快速甚至动态地交付应用程序。为什么像Web服务这样的某种技术是好的，但是我们真正需要的是一种不受技术约束的体系结构，有很多文章对此进行了讨论。让我们首先考虑一些基本的问题，这些问题是我们寻求更好的基础的依据，如何解决这些问题将决定我们工作的成败。

首要问题—复杂性
一些事情总是相同的，特别是IT组织所面对的业务问题。公司管理层总是努力争取更好地利用IT、获取更大的投资回报率（ROI）、集成历史上分离的系统和更快地实现新系统；但是时至今日，事情发生了些许变化。现在，您遇到的是更复杂的环境。必须重用而不是替换遗留系统，因为考虑到更有限的预算，替换的成本是高昂的。您将发现费用低廉、无处不在的Internet访问使得建立一个全新的业务模型成为可能。公司至少需要评估这个模型，因为竞争使然。合并和收购的增长已经成为家常便饭，因此必须将整个IT组织、应用程序和基础架构集成和融合在一起。在这样复杂的环境，点解决方案只会使问题进一步恶化，而决不会引导我们走出丛林。必须在一个以异构为基础的环境中开发系统，因为它们必须容纳种类繁多的硬件、操作系统、中间件、语言和数据存储。长达数十年的发展和演化积累起来的影响导致了严重的复杂性。面对所有这些对IT业务的挑战，很多CIO将应用程序集成作为首要任务也就不是令人惊讶的事情了，如图1所示。
另一问题—冗余和不可重用编程
考虑一个银行有一些分离的“地窖”—在银行内不为其他系统所知的自包含应用程序系统。这些应用程序系统中的第一个可能是优秀的设计，同样，第二个、第三个可能都是。但是每一个都是针对银行中不同业务的，是单独投资的孤立项目。因而，例如获取账户余额的功能在ATM系统、分行出纳员交付系统、信用卡计分系统都是重复的，即便它们存取相同数据库中的相同会计数据。现在，假设该银行必须为客户开发Internet服务、在线银行或在线贷款发放系统以保持竞争力，结果会怎么样。新系统只会给已经存在的冗余编程问题雪上加霜，除非通过某种方式使得现有的代码可以重用。

真正的集成难题—接口多样性
同样考虑n（n-1）集成问题。任何组织都会碰到某些类型的集成问题；或许是因为一次公司的合并、一个新的商业联盟或者仅仅是需要互连现有的系统。如果n个应用程序系统必须直接互连，那么将会产生n(n-1)个连接或接口。在图2中，每个箭头表示一个接口。
因此，如果另一个应用程序系统A（第n+1个）必须集成进来，将需要产生、文档化、测试和维护2n个新的接口。虽然在上图中，5个应用程序组成的集合需要20个直接接口，但是添加第6个应用程序将需要10个新接口！而更糟的是，必须修改每个已有的应用程序中的代码以包括进新的接口，因而将发生大量的测试费用。您可以立即为n个应用程序找到产生最小接口数目（n）的最优解决方案，只为每个附加的系统添加一个新的接口，但是，通过直接连接是做不到的。

将来会怎样呢？
在过去的40多年来，软件开发的实践经历了几个不同的编程模型。而进行的每一次转变在某种程度上都是为了处理更高级别的软件复杂性，并且使得可以通过部件、组件或服务来装配应用程序。近来，Java技术促成了平台中立的编程，而XML促成了自描述，因而也促成了平台中立的数据。现在，Web服务通过允许应用程序以对象模型中立的方式实现互连，从而克服了另一个障碍。使用简单的基于XML的消息传递Scheme，Java应用程序能够调用基于DCOM、遵循CORBA甚至是COBOL的应用程序。在新加坡的一台大型机上的CICS或IMS事务能够被一台在慕尼黑的Domino服务器上运行的Lotus脚本驱动的基于COM的应用程序调用。最好的情况是，调用程序很有可能根本不知道该事务在哪里运行、它是由哪种语言编写的以及消息的传输路径。只需提出服务请求，然后就会得到答案。
与其任何一个前身相比，Web服务更有可能成为提供有效的、可靠的和可扩展的机器到机器交互的标准，这是几个技术和文化上必须具备的先决条件适时结合的产物。这些先决条件包括：
l 无处不在的、开放标准的、低成本的网络基础架构和技术。它有助于一个分布式环境的形成，这个环境更有利于采用Web服务，而不是CORBA和DCE。
l 在一个以网络为中心的领域内达到的接受程度和技术成熟水平。它要求互操作性以实现关键的业务目标（比如，分布式协作）。
l 一致同意基于Internet的开放标准和相关技术是实现低成本互操作性的最好方法。
l 基于网络的技术（比如TCP/IP）、工具集（IDE、UML等等）、平台（比如J2EE平台）和相关的方法（比如OO、服务等等）的成熟水平。它们提供了简化松散耦合的、可互操作的、机器到机器的交互（一种比CORBA用户体验到的高级得多的状态）所需的基础架构。
面向服务的体系结构允许设计这样的软件系统，它通过发布的可发现的接口为其他的应用程序提供服务，而其中的服务可以通过网络进行调用。当您用Web服务技术来实现面向服务的体系结构时，您是在一个更强大、更灵活的编程模型中创建一种新的构建应用程序的方式，从而降低开发成本、持有成本以及实现风险。SOA既是体系结构模型，又是编程模型，是一种考虑构建软件的方式。
然而，还有更重要的机会刚刚出现。其中第一个就是网格计算，网格计算不仅是使用拥有大量MIPS的应用程序来进行计算的解决方案，而且还将提供一个框架，通过此框架可以动态地定位、重定位、平衡和管理大量的服务，这样，无论系统上的负载如何，总可以保证安全地获取所需的应用程序。而这又明显地需要按需计算的概念（On Demand Computing），按需计算可能是在任何配置下实现的，从简单的服务器集群到有1024个节点的SP2网络。用户需要解决问题和适当的用于解决问题的计算资源—不多也不少—并且为实际使用的资源付费。
这些新功能的有效使用将需要重新构造许多现有的应用程序。现有的单一应用程序能够在这些环境中运行，但没有以最优的方式来使用可用的资源。这个问题和先前讨论过的问题一起可以产生如下结论：必须作出根本的改变—迁移到面向服务的体系结构。

面向服务的体系结构的需求
根据上面讨论的问题，可以很明显地看出，应该开发一种体系结构来满足所有的需求，这些需求包括：
1. 首要的一点就是利用现有的资产。现有系统很难被抛弃，它们通常都包含对于企业很有价值的东西。从战略上讲，目标是构造一个新的体系结构来创造所有想要的价值，但是，从战术上讲，必须集成现有系统，以便随着时间的推移，可以在可管理、渐进式项目中分化或取代它们。
2. 支持所有必需的集成类型或“样式”。这包括：
l 用户交互—能够提供单一的、交互式的用户体验。
l 应用程序连接性—通信层构成了所有体系结构的基础。
l 流程集成—编排应用程序和服务。
l 信息集成—联合和移动企业数据。
l 依集成需求而构建—构建和部署新的应用程序和服务。
3. 允许渐进式实现和资产迁移—这将支持开发这种体系结构的一个最关键的方面：获得更大的投资回报率（ROI）的能力。数不清的集成项目由于它们的复杂性、成本和不切实际的实现进度安排而失败。
4. 包括一个以标准的组件框架为基础构建的开发环境，促进更好地重用模块和系统，允许将遗留资产转移到这个框架中，并且考虑到新技术的及时实现。
5. 允许实现新的计算模型，特别是新的基于Portal的客户端模型、网格计算和按需计算（On Demand Computing）。

面向服务的体系结构—不只是Web服务
Web服务的出现产生了根本的改变，因为很多Web服务项目的成功显示这种技术事实上确实存在，借此您可以实现真正的面向服务的体系结构。它使您又往回走了一步，不仅分析您的应用程序的体系结构，而且还要分析您正设法解决的基本业务问题。从业务的角度来看，它不再是一个技术问题，而是要开发一种应用程序体系结构和框架，可以在其中定义业务问题，还可以以一致的可重复的方式来实现解决方案。
不过，首先必须理解Web服务并不等同于面向服务的体系结构。Web服务是包括XML、SOAP、WSDL和UDDI在内的技术的集合，它使您能够针对特定的消息传递和应用程序集成问题构建编程解决方案。随着时间的推移，您有理由相信这些技术将逐渐成熟并最终为更好、更有效、更强大的技术所取代，但是，就目前的情况而言，它们可以发挥作用。至少，它们是SOA能够最终实现这种观念的证明。那么，面向服务的体系结构实际上是由什么组成的呢？
SOA只不过是一种体系结构。它不是任何诸如Web服务这样的特定技术的集合；而是超越它们的，在理想的情况下，是完全独立于它们的。在业务环境中，SOA的纯粹的体系结构定义可能会是这样的“一种应用程序体系结构，在这种体系结构中，所有功能都定义为独立的服务，这些服务带有定义明确的可调用接口，可以以定义好的顺序调用这些服务来形成业务流程”。请注意这里的表述：
1. 所有功能都定义为服务。这仅仅包括业务功能、由底层功能组成的业务事务和系统服务功能。这将会产生粒度问题，后面我们将对此进行讨论。
2. 所有的服务都是独立的。它们就像“黑匣子”一样运行：外部组件既不知道也不关心它们如何执行它们的功能，而仅仅关心它们是否返回期望的结果。
3. 在其最一般的意义上来说，接口是可调用的；也就是说，在体系结构的层面上，它们究竟是本地的（在本系统内）还是远程的（在直接系统外）、是用什么互连Scheme或协议来调用或需要什么样的基础架构组件来连接，都是无关紧要的。服务可能是在相同的应用程序中，也可能是在公司内部网内完全不同的系统上的不对称多处理器的不同地址空间中，还有可能是在用于B2B配置的合作伙伴的系统上的应用程序中。
在所有这些表述中，接口是最关键的，同时也是调用应用程序关注的焦点。它定义了必需的参数和结果的类型；因而，它定义了服务的类型，而不是实现服务的技术。系统的责任是实现和管理服务的调用，而不是调用应用程序。这使得可以认识到两个关键的特征：其一，服务是真正独立的；其二，它们是可以管理的。管理包括许多功能，其中有：
1. 安全性—请求的授权、加密和解密（在需要时）、确认等等。
2. 部署—出于性能、可用性冗余或其他方面的原因，允许服务在网络内重新部署（移动）。
3. 日志—用于审核、测量等等。
4. 动态重新路由—用于故障排除（Fail Over）或负载平衡。
5. 维护—管理服务的新版本。

服务的性质
什么是服务？如前所述，在一个典型的业务环境里，服务意味着业务函数、业务事务和系统服务。业务函数可能是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组），在一个较高的层次上，框架看起来如图3所示。在这个框架中，配置定义了一个应用程序，描述了该应用程序的组件以及它们调用的顺序和方法。以源中立的方式接收输入并将其传送到应用程序。因此，举例来说，用现有的ATM访问将因特网连接添加到一个银行应用程序，对应用程序逻辑来说是透明的。前端设备和协议处理程序使其成为可能。核心提供系统级服务，而特定用途的使得能够连接后端企业应用程序，这样它们就可以保持原来的状态，或者在一段时间以后进行迁移。虽然EWA是完全遵循J2EE，但是它可以连接到外部基于DCOM或CORBA组件的系统。
现在，EWA包括超过1500个的常规和特定用途的组件，从而大大地减少了编写新的应用程序所需的代码数量。本系列的另一篇文章将详细地研究应用程序框架以及用户在开发这样一个应用程序框架的过程中需要什么。

解决前面的问题
现在，让我们回到讨论第一个集成场景，寻找一个将所需的接口数量减到最少的Scheme，如图4所示。
这张图看起来可能过于简化，但是现在可以很清楚地看出，在像EWA这样的框架中，这张图是一个起点。现在，添加属于体系结构概念范围的服务总线（Service Bus）（在图5中用深色的中线表示）和服务或流管理器来连接服务和提供服务请求的路径。流管理器处理定义好的执行序列或服务流，它们将按照适当的顺序调用所需的服务来产生最后的结果。业务流程执行语言（Business Process Execution Language，BPEL）就是这种将流程定义为一组服务调用的技术的例子。
在这里，您需要确定如何调用服务，因而您将添加应用程序配置。接着，虚拟化输入和输出。最后，提供到后端流程的连接，以便使它们可以按“仅此状态”运行，并且还可以在将来进行迁移。现在，这个高层次的图至少在结构上是完整的了，如图6所示。
这张图与EWA框图有一些类同之处是毫不奇怪的。在最高的层次上，任何强大的应用程序框架都必须提供这些功能。然而，从现在起，真正的工作开始了——构建1500个组件来丰富这个骨架。这就是为什么很多IT架构师选择在一个现有的框架中进行实现的原因；把现有的应用程序分解成用于框架的组件就够了，而不必重新开发所有其他已知将要用到的通用用途组件和系统组件。无论您如何使用它，您都可以使用现有的技术和框架来实现该体系结构，所以您绕了一整圈，现在又回到了开始的地方，在这里，流程首先分析必须解决的业务问题。如果您敢肯定您的体系结构事实上是可实现的，您现在就可以这样做。

体系结构中的集成需求
讨论至此，集成已限定为通过基于组件的服务进行的应用程序的集成，但是集成这个主题比这要宽泛得多。在估计一个体系结构的需求时，必须考虑一些集成的类型或“方式”。您必须考虑如下几方面：
l 应用程序集成
l 终端用户界面集成
l 应用程序连接
l 流程集成
l 信息集成
l 构建集成开发模型
终端用户界面集成涉及如何集成特定用户访问的全部应用程序和服务来提供可用、高效、一致的界面。它是一个正在发展的主题，而新的发展在近期将主要取决于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环境可能只有很少的数据源类型，因此，消息集成可能会很简单。同样地，应用程序连接的作用域可能也很有限。虽然如此，如果希望框架能够随着企业的成长和变化成功地继续得以保持，则框架中的集成功能仍然必须由服务提供，而不是由特定的应用程序来完成。

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

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

未来—新模型，新需求
到目前为止，讨论集中在满足现有业务的需求、更好地利用和重用资源以及集成现有的和新的应用程序的相关概念上。但是，一个全新的应用程序模型究竟是什么样的呢？面向服务的体系结构的观念是否仍然有意义或者是必不可少的呢？实际上，两种新的概念已经开始实现了：网格计算（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正在成为开发响应性好、可适应的新型应用程序所选择的体系结构。