面向服务架构，它可以根据需求通过网路对鬆散耦合的粗粒度套用组件进行分散式部署、组合和使用。服务层是SOA的基础，可以直接被套用调用，从而有效控制系统中与软体代理互动的人为依赖性。

SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。SOA可以看作是B/S模型、XML（标準通用标记语言的子集）/Web Service技术之后的自然延伸。

SOA将能够帮助软体工程师们站在一个新的高度理解企业级架构中的各种组件的开发、部署形式，它将帮助企业系统架构者以更迅速、更可靠、更具重用性架构整个业务系统。较之以往，以SOA架构的系统能够更加从容地面对业务的急剧变化。

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 中都起着重要的作用。

我可以用面向服务的体系结构做什幺？

对 SOA 的需要来源于需要使业务 IT 系统变得更加灵活，以适应业务中的改变。通过允许强定义的关係和依然灵活的特定实现，IT 系统既可以利用现有系统的功能，又可以準备在以后做一些改变来满足它们之间互动的需要。

下面举一个具体的例子。一个服装零售组织拥有 500 家国际连锁店，它们常常需要更改设计来赶上时尚的潮流。这可能意味着不仅需要更改样式和颜色，甚至还可能需要更换布料、製造商和可交付的产品。如果零售商和製造商之间的系统不兼容，那幺从一个供应商到另一个供应商的更换可能就是一个非常複杂的软体流程。通过利用 WSDL 接口在操作方面的灵活性，每个公司都可以将它们的现有系统保持现状，而仅仅匹配 WSDL 接口并制订新的服务级协定，这样就不必完全重构它们的软体系统了。这是业务的水平改变，也就是说，它们改变的是合作伙伴，而所有的业务操作基本上都保持不变。这里，业务接口可以作少许改变，而内部操作却不需要改变，之所以这样做，仅仅是为了能够与外部合作伙伴一起工作。

另一种形式是内部改变，在这种改变中，零售组织决定它还将把连锁零售商店内的一些地方出租给专卖流行衣服的小商店，这可以看作是採用店中店（store-in-store）的业务模型。这里，虽然公司的大多数业务操作都保持不变，但是它们需要新的内部软体来处理这样的出租安排。儘管在内部软体系统可以承受全面的检修，但是它们需要在这样做的同时不会对与现有的供应商系统的互动产生大的影响。在这种情况下，SOA 模型保持原封不动，而内部实现却发生了变化。虽然可以将新的方面添加到 SOA 模型中来加入新的出租安排的职责，但是正常的零售管理系统继续如往常一样。

为了延续内部改变的观念，IT 经理可能会发现，软体的新配置还可以以另外的一种方式加以使用，比如出租贴上海报的地方以供广告之用。这里，新的业务提议是通过在新的设计中重用灵活的 SOA 模型得出的。这是来自 SOA 模型的新成果，并且还是一个新的机会，而这样的新机会在以前可能是不会有的。

垂直改变也是可能的，在这种改变中，零售商从销售他们自己的服装完全转变到专门通过店中店模型出租地方。如果垂直改变完全从最底层开始的话，就会带来 SOA 模型结构的显着改变，与之一起改变的还可能有新的系统、软体、流程以及关係。在这种情况下，SOA 模型的好处是它从业务操作和流程的角度考虑问题而不是从应用程式和程式的角度考虑问题，这使得业务管理可以根据业务的操作清楚地确定什幺需要添加、修改或删除。然后可以将软体系统构造为适合业务处理的方式，而不是在许多现有的软体平台上常常看到的其他方式。

正如您可以看到的，在这里，改变和 SOA 系统适应改变的能力是最重要的部分。对于开发人员来说，这样的改变无论是在他们工作的範围之内还是在他们工作的範围之外都有可能发生，这取决于是否有改变需要知道接口是如何定义的以及它们相互之间如何进行互动。与开发人员不同的是，架构师的作用就是引起对 SOA 模型大的改变。这种分工，就是让开发人员集中精力于创建作为服务定义的功能单元，而让架构师和建模人员集中精力于如何将这些单元适当地组织在一起，它已经有十多年的历史了，通常用统一建模语言（Unified Modeling Language，UML），并且描述成模型驱动的体系结构（Model-Driven Architecture，MDA）。

对于面向同步和异步套用的，基于请求/回响模式的分散式计算来说，SOA是一场革命。一个应用程式的业务逻辑（business logic）或某些单独的功能被模组化并作为服务呈现给消费者或客户端。这些服务的关键是他们的松耦合特性。例如，服务的接口和实现相独立。套用开发人员或者系统集成者可以通过组合一个或多个服务来构建套用，而无须理解服务的底层实现。举例来说，一个服务可以用.NET或J2EE来实现，而使用该服务的应用程式可以在不同的平台之上，使用的语言也可以不同。.

SOA的实施具有几个鲜明的基本特徵。实施SOA的关键目标是实现企业IT资产的最大化作用。要实现这一目标，就要在实施SOA的过程中牢记以下特徵：

可从企业外部访问

随时可用

粗粒度的服务接口分级

鬆散耦合

可重用的服务

服务接口设计管理

标準化的服务接口

支持各种讯息模式

精确定义的服务契约

SOA服务具有平台独立的自我描述XML文档。Web服务描述语言（WSDL， Web Services Description Language）是用于描述服务的标準语言。

SOA蓝图

SOA 服务用讯息进行通信，该讯息通常使用XML Schema来定义（也叫做XSD， XML Schema Definition）。消费者和提供者或消费者和服务之间的通信多见于不知道提供者的环境中。服务间的通讯也可以看作企业内部处理的关键商业文档。

在一个企业内部，SOA服务通过一个扮演目录列表（directory listing）角色的登记处（Registry）来进行维护。应用程式在登记处（Registry）寻找并调用某项服务。统一描述，定义和集成（UDDI， Universal Description， Definition， and Integration）是服务登记的标準。

每项SOA服务都有一个与之相关的服务品质（QoS， quality of service）。QoS的一些关键元素有安全需求（例如认证和授权），可靠通信（译注：可靠讯息是指，确保讯息“仅且仅仅”传送一次，从而过滤重複信息。），以及谁能调用服务的策略。

纵观信息化建设与套用的历程，儘管出现过XML（标準通用标记语言的子集）、Unicode、UML等众多信息标準，但是许多异构系统之间的数据源仍然使用各自独立的数据格式、元数据以及元模型，这是信息产品提供商一直以来形成的习惯。各个相对独立的源数据集成一起，往往通过构建一定的数据获取与计算程式来实现，这样的做法需要花费大量工作。信息孤岛大量存在的事实，使信息化建设的ROI（投资回报率）大大降低，ETL成为集中这些异构数据的有效工具。 ETL常用于从源系统中提取数据，将数据转换为与目标系统相兼容的格式，然后将其装载到目标系统中。数据经过获取、转换、装载后，要产生套用价值，还需另外的数据展现工具予以实现，如此複杂的数据套用过程，必定产生高昂的套用成本。

结构化的数据管理尚可通过以上方法，予以实现其集成套用。在非结构化的内容方面，这些具有挑战性的问题令人生畏。内容管理的套用方案基于不同的信息化套用系统，而且大部分是纵向的以组织部门为界限的。在内容管理市场中，经常使用来自不同厂商的产品来提供这些解决方案。即使是同一个厂商的产品，相互之间的功能也是经常重叠，并且无法集成。

随着信息化建设的深入，不同套用系统之间的功能界限已趋于模糊。同时企业资源计画系统和协同商务系统，又需要商业智慧型的分析展现数据提供用户操作依据。

在激烈竞争且多变的市场环境下，企业的管理模式很难固化，套用传统的信息化软体，当企业要做出一些改动时需要面对巨大的挑战。

Teradata大中华区服务部总经理辛儿伦介绍说，从上世纪60年代套用于主机的大型主机系统，到80年代套用于PC的CS 架构，一直到90年代网际网路的出现，系统越来越朝小型化和分散式发展。2000年WebService出现后，SOA被誉为下一代Web服务的基础框架，已经成为计算机信息领域的一个新的发展方向。

SOA的出现给传统的信息化产业带来新的概念，不再是各自独立的架构形式，能够轻鬆的互相联繫组合共享信息。

可复用以往的信息化软体。基于SOA的协同软体提供了套用集成功能，能够将ERP、CRM、HR等异构系统的数据集成。

鬆散耦合方式，只要充分了解业务的进程，就可以不用编写一行代码，通过流程图实现一套我们自己的信息系统。就像已经给你準备好了砖瓦和水泥，只需要想好盖什幺样的房子就可以轻鬆的盖起。加快开发速度，并且减少了开发和维护的费用。软体将所有的管理提炼成表单和流程，以记录管理的内容，指定过程的流转方向。

更简便的信息和数据集成。信息集成功能可以将散落在广域网和区域网路上的文档、目录、网页轻鬆集成，加强了信息的协同相关性。同时，複杂、成本高昂的数据集成，也变成了可以简单且低成本实现的参数设定。创建了完全集成的信息化套用新领域。

在具体的功能实现上，SOA协同软体所实现的功能包括了知识管理、流程管理、人事管理、客户管理、项目管理、套用集成等，从部门角度看涉及了行政、后勤、行销、物流、生产等。从套用思想上看，SOA协同软体中的信息管理功能，全面兼顾了贯穿整个企业组织的信息化软硬体投入。儘管各种IT技术可以用于不同的用途，但是信息管理并没有任意地将信息分为结构化或者非结构化的部分，因此ERP等结构化管理系统并不是信息化建设的全部；同时，信息管理也没有将信息化解决方案划分为部门的视图，因此仅仅以部分为界限去构建软体套用功能的思想未必是不可撼动的。基于SOA的协同软体与 ERP、CRM等传统套用软体相比，关键的不同在于它可以在合适的时间、合适的地点并且有正当理由向需要它提供服务的任何用户提供服务。

不同种类的作业系统，套用软体，系统软体和套用基础结构（application infrastructure）相互交织，这便是IT企业的现状。一些现存的应用程式被用来处理当前的业务流程（business processes），因此从头建立一个新的基础环境是不可能的。企业应该能对业务的变化做出快速的反应，利用对现有的应用程式和套用基础结构（application infrastructure）的投资来解决新的业务需求，为客户，商业伙伴以及供应商提供新的互动渠道，并呈现一个可以支持有机业务（organic business）的构架。SOA凭藉其松耦合的特性，使得企业可以按照模组化的方式来添加新服务或更新现有服务，以解决新的业务需要，提供选择从而可以通过不同的渠道提供服务，并可以把企业现有的或已有的套用作为服务， 从而保护了现有的IT基础建设投资。

如图1的例子所示，一个使用SOA的企业，可以使用一组现有的套用来创建一个供应链複合套用（supply chain composite application），这些现有的套用通过标準接口来提供功能。

为了实现SOA，企业需要一个服务架构，图2显示了一个例子：

在图2中， 服务消费者（service consumer）可以通过传送讯息来调用服务。这些讯息由一个服务汇流排（service bus）转换后传送给适当的服务实现。这种服务架构可以提供一个业务规则引擎（business rules engine），该引擎容许业务规则被合併在一个服务里或多个服务里。这种架构也提供了一个服务管理基础（service management infrastructure），用来管理服务，类似审核，列表（billing），日誌等功能。此外，该架构给企业提供了灵活的业务流程，更好地处理控制请求（regulatory requirement），例如Sarbanes Oxley（SOX），并且可以在不影响其他服务的情况下更改某项服务。

图2

要运行，管理SOA应用程式，企业需要SOA基础，这是SOA平台的一个部分。SOA基础必须支持所有的相关标準，和需要的运行时容器。图3所示的是一个典型的SOA基础结构。

SOAP， WSDL， UDDI

WSDL，UDDI和SOAP是SOA基础的基础部件。WSDL用来描述服务；UDDI用来注册和查找服务；而SOAP，作为传输层，用来在消费者和服务提供者之间传送讯息。SOAP是Web服务的默认机制，其他的技术为可以服务实现其他类型的绑定。一个消费者可以在UDDI注册表（registry）查找服务，取得服务的WSDL描述，然后通过SOAP来调用服务。

WS-I Basic Profile

WS-I Basic Profile，由Web服务互用性组织（Web Services Interoperability Organization）提供，是SOA服务测试与互用性所需要的核心构件。服务提供者可以使用Basic Profile测试程式来测试服务在不同平台和技术上的互用性。

J2EE 和 .Net

儘管J2EE和.NET平台是开发SOA应用程式常用的平台，但SOA不仅限于此。像J2EE这类平台，不仅为开发者自然而然地参与到SOA中来提供了一个平台，还通过他们内在的特性，将可扩展性，可靠性，可用性以及性能引入了SOA世界。新的规範，例如 JAXB（Java API for XML Binding），用于将XML文档定位到Java类；JAXR（Java API for XML Registry）用来规範对UDDI注册表（registry）的操作；XML-RPC（Java API for XML-based Remote Procedure Call）在J2EE1.4中用来调用远程服务，这使得开发和部署可移植于标準J2EE容器的Web服务变得容易，与此同时，实现了跨平台（如.NET）的服务互用。

在企业中，关键任务系统（mission-critical system，译注：关键任务系统是指如果一个系统的可靠性对于一个组织是至关重要的，那幺该系统就是该企业的关键任务系统。比如，电话系统对于一个电话促销企业来说就是关键任务系统，而文字处理系统就不那幺关键了。）用来解决高级需求，例如安全性，可靠性，事物。当一个企业开始採用服务架构作为工具来进行开发和部署套用的时候，基本的Web服务规範，像WSDL，SOAP，以及UDDI就不能满足这些高级需求。正如前面所提到的，这些需求也称作服务品质（QoS，quality of services）。与QoS相关的众多规範已经由一些标準化组织（standards bodies）提出，像W3C（World Wide Web Consortium）和OASIS（the Organization for the Advancement of Structured Information Standards）。下面的部分将会讨论一些QoS服务和相关标準。

Web服务安全规範用来保证讯息的安全性。该规範主要包括认证交换， 讯息完整性和讯息保密。该规範吸引人的地方在于它藉助现有的安全标準，例如，SAML（as Security Assertion Markup Language）来实现web服务讯息的安全。OASIS正致力于Web服务安全规範的制定。

在典型的SOA 环境中，服务消费者和服务提供者之间会有几种不同的文档在进行交换。具有诸如“仅且仅仅传送一次”（ once-and-only-once delivery），“最多传送一次”（ at-most-once delivery），“重複讯息过滤”（duplicate message elimination），“保证讯息传送”（guaranteed message delivery）等特性讯息的传送和确认，在关键任务系统（mission-critical systems）中变得十分重要。WS-Reliability 和 WS-ReliableMessaging是两个用来解决此类问题的标準。这些标準都由OASIS负责。

服务提供者有时候会要求服务消费者与某种策略通信。比如，服务提供商可能会要求消费者提供Kerberos安全标示，才能取得某项服务。这些要求被定义为策略断言（policy assertions）。一项策略可能会包含多个断言。WS-Policy用来标準化服务消费者和服务提供者之间的策略通信。

当企业着手于服务架构时，服务可以用来整合数据仓库（silos of data），应用程式，以及组件。整合套用意味着例如异步通信，并行处理，数据转换，以及校正等进程请求必须被标準化。在SOA中，进程是使用一组离散的服务创建的。BPEL4WS 或者 WSBPEL（Web Service Business Process Execution Language）是用来控制这些服务的语言。WSBPEL也由OASIS负责。

随着企业服务的增长，所使用的服务和业务进程的数量也随之增加，一个用来让系统管理员管理所有运行在多相环境下的服务的管理系统就显得尤为重要。WSDM（Web Services for Distributed Management）规定了任何根据WSDM实现的服务都可以由一个WSDM适应（WSDM-compliant）的管理方案来管理。

其它的qos特性，比如合作方之间的沟通和通讯，多个服务之间的事务处理，都在WS-Coordination 和 WS-Transaction 标準中描述， 这些都是OASIS 的工作。

在理解SOA和Web服务的关係上，经常发生混淆。根据2003年4月的Gartner报导，Yefim V. Natis就这个问题是这样解释的：“Web服务是技术规範，而SOA是设计原则。特别是Web服务中的WSDL，是一个SOA配套的接口定义标準：这是Web服务和SOA的根本联繫。”从本质上来说，SOA是一种架构模式，而Web服务是利用一组标準实现的服务。Web服务是实现SOA的方式之一。用Web服务来实现SOA的好处是你可以实现一个中立平台，来获得服务，而且随着越来越多的软体商支持越来越多的Web服务规範，你会取得更好的通用性。

SOA的概念并非什幺新东西，SOA不同于现有的分散式技术之处在于大多数软体商接受它并有可以实现SOA的平台或应用程式。SOA伴随着无处不在的标準，为企业的现有资产或投资带来了更好的重用性。SOA能够在最新的和现有的套用之上创建套用；SOA能够使客户或服务消费者免予服务实现的改变所带来的影响；SOA能够升级单个服务或服务消费者而无需重写整个套用，也无需保留已经不再适用于新需求的现有系统。总而言之，SOA以藉助现有的套用来组合产生新服务的敏捷方式，提供给企业更好的灵活性来构建应用程式和业务流程。

A. 平衡最初的旧系统投资(Leverage initial investment)：

组织过去所投资的系统、软硬体，如果能再利用等于赋予其新的价值，这也替组织降低成本并增加竞争力。

B. 基础建设的便利性(Infrastructure Commoditization)：

让所有的套用程式能相互沟通(互通性)。

C. 快速的接近市场(Faster time-to-market)：

服务的重複使用(再利用)，来缩短过去的组织流程，更快速的提供服务来接近市场。

D. 减少支出(Reduce Cost)：

服务的重複使用，可降低开发成本。因为开发新系统的成本，大部份比更新旧有系统来的花费大。

E. 减低风险(Risk mitigation)：

开发新系统的风险远大于更新旧系统。

F. 持续改善商业流程的循环(Continuous improvement cycle for business process)

G. 中心流程处理(Process-centric processing)

一，SOA可通过网际网路伺服器发布，从而突破企业区域网路的限制，实现与供应链上下游伙伴业务的紧密结合。通过SOA架构，企业可以与其业务伙伴直接建立新渠道，建立新伙伴的成本得以降低。

二，SOA与平台无关，减少了业务套用实现的限制。要将企业的业务伙伴整合到企业的“大”业务系统中，对其业务伙伴具体採用什幺技术没有限制。

三， SOA具有低耦合性特点，业务伙伴对整个业务系统的影响较低。在企业与各业务伙伴关係不断发生变化的情况下，节省的费用会越来越多。

四， SOA具有可按模组分阶段进行实施的优势。可以成功一步再做下一步，将实施对企业的冲击减少到最小。

五， SOA的实施可能并不具有成本显着性。这要分三种情况加以讨论：

(1) 当企业从零开始构建业务系统时，採用SOA架构与不採用SOA架构成本可看做是相同的。

(2) 当企业业务发展或发生企业重组等变化而原有系统不能满足需要，而需要重构业务系统时，採用SOA架构与不採用SOA架构成本可看做是相同的。

(3) 当企业业务发生缓慢变化并可预见到将来需要重构业务系统时，由于可以按模组分阶段逐步实施SOA以适应变化的需要，这样企业不需一下投入一大笔经费进行系统改造，而是根据企业业务发展情况和资金情况逐步投入，缓解了信息投入的压力。

IDC负责企业平台研究的副总裁Michelle Bailey说，最近的IDC的研究表明，到2011年，18%以上的全部新伺服器都将採用虚拟化技术，对于伺服器硬体供应商来说，这是一个年收入达220亿美元的市场机会。

对于企业来说，日益增长的挑战是如何管理和保证虚拟环境的安全，因为随着机构採用虚拟化技术，传统的管理物理伺服器蔓延的挑战正在转向管理虚拟机蔓延的挑战。机构将需要可靠的、稳定的、安全的和可管理的虚拟化解决方案。

绿色IT一直被列为头号的战略技术和2008年大多数机构的趋势。据IDC称，虚拟化的绿色的好处不仅是减少伺服器占地面积，而是还包括减少碳排放量和耗电量。这些好处正在成为重要的好处。

据IDC对亚太地区绿色IT的调查，75%的受访者对于IT部门没有绿色IT政策。然而，80%以上的受访者认为他们的IT供应商的“绿色”在未来几年将更加重要。

虚拟化在这方面将发挥重要作用，一些企业将採用更环保的方法经营业务以便赢得政府部门的契约。其它机构正在採用虚拟化技术以便得到节省电源的好处和减少碳排放量的奖励。

同时，一些企业管理者和市场研究人士也对虚拟化的未来发展发表了看法：

Avnet公司行销经理Michael Costigan：

儘管虚拟化有巨大的潜力，许多转销商不知道这种有潜力的新技术的实际状况。机构能够获得显着的能量和计算效率，同时提高技术的套用率和灵活性。

为了帮助你的客户认识到这些好处并且为你的企业建立强大的市场占有率，你需要了解这个强大的新技术的细节，了解需要採取什幺有效手段识别和利用虚拟化的真正机会。

虚拟化正在用来解决範围日益广泛的商业目标和挑战，如伺服器整合/保留、业务持续性、测试/开发最佳化、软体开发与发布以及桌面管理和安全。

人们对于虚拟化的未来显然非常感兴趣。但是，还有许多言过其实的宣传。第一波x86伺服器虚拟化的套用一直集中在伺服器整合方面，重点是减少资本开支 (也就是伺服器开支)以及电源和冷却等运营开支。在未来的五年里，机构将超越伺服器整合寻求如何利用虚拟化技术得到其它的好处，如重点减少运营成本(也就是物理管理成本)和让基础设施更有活力和更灵活，以便改善IT对于不断变化的商业需求的反应能力。

分析师认为，虚拟化的下一个大事将是高可用性和灾难恢复工具。灾难恢复在历史上一直是非常难管理的。虚拟化将提供一个节省成本的和容易管理的灾难恢复解决方案。

虚拟桌面基础设施、资源平衡和应用程式级高可用性可能是其它的未来套用实例。这些解决方案有一些技术的和经济的障碍。这些障碍必须要在虚拟化广泛套用前克服。但是，考虑到虚拟化的重点，这些障碍已经在开始克服。虚拟化还将成为SOA(面向服务的架构)技术套用的推动因素。面向服务的体系结构基于这些实际活动或业务服务进行组织，而不是形成公司所维护的不同的信息竖井 (Silo)。通过实现 SOA，可以带来大量好处，包括以下各个方面： 　*更高的业务和 IT 一致性

*基于组件的系统

*鬆散耦合的组件和系统

*基于网路的基础设施，允许分散于各地且採用不同技术的资源协同工作

*动态构建的按需应用程式

*更高的代码重用率

*更好地标準化整个企业内的流程

*更易于集中企业控制

服务导向架构并不是一种全新的解决方案；相反，SOA是技术与架构的自然进化。系统架构一直在不断进步，与商业保持高度一致。系统设计师与商家很早就认识到将技术与商业流程相协调的重要性，包括充分套用併合理化技术资源，以及为商业提供更好的支持。

SOA也在一定程度上源于早已有之的企业架构理论。企业架构对技术进行评估，但是更重要的是，它关注整个企业和全部的商业流程并提供了做出技术决策的背景信息。SOA工具则融合了网际网路技术，如HTTP和XML，以及综合技术，如讯息汇流排、转译技术和连线技术。