如果SOA无法虚拟化 就没有灵活性

申请免费试用、咨询电话：400-8352-114

三种类型的SOA虚拟化

虚拟化技术占我们IT预算的80%以上。如果我们把虚拟化的好处应用到我们在商务活动中使用的关键企业软件并且应用到这些应用程序的深入开发、技术支持和维护成本等方面，情况会怎么样呢?服务器虚拟化可直接减少硬件和配置成本。但是，仅把重点放在虚拟化的硬件方面，我们会浪费金钱吗?

虽然机构能够减少它们需要的设备数量，并且为虚拟测试平台节省复制服务器的成本，但是，这些服务器正在变成商品。

毫无疑问，来自电信、制造、石油天然气、金融、电力等等行业的大企业是中国信息化服务的最重要对象之一，经过这些年的信息化建设，他们的信息化建设已经取得了很不错的成绩。这些掌控着中国IT采购最重要生杀权的IT厂商的最直接上帝们，他们对现在的IT系统还有什么痛点?他们目前的IT状况如何?他们下一步的采购重点将是什么?他们未来需要什么样的IT系统与产品?他们最关心什么?

虚拟化技术占我们IT预算的80%以上。如果我们把虚拟化的好处应用到我们在商务活动中使用的关键企业软件并且应用到这些应用程序的深入开发、技术支持和维护成本等方面，情况会怎么样呢?

目前，主要企业都依赖多种分布式技术和新的功能，如SOA等。虚拟化能够提高这些系统的质量和上市的时间。但是，团队如何实施虚拟化以便提高不在一个集中的团队控制下的SOA功能和加快上市时间呢?这个扩展的机构必须要通过把共享的服务行为虚拟化才能把这两个战略联系起来，从而成倍增加SOA的价值。

三种类型的SOA虚拟化

企业在SOA中应用虚拟化的概念有三种独特的方法：

1、硬件虚拟化包括在一个硬件设备中，以虚拟机的方式运行多个版本的操作系统。这将为在数据中心运行的内部应用程序提供更低的成本、更大的灵活性和风险管理的好处，并且为SOA系统提供一个复制测试平台的有用的途径。

2、虚拟端点能够在你与这个实际的端点隔离开来的时候允许SOA定义服务的虚拟位置。这对于SOA应用程序中固有的动态流程是很理想的，因为一个服务的物理地址也许需要根据它什么时候和如何用作一个指定的工作流的一部分而进行改变。

3、虚拟服务不仅仅是对SOA测试有用。虚拟服务通过优化整个实践的开发和应用来提高价值。

本文重点讨论第三种类型的虚拟化--在数据中心外部发生的虚拟服务。对于SOA应用生命周期的其它方面来说，我们创建虚拟测试平台的努力只能达到这个程度。企业通常为了验证和开发SOA而依靠实时的实施。然而，这些复杂的相互连接的环境能够通过硬件虚拟化技术复制。我们需要把虚拟化扩展到实际的分布式软件组件中和在这些环境中运行的服务中。

如果SOA不能虚拟化，它就没有灵活性

在硬件和数据中心的级别上实施虚拟化可以产生立竿见影的节省运营成本的回报，可直接节省数百万美元IT成本。

然而，当我们把组件或者服务开发任务分配给多个团队的时候，我们经常忘记这些团队仍需要实时访问这个应用程序的其它部分以完成自己的开发和测试目标。所有这些团队之间仍需要高水平的依赖性和相互沟通以提供一个完整的工作流。对于大规模企业系统来说，这给SOA的投资回报提出了严格的限制。

有一种方法可以是使用SOV(面向服务的虚拟化)把这两种技术联系起来：模拟应用软件资产行为的策略以及合成制作企业SOA应用程序的组件。不利用SOV的优势，在整个企业范围内最大限度地实现SOA价值是很困难的，如果不是不可能的话。

挑战：SOA的障碍

企业采用SOA的最佳做法实现商业灵活性和成本的好处。遗憾的是，当SOA应用程序试图通过升级来满足大型企业的现实需求的时候，最佳的SOA架构和治理战略仍很缺乏，即使拥有虚拟的服务器也是如此。出现这种事情有若干原因。

共享的系统资源的冲突

SOA就是通过把企业系统当作共享的服务提供来发挥企业系统的优势。然而，访问共享的资源问题危害每一个单独的SOA计划。一个主要的erp系统管理员或者大型计算机管理员可能会对他们在生产中的应用程序采取保护措施，限制开发和测试团队直接访问这个应用程序以避免出现不可预料的问题。

此外，即使允许访问，实时的服务经常会受到一个SOA环境中的多个机构需求的限制。当各个团队被迫排队等候访问一个现实的环境以便进行测试和开发的时候，灵活性就受到了影响。在大型企业应用程序中，通过硬件虚拟化本身创建另一个环境的实例成本太高，是不允许的。

不连贯的开发和整合生命周期

开发人员需要把服务接口做成一个占位符模型以便确定他们的服务如何与其它服务互操作。例如，一个开发团队正在扩建用户数据，而第二个开发团队正在创建账户数据。由于这些应用程序是并行开发的，这两个团对需要相互依赖对方的服务。每一个团队都需要依靠访问接近完成或者已经实施的服务来证明他们自己的服务能够正确地互操作。

SOA通过把松散耦合的组件当作服务来实现灵活性。因此，更小的和更分散的团队能够并行开发和集成这些服务。当仍然存在依赖性的时候，我们如何才能达到这种并行开发的水平呢?看一下这个典型的项目计划或者甘特进度表。在下一个开发团队继续开发下一个组件的之前，肯行会遇到一个项目中可用组件的下一个“依赖性”。这正是我们希望用SOA打破的一个模式。

增加的复杂性和异质性

虽然许多做SOA的计划都是以Web服务(WSDL/SOAP)为中心的，但是，在最佳的企业实施的SOA计划中只有大约50%是基于Web服务的。有多种技术可以用来创建SOA中间件软件。这些SOA中间件软件也许是非常合法的，对于一个指定的机构来说也许比一个Web服务栈更好，例如使用一个几乎不依赖Web服务的企业服务总线。要保证SOA的质量，各个团队需要验证实施状况和对各种不同技术产生的副作用，而不仅仅测试自己选择的Web服务或者中间件软件层。

SOA测试环境维护和技术支持的高成本

要向一个SOA应用程序提供服务，许多机构试图复制和维护自己的测试环境。然而，复制他们需要在自己的过渡环境中进行交流的全部组件是一个成本非常高的过程。它需要高水平的配置、许可证成本和维护，以保证那个测试构件保持最新状态，即使它是在虚拟的硬件中运行也是如此(虚拟的硬件也有一些增量的许可证成本)。SOA利用的许多企业系统都太大了，有太多的开销，不能实施虚拟化。

不要试图通过复制数十个变化的服务来创建一个巨大的测试基础设施，SOA需要一个策略解除这些团队对这些实施的依赖。这将提供一种根据部署中存在的现实状况进行测试和开发的方法。

数据和系统记录的庞大规模

达到企业级SOA应用水平的最后(也许是最困难的)障碍是需要管理的系统和数据的庞大规模。要测试一个SOA应用程序的实际效果，机构需要输入一套逼真的数据，然后离开正在测试中的环境。

虽然他们能够在架构和设计过程中根据制定的元数据描绘出与其它服务之间的互动，但是，一旦他们通过连接这些端点的理想的模型，他们还必须要应付一个CRM大型计算机或者企业系统以及这些系统的管理者。嵌入在这些层的数据和商业逻辑在过去的若干年里已经增加并且客户化了。把这个系统和数据制作成完整的镜像副本并且根据另一个企业许可证和实施团队的要求进行测试成本太高了。

引进面向服务的验证

SOV(面向服务的虚拟化)是一种IT策略，它要模拟组成一个SOA应用程序的软件资产的实际行为，进而使开发和测试团队摆脱对应用的服务及其基本实施层的依赖。

SOV包括建模和模拟设计之中和应用的服务以及虚拟的服务。这些虚拟的服务将提供给扩展的SOA团队进行测试并且开发自己的服务和工作流，不用依靠这些服务的实例。当各个团队摆脱了对应用的服务和实施层的依赖的时候，提高的灵活性、更快的上市时间和减少的交付成本等扩展的SOA的好处就全部实现了。要做个比喻的话，SOV是针对SOA的，就像硬件虚拟化是针对数据中心的一样。