现在的市场并不十分成熟，因此，解决方案的提供者经常通过定义市场本身，来抓住这个市场。直到有一些实际的SOA解决方案出台，产品厂商才能够真正的成为该产品具有支配力的提供者。这并不是一件坏事情，除了会带来解决方案提供者之间的激烈竞争外——因为，各大提供商需要在其独家产品中创建新的术语、纳入与众不同的功能，以此来定义市场。

　　TICBO通过通用接口(General Interface)平台，为创建Ajax Web应用程序添加了支持。LogicBlaze在它的FUSE SOA解决方案中，也已经纳入了LifeRay门户。IBM的SOA基金会，在它的WebSphere应用程序服务器中，添加了大量的包括从商业模型到身份管理的软件。不能因为竞争而抨击这些公司，但是，如果因为竞争，使得SOA平台中包含了几乎所有的东西，那么，“SOA”的概念就混淆了，这个术语应该同时更名为“Web技术”。

　　从解决方案的角度来看，SOA是关于中间件的。它是关于消息队列、协作和改变的。它是Web服务和企业服务总线。这些才是SOA解决方案的领域，而门户、身份管理和应用程序服务器——这些都是为了竞争，为了使SOA看起来更加强大，所添加进来的外部功能。SOA解决方案的提供者们，应该为提供最好的SOA中间件而进行竞争，并且竞争优势应该有所区分，比如，为提供者创建强大的通讯机制、为用户创建清晰的解决方案。SOA的提供者，应该通过提供最佳的管理界面、最简单的安装、最完整的文档和支持，以及更高的服务质量来赢得用户，而不应该担心惶恐于是否需要把每一个Web功能的类型都添加到平台中。

　　标准本身——保持简单

　　现在SOA的标准实在太多了。正如SOA的提供者，标准本身通过竞争，来定义最流行的和采用最广泛的标准。因为，理所当然地，提出标准的公司提供具有竞争力的优势，自然就是第一个提供依赖此标准的解决方案的公司。

　　这样的结果就是一场标准之战，试图使解决方案的结构标准化。如此一来，导致的后果就是——SOA的众多解决方案通常无法协同工作，因为每一个解决方案所遵循的标准总是有所不同。为了帮助解决这个问题，类似WS-I这样的公司应运而生。WS-I公司所做的工作主要是，促使Web服务能够跨平台、跨系统以及编程语言地进行互操作。WS-I的基本框架(wsbasic)是基于其他标准的，包括W3C的WS-Adressing，SOAP绑定以及WSDL绑定标准。它是所有标准的标准。

　　WS-I公司的出发点是崇高的，但是，它的存在就代表着，SOA有太多的标准而且这些标准仅仅都是Web服务标准。如果再考虑SOA技术，如JBI、JMS、J2EE以及其他技术，那么，问题变得越来越严重。一些新方案，如服务组件架构(SCA)、服务数据对象(SDO)，为了解决这一问题，它们尝试着通过使用通用的API来继承各种各样的服务，但是，这样做还不如创建新的标准，因为更加让人迷惑并且增加了复杂度，如此看来，关键是要保证标准简单。

　　REST是具有支配地位的Web服务API，因为它是如此地简单。虽然，它没有大多数结构化的Web服务协议的功能强大，但是，它能够解决整合所涉及的大多数问题，而且它极其的简单，因此REST能够被广泛采用。复杂标准非常难以推广，Java/J2EE团体已经吸取了这一教训，因为，如此强大的语言，它居然输给了十分简单的PHP、Perl、Python以及Ruby这样的语言。J2EE最新的变身——JavaEE 5，其目的就是，通过使代码编写更简单、更直接从而使开发更加简单。

　　SOA看起来会继续向着复杂标准的方向继续发展下去，但是，我们不应该这样做。创建简单的标准就能够解决SOA中90%的问题，剩下那10%的问题，就留给那些更加复杂的特性和标准吧，推崇简单的标准，这能够使用户更加轻松地采用SOA。

　　大学——教授架构知识

　　一个刚毕业的计算机科学与技术专业应届生，不知道什么是架构。不了解什么是企业或应用程序的架构。对架构概念，如模式、聚合、封装、松散耦合以及重用，没有很坚实的基础知识。

　　对于一个系统中的服务元素质量，几乎一点也不了解。不能很好的理解组建和对象的不同之处，完全不懂这些组件是如何组成一个服务的。因此，对于这些毕业生而言，SOA就是一个抽象概念。他们认为，SOA是产品、一套标准集或者是仅仅是新的首字母缩写集合。

　　如果对软件架构基础结构不理解，那么，SOA是模式或者是架构的评价这一认识，就很难理解。如果是公司，就应该组织人员和设备来教授什么是软件架构; 如果是个人，我们就自学什么是软件架构。因为，有太多的IT职位根本没有机会来学习这些基础结构，因此，SOA被当作是失败的或者仅仅遥不可及的概念。

　　因为上述现象，SOA将是毫不相关的，因为，如此多的用户对SOA的架构基础一无所知，SOA根本无法解决所遇到的问题。理解架构的工程师们有机会看到SOA的价值，但是，那些不理解架构的人们，是无法理解SOA的价值的——无论他们评估过的多少SOA产品。

　　咨询顾问—— 使SOA与商业相关

　　咨询顾问能够访问公司的业务团体。如果SOA达到了商业潜力，商业用户就必须给它估价。这是SOA咨询顾问的责任——使SOA与商业相关。

　　咨询顾问们使用商业语言进行讨论。他们不谈论技术术语，如Web服务和协作，而且肯定不会用到SOAP和BEPL。他们所谈论的是，关于快速转向市场、通过重用和使业务改革创新的能力来降低成本。他们关心投资回报率(ROI)。

　　遗留系统给业务带来禁锢的商业用户。而SOA允许快速的改变，以及成本更低的系统整合。咨询顾问要使商业用户关心SOA。使商业用户理解他们所拥有的服务。图形化模型服务，从某种程度上说，商业团体更加容易理解，并且能够参与进来。从而使用与商业相关的命名法来命名服务。

　　商业用户并不会像工程师那样为SOA激动，但是，至少咨询顾问可以使商业用户了解服务的真正价值之所在。向他们证明，SOA能够更快更节省的创建应用程序，比任何方式都具有优势。并且，使他们认为SOA非常重要。

　　IT公司—— 不仅仅是概念验证

　　IT部门在推广SOA和实施新方案方面做得非常好。然而，这基本上是采用概念验证的格式和SOA的策略。主要的SOA新方案还没有真正地开始。

　　IT公司应该尝试着从概念验证到SOA产品系统。不再把SOA当作企业级概念，而是把SOA用于整合应用程序，使用SOA概念来构建个人应用程序。使SOA不仅仅是CTO和企业架构的王国。

　　在更小的规模上使用SOA技术，并不是如此困难。这种概念验证为实现提供方法，因为规模并不是最重要的因素。这是给公司介绍SOA、以及深入浅出的解释SOA概念的最佳方式。

　　虽然，有很多关于SOA的评论，但是都没有具体实现。SOA仍然在慢慢揭开她的面纱——SOA有可能向数据集中、面向对象数据库的道路发展，因为，很多该领域的其它技术都无法满足最初的期望。当然，SOA在架构上是个非常大的进步。

　　大多数软件工程师都知道SOA有迷人之处，但是，到底是迷人之处在哪却难以解释。这就是在SOA团体的人们应该尽到的责任，帮助人们认识SOA并且使SOA更有价值。

　　查阅关于SOA的全部文档

上一篇： 傲慢与偏见 程序员想让HR知道的七件事
下一篇： 透视“语言大战”：C++呼唤敏捷实践