是SOA仍然神秘，还是人们不再关注它了?1996年，Garnter第一次对SOA进行描述，从那时算起，SOA已经出现一段时间了。Garnter曾经断言过，到2007年，SOA将成为全球公司的主流。

　　到目前为止，面对所发生的一切，我们是否震惊?虽然，看起来已经有大量关于SOA的论断，但这些都还不称不上主流。最近，国际性标准化组织OASIS在其SOA 相关模型一文中，为SOA做出了一个标准定义。虽然，要定义一个已经出现了十几年的术语，这确实是有些令人难以接受，但是他们做到了。

　　目前，SOA仍然依赖着其提供者，还是已经摆脱了他们的限制?商业团体看起来并不关心SOA如何发展，那么，IT团体就真正的关心么?我们好像陷入了一个教授、推广和概念验证的阶段。要到什么时候，所有大SOA新方案才能够开始实施，预算才能够拨下来呢?我们都知道，为IT项目定义投资回报率(ROI)是多么的困难，而且SOA没有例外。那么，SOA提供者真正看重的SOA敏捷性和重用性优势是什么呢?由于SOX方案符合最初的预算，虽然，SOA已经将其自身定在治理方面，但是，这并不能使SOX摇身变成大的SOA新方案。

　　当然，SOA团体是积极主动并且充满激情的。我们向商业团体谈论关于松散耦合服务协调合作的可能性，在我们脑海中，这个话题时非常宽泛的。我们关心SOA，但是交谈对象并不关心。当我们试着向他们解释SOA的强大和典雅时，他们点头表示同意。因为SOA的活力，所以商业中到处都充斥着贯名SOA的会议。会议名称里面有SOA这个术语，当然是无可厚非的，但是，当会议结束，这些与会者回到日常的业务中，他们仅仅学到了一些新的首字母缩写，而并没有准备开始实施实际项目。

　　我推测，这些商业人士在听我们谈论SOA时的感觉，就像是我在艺术博物馆所感受的，我知道我所看到的艺术品有其伟大之处，但是我并十分确定该伟大之处到底在哪里。对于那些非常欣赏艺术的人们，在对所看到的艺术品进行交流讨论时，他们会使用很有想象力的术语，而这些术语我基本上都不理解。当他们向我描述艺术品时，我能感觉到他们言语中的激情，而且在那一瞬间，我能够理解他们所描述艺术品的伟大之处——使一个艺术家伟大而另外一个平庸的关键。

　　但是，当我转回到自己的立场，对我而言，伟大之处是很难定义的——它涉及的内容太广。因此，我怀着对所见艺术品的欣赏和所受的一些灵感激发，离开了这个艺术博物馆，但是，我发现，我离开了博物馆之后，我的生活并没有因为这次经历而受到任何影响，因为有很多其他的事情使我分心并且占据了我的生活。

　　同样，我们这些对SOA着迷的人们，被SOA的魅力深深打动，并且满怀激情，当我们向他人解释SOA时，他们能够欣赏，但是最终没有付诸实现。如果说，IT团体类似于艺术博物馆里的成人，那么，商业团体就像是孩子。当我们充满激情地向他们展现SOA时，他们的眼睛神扑朔迷离、整个人变得毫无生气、他们甚至在内心大喊“我对此很厌烦!”这确实是个问题,因为商业团体掌握着预算，而且如果他们愿意的话，他们完全能够操纵预算的改变。

　　那么，我们应该怎么办呢?热爱SOA的我们如何才能推广SOA，并且使大家对SOA的认识有所改善呢?我们如何才能使SOA有价值呢?

　　下面是一封写给SOA团体的公开信，它根据不同的小团体，提出了如何帮助改善SOA的建议。

　　SOA 解决方案提供者——使SOA更加清晰。现在的市场并不十分成熟，因此，解决方案的提供者经常通过定义市场本身，来抓住这个市场。直到有一些实际的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新方案还没有真正地开始。 I

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

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

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

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