换个角度看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提供可灵活修改的，可组合服务，可调整流程的技术架构，这些优势终将反应在市场上。

评论

30 楼 gysh 2008-05-07  

SOA!!!现在我这个项目就是利用IBM的SOA，感觉开发效率的确很高啊！！！对于遗留系统的集成效果还是可以的！！

29 楼 insky 2008-05-03  

triu 写道

Cocoon是我的梦魇! 开发效率和调试效率的低下令我敬而远之

使用好的xml/xslt编写调试工具，cocoon的开发效率其实是很高的
调试以及查找bug的效率确实是一个问题   但既然项目选择了cocoon，这点也可以忍受了

28 楼 wl95421 2008-04-30  

不是很同意吧

或者这样说，合适一点
SOA不是给技术人员来看的
而是给管理者和规划者来用的

27 楼 gates_lee 2008-04-28  

我认为如果SOA要被大家接受，至少SAAS也要能被大家接受，但是目前看来，SAAS展看得并不好，这种软件模式，一时半伙客户还难以接受

26 楼 hongsoft 2008-04-26  

abcx 写道

购买SOA的基础设施的成本不会低吧，IBM整了那么多庞大的软件出来，情况会不会又象EJB那样。

IBM软件的庞大  好象与 SOA无关。它本来就大。

如果不了解，建议 参考  BEA的 SOA 方面的产品 或者 primeton的 EOS6。

（BTW： IBM 与 EJB有关的产品 多吗？好象我没有知道几个）

25 楼 诺铁 2007-12-10  

gocom版主已与我联系，加上了出处，误会已消除

24 楼 诺铁 2007-10-17  

普元的gocom论坛转贴了我这文章却不注明作者和原文链接，我给版主发了邮件要求补上，等了两天也没回音，想在帖子后面跟贴却发不上去，郁闷，谁认识里面的管理员，把这个改改啊，做人要厚道
http://gocom.primeton.com/modules/newbb/forumtopic4009_8802_11.htm

23 楼 triu 2007-10-16  

pioneer21th 写道

triu 写道

建议各位了解IBM的WebSphere Information Integrator（WII），Apache的Cocoon2，Ultimus的BPM，Adobe的ColdFusion。

我正在开发一套SOA开发工具，通过Web Services操作数据库，采用XML+XSLT作为Web的显示，加上自有的流程引擎和管理控制，开发工具使用起来将和ColdFusion差不多，只是，不需要写SQL语句，取而代之的是进行Web Services配置。

Cocoon是我的梦魇! 开发效率和调试效率的低下令我敬而远之

很赞成！虽然从2003年就开始学习这个框架，但始终没有勇气将其应用到项目中。直到最近，我才想到不使用Site Map的方法，就是用功能目录的概念，将分散的管理集中起来，并提供配置管理界面，呵呵，现在可以不用考虑嵌入代码的烦恼，也不再有Cocoon的麻烦。

22 楼 pioneer21th 2007-10-16  

triu 写道

建议各位了解IBM的WebSphere Information Integrator（WII），Apache的Cocoon2，Ultimus的BPM，Adobe的ColdFusion。

我正在开发一套SOA开发工具，通过Web Services操作数据库，采用XML+XSLT作为Web的显示，加上自有的流程引擎和管理控制，开发工具使用起来将和ColdFusion差不多，只是，不需要写SQL语句，取而代之的是进行Web Services配置。

Cocoon是我的梦魇! 开发效率和调试效率的低下令我敬而远之

21 楼 triu 2007-10-16  

建议各位了解IBM的WebSphere Information Integrator（WII），Apache的Cocoon2，Ultimus的BPM，Adobe的ColdFusion。

我正在开发一套SOA开发工具，通过Web Services操作数据库，采用XML+XSLT作为Web的显示，加上自有的流程引擎和管理控制，开发工具使用起来将和ColdFusion差不多，只是，不需要写SQL语句，取而代之的是进行Web Services配置。

20 楼 renavatio 2007-10-16  

等到SOA开发工具像今天的WEB框架一样百花齐放的时候就是SOA的成熟期了。

19 楼 abcx 2007-10-16  

购买SOA的基础设施的成本不会低吧，IBM整了那么多庞大的软件出来，情况会不会又象EJB那样。

18 楼 诺铁 2007-10-15  

随着SOA思想和配套工具的成熟，SOA也会成为经过实践证明的，实施成本更低的技术。

17 楼 pioneer21th 2007-10-15  

不理解大家心目中的SOA为什么那么难，我的理解是：当你需要公司已经存在的数据而又和支持那个数据的系统不能用传统方式进行集成时，SQA就来了，而不管你的系统，不管那个数据支撑系统大小。而事实上，我们的确也是这样做了。

即便一个小小的功能都可以做成全公司都能用的service。

16 楼 JerryZheng 2007-10-15  

"不管有没有遗留系统，达到业务敏捷都是SOA的一个目标"
确实SOA可以做到，不过用其它的架构或技术也能实现不是吗？而且是经过实践证明的，实施成本也很低，为了“业务敏捷”而采用SOA对技术人员来说有点over，也许sales比较喜欢这种说法。

15 楼 诺铁 2007-10-15  

blueoxygen 写道

SOA为啥让人雾里看花，因为这个概念太大，和当初.NET提出来时一样。这不是一个spring release新版本，列出特性表那样直观。对于这种真正的high level的东西，我们技术人员就是很难一下子搞明白。而形成对比的是，一些高管绘声绘色的描述着，说的话还是那么云里雾里，还是那么有政治高度。
包括程序员搞得那几期SOA专题，讲和没讲一个样。没有任何一个人能将SOA具体的实例化。
关于楼主描述的SOA里，有个有讨论必要的地方就是遗留系统的问题。
SOA到今天，已经从大家当初理解的集成方法变成了业务敏捷的架构方法。有没有遗留系统和用不用SOA没有任何关系。我现在用的一个产品号称是SOA产品，可是我还是没看到SOA在哪里，怎么能敏捷的重组业务。导致一直到现在，我还是认为某种service+工作流描述便组成了SOA。

遗留系统不是必要条件，我的文章意思是说，如果有很多有价值的遗留系统，那么用SOA的思想加以重构和集成会比完全新构建系统得到更多的回报。 不管有没有遗留系统，达到业务敏捷都是SOA的一个目标。 我的SOA的理解也是service+流程再加上可靠通信机制（比如可靠的ESB）。

14 楼 abcx 2007-10-15  

在开发新系统的过程中，有多少公司愿意为不可预计多长时间的未来买单呢？

13 楼 soft4any 2007-10-14  

感觉soa还是主要用于集成，比如javabean，webservice,jms等，而访问客户也非常灵活，甚至包含.net客户端。服务之间可以灵活的互访问。
至于服务的概念，粒度可大可小，本质还是基于接口的编程。

12 楼 blueoxygen 2007-10-12  

SOA为啥让人雾里看花，因为这个概念太大，和当初.NET提出来时一样。这不是一个spring release新版本，列出特性表那样直观。对于这种真正的high level的东西，我们技术人员就是很难一下子搞明白。而形成对比的是，一些高管绘声绘色的描述着，说的话还是那么云里雾里，还是那么有政治高度。
包括程序员搞得那几期SOA专题，讲和没讲一个样。没有任何一个人能将SOA具体的实例化。
关于楼主描述的SOA里，有个有讨论必要的地方就是遗留系统的问题。
SOA到今天，已经从大家当初理解的集成方法变成了业务敏捷的架构方法。有没有遗留系统和用不用SOA没有任何关系。我现在用的一个产品号称是SOA产品，可是我还是没看到SOA在哪里，怎么能敏捷的重组业务。导致一直到现在，我还是认为某种service+工作流描述便组成了SOA。

11 楼 诺铁 2007-10-12  

zpple 写道

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

普元真是很有名啊，可偶不是的。