严峻的经济形势，缺乏有说服性的案例使得SOA开始面临质疑，有分析师断言SOA已死，并批评SOA项目浪费了企业大量的投资。
 

    这真的是SOA将死的预言，还是对SOA的深刻反思，企业又该如何避开SOA的误区，迅速切入SOA，并看到收益呢。

    刚刚进入2009年，Burton集团副总裁兼研究总监Anne Thomas Manes在她的博客中宣布SOA已经死亡。她说:“2009年元旦，SOA遭遇死亡，经济衰退的灾难性影响彻底摧毁了它。”
 

    她认为SOA曾被认为是IT的大救星，现在却证明是一项极其失败的试验——至少对于大多数组织而言如此。SOA被认为能大规模降低成本和增加机动性。但除了极个别情况，SOA并未兑现它承诺的好处。在投资百万后，IT系统并未得到改善。许多组织的情况更糟:成本增加、项目延期，系统比以往更脆弱。手握钱袋的人们对此已感到厌倦。鉴于2009年的预算紧缩，许多组织消减了他们SOA项目的资金。
 

    此言一出，在IT界引起了轩然大波，不少分析师表示支持，并拿出了自己的观点。不过即使这些支持SOA概念已死的人也承认:SOA提出的理念和思想是先进的，它将渗透在其他形式中继续发展。
 

    那么SOA本身为什么面临着如此巨大的挑战，SOA产业的推进是否陷入困境中呢？“SOA向我们描述了一个美好的愿景:降低复杂性、松耦合、灵活支持业务等等，但是这些好处都是不可量化的，属于隐形的收益。”赛迪顾问副总裁张涛告诉记者，“归根到底，SOA的核心和难点在于架构和思想，而不是技术。”
 

    正是SOA所提倡的架构革命、业务价值、IT与业务的一致使得SOA在现实当中困难重重。因为它只是提出了理念、思想和目标，并没有给出具体可行的实现方法，而这个理想又过于美好，类似于共产主义的终极诉求。“过高的目标压垮了SOA本身，因为一旦无法实现，就面临着被质疑甚至被否定的结果。”一业内人士指出。
 

    SOA被质疑是否就真的表明SOA已死呢，换个角度，我们可能会有不同的看法。权威的全球IT咨询／分析机构Gartner在1995年发明了一个叫“炒作周期 (Hype Cycle)”的曲线模型，利用它来观察、预测各种新科技被企业接受、落地的成熟度。
 

    这个曲线模型把任何一个新兴科技的发展分为五个阶段，触发阶段、夸大的期望定点（炒作最厉害的时候）、幻灭的谷底（被质疑、被否定的时候）、启示的上坡（应用开始出现并蔓延）、生产力的高原（广泛的应用，最终开花结果）。
 

    每年Gartner针对不同的行业和技术领域，都会更新其炒作周期曲线，2008年公布的曲线图中，SOA正步入“启示的上坡”阶段，表明SOA应用已经开始出现，并正在逐步推广过程中。
 

    其实不管质疑、否定，或者是静悄悄，都是任何一个新兴科技发展的必然阶段，它反而表明了这项新兴科技真的开始进入应用阶段，而不再是华而不实的炒作和空口承诺。因此对于“SOA已死”的争论不妨看做对SOA的有益反思。

SOA的五个切入点

    无法落地，无法看到投资回报是SOA当前面临困境的根本原因，这也是SOA应用过程中的硬伤。如何迈出第一步，让SOA的理念变成现实，让SOA口号变成真真切切可以体验到的幸福，这是SOA至关重要的一步。
 

    为此，IBM很早就提出了SOA的五个切入点，它们分别是人员、流程、信息、连接性和重用。其中人员、流程和信息是任何一个IT项目必须考虑的三要素，而连接性和重用则是SOA的精华所在，连接异构系统，实现代码重用是SOA在架构层面的本质。
 

    在人员方面，SOA 的这个切入点关注用户体验，从用户的角度入手来考虑SOA。例如在交通银行中开展的SOA项目，一开始就提出了“One Page”的概念，也就是说对于每个使用人员，他所有的操作只要在一个页面就可以完成。而不用再像以前那样，报销的时候要进入财务系统，预定办公室的时候再进入OA系统，请假的时候又要进入HR系统。在新的页面中，这些系统都变成一个个的功能被嵌入在同一个页面当中。当然，面向不同类型的人员，这个页面也是不同的。
 

    流程切入点可帮助企业了解其业务中发生的情况，从而支持其对现有业务模型进行改进。SOA所倡导的服务就像一粒粒的珍珠，而流程则是串起这一粒粒珍珠的线，在SOA中，通过利用BPM（业务流程管理），不同的服务被灵活地组装在一起形成新的应用，而其中的核心在于灵活的组装、动态的调整和持续的优化。
 

    信息切入点确保能以一致而可见的方式利用公司中的信息。在SOA的架构中，信息也是以服务的形式来展现出来的。
 

    连接性切入点强调各个层面的互联互通，强调异构系统的连接，以此，所有的服务都可以进行对话和交互。其中，ESB（企业服务总线）是最常见到的产品和技术。
 

    重用切入点即SOA所倡导的服务，IT被模块化，并以服务的形式来展现自己，这样现有的资产就可以被最大化的重用，提高投资价值的同时，缩短应用开发时间。“在SOA时代，一个新应用的开发，大部分的工作是组装现有的服务，而不是开发新的代码。”普元CEO沈惠中说。
 

    从以上五个切入点的任何一个入手，都可以开始SOA的项目，不同企业可以根据自己的现实状况和需求，寻找最适合自己，最迫切需要进行改进的地方，从而有针对性地解决问题，开展SOA项目。不要为了实施SOA而实施SOA，这样SOA的价值才能找到承载体。
 

    对于迫切需要进行流程组装的企业，例如电信、银行各种的业务系统都迫切地需要流程的支持，就可以以流程入手，通过BPM来切入SOA应用;而对于那些已经存在大量应用系统，但是却彼此孤立的企业，则可以从连接入手，通过ESB来切入SOA应用;而对于那些有大量的应用需要上线的企业，则从开发阶段就开始切入SOA，以方便以后的重用和连接。
 

    如此以来，SOA这个宏图理念就变成了现实中可以操作的项目，而SOA所宣扬的价值也找到了落脚点。

SOA的误区

    尽管SOA最初主要被技术人员接受，但就其本质而言，它是业务而非技术问题。又由于是技术人员和产品提供商引入（并且往往执行）了SOA，他们对SOA技术（软件销售）的关心要多过对其本身业务影响的关注。
 

    热衷技术问题，而忽略业务价值使得SOA局限在技术圈子，无法在最终用户那里得到认可。热衷细节，而忽略架构使得SOA的价值无法发挥。同时厂商对于SOA的宣传成为其兜售产品的噱头，用户误以为只要购买了相应的产品就等于实现了SOA，在配置了一系列的ESB、BPM、WebService工具后，迟迟看不到其价值，大量的产品被闲置，用户逐渐对SOA失去耐心。
 

    “人们忘记了SOA的目的，沉醉于愚蠢的技术争论（如‘最好的ESB是什么？’或者‘WS-*火拼REST’），却遗忘了重要的内容:架构。”Anne Thomas Manes说。
 

    另一位分析师Steve Jones指出:“并不是说SOA已死，而是意味着在无法销售更多的ESB和Web服务工具时，市场对T-SOA（Technology-SOA，技术性SOA）不再青睐。剩下来的，SOA的服务所带来的事实是SOA的起点不是那些绚丽的技术;如果你采用新的技术，而不具备服务的心态，那么你就会制造一定程度的混乱，结果会轻易地让咨询师和提供商利用EAI而大发横财。”
 

    热衷技术和产品的典型表现就在于对于ESB的态度，很多人把ESB等同于SOA，认为购买了ESB，SOA就指日可待了。殊不知，ESB的作用只是在于跨越异构的系统把服务连接起来，使服务与服务彼此能够沟通。在当前企业的IT系统中，服务尚且不存在，何来连接服务？即使存在服务，在未达到一定数量的时候，也根本没有采用ESB的必要。
 

    “ESB就是道路，试想城市规划时是先把所有的道路都修好，然后再去修大楼吗?”IBM SOA中国设计中心主任毛新生说，“ESB是后一个阶段的事情，不要一开始就采用它”。
 

    在中国， SOA概念已经获得了绝大多数用户的认可，很多企业在招标中已经明确地把SOA提出来，要求支持这种技术方向。不过沈惠中指出，用户对SOA的认知只是停留在概念层面，他们只知道SOA是未来的方向，是先进的，却很少有人能够真正弄清SOA是什么。SOA被当作金纸，只是贴在脸上让别人看的。
 

    这种对SOA浅薄的认识很可能成为SOA项目未来的隐患，“SOA已死”的争论表明了国外已经开始认识到SOA走入误区后的危害，而IT落后美国数年的中国，如果不能避免SOA误区，迟早也会遇到同样的危险。

SOA从应用开始

    对SOA如何落地，沈惠中认为有两种方法，一是从架构入手，一是从应用（下文的应用都是指应用系统，如CRM、HR等）入手。从架构开始是一种自顶向下的方法，在统一的规划中实施一个又一个的SOA项目;而从应用开始是自底向上的方法，每一个应用都采用SOA的方式来构建，当应用越来越多的时候，SOA项目就开始显现价值。
 

    不过，沈惠中指出从架构入手，虽然可以有统一的规划，但是周期过长、风险较大，在前期就要投入大量的资金和时间，进行总体设计和系统搭建，而SOA所倡导的灵活性和低成本是无法在这个阶段体现的。
 

    “起一个SOA项目，首先把所有的基础设施建好，最后再用统一的框架把原有的系统做一遍。5年过去了，但是这5年，企业的业务需求也发生了巨大的变化，外界环境和技术潮流也在快速演进，而以前的规划又落伍了”沈惠中说。
 

    在美国，一些企业的IT部门会有专门的架构组，负责整体的规划和设计，所有的系统和应用都必须按照架构组的要求进行。在这种企业中，从架构入手的办法还能发挥作用。但是在中国，企业的信息化程度普遍较低，很少有专门的架构组，即使从总体架构角度来考虑每一个系统的建设仍是比较少见的。中国的IT建设基本都是采用项目制，在总体规划上相当薄弱，因此从架构入手，中国企业既没有经验，也缺乏相应的能力。
 

    “在中国只听说过OA的项目、CRM的项目，很少听说过一个架构的项目。只有满足具体业务需求的项目才可能被审批，那些无法直接产生业务价值的项目则很难通过。”沈惠中告诉记者。
 

    此外，中国的信息化还处于初级阶段，有大量的应用和系统需要建设，面临的主要任务是承建新的系统;而美国的信息化已经相当成熟，存在着大量的系统和应用，面临的主要任务就是集成和改造。中美的现实情况不同，决定了切入SOA的方式也不同，在美国，从架构入手更容易推动，而在中国，从应用入手则是最现实的选择。
 

    “在做一个OA项目的时候，我们基于SOA来构建一个OA项目;在做一个CRM项目的时候，我们基于SOA来构建一个CRM项目。在一个个基于SOA的应用逐步建立的时候，SOA已经开始发挥作用，并且越来越大。”沈惠中说，“每前进一步，我们都能体会到SOA的价值，并且积累下经验，培养好人才，为下一个项目做好准备。”
 

    沈惠中指出这种办法循序渐进，每一步都能看到收益，信心越来越强;每一步都扎扎实实，项目越做越好。“不要妄想一口吃个大胖子”他说。
 

    此外沈惠中也指出，在初级阶段应该把精力主要放在模块化、松耦合、符合标准上，而不要过分追求服务的切分。“服务的切分是个无解的事情，在稳定性和灵活性中间寻求最好的平衡点是门艺术。”沈惠中认为SOA必须从业务出发，但是不要被业务价值所吓到，否则SOA永远也落不了地。

SOA实施路径

    Anne的言论可以理解为，现在的经济环境，自上而下实施SOA来的太慢了，不如自下而上见效快。

    关于SOA已死的话题，这两个月不断接到各个方面的问讯，语出自Anne Thomas Manes两个月前的一篇博文，大意是在当前环境下，SOA早期的很多项目因为没有达到相应的效益而面临挑战。这里不再赘述，倒是想借此话题谈谈SOA实施几年来一些模式的变迁与当前的状态。
 

    几年前SOA刚刚进入媒体与公众视线的时候，我发现了一个有趣的现象，不同的人对它的认知完全不同，媒体与市场营销人士将它作为一种革命性的趋势，而多数的工程师与架构师都认为SOA只是一个“Market Term”, 没啥新鲜的。他们认为SOA不过是在面向对象的方法上加了一层包装，用了更为标准的技术尤其是Web Service而已。
 

    客户方的业务人员听到这词汇，多半认为是个抽象的技术术语，没法理解SOA怎么就面向业务了。对业务人员太抽象，对技术人员太市场，SOA这个概念从一开始在认知上就波折不断。
 

    在最早客户谈论SOA 的年代，私下里我经常自嘲我所推广的东西是门屠龙之术，一般的企业是短期内派不上用处的，没想到后来SOA如同超市里的绿色食品标签，在国内所有的软件领域散播开来。
 

    SOA一词这几年的变迁，在媒体，工程师，业务人员的头脑中也如同变色龙，不仅在不同角度上看颜色不同，随着时间的推移这个词的含义也有了侧重点的变化。
 

    SOA的实施模式与侧重点也在这段时间发生了一些性的变化。这里借助国外的一些调查结果，结合自己与一些国内具体项目的观察，给出自己的分析，算是仁者见仁，智者见智的一种。
 

    去年开始，媒体对于SOA开始失去热度，大有“行到水穷处，坐看云起时”的味道。于是Anne女士的SOA已死才有被断章取义，广泛探讨的现象，Anne女士提到的很多逻辑，自有她的见地，我更愿意从SOA的实施模式来探讨。服务化的架构在她的文章里也是永存的，她说的SOA已死在我理解是某种SOA推进模式在目前的经济环境下遇到巨大的挑战。

SOA的实施模式与状态
 

   InformationWeek给出的国外SOA实施分析报告来看，超过54%的企业项目达到或超过预期，已经是一份不错的成绩单，其情形并不比几年前的ERP实施更差。
 

    从国内的客户情况来看，SOA的侧重点从强调开发模式的革命性转变，过渡到企业切入点的探讨，再到架构的规划与治理，乃至SOA有关的项目与管理，其实它的主线已经相当踏实。
 

    我长期跟踪的一些客户SOA项目都在逐步做到2期，3期，有些已经扩展到企业级，其中大型企业集成项目、流程整合、数据整合、门户整合、业务总线等项目的客户都尝到了甜头，业务价值值得肯定。
 

    不过相比于整个的国内IT客户群，应该承认，真正实施SOA客户的还是极少数，归根到底，SOA项目的实施，离不开高水平的架构与规划人员，这部分人的数量扩张是SOA扩张的瓶颈。
 

    购买挂了SOA 标签的软件产品和SOA的真正实施之间，还有一段不小的距离。用作标签的SOA，其时髦性现在被云计算、SaaS、Mush-up等后来的热词替代，但背后说的那个服务化的总趋势其实一直都在发展，因此才有SOA 已死的后半句，“尽管SOA这个概念已死，但是人们对面向服务架构的需求比以前更迫切了”。 

更快兑现业务价值
 

    从另一个角度，这场有关SOA生死的讨论，让我想起2004年那场“Does IT Matter?” 争论，研究与学术机构总是有反骨的，这是他们显示自己价值的地方。当时的质疑者针对的是套装软件的投资方式，假如两家互相竞争的汽车制造公司都部署了相同版本的ERP软件，软件本身并没有给其中之一带来特有的竞争力，而仅仅成为一种“Me Too”的技术设施。
 

    这场针对IT价值的争论和目前的SOA生死的争论有内在的联系，Anne指出的一些SOA项目短期没有兑现业务价值的承诺，与IT价值的争论如出一辙。她在肯定面向服务架构作为一种架构模式的同时，对初始SOA项目过于计划性的实施模式提出了质疑。
 

    的确这几年的经验下来，自上而下的大型SOA实施的确遇到了短期价值不明显，甚至成本更高的结构性难题。她在文中提到，作为一个词汇的SOA已死，但她的后继者，云计算、SaaS、Mashup反而带来更为强壮的需求。
 

    让我们尝试分析她提到的后继者有何规律，最近看了一篇文章，陈述采用轻量的REST代替SOAP模式的服务架构实施的效果会更快。我们权且做这样一种立论，服务导向的架构是一种不可逆转的总趋势，但采用原有自上而下的长期项目的实施模式因为周期过长，遇到组织变化等原因导致短期内的业务效益受到质疑，尤其是在当前的经济环境显得更为挑战。
 

    采用自下而上、借鉴互联网模式的、业务价值明确的方法逐步成为实质上更为普遍的方法。换句话说，以企业级业务服务重用，彻底改变开发模式的初始SOA推进模式在实际中，逐步被更加针对某些具体业务问题的模式所替代，因为后者更易滚动实施业务价值的轮子。
 

    比如SOA治理这个主题，理论上是SOA服务重用的关键，没有清晰的治理策略，大规模的业务重用无从谈起。问题是，对于一个还没有实施一个SOA项目的客户，在听到SOA治理难度后，多半会知难而退，我就见过听了SOA治理主题后决定放弃项目的客户。
现在大家都有了经验，只对已经实施了SOA项目，取得了业务效益，但被服务管理所困的成熟客户去谈SOA治理，从而避免了吓跑初期客户的尴尬。
 

气宗还是剑宗？
 

    由此看来，SOA生死的讨论，其实是SOA实施路径选择的讨论。这里引用笑傲江湖的气宗剑宗来将问题形象化，初始SOA的教义类似气宗，就是刚才讲的自上而下的模式，特点是循规蹈矩、按部就班、全盘规划、同步推进，但见效较长。
 

    近期的BPM、数据整合、服务总线实施等算是剑宗，是自下而上的模式，项目实施的时候先不考虑过于全局性的问题，比如业务分拆，而致力于先解决一个业务问题。
 

    Anne的言论可以通俗化地理解为，现在的经济环境都是短兵相接，练气太慢了，不如一剑封喉来得可行。遥想令狐冲当年，在风清扬的现场教习下，打败田伯光，剑宗的厉害大概也是当下CIO们向往的吧。
 

    我前面谈到的一些国内SOA客户，几乎都采用了从单一项目入手的剑宗手法，在项目管理、主数据管理、管理仪表盘得到良好收益，其中一个项目也采用了中间相遇的实施方法，就是把自上而下和自下而上结合的办法，可以成为剑气合一。
 

    其实剑宗的手法，是受了互联网模式的启发，试问有哪一个互联网巨头是采用“养气”的办法起家。亚马逊去年成功运用“平台即服务（Platform As A Service)”模式，将自己的技术平台作为一种商业产品卖给做网上业务的其他公司，算是剑宗里的独孤九剑。
在近期的金融危机的环境下，流程快速变更、数据和实时性分析、应用的快速重建，都需要依托服务化来完成，这几把利剑的商业价值，可能比泛泛的SOA生死争论对于企业更为急迫，对于企业CIO来说，已经没有空间为SOA而SOA，而是要针对当前业务特点谨慎确定实施路径，才是最现实的。
 

(刘松:甲骨文fusion产品战略总监)
 

黯淡，还是涅磐

    纠缠与SOA概念并没有意义，SOA所倡导的敏捷性、低成本不正是我们一直都在不断追求的目标吗？

IBM的SOA架构框架

    当百年一遇的经济危机在全球愈演愈烈的时候，越来越多的纷争和思考已经溢出了金融市场的范围，而延伸到了IT领域。曾经在全世界得到无比追捧的面向服务架构——SOA也遇到了令人尴尬的挑战。
 

    知名IT评论家Anne Thomas Manes在其博客中惊呼:SOA已死！此言一出端的是震撼天下，在中国市场中也引起无数纷争，SOA的支持者们有些不知所措，而SOA的反对者们却无比兴奋，用Anne的原文来作为自己的论据。
 

    SOA的声音在中国似乎也黯然了下来;尽管主要的IT厂商们还在不遗余力地在市场中推广SOA、不厌其烦地用印刷术或者太极拳等等或玄妙或浅显的比喻来教育仍然不明SOA为何意的客户们，但是无论是媒体还是分析师们对于SOA的质疑却越来越强烈。
 

    究竟这是一个客户真正需求的解决方案，还是一个IT厂商用来“忽悠”客户的纯粹概念？为什么这么多年，似乎在国内仍然无法看到响亮的SOA实施成功的案例？
 

    毕竟现在市场中各个行业的客户也没有哪个是真的把SOA这三个字顶在头上，大张旗鼓地进行相关的项目，电信运营商忙于3G的整合和新产品、新网络、新服务，银行业忙于处理焦头烂额的客户服务、存量房贷利率变更，政府忙于街道、城管、应急响应处理，制造企业忙于降低成本、优化供应链、在经济危机的时候绞尽脑汁地保住或进一步开拓海外市场，而SOA这三个字已经被人淡忘。
 

    必须承认，无论政府还是银行还是企业，大家都是要做实际的事情的，这一点无可厚非;大家关心的事情无非是两方面:降低成本、提升敏捷性。只要能够帮助自己实现这两点，无论是SOA还是别的什么都没有关系——黑猫白猫，只要抓住耗子就是好猫。所有的企业都不约而同地对正在进行或者即将进行的IT项目提出了两点最主要的要求。
 

    首先是重用投资、节约成本，尽量重用以往的IT投资和已有的IT资产，并且确保一切必要的新投资可以在未来的新项目中充分重用，而不需要产生过多的维护、修改成本。
 

    其次要增加企业的敏捷性，可以根据市场需求的波动而灵活调整自身的运营流程——设想一下大家都熟悉并且关注的中央银行存量房贷利率7折的政策出台后，各大银行反应迟缓的原因:除了各种经济利益之外，是否也是因为其政策的变化牵扯到大量的后台IT应用和支撑系统的流程、规则调整，不能在短期内迅速实施？
 

    所有的企业或政府机构都在为着解决上面两点需求而努力，而越来越多的相关项目也在证实着这一点。北京市卫生局、云南省卫生局实现了区域医疗联网，患者可以灵活地实现社区卫生诊所和三甲医院之间的信息共享、病例流转和自由的转院机制，从而方便了患者的看病，同时节约宝贵的医疗资源可以为真正需要的疑难杂症所使用。大量的客户案例都在证明，无论是政府还是企业，大家所追寻的目标永远都是一样的。
 

    至于SOA，没有人提SOA并不足以证明SOA已经黯然退场。事实上，上面提到的两点:通过将IT应用转变为服务模块再进行整合，从而实现降低成本、重用资产、提升效率、推动创新，这正是SOA的精神所在。
 

    而已经列出的和没列出的大量客户案例证明，SOA的精神和思想已经融入到千万个具体的客户项目中，生根发芽，至于该项目究竟被称作为“SOA项目”还是某个行业中的具体项目名字，其实并不重要。SOA只是一种思想和方法，并不是目的和结果。但是为了达到降低成本、提升效率的目的，SOA仍然是最有效的方法之一。
 

    回过头来再看看Anne的原文，其实他也在文中说到，SOA的以服务为核心的理念和架构仍然是BPM、云计算、Mash Up、SaaS的基础。“Long live the service”——SOA并没有黯淡退场，而是在涅盘中永生。

SOA之滥用

    大家都想往SOA上靠,这让我想起股市的一句话:当大家都疯狂的时候，离崩溃就不远了。

    最近一年多满耳朵都是SOA的宣传，几个QQ群里也都在一直忽悠概念，大家都想往SOA上靠。这让我想起股市的一句话－当大家都疯狂的时候，离崩溃就不远了。就我所能接触到的范围内的情况，种种迹象显示SOA已经开始泛滥了。
 

    看见这篇文章的人士可以对比下自己周围的项目情况，是不是有人言必及SOA；是不是就连内部系统也要往SOA上靠；没有实际的需求，假想未来两三年的应用场景，然后硬加上SOA；攀比，跟风，大家都SOA了，我们也快SOA吧；听了厂商忽悠就也非要把系统带个SOA，仿佛不这样就不好意思出去见人一样。
 

    有天在网上看见这么个消息:“现在有项目，找人合作，地点最好在深圳。要求:windows系统下，在驱动程序（C++编写而成）中，调用web service更新驱动程序，时间2周。”。这个应用场景具体的特点我不清楚，但我实在是想破头也不明白为什么驱动程序的更新都要用web service，难得就因为这年头流行这个概念吗？
 

     那么问题来了，如何避免滥用？首先要肯定SOA确实有它的优势，否则它也不会流行起来。肯定了这点，然后我们再来看，哪些是SOA适合的场景，只有在适合的地方才能发挥出它最大的潜力。
 

    在强调松散耦合、多应用交互、快速变更业务流程、分散数据集中显示等等的场景中，SOA是一种很好的架构风格。松散耦合，这个不用说了，通过 XML定义服务接口，有了这个中间层，服务之间的耦合性可以降低很多。
 

    多应用交互，不同的应用通过暴露服务来实现应用之间的交互，甚至这些服务可以组织成新的有价值的应用。把已有应用的服务重新组织排列成新应用有几点好处，一是快速，因为单个服务都是现成的;二是灵活，服务之间松散耦合，可以灵活改变组织方式;三是省钱，现成的拿来就用了，实在没有再开发任务量也不会太大。
 

    分散数据集中显示，XML不作为应用接口，而作为数据呈现接口，可以统一处理对比分散但存在相关性的数据，而且取得数据的方式与提供数据的应用间的耦合性被降低了。
 

    但是如果是一个应用的内部作为分层，SOA就不适合了。首先这种内部分层几乎不可能暴露给外部，因为它们的粒度大部分都不足以提供一个有意义的功能。其次，SOA需要某种形式的 XML文档来作为service的表现形式，而一旦采用XML就注定了它的性能是个硬伤，而作为内部系统来说，这种硬伤是不可能绕过去的。还有就是这种为了SOA而分层必然会加大层与层之间的工作量，结果却是没有带来任何收益，费力不讨好。
 

    贴近底层系统的应用，使用SOA也是不合适的。这种情况下不同应用分层之间存在耦合的情况比较少，即使存在耦合其耦合性也比较强，而且一般都有更高效的接口或通道来作为耦合机制。
 

    对于为什么SOA如此被滥用，我想最主要还是由国内的IT环境所致。国内的IT行业发展时间比较短，大部分应该都属于新建应用。在这种情况下，其实SOA多数应该做为前瞻性的准备工作来做，更多的是方便以后工作开展，各种应用能够很快、很容易的就暴露有价值的服务出来，并且快速组合为新的应用，实现新的业务目标。
 

    然而为了赚到银子，大部分厂商都拼命往自己的东西上加卖点，往往忽视了实际情况到底需不需要;很多客户也不知道自己到底需要的是什么，只好很盲目地挑哪个名词多,哪个叫的响，选哪个厂商。
 

    相比来说，欧美的IT行业发展了几十年，客户相对理性，花多少钱就要得到多大的收益，这也是他们在谈论SOA时很强调ROI的一个原因所在。
 

    就甲方来说，与其跟风，不如静心规划好应用，让IT投资真正体现出价值，同时给以后扩展留下余地。就乙方来讲，流行概念当然也要跟进，做好技术储备，但绝不能拿客户的钱做试验，需要方案的时候能很快拿出。用户最好是两手抓，专心手头工作，跟紧技术趋势。对待新技术我们的口号是:不盲目，不掉队，不排斥。

SOA的7 个误读

    作为一种深奥、复杂的理念，SOA要么被简化，等同于一些产品、技术；要么被神化，认为无所不能。

    SOA是计算机领域业已公认的实用解决方案。从根本上讲，SOA针对系统开发和系统集成提供企业级方法，它将遗留系统作为分散的业务功能、封装为标准服务接口。
 

    过去几年来，SOA的普及程度成指数增长，逐步成为各公司以灵活、复用和经济方式结合应用程序和流程的一种方法。SOA的功能划分为不同的单元或服务，开发人员通过网络进入用户平台，在创建企业应用程序的过程中将不同的单元或服务进行非常好的结合与复用。通过从一项服务到另一项服务传输数据，或者在两项服务或多项服务之间协调活动，实现多项服务之间的通信。
 

    然而，与其他任何技术、业务流程或计算方法一样，现实中确实存在对 SOA 的误读—SOA 是什么，如何工作，有哪些优势和风险以及适合哪些用户。

1 误读: SOA 等同于 Web 服务
 

    首先要提到的是人们对 SOA概念的误读非常之大。有人直接说 SOA 就是Web 服务，甚至随便互换这两个概念。事实上，Web 服务，例如基于HTTP的SOAP协议，是一种定义接口的标准方式，符合SOA定义的架构模式。尽管这些标准有助于不同类型的系统在无需所有者协议的情况下互相通信，但我们依然不能夸大其重要性。
 

    相反，SOA以基础导向架构原理为依据，结合所谓的“非常好的实践”，将Web服务应用程序的功能以开放的方式呈现。SOA和Web服务不可互换。当然，Web服务可用来创建 SOA;其实，Web服务是配置SOA的行业标准。然而，SOA不是必须依靠 Web服务标准，因为 SOA 还可以通过CORBA、JMS、MQ和其他接口/消息传输标准，单独实施或并行实施。
 

    实际上，Web 服务可以更多地视作SOA中的互动模式，通常指客户端和HTTP服务器之间的互动，而不是和SOA本身的互动。
 

    从根本上讲，SOA可以以 Web 服务为基础，或以SMTP电子邮件接口标准为基础。但是，如果将Web服务等同于SOA就会忽略许多其他类型的SOA接口和功能，这些接口和功能适用于定义真正的SOA的松散偶合、自发且可复用的组件。

2 误读 :可以“购买”SOA
 

    对SOA的主要误读之一就是认为SOA是一件可以购买的东西，可以买卖的一个实实在在的产品。许多公司愿意花大价钱购买基础架构组建SOA，同时购买带有诸如目录、发现或消息传输功能的组合产品。购买这些之后，他们就声称自己现在有SOA了。
 

    然而，事实还远远不止于此。SOA的真正优势不是其依托的基础架构，而是从基础架构延伸而来的服务。许多公司错误地专注于技术基础架构的创建，认为那就是成功的SOA实施，完全不知道创建一个有价值的实用服务平台才只是第一步，更不知道需要依托SOA基础架构进行并行的服务识别、定义、设计和开发。
 

    尽管您可能确实需要购买进行服务管理、方便其他应用程序查找的登录库以及供客户和供应商交换信息的机制，但是不购买这些新的服务项目您同样可以开始应用SOA。

3 误读 :SOA复用很简单
 

    尽管软件复用可以小规模地进行，但企业级别的复用就很难实现，这一点SOA也不例外。“强行”复用会适得其反，尝试创建企业中单个应用程序或数据库的服务可能导致维护和兼容方面的严重问题。
 

    根本的一点就是在SOA开发过程中，最好不要尝试仅以复用为目的的设计。最好的选择是在企业级别根据要求允许SOA服务自动复用。那样的话，多次修改接口后，“服务”开始自动复用。

4 误读:购买SOA价格昂贵
 

    许多人认为实施SOA耗资庞大。无疑，创建SOA需要大笔资金支出，但通常情况下，初期资金只是用于前面提到的基础架构组件创建的资金。许多公司认为创建SOA需要创建包括目录服务、发现服务、消息服务和物理媒体中介服务在内的一套完整的SOA组合，还有可视化和显示门户。但是不必购买许多这些组件，同样可以实现SOA的核心优势。
 

    随着各公司对SOA应用的成熟化发展，会出现许多便宜或免费的服务，保证基础架构组件的功能扩展。现在其实就有提供高效而灵活的SOA平台功能的许多开放源码技术。在很大程度上，这些开放源码技术非常完善，可以促进SOA在整个企业的增强应用。

5 误读 :SOA解决所有集成问题
 

    SOA可以解决所有集成问题的这个误读非常普遍。实际情况是SOA只能解决紧密偶合系统引发的集成问题;应用SOA后，许多问题依然存在，例如语义集成方面的相关问题。还有就是集成方面的许多问题与公司的内部政策、人事等权力相关。全球非常好的的SOA项目就是避开这些非技术问题。

6 误读 :SOA 是新兴的
 

    有观点认为SOA相对来讲是新兴事物。只要纵观整个IT基础架构所提供的功能（例如服务），而不是只关注特定硬件环境下的一系列分散应用程序，我们就会发现SOA早已不是新兴事物。
 

    20年前，就有公司以服务接口标准为基础创建模块化COBOL应用程序。如果我们仔细想想就会发现COBOL应用程序具有与XML和WSDL非常相似的分级数据结构。再回到10年前的面向消息的中间件时代，您会发现SOA企业模式早已崭露头角（当然那时还是其它名称）。
 

    事实上，企业集成模式的SOA存在至少已有二十年之久。确实，技术标准发生了变化，语言和中间件也有所变化，但是基础集成模式没有变。一切过去的事物都可以再次体现新意。

7 误读 :一劳永逸

    如今，在许多大型公司中，管理层已经引入SOA概念并将SOA作为补充现存遗留功能的工具和确保未来发展的有效途径。他们认为，一旦必要的SOA基础架构技术到位，具体实施完成，问题就解决了。
 

    错！SOA实施需要参与、坚持和连续测评，以确保真正成功实施。SOA不是具体问题的一个答案，而是可以解答未来问题的途径和方法学。另外，使用SOA解决方案和标准要求一些约束和强有力的管理。使用系统的高层管理、中层管理、乃至普通员工都必须积极支持SOA。SOA不是应急之道、权宜之计，也不是可以呼之即来、挥之即去的解决方案。
 

    SOA不是企业中解决所有IT和经营问题的灵丹妙药，应用和实施也不是一蹴而就的事情。然而，只要企业愿意系统而认真地加以了解应用，SOA还是可以带来极大优势的——而且需要企业花时间了解SOA的真正概念:究竟是什么，不是什么。

原文来自《软件世界》