SOA：在应用服务器中寻求特例（一）

在过去几年时间里业内的大肆颂扬，越来越多的用户已经开始采用面向服务架构(SOA)的方法来开发和部署其IT，用以实现更大的业务灵活性，优化相关的开发流程并有效缩减成本。

　　当讨论SOA时，对于整个SOA部署周期或是如何通过治理让元数据存储库建立起与遗留系统的联系从而控制并有效支配，这些“治理”流程的规则与价值并不是讨论中所重点关注的问题，同样，关于企业服务总线在流程调用与服务之间转换所扮演的核心角色也没有得到深入的关注。

　　虽然治理流程与企业服务总线会是SOA明显区别于别的架构方法的重要特点，同时也是成功部署SOA的关键核心，然而这两个对于成功部署SOA而言重要的并且极有价值的区别点在受重视的程度上却被相对的忽视掉了，以至于这些“服务”自身被遗忘掉这一现象也变的很必然，尽管这对于部署一个成功的，企业级的，关键使命的SOA而言是非常重要的决定性因素，也同样如此。

　　本文的部分内容将试图讨论服务运行环境与运行所扮演的职责与典型特点以纠正这种不平衡的受重视程度，尤其是对于Java应用服务器而言，以及他们是如何成功实现企业级SOA部署的。

　　可能是因为SOA是一个“不可知技术”(即，更像一个成长型架构方法)，这与它的前辈有所不同，所以它更多的是在不断的实施与采用过程中发展起来的。事实上，你可以使用.NET，Java，CORBA，面向消息的中间件(MOM)，DCE(分布计算环境)，DCOM(分布式组件对象模型)，Web服务(基于REST和SOAP)或者许多其它的技术创建起SOA的全面部署，这是SOA部署的核心优势所在。这种技术层面的多样性决定了成功部署SOA的可能，但因为大量服务的运行环境和运行所引发的需求驱使着很多麻烦的产生，同样也成为了成功部署的关键问题。

　　在最开始考虑服务容器与运行的规则和职责时，值得注意的一个关键点则是如何区别对于应用程序和服务的开发和部署。

　　应用程序通常意义上可以理解为一个自成一体的黑盒子，调整其内部的一些执行在很多时候根本不会对用户或使用者带来明显的影响;同样，服务内部的一些执行也可以在不影响用户的前提下进行调整。

　　服务与应用程序不同的地方在于，服务无法在最初的时候就能够预计到它将如何被采用，怎样去重复利用，或者成为某一环节的关键组成。所以，这要求你必须在开发和部署服务的时候就明确的定义好你的平台(API)和所提供的服务(服务质量/服务协议级别)。

　　这将会带来什么样的影响呢?当选择一具体的编程模型以执行某一项特定服务，开发人员应该充分考虑这一模型是否具有充分的可扩展性，普遍的适用性以及可扩展的服务接口定义(IDL)是否准确，这些正是决定了服务在执行过程中是否能够做到分别扩展的关键。

　　为了更好的阐明这一点，让我们来仔细考虑一下CORBA IDL以及Web服务定义语言(WSDL)。

　　虽然这两个都是从各自的目标执行语言中抽象出来的IDLs，但是可以明确的说，WSDL较CORBA IDL在接口解耦方面的执行要更加完全，因而更受关注，也正是如此，支持了服务执行与可演化的扩展接口能够开发和部署以往版本的任一特定定义或模式，以满足各个不同使用版本的客户或者消费者继续运作其服务。同样，这也是WSDL倍受关注的原因之一。

　　忽略掉这一优势将会有非常大的隐患存在：如果你还在继续发展着你的服务实施，但是却只考虑到以后的兼容问题而没有更多的考虑向前兼容，那对于你当前已有的客户而言这必将会是一个巨大的困难。

　　因此，当选择一个容器和运行环境用以支持一系列广泛的编程模型时，其相关的IDLs(如果有的话)是否有能力支持多个版本特定服务的执行与接口将会是关键所在。

　　在应用程序与服务之间第二个比较明显的区别在于，服务相对于应用程序而言在超越其自身生命周期的时间里还会有更多不可预测的需求出现。随着SOA部署的不断成熟，那些在部署过程中关键的，有效的服务将会越来越多的被反复利用起来，而且在很多时候，这些服务并不是最初就被开发人员和部署人员意识到可以重复使用。

　　因此，容器和运行环境对于特定服务的支持规模以满足其客户或消费者多种可变需求的能力将会决定着SOA部署任务的关键环节。由于SOA架构下的应用程序往往有着固有的分布式性质，某一特定的组合式应用，其健全程度和可升级程度大部分情况下也仅仅只是和其中的某一特定构件保持一致。这一点在已有的应用和部署中早已显而易见，但是却在开发和部署组合式应用的时候经常被忽视掉，以至于造成了严重的后果。