成功SOA的设计方式必须是，使它能与现有的技术共存，并尽可能简单和不影响现有系统。

    面向服务的架构承诺，一旦被采用，将会带来许多好处。任何新方法所带来的典型问题都是，如何克服初始成本和中断采用的问题。对于SOA来说，其现实问题是，大多数企业信息尚未支持WebService，甚至无法以XML格式交付数据。现实中的数据仍被“老信徒”们所统治着的——从逗号分隔的数据到Cobol数据格式。更有甚者，许多使用这些格式的系统恐怕根本就碰不得——它们太重要或者太脆弱了，不能乱动，也就无法达到启用WebService的目的。

    就在我们思讨如何把数据传遍整个企业时，一个类似的问题出现了。虽然很多人会采用基于JMS的可靠消息传递来形成规则的传输机制，但是，多数情况下，数据是通过FTP传送的，甚至遗留在目录中有待收集。

    然而，我们不应该举手投降。再次提出的是，确保所采用的方法在本质上持续增量，并允许这些遗留数据格式化和迁移，从而成为SOA的一部分，这还真是一个问题——如何把遗留系统带入现代系统。

    新新事物

    新技术的出现往往很容易使人狂热失控。IT历史就是一长串改变一切的新“范例”。但是，人们难以吸取的教训是，这只是一个罕见的特例，并且，对于新技术来说，无论它们的倡导者多么伟大，它们都必须学会在充斥着现有系统的现实世界中生存，这个世界是一个杂乱无章且时常让人迷惑的地方。

    对于SOA而言，若要重新配置正在运行的现有系统，则很少有企业乐意大规模地转移到这种方法。有些SOA倡导者会成功地建立一些引人注目的商业案例，并使企业确信能够获得长期收益。还有些SOA倡导者在宣传这种转换时正好幸运地赶上了某个企业正准备进行大规模改造。然而摆在大多数SOA倡导者面前的事实是，确实难以通过采用一套新的架构来获得长期收益。

    我曾在前面指出，确实可能有一种本质上持续增量的方法，并因而减少新架构所带来的系统中断成本。在本文所述情况下，这种持续增量的方法表明，成功SOA的设计方式必须是，使它能与现有的技术共存，并尽可能简单和不影响现有系统。

    共存的两个方面

    总的说来，在这两个关键领域中，SOA必定会实施过程中遭遇“遗留”系统。这就是遗留应用程序和传输协议。

    首先看看遗留应用程序，最初的解决方案看起来似乎很直观：使用一个webservice启动工具，并创建一个面向现有系统的新接口。然而，当使用这个工具时，仍然存在着很多问题，因为通常都需要这个工具能够直接访问应用程序的接口或数据。这基本上是不可能的，因为应用程序不会公开这些接口或数据，相反它是批处理驱动的——在特定时间间隔内创建一个报告。

    换言之，几乎不可能简单地直接访问，因为应用程序属于另一个企业，没有理由认为，该企业会为了改造成SOA而冒险花钱。最后一个问题在任何B2B服务供应场景中都很常见。举个金融服务业的例子：首要经纪人赖以生存的能力是，根据各个对冲基金客户的不同需求，导入或导出不同的消息格式。对于对冲基金来说，没有任何理由改变和引入webservices，以减轻首要经纪人的工作。

    它们所支持的传输协议和现有业务流程同样存在着错综复杂的问题。实际情况是，很多此类问题仍然是基于批处理的，甚至是使用FTP或email来分发非XML文档（如Excel文件）。同时，一些综合项目可能选择HTTP，这种方式适用于灵活而又资源占用少的消息传递，或者是选择JMS，这种方式适合于健壮而可靠的实现，这增加了现有系统的复杂性。

    很明显，在消息格式和传输方式这两个问题上，SOA实现都必须在企业涉及的范围内进行调整和集成，而无需任何外来的压力。

    实际步骤

    这对于SOA部署来说意味着什么？

    首先，成功与否取决于SOA能否与现有技术有效地并行工作。这意味着能够访问应用程序所能公开的信息——即目录中的文件或队列中的信息。这同时也意味着XML是否保留“普通格式”，并且我们能够继续利用它的独特属性来处理编排与调解，SOA实现必须使非XML格式与XML格式之间尽可能无缝地相互转换。

    这是一种相对直接的方法，可以通过映射技术来实现它，这种映射技术能够采用类似于XML转换一样的方式来定义这些转换。接着，在运行时执行，并提供了全自动化以及跨多种数据格式的多种交付的能力。步入XML世界后，接下来提供WebService并完成整个过程就相关直接了。

    其次，SOA实现的核心部分当然是业务流程的快速自动化。这种自动化必须能够包括不基于WebServices的步骤。回到首要经纪人的例子中来，对冲基金可能正在通过FTP向服务提供者传输Excel文件，那么有效的SOA实现应该使用目录轮询和数据格式转换技术来自动地从相应目录提取数据，并将其转换成内部格式——无需在该事务的另一边对业务进程作任何技术上的改动。

　　这一切说明了一个重要事实：SOA的迁移必须受业务需求的驱动，而不应是感觉到需要选择和交付单一的“聚合性”架构。成功的SOA实现涉及到接收一些无法改变的事物，并将它们合并在一起。