我们把平台定义为运行时间的执行设施，但是SOA却需要一个不同的平台，因为运行时间的执行设施与其在SOA内的意义是不同的。

　　ZapThink公司很担心没有富有宣传性的语言，在这个ZapFlash中，我们将会采用最别扭的一个词:平台。当然对于这个术语有多定义，我们在这里所关注的一个是允许汇编的或者非汇编的代码进行运行的运行时间的执行设施。然而，这个定义却很灵活，因为面向服务架构(SOA)并不是关于代码的，而是灵活的过程中服务的集合。自然，对于真正运行的服务来说，一定会存在一些运行时间的设施，只有这个时候我们用“运行”这个词来表达了一些其他的意思。SOA毕竟是用来抵消不均衡性的企业架构，所以SOA平台应该必然是一个中立性质的平台。此外，比较那些位于服务界面下方的概念来说，SOA尤其关注服务界面及其上方(包括组合式元数据、安全策略和动态绑定信息)。

　　也许你会发现上一段话中的基本矛盾:如果平台的中立性是SOA的核心要求，那么怎么能够存在一个类似于SOA平台的东西呢?这是否可以理解为一个具有中立性的平台呢?之所以存在矛盾的原因是因为我们正在扩展“平台”这个词的含义。我们把平台定义为运行时间的执行设施，但是SOA却需要一个不同的平台，因为运行时间的执行设施与其在SOA内的意义是不同的。正如我们在上一个ZapFlash中所解释的，SOA的目标是使商业用户和业务流程架构者通过描述性的方式把服务结合到流程中去，并且管理和发展这些流程。因此对这种流程运行时间的执行是一种对不同平台元数据的操作——一种面向服务的组合式应用程序平台。

　　应用程序设施 VS. 服务设施

　　“平台”这个词的不同概念引起了混乱，这种混乱原因是由于组合式应用程序平台是描述性服务设施的一部分，同时，潜在的运行时间执行平台本来就是程序化应用程序设施的一部分。组合式应用程序平台从本质上提取了潜在技术的执行详细信息，并且为建立和运行面向服务的流程组合式应用程序提供了一个运行时间的执行设施。

　　这里我们要特别注意两点。第一，组合式应用程序平台要求为其而运行的潜在运行时间执行平台——毕竟它们是由代码所编写的，而这些代码需要一个能够运行的空间。然而，运行时间平台并不是SOA的价值之所在。更确切的说，运行时间平台只是简单地使系统用相同的方式来工作，因为计算机芯片仍然是在二进制水平上进行操作，但是我们很早以前就已经停止了继续在二进制水平上开发代码了。第二，急需理解组合式应用程序平台和运行时间的执行设施是完全不同的事情，相对于单独使用运行时间的执行设施来说，使用组合式应用程序平台更适合SOA。组合式应用程序平台并不假设运行时间的环境，而是关注于描述和管理服务之间交互作用的元数据，与此同时，运行时间执行环境更关注于一个特定的服务是如何被贯彻和执行的。

　　从头开始建设SOA平台

　　让我们来看看两种领先的运行时间执行平台:J2EE和微软视窗操作系统的.Net。这两种运行时间平台对服务的执行都具有非常出色的支持功能，它们自身并不在SOA平台之内，也不是SOA平台。为了理解为什么这两种平台都不是基本的SOA平台，就要考虑当你从头开始建设SOA平台的时候，它可能是什么样子的。

　　首先让我们来看看Java 2企业版(J2EE)。现在你能够在J2EE的基础上建立一个非常完美的SOA执行方式，事实上，你可以在很多其他平台和产品上建立SOA执行方式，正如我们在上一个ZapFlash中所阐述的一样。在当今许多产品中SOA执行方式都依赖基于J2EE的运行时间设施，而且Java的J2EE风格对于执行多层式(n-tier)架构来说是一个特别的框架。但是很不幸，Java的任何方面都不是适合SOA的理想平台，同时，其他关于此方面的基于虚拟机的和面向对象的运行时间环境也都不理想。面向对象(OO)通过安装建立了对象例证，而且这些例证在执行环境中维持了其状态。然而，服务却是通过元数据来维持其状态。对象例证的整个概念作为单独的方面几乎没有给SOA带来什么价值。

　　此外，虚拟机(VM)并不是在理论上与SOA一同被制作，也并不特别适合SOA。虚拟机的目的是提供代码的可移植性，在SOA中。协同工作能力是相当重要的，就像我们在另一个ZapFlash中所阐述的一样。既然在SOA中你只是想把代码放置于它应该在的地方，那为什么还要不胜其烦地创建具有可移植性的代码呢?在本质上，虚拟机分布式计算的方式是通过能够导致远程方法的调用对象的连续性实现的，而SOA是运行于通过约定界面的不同服务之间信息交换基础上的。你同样可以使用Java来实现在不同的约定界面之间的信息交换，当然你这样做的唯一理由就是你在开始的时候就已经使用Java来制作面向服务的平台，而不是因为Java是你开始制作平台时的一个选择。

　　最后，让我们来看看由J2EE所提供的企业JavaBeans、Servlet和Java Server Pages的框架。显然，J2EE主要关注于提供一种可扩展的多层式架构框架，这类似于那种大规模的交易网站所需求的一样。然而，如果你想要开发创建一个企业级的SOA框架，那么你最好创建一些不同的东西——你所创建的框架要以启动和维护服务的抽象层为中心，而且对于SOA是非常紧急的。所以，虽然J2EE非常适合运行依赖于平台的服务，但却不是服务的设施。J2EE并不能发展成为面向服务的平台，但在运行时间代码执行方面却是非常好的分布式的、基于虚拟机的、面向对象的平台。J2EE也并不能理想地适合一个SOA的、描述性的、元数据驱动成分的绝佳可移植性代码。

　　现在让我们再来看看视窗操作系统和.NET平台。微软公司将在Longhorn潮(下一代视窗操作系统的主要版本)及其编程模式中使用Windows和.NET，代号叫做“靛蓝(Indigo)”。靛蓝从根本上整合了微软公司的当前编程模式和应用程序编程接口(APIs)这些大杂烩，包括了COM+、Enterprise COM、.NET Remoting等等，靛蓝把这些整合到一个单一的、面向服务的编程模式中。在这种Windows、.NET和Indigo的组合中，微软公司扩建了其整个分布式计算设施，使其成为不同运行时间执行设施的松散联系装置，其中每一个装置都是由服务界面抽取出来。因此，Longhorn是不是真的能很好地适合SOA平台呢?

　　即使微软公司在关于Longhorn的面向服务的计划上倾尽全力，对于SOA执行的很多方面仍然存在着不能以平台的形式去良好适应的可能性，因为Longhorn永远是个单独商家的平台。做为事实，微软公司认真地采取了开放标准和协同工作能力，但是微软公司的平台是通过促进平台之内和平台之外运行的一切事物之间的协同工作能力来参与到具有异质性的复杂环境中的。在这个平台中，同质性要比异质性重要得多。

　　换句话说，为微软公司主要是为那些已经购买了.NET的用户提供清晰的具有价值的建议:在你的平台上建立你的SOA，并且吸取了我们逐级建立SOA平台的优势。但是对于那些工作于协同工作能力背景之下的组织来说，微软公司具有价值的建议(或者是其他单独商家的建议)并不意味着那种具有异质性和描述性的SOA平台，SOA在某种程度上要求该平台抽象运行时间环境。

　　为你的平台而服务的平台?

　　对于SOA来说，一个面向服务的组合式应用程序平台或另外的平台可能是最好的平台，但是这些平台中的任何一个都不能取代J2EE和Windows的.NET，当然这是因为每一个组合式应用程序平台都需要运行在其独立的潜在运行时间执行平台之上。有一些运行于J2EE之上，其他的运行于.NET之上，而且还存在很多其他的平台，包括大型机平台、基于脚本的平台以及其他专有和开放资源的平台。换句话说，这里主要有两种不同类型的平台:一种为描述性组合式应用程序提供了执行环境，另一种为潜在的编程代码提供了执行环境。理想状态下，只要组合式应用程序平台能够满足对其移植的业务需求，那么你的组合式应用程序平台运行于哪一个潜在的平台上都无所谓。从根本上说，把运行时间执行平台认同于SOA平台是不合适的。在本文中，平台具有更高抽象水平的含义——在这种水平中我们不用强调执行环境，即使我们知道这里必然存在着一个或者可能更多的含义。

　　关于潜在的执行平台是创建组合式应用程序平台的最佳平台仍然存在着问题，但是要注意到这些问题与当前存在的问题没有任何关系，认识到这一点是重要的。那些正在创建组合式应用程序平台产品的商家必须决定是否使用Java和.NET(或其他工具)，当然，这些商家并不使用SOA——是他们的客户在使用SOA。一个组合式应用程序平台的商家做出关于潜在平台的选择，如果这种选择影响了他们客户的SOA使用，那么一定是他们的产品出了问题。组合式应用程序平台产品必须真正地从潜在执行环境中抽象出来——换句话说，它们必须是具有独立性的SOA平台。从本质上讲，SOA平台仅仅处理服务的抽象化和一些包含了层的东西。在其之下的不应该被理解为组合式的平台。

　　ZapThink公司的收获

　　由于面向服务的组合式应用程序平台市场刚刚开始启动，很多目前使用SOA的企业的客户的建立都是从零散到整体——他们经常使用已经存在的中间设备和平台设施，同时配合使用外加的能够提供企业服务总线(ESB)能力的附加软件、SOA管理、策略和管理工具以及其他类似的工具。当然，通过J2EE、Windows的.NET或其他平台，你可以创建一个非常完美的SOA的实现方式。然而，采取零散方式来执行SOA仍然意味着要做更多的工作、要冒更大的风险，而这些并不是必要的，这样的事实没有改变。随着组合式应用程序平台市场的逐渐成熟以及该领域内先导性产品的出现，SOA平台和运行时间执行平台之间的区别将会逐渐清晰起来。