开发面向服务的体系结构说明

16/16内容：开发面向服务的体系结构的情况面向服务的体系结构的需求总结参考资料关于作者相关内容：Web服务体系结构与最佳实践在Web服务专区还有：教学工具与产品所有的文章简介和概述级不：中级KishoreChannabasavaiah，执行架构师，IBMGlobalServices

KerrieHolley，杰出工程师，电子商务集成解决方案首席架构师，IBMGlobalServices

EdwardM.Tuggle,Jr.，高级软件工程师，IBMSoftwareGroup

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

一些情况总是相同的，特不是IT组织所面对的业务问题。公司治理层总是努力争取更好地利用IT、猎取更大的投资回报率（ROI）、集成历史上分离的系统和更快地实现新系统；然而时至今日，情况发生了些许变化。现在，您遇到的是更复杂的环境。必须重用而不是替换遗留系统，因为考虑到更有限的预算，替换的成本是高昂的。您将发觉费用低廉、无处不在的Internet访问使得建立一个全新的业务模型成为可能。公司至少需要评估那个模型，因为竞争使然。合并和收购的增长差不多成为家常便饭，因此必须将整个IT组织、应用程序和基础架构集成和融合在一起。在如此复杂的环境，点解决方案只会使问题进一步恶化，而决可不能引导我们走出重林。必须在一个以异构为基础的环境中开发系统，因为它们必须容纳种类繁多的硬件、操作系统、中间件、语言和数据存储。长达数十年的进展和演化积存起来的阻碍导致了严峻的复杂性。面对所有这些对IT业务的挑战，专门多CIO将应用程序集成作为首要任务也就不是令人惊奇的情况了，如图1所示。图1.CIO优先考虑的情况

另一问题-冗余和不可重用编程

考虑一个银行有一些分离的“地窖”——在银行内不为其他系统所知的自包含应用程序系统。这些应用程序系统中的第一个可能是优秀的设计，同样，第二个、第三个等等可能差不多上。然而每一个差不多上针对银行中不同业务的，是单独投资的孤立项目。因而，例如猎取账户余额的功能在ATM系统、分行出纳员交付系统、信用卡计分系统差不多上重复的，即便它们存取相同数据库中的相同会计数据数据。现在，假设该银行必须为客户开发Internet服务、在线银行或在线贷款发放系统以保持竞争力，结果会如何样。新系统只会给差不多存在的冗余编程问题雪上加霜，除非通过某种方式使得现有的代码能够重用。真正的集成难题-接口多样性

同样考虑n（n-1）集成问题。任何组织都会碰到某些类型的集成问题；或许是因为一次公司的合并、一个新的商业联盟或者仅仅是需要互连现有的系统。假如n个应用程序系统必须直接互连，那么将会产生n(n-1)个连接或接口。在图2中，每个箭头表示一个接口。图2.n个应用程序的直接集成

因此，假如另一个应用程序系统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服务更有可能成为提供提供有效的、可靠的和可扩展的机器到机器交互的标准，这是几个技术和文化上必须具备的先决条件适时结合的产物。这些先决条件包括：无处不在的、开放标准的、低成本的网络基础架构和技术。它有助于一个分布式环境的形成，那个环境更有利于采纳Web服务，而不是CORBA和DCE在一个以网络为中心的领域内达到的同意程度和技术成熟水平。它要求互操作性以实现关键的业务目标（比如，分布式协作）一致同意基于Internet的开放标准和相关技术是实现低成本互操作性的最好方法。基于网络的技术（比如TCP/IP）、工具集（IDE、UML等等）、平台（比如J2EE平台）和相关的方法（比如OO、服务等等）的成熟水平。它们提供了简化松散耦合的、可互操作的、机器到机器的交互（一种比CORBA用户体验到的高级得多的状态）所需的基础架构。面向服务的体系结构同意设计如此的软件系统，它通过公布的可发觉的接口为其他的应用程序提供服务，而其中的服务能够通过网络进行调用。当您用Web服务技术来实现面向服务的体系结构时，您是在一个更强大、更灵活的编程模型中创建一种新的构建应用程序的方式，从而降低开发成本、持有成本以及实现风险。SOA既是体系结构模型，又是编程模型，是一种考虑构建软件的方式。然而，还有更重要的机会刚刚出现。其中第一个确实是网格计算，网格计算不仅是使用拥有大量MIPS的应用程序来进行计算的解决方案，而且还将提供一个框架，通过此框架能够动态地定位、重定位、平衡和治理大量的服务，如此，不管系统上的负载如何，总能够保证安全地猎取所需的应用程序。而这又明显地需要按需计算的概念（on-demandcomputing），按需计算可能是在任何配置下实现的，从简单的服务器集群到有1024个节点的SP2网络。用户需要解决问题和适当的用于解决问题的计算资源——不多也许多——同时为实际使用的资源付费。这些新功能的有效使用将需要重新构造许多现有的应用程序。现有的单一应用程序能够在这些环境中运行，但没有以最优的方式来使用可用的资源。那个问题和先前讨论过的问题一起能够产生如下结论：必须作出全然的改变——迁移到面向服务的体系结构。面向服务的体系结构的需求依照上面讨论的问题，能够专门明显地看出，应该开发一种体系结构来满足所有的需求，这些需求包括：首要的一点确实是利用现有的资产。现有系统专门少能够抛弃，它们通常都包含关于企业专门有价值的东西。从战略上讲，目标是构造一个新的体系结构来制造所有想要的价值，然而，从战术上讲，必须集成现有系统，以便随着时刻的推移，能够在可治理、渐进式项目中分化或取代它们。支持所有必需的集成类型或“样式”。这包括：用户交互——能够提供单一的、交互式的用户体验应用程序连接性——通信层构成了所有体系结构的基础流程集成——编排应用程序和服务信息集成——联合和移动企业数据依集成需求而构建——构建和部署新的应用程序和服务。同意渐进式实现和资产迁移——这将支持开发这种体系结构的一个最关键的方面：获得更大的投资回报率（ROI）的能力。数不清的集成项目由于它们的复杂性、成本和不切实际的实现进度安排而失败。包括一个以标准的组件框架为基础构建的开发环境，促进更好地重用模块和系统，同意将遗留资产转移到那个框架中，同时考虑到新技术的及时实现。同意实现新的计算模型；特不是，新的基于Portal的客户端模型、网格计算和按需计算（on-demandcomputing）。面向服务的体系结构——不只是Web服务

Web服务的出现产生了全然的改变，因为专门多Web服务项目的成功显示这种技术事实上确实存在，借此您能够实现真正的面向服务的体系结构。它使您又往回走了一步，不仅分析您的应用程序的体系结构，而且还要分析您正设法解决的差不多业务问题。从业务的角度来看，它不再是一个技术问题，而是要开发一种应用程序体系结构和框架，能够在其中定义业务问题，还能够以一致的可重复的方式来实现解决方案。只是，首先必须理解Web服务并不等同于面向服务的体系结构。Web服务是包括XML，SOAP，WSDL和UDDI在内的技术的集合，它使您能够针对特定的消息传递和应用程序集成问题构建编程解决方案。随着时刻的推移，您有理由相信这些技术将逐渐成熟并最终为更好、更有效、更健壮的技术所取代，然而，就目前的情况而言，它们能够发挥作用。至少，它们是SOAs能够最终实现这种观念的证明。那么，面向服务的体系结构实际上是由什么组成的呢？SOA只只是是一种体系结构。它不是任何诸如Web服务如此的特定技术的集合；而是超越它们的，在理想的情况下，是完全独立于它们的。在业务环境中，SOA的纯粹的体系结构定义可能会是如此的“一种应用程序体系结构，在这种体系结构中，所有功能都定义为独立的服务，这些服务带有定义明确的可调用接口，能够以定义好的顺序调用这些服务来形成业务流程”。请注意那个地点的表述：所有功能都定义为服务。这仅仅包括业务功能、由底层功能组成的业务事务和系统服务功能。这将会产生粒度问题，后面我们将对此进行讨论。所有的服务差不多上独立的。它们就像“黑匣子”一样运行：外部组件既不明白也不关怀它们如何执行它们的功能，而仅仅关怀它们是否返回期望的结果。在其最一般的意义上来讲，接口是可调用的；也确实是讲，在体系结构的层面上，它们究竟是本地的（在本系统内）依旧远程的（在直接系统外）、是用什么互连Scheme或协议来调用或需要什么样的基础架构组件来连接，差不多上无关紧要的。服务可能是在相同的应用程序中，也可能是在公司内部网内完全不同的系统上的不对称多处理器的不同地址空间中，还有可能是在用于B2B配置的合作伙伴的系统上的应用程序中。在所有这些表述中，接口是最关键的，同时也是调用应用程序关注的焦点。它定义了必需的参数和结果的类型；因而，它定义了服务的类型，而不是实现服务的技术。系统的责任是实现和治理服务的调用，而不是调用应用程序。这使得能够认识到两个关键的特征：其一，服务是真正独立的；其二，它们是能够治理的。治理包括许多功能，其中有：安全性——请求的授权、加密和解密（在需要时）、确认等等部署——出于性能、可用性冗余或其他方面的缘故，同意服务在网络内重新部署（移动）日志——用于审核、测量等等动态重新路由——用于故障排除（failover）或负载平衡维护——治理服务的新版本总结在第一部分中，您差不多简要地分析了一些导致需要考虑SOA的问题，这些需求寄希望于新的体系结构。而在第二部分中，我们将研究服务的类型，构造一个基于服务的组件的应用程序框架和一些今后的计算环境，这些环境将使得SOA的开发更加势在必行。参考资料查阅IBMdeveloperWorksWebservices专区来获得Web服务白皮书和工具。要查找Web服务和面向服务的体系结构方面的客户项目案例，请参阅IBMjStartWeb站点。阅读文章BestpracticesfordeterminingtheproperlevelofgranularityofserviceswithinaSOA（developerWorks，2003年10月）。阅读AccessingCICStransactionsasserviceswithinaSOA（IBM）。ZackmanFrameworkforEnterpriseArchitecture将是这一系列关于SOA的文章中另一篇的主题。在Zachman框架以外，还开发了几个要紧的体系结构框架，其中包括：联邦企业体系结构框架（FEAF）用于命令、操纵、通信、计算机、智能、监视和侦查（C4ISR）体系结构开放组织体系结构框架（TOGAF）关于作者

KishoreChannabasavaiah获得了印度Bangalore大学机械工程学士学位。他现在是IBM全球服务芝加哥创新中心（ChicagoInnovationCenterofIBMGlobalServices）的执行架构师。他专门从事Web服务和端到端解决方案的研究，为电子商务的集成解决方案提供思想指导。目前，他侧重于Web应用程序的解决方案、技术解决方案评论、Web服务、面向服务的体系结构和普及计算（PervasiveComputing）。您能够通过kishorec@与Kishorec联系。

KerrieHolley获得了DePaul大学数学文学学士学位和法学博士学位。他现在是IBMGlobalServices的杰出工程师和电子商务集成解决方案首席架构师。在电子商务集成解决方案方面，他提供Web服务实践的思想领导。他目前要紧从事软件工程最佳实践、端到端高级Web开发、自适应的企业体系结构、体系结构评论、Web服务和面向服务的体系结构。您能够通过klholley@与Kerrie联系。

EdwardM.Tuggle,Jr.获得了俄克拉何马州大学数学理学士学位，目前是IBMSoftwareGroupjStartEmergingTechnologySolutionsteam的高级软件工程师。他在IBM从事操作系统设计、开发和维护工作有23年，在过去的6年里研究的是Java技术和其他新兴技术。现在，Edward专攻Web服务和面向服务的体系结构。您能够通过b391747@与Edward联系。

迁移到面向服务的体系结构，第2部分英文原文内容：服务的性质解决前面的问题体系结构中的集成需求部署面向服务的体系结构的好处以后——新模型，新需求总结参考资料关于作者相关内容：WebServices体系结构和最佳实践迁移到面向服务的体系结构，第1部分在Web服务专区还有：教学工具与产品所有的文章简介和概述（接着）级不：中级KishoreChannabasavaiah，执行架构师，IBMGlobalServices

KerrieHolley，杰出工程师，电子商务集成解决方案首席架构师，IBMGlobalServices

EdwardM.Tuggle,Jr.，高级软件工程师，IBMSoftwareGroup

2004年1月这是一系列文章的第二部分。这一系列文章旨在关心您更好地理解面向服务的体系结构（SOA）的价值，制订出一个实际的打算来评估您现在的基础架构，并把它转变成一个真正的面向服务的体系结构。其目的在于，当您读完本文时，您将理解什么缘故声称SOA是把现有资产带到以后的最好的平台，同时也使得迅速而正确地开发以后的程序成为可能。另外，您将对在打算如此一次迁移的过程中要紧考虑的事项有更好的理解。这一系列文章的第一部分描述了推动考虑SOA的动力和如此的一个体系结构的需求。现在，第二部分将接着讨论服务和接口。服务的性质什么是服务？如前所述，在一个典型的业务环境里，服务意味着业务函数、业务事务和系统服务。业务函数可能是getStockQuote、getCustomerAddress或checkCreditRating。业务事务可能是commitInventory、sellCoveredOption或scheduleDelivery。系统服务可能是logMessageIn、getTimeStamp或openFile。请注意各种类型服务之间的区不。从应用程序的角度来看，业务函数实际上是原子的非系统函数。业务事务专门像是调用应用程序的简单函数，然而它们可能是作为自己的事务的上下文所包含的复合函数来实现的。它们可能包括多个底层函数，这些底层函数对调用者来讲是透明的。系统函数是能够从诸如Windows或者Linux如此的特定平台中抽象出来的广义函数。应用程序框架可能提供像openFile如此的广义函数来有效地虚拟化数据源，从而能够在不考虑真实数据源的类型和位置的情况下使用这类函数。这看起来像人为地规定服务之间的区不；您能够从应用程序的角度断言，所有的服务差不多上原子的，而与它是业务服务依旧系统服务无关。做出如此的区不仅仅是为了引入粒度那个重要的概念。将业务程序分解成服务不仅仅是一个抽象的过程；它具有特不真实的现实含义。依照定义，服务可能是低级（细粒度的）函数，也可能是复杂的高级（粗粒度的）函数，同时在性能、灵活性、可维护性和可重用性方面都有专门现实的折衷选择。定义服务的过程通常是在更大的作用域（应用程序框架的作用域）内完成的。这才是必须做的实际工作：也确实是开发基于组件的应用程序框架，其中，服务定义为一组可重用的组件，而这些组件又能够用来构建新的应用程序或集成现有的软件资产。现在，能够获得专门多如此的框架；在IBM，一些像EWA、JADE和Struts（来自Jakarta）的如此的框架正用在客户集成场景中。以EWA（读作“Eva”）为例（它来自IBMSoftwareGroupAdvancedTechnologySolutions组），在一个较高的层次上，框架看起来如图1所示。在那个框架中，配置定义了一个应用程序，描述了该应用程序的组件以及它们调用的顺序和方法。以源中立的方式接收输入并将其传送到应用程序。因此，举例来讲，用现有的ATM访问将因特网连接添加到一个银行应用程序，对应用程序逻辑来讲是透明的。前端设备和协议处理程序使其成为可能。核心提供系统级服务，而特定用途的使得能够连接后端企业应用程序，如此它们就能够保持原来的状态，或者在一段时刻以后进行迁移。尽管EWA是完全遵循J2EE，然而它能够连接到外部基于DCOM或CORBA组件的系统。图1.EWA框图

现在，EWA包括超过1500个的常规和特定用途的组件，从而大大地减少了编写新的应用程序所需的代码数量。本系列的另一篇文章将详细地研究应用程序框架以及用户在开发如此一个应用程序框架的过程中需要什么。解决前面的问题现在，让我们回到讨论第一个集成场景，查找一个将所需的接口数量减到最少的Scheme，如图2所示。图2.将接口减到最少

这张图看起来可能过于简化，然而现在能够专门清晰地看出，在像EWA如此的框架中，这张图是一个起点。现在，添加属于体系结构概念范围的服务总线（ServiceBus）（在图3中用深色的中线表示）和服务或流治理器来连接服务和提供服务请求的路径。流治理器处理定义好的执行序列或服务流，它们将按照适当的顺序调用所需的服务来产生最后的结果。业务流程执行语言（BusinessProcessExecutionLanguage，BPEL）确实是这种将流程定义为一组服务调用的技术的例子。图3.添加总线和执行治理

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

这张图与EWA框图有一些类同之处是毫不惊奇的；在最高的层次上，任何健壮的应用程序框架都必须提供这些功能。然而，从现在起，真正的工作开始了——构建1500个组件来丰富那个骨架。这确实是什么缘故专门多IT架构师选择在一个现有的框架中进行实现的缘故；把现有的应用程序分解成用于框架的组件就够了，而不必重新开发所有其他已知将要用到的通用用途组件和系统组件。不管您如何使用它，您都能够使用现有的技术和框架来实现该体系结构，因此您绕了一整圈，现在又回到了开始的地点，在那个地点，流程首先分析必须解决的业务问题。假如您敢确信您的体系结构事实上是可实现的，您现在就能够如此做。体系结构中的集成需求讨论至此，集成已限定为通过基于组件的服务进行的应用程序的集成，然而集成那个主题比这要宽泛得多。在可能一个体系结构的需求时，必须考虑一些集成的类型或“方式”。您必须考虑如下几方面：应用程序集成终端用户界面集成应用程序连接流程集成信息集成构建集成开发模型。终端用户界面集成涉及如何集成特定用户访问的全部应用程序和服务来提供可用、高效、一致的界面。它是一个正在进展的主题，而新的进展在近期将要紧取决于Portal服务器使用方面的进展。尽管Portlet差不多能够通过Web服务调用本地服务组件，然而新技术（比如用户远程Portlet的Web服务）将使内容和应用程序提供者能够创建交互式服务，这些服务在因特网上能够通过Portal即插即用，从而为专门多新的集成提供了可能。应用程序连接是一种集成方式，它涉及体系结构必须支持的所有类型的连接。在一个层次上，这意味着数据的同步和异步通信、路由、转换和高速分布、以及网关和协议转换器等等。而在另一个层次上，它还与输入和输出或源（sources）和汇（sinks）的虚拟化有关，正如您在EWA的通道（Channel）和协议转换程序（ProtocolHandlers）中所看到的。那个地点的问题在于数据移入、移出以及在实现体系结构的框架中移动的方式。流程集成涉及开发映射到业务流程和为业务流程提供解决方案的计算流程、将应用程序集成到流程以及集成一些流程与其他一些流程。尽管第一项需求可能看起来大概无关紧要，只是确实是体系结构提供一个模拟差不多业务问题的环境，然而，假如在这一层中不进行充分的分析，体系结构的任何实现注定都将失败，不管它采纳的技术是多么的巧妙。将应用程序集成到流程可能包括企业中的应用程序，也可能涉及调用远程系统中的应用程序或服务，而这些远程系统多半属于业务合作伙伴。同样地，流程层集成可能涉及整个流程的集成而不仅仅是来自外部源的单个服务，比如供应链治理或金融服务如此横跨多个机构的流程。为了满足如此的应用程序和流程的集成需求，能够使用像BPEL4WS如此的技术，而应用程序框架也能够使用程序配置Scheme（比如在EWA中看到的）。实际上，能够在底层使用BPEL4WS来构造一个高层配置Scheme，然后通过一个引擎来驱动，那个引擎不仅提供流治理，而且还提供其他功能。然而，在构建这一切之前，您应该首先了解体系结构方面的需求，然后，再构建合适的基础架构。信息集成是一个流程，其作用在于为所有需要它的应用程序提供对企业中全部数据的一致访问，而不管这些应用程序是以什么形式需要它，也不受数据的格式、来源或位置的限制。在实现时，这项需求可能包括适配器和转换引擎，只是它通常要比这复杂。而关键的概念往往是数据的虚拟化，这可能包括数据总线（DataBus）的开发，企业中的所有应用程序都通过标准服务或接口从数据总线中请求数据。因此，不管数据是来自电子数据表、本地文件、SQL或DL/I数据库，依旧来自内存中的数据存储，都能够将数据提供给应用程序。永久存储中的数据格式可能还不为应用程序所知。应用程序更不明白治理数据的操作系统，因而访问AIX或Linux系统中的本地文件的方式与这些文件放在Windows、OS/2、ZOS或其他系统中时访问它们的方式相同。同样地，数据的位置也是透明的；由于它是由共同的服务提供的，因此是由访问服务而不是由应用程序来负责查询数据（不管是本地的依旧远程的），然后按照请求的格式提供数据。应用程序开发环境的最后一项需求是，必须考虑可能在企业中实现的集成的所有方式和层次，同时为它们的开发和部署做好预备。要想真正做到健壮，开发环境必须包括（和执行）一种方法来明确地规定如何设计和构建服务和组件，以便促进重用、消除冗余和简化测试、部署和维护。上面列出的所有集成方式在任何企业中都有一定程度的体现，尽管在某些情况下它们可能是简化的，或者没有明确地进行定义；因而，在着手设计新的体系结构框架时，您必须全面的考虑它们。特定的IT环境可能只有专门少的数据源类型，因此，消息集成可能会专门简单。同样地，应用程序连接的作用域可能也专门有限。尽管如此，假如希望框架能够随着企业的成长和变化成功地接着得以保持，则框架中的集成功能仍然必须由服务提供，而不是由特定的应用程序来完成。部署面向服务的体系结构的好处面向服务的体系结构能够基于现有的系统投资来进展，而不需要完全重新创建系统。假如组织将开发力量集中在创建服务、利用现有的技术、结合基于组件的方法来开发软件上，将获得如下几方面好处：利用现有资产——这是首要的需求。通过使用适当的SOA框架并使其可用于整个企业，能够将业务服务构造成现有组件的集合。使用这种新的服务只需要明白它的接口和名称。服务的内部细节以及在组成服务的组件之间传送的数据的复杂性都对外界隐藏了。这种组件的匿名性使组织能够利用现有的投资，从而能够通过合并构建在不同的机器上、运行在不同的操作系统中、用不同的编程语言开发的组件来创建服务。遗留系统能够通过Web服务接口来封装和访问。商品化基础架构——在所有不同的企业应用程序之间，基础架构的开发和部署将变得更加一致。现有的组件、新开发的组件和从厂商购买的组件能够合并在一个定义良好的SOA框架内。如此的组件集合将被作为服务部署在现有的基础构架中，从而使得能够更多地将基础架构作为一种商品化元素来加以考虑更快的产品上市速度——组织的Web服务库将成为采纳SOA框架的组织的核心资产。使用这些Web服务库来构建和部署服务将显著地加快产品的上市速度，因为对现有服务和组件的新的制造性重用缩短了设计、开发、测试和部署产品的时刻。减少成本——随着业务需求的进展和新的需求的引入，通过采纳SOA框架和服务库，为现有的和新的应用程序增强和创建新的服务的成本大大地减少了。同样，开发团队的学习难读也降低了，因为他们可能差不多熟悉了现有的组件。降低风险——重用现有的组件降低了在增强或创建新的业务服务的过程中带来的风险。如前所述，这也减少了维护和治理支持服务的基础架构的风险。持续改进业务过程——SOA同意清晰地表示流程流，这些流程流通过在特定业务服务中使用的组件的顺序来标识。这给商业用户提供了监视业务操作的理想环境。业务建模反映在业务服务中。流程操纵是以一定的模式重组部件（构成业务服务的组件）来实现的。这将进一步同意更改流程流，而同时监视产生的结果，因此促进了持续改进。以流程为中心的体系结构——现有的体系结构模型和实践往往是以程序为中心的。应用程序是为了程序员的便利而开发的。通常，流程信息在组件之间传播。应用程序专门像一个黑匣子，没有粒度可用于外部。重用需要复制代码、合并共享库或继承对象。在以流程为中心的体系结构中，应用程序是为过程开发的。流程能够分解成一系列的步骤，每一个步骤表示一个业务服务。实际上，每个过程服务或组件功能都相当于一个子应用程序。将这些子应用程序链接在一起能够创建能够满足业务需求的流程流。这种粒度同意利用和重用整个组织中的子应用程序。以后——新模型，新需求到目前为止，讨论集中在满足现有业务的需求、更好地利用和重用资源以及集成现有的和新的应用程序的相关概念上。然而，一个全新的应用程序模型究竟是什么样的呢？面向服务的体系结构的观念是否仍然有意义或者是必不可少的呢？实际上，两种新的概念差不多开始实现了：网格计算（GridComputing）和按需计算（On-demandComputing）。尽管这两个模型是截然不同的，同时是独立开发的，然而它们之间的关系又是特不的紧密，而每个模型都使SOA的进展更加势在必行。网格计算

深入讨论网格计算超出了本文的范围，然而有几个要点值得提及的。其一，网格计算不仅是使用拥有大量MIPS的应用程序来进行计算的解决方案，它还涉及包括硬件、应用程序和数据在内的所有系统资源的虚拟化，因此，在网格中，不管在什么地点，用什么方法，只要需要就能够利用这些资源。其二，前面的章节差不多讨论了虚拟化数据源和将应用程序分解成基于组件的服务的重要性，因