当今，无论你走到哪里，都会看到一些关于SOA的东西，以及关于用“适当”的方式执行它的争辩。笔者认为这一点也不奇怪，因为伴随着每一个IT行业相关的新趋势的出现，都会有争辩，并且卖主会尽力说服顾客相信，他们的技术才是适当的技术、产品。
当卖主为了迎合消费者对于信息技术一个新趋势的兴趣，试图重新配制他们现有的产品组件时，抢夺开始了。但是很不幸，这种行为通常会引起许多混乱局面，因为卖主的诺言一般是不会实现。当然，面向服务架构适当的技术方案，也可能并不像他们说的那样好。
为了对此建立正确的观点，重要的是应该注意到，像定义所说，SOA是分布式的。一项服务的目的就是，通过远程线路跟另一项服务相通，以共享数据为特色。而其整体的目的是，改变信息技术的途径，由原来的制定辐射中心的小部分应用软件，到制定另一系列的应用软件，它可以通过集合共享的并且可以再度利用的功能性，即各种服务，开发和汇集越来越多的应用资产。
紧耦合VS松耦合
现在宣传SOA的厂家非常之多，但是真正提出分布式SOA架构的并不多。因为很多大型软件厂商习惯了以紧耦合的方式提供SOA架构的主要功能，SOA紧紧地和他们的数据库、操作系统、服务器和存储绑定，这种紧耦合方式缺乏与其他系统的互操作性，初期需要大量的资金投入，往往会导致用户对某个厂商的依赖。紧耦合式SOA架构导致用户对采用SOA处于犹豫状态，因为还未看到成功的希望时就需要大量的投资。
面向服务的体系结构最重要的一个思想就是实现软件间的松耦合。松耦合的软件结构可以降低软件的复杂性，提高重用性，使软件能够更好地适应需求的变换。
其实，用户更需要低成本的SOA解决方案，令他们可以从小规模SOA做起，并随着业务的增长逐步扩大规模，同时根据自身的需求增加服务质量和其他功能等。
与此同时，用户可以使用点到点的通信方式，避免新增加昂贵的服务器。简而言之，SOA用户需要的SOA架构必须真正具备SOA架构的固有特性也就是分布式的特性，如图1所示。
SOA的本质是通过松耦合的方式实现服务的重用。分布式SOA则是把松耦合的优势发挥得淋漓尽致。它可以帮助用户摆脱紧耦合的束缚，以较少的投资开始SOA建设，用户只配置需要的功能，并根据需要以渐近的方式扩大整合的规模。分布式SOA可以在运行环境中动态配置,也就是说用户的业务无需中断。分布式SOA基础架构，具备今天SOA所涉及的全部元素。
一个分布式SOA的基础结构，代表着配制和吸收可共享和再度利用的服务最简易的方法，促进对服务的应用，提高部署的灵活性、适应性和持久性。
不幸的是，到达SOA基础结构的途径被集中化，并不断被开发和提议。
对于卖主来说，说服购买技术的群众相信提供给他们的技术已经是跟SOA相适应的，以前是，以后也是，设计这项技术的初衷就是加快顾客走向SOA的步伐，将是一个更艰难的过程。卖主也不管它最初是以J2EE应用服务器还是EAI系统的形式设计出来的。
换言之，对分布式SOA持对立态度的卖主通常这样做，因为途径集中化是他们已经拥有的软件基础构架的特征。一个更新了的企业应用集成或一个基于JEE的堆栈，或其他任何在通过中控点时需要发送请求的方案，都不能被看成是真正的分布式，因为它们所有通向服务路径的前提都是必须首先进行集中处理。将通往SOA途径集中增加了成本，限制了再利用，降低了灵活性，且暗中引入了一个昂贵的瓶颈。最坏的情形是，它将在第一时间否定到达SOA的理由。如果SOA的基础构架的灵活性没有满足他们的要求，人们一定会感到很失望。
只要上网查，就可以了解分布式应用软件满足其用户需求的成功案例。网络是目前最大的分布式应用程序，由特征决定其分布模式，SOA是同样的道理。
当你在浏览器上点击一个链接到某一个具体网址时，你的需求并不需要经由某个配制在一个服务器或者网络中心的中控系统，而是直接从你的浏览器传达到网络服务器，这种模式在企业的SOA运作得也非常好。
网络终端能够以个体为单位进行升级，而不会打断客户机程序的运转，影响其他站点，或者导致中央集线路或服务器也需要更新，那是因为需求不需要首先通过一个中央集线路或者服务器。一个好的SOA的基础构架同样支持这些性能。
幸运的是，一个基础构架方案包含了SOA分布式的特征。到达SOA基础构架分布式的途径使用很精巧的终端，有可提供服务的应用软件，并使得这些软件能够直接跟其他服务相通。企业性质的服务，比如具有高度的实用性或者安全性的服务，也可以由终端系统提供，以确保现有的承担着重大使命的应用软件有所依靠。
分布式SOA的基础构架是关于创造信息技术环境的，这个信息环境是一个交流平台，标准高，灵活性强，所以它可以对不断更新的技术和商业前景做出更有效的反应。因此，一个分布式的SOA工作环境能够更好地支持一个以SOA为基础的应用软件的技术和经济需求。最后，到达SOA基础构架的分布式途径允许你以自己的速度进行，每次配制一个或两个服务，可以根据需要随时增加服务，注册/存储库，管理等功能，而不是事先就必须完全添加好的。
分布式SOA的好处与航空行业有相似之处，后者用成本低廉的操作系统挑战着已建造的航空器。已制定操作系统的方法是以一个成本很高的枢纽和辐射模式为基础，通过少数几个专业的旅游中心汇集乘客。操作大型飞机需要更多成本，从分支机场飞往枢纽机场，乘客在那里准备继续他们的旅程到达最终目的地。用这种模式，飞机需要更多成本，机场设备的费用也因此增加。当低成本航线—一个分布更广的，点对点的运作模式(较小的飞机直接飞往较小的机场)—被制定出来之后，被传统的枢纽模式所束缚的航线便在资金方面处于劣势。
SOA的消费者不需要再花钱买老式的昂贵的软件堆栈了。SOA设计需要一个好的方式来创造和配制可再利用性服务，无论何时何地只要有需要就能够很简易并且直接地拿出来用的方式。消费者需要成本低的选项，可以让他们从小规模开始，随需要逐渐增加对它的采用，运用点对点通讯方案可以避免使用昂贵的新服务器和集成线路，根据需求增加服务的质量和其他性能。总而言之，他们需要SOA的基础构架，它能够真正符合一个SOA固有的分布式特征。
SOA治理同等重要
随着服务数量的增加，管理服务成为SOA过程中的一项重要工作，与IT治理同等重要。
同样需要指出的是，IT系统在建立之日起就需要考虑IT治理的理念和方法一样，SOA也存在着类似的问题。随着大量服务的构建，系统也日益复杂，尤其是随着服务的可重用性日益提高，调用同一个服务的请求的个人和部门也越来越多。而Web服务的数量越来越多且被不同的部门调用和管理的时候，SOA治理问题就被提上了日程，对IT系统有灵活、可扩展和快速响应需求的企业尤其如此。所以说，SOA的构建和与治理几乎是同步的，这关系着一个企业能否从SOA上获得高收益，甚至也决定着SOA的成功与否。
SOA治理并不设计服务，而是指导将如何设计服务。这可以帮助回答和解决很多关于SOA的问题，包括:我们提供了那些服务？谁可以使用这些服务？它们的可靠性、安全性如何？……
因此，治理更多的是策略问题，而不是技术或业务问题。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
