换个角度看SOA

换个角度看SOA

    我的观点是SOA前途无量，但SOA不是给小实体企业和小软件公司的，要在中国流行尤其困难。以下试论证之。

    （各种数据资料收集中，盼有资料的朋友不吝提供）

    在一个持续两年的SOA工具开发项目中参与了其中一年半的时间，现在也颇有些想法想要写一写。 即使在我们这个开发队伍中，真正对SOA的将来充满信心的也不过包括我在内的一二人而已。接触的大部分开发人员或者觉得SOA高深莫测，或者觉得不过是大公司又搞出的一个“大词”，推销东西而已。

    为什么大公司热衷不已，且业界也是热闹无比，但我们很多开发人员却兴趣寥寥？我觉得，那是因为这个概念本身就不是要推销给小型企业和小型软件开发公司的。

    有资料说，国内大部分企业活不过五年，而且总体来说信息化程度非常之低，而国外有几十年，上百年历史的大型企业则很多， 这些大型企业很早就开始信息化，在几十年的时间里，他们积累了大量的技术资产（各种信息系统，业务系统）。也同时产生了信息孤岛问题和遗留系统改造升级的大量需求。这些大企业的几十甚至上百个独立运行的系统建立于不同的年代，采用不同的技术，运行在不同的平台上，集成的困难非常大。这些企业也是国外大软件商和软件服务商的主要客户群体，以前看到过一份资料，系统集成和系统改造的业务在国外大型软件供应商的业务中占相当大的一个比例（TODO:数据数据！）。而国内大部分软件商和软件开发人员则面对一个又一个新项目，大部分都是新系统上线的业务。这一点上之差别极大。

     因为有这样的业务特点，所以国外大厂商不断提出“跨平台，跨语言”的技术架构和编程模型，从CORBA到EJB到SOA无不打出这样的旗帜，而这一点对大量开发新系统的国内市场来说，吸引力显然没有那么大。

    另一方面，这些大型企业内存在大量遗留系统，如果不能够解决信息孤岛问题，那么他们会逐渐成为企业的负担，而如果能够解决这个问题，就能够把这些技术资产“盘活”，使他们真正成为企业的财富，焕发出新的生命力。

    SOA架构提出系统“服务化”，SCA架构又提出了服务组件模型，提出可以将组件部署为服务，服务又可以组合为更大的服务等等，其实这样的思路乍看上去跟CORBA，EJB也差不了多少。但关键在于这里的服务也好，组件也好，指的不是技术模块，而是业务模块。事务处理，O/R MAPPING，事件处理等等技术模块属于基础设施，在客户眼里毫无意义，而业务服务，比如“查询某用户余额”，“查询某商品库存”，“查询某用户消费记录”等等这样的业务服务对企业的业务管理人员却是含义丰富且极具价值的。通过将技术“服务化”，技术资产成为业务人员可以理解的业务资产，业务分析人员可以将业务服务组合开发出新的业务，也可以很清楚的知道企业现在拥有哪些业务服务（资产），想要推出一个新的业务还需要增加或修改哪些业务服务。对于大企业来说，他们拥有的技术资产非常丰富，一旦将这些原来几乎无法管理的技术资产整理（包装）成粒度大小合适，可以很方便访问和管理的服务组件，再加上可以动态调整和监控的流程(bpel, bpm等，在我看来SOA就是流程+服务)，这些大企业就可以将之转化为强大的竞争优势，他们将即拥有强大的力量，又拥有灵活的身手，套句时髦话：“大象也能跳舞”。目前鼓吹SOA的开发商和支持SOA的企业基本都属于“大企业”这个群体，屁股决定脑袋。

    以上是从业务上说。

    从技术上说，SOA将带来软件开发方法上的一些变化。软件开发有自顶向下和自底向上两种思路，现在一般都是两种的结合而有所侧重。 几年前我搞过XPCHINA论坛，介绍和讨论极限编程，那时我认为自底向上，通过重构逐渐产生架构是最有效率的开发方法，现在经过十年的软件开发实践，我现在是架构驱动、逐步求精开发方法的拥趸。 传统的SOA实现方式（我是指BPEL+Webservice）在合适的开发工具(BPEL流程设计、模拟执行等)的支持下，为架构驱动、自顶向下的开发方法提供了非常好的支持，并且非常有利于人力资源的分层配置。对于新推出的SCA架构，我刚开始研究，还未深入，初步感觉更偏向组件化，是另一种（与EJB相比）跨平台，跨语言的组件架构。对开发方法的支持更平衡一些，自顶向下，自底向上皆可。 但不论那种实现方式，都需要有强有力的、有整个企业大局观的架构师来领衔才能真正发挥其效力。 而国内中小型软件企业恰恰非常缺乏架构师，国内有大量优秀的高程，在我看来他们与架构师的差距就在于大局观，而偏偏很多人就跨不过去这个不高的坎。 眼睛里盯着一个功能的人和眼睛盯着一个应用的人和眼界覆盖全企业的人会看到不同的东西，有不同的需要。

    以上从技术上和开发人员的特点上看。

    最后一个方面，中国经济发展非常迅速，那些打不到单子，难以生存的软件企业且不提，有单子在做的软件企业都是忙不过来，首先感到的是开发效率不足的痛苦，而解决开发效率问题的妙药不是SOA，而是组件化。

    总结，国内中小软件企业，他们的客户还不需要SOA，他们自身还在解决开发效率问题和培养架构师。 但是环境迟早会改变的，SOA淡化了技术资产和业务资产的边界，SOA提供可灵活修改的，可组合服务，可调整流程的技术架构，这些优势终将反应在市场上。

SOA，感觉太遥远，目前看来还没有接触的可能。

对于 SOA 不是很有兴趣，但是对于 LZ 提到的这一点，很有兴趣了解一下 LZ 的看法。这里提到的组件化是指类似 windows 的 COM 这样的组件吗？ LZ 的意思是类似这样的组件能够提升软件开发效率？

COM是一种组件模型。
使用现成的COM组件和把自己公司开发的功能规划、打包成COM组件是其中一种组件化的方式。
能不能提高软件开发效率还是要看架构师（规划师）、组件的开发者和组件的使用者的水平了。
组件化的目的是促进重用，目前为止除了重用我还看不出其他真正有效能大幅度提高软件开发效率的手段。

SOA的重心落在S上，也就是Service，企业的每一角色对Service的理解也是不同的，所以SOA才有如此的魅力，也正是这一点，才有SOA所谓概念上的混乱，因为每个人根据自己所处的角色不一样，就有不同的理解。

最后一个方面，中国经济发展非常迅速，那些打不到单子，难以生存的软件企业且不提，有单子在做的软件企业都是忙不过来，首先感到的是开发效率不足的痛苦，而解决开发效率问题的妙药不是SOA，而是组件化。


这是因为开发人员对组件化的方法更熟悉，SOA开发起来还是很复杂。

LZ能否谈谈你开发SOA所用的工具，人员配置。

我不是开发SOA，我是开发支持SOA开发的工具。。。具体内容不方便多说。

看来楼主是普元的研发人员了，国内好像就普元在做SOA的开发工具。
很想尝试一下用普元的套件，但是公司没有买。我们现在都是在用ORACLE的SOA套件，个人感觉，现在IDE还不是很成熟，做项目时候会碰到很多问题，但是确不能否认SOA这种思想！赞成楼主的大部分观点！

还在学习SOA，同意楼主的基本观点。SOA对大企业的多系统之间的贡献远大于中小企业的新系统。