SOA有毒

——SOA业务开发平台(二)

那天在QQ群，和众多网友讨论关于SOA的话题，发现业界对于SOA的宣传，不是太飞机，说的都是高层面的理念，就是太土鳖，讲的都是如何开发SOA。但是缺少中间一个层面的落实，那就是理念层次往项目经理和程序员这边降一层，而非一直高飞在架构师、总规划师这一层面。

因为现在大量的程序员，都是新生代的程序员，他们写的代码量少，做的软件项目少，还无法体会代码量多了会如何解决，还无法体会项目定制多了会如何解决。没有问题的痛楚，当然也就不太明白为什么要聚合成函数。讨论过程中，发现不少程序员，连函数层面都未理解到，他们代码中的函数是怎么来的呢，是他们在编程过程中组件的事件产生的，如onclick之类的函数。他们自己并未主动或者很少主动封装函数。而且不少人也把函数仅仅停留在为了公共调用，或者一个代码都1500多行了，实在整理不了清晰思路了，才切割代码成另一个函数，和我初期对函数的理解是一模一样。对于真正理解函数的封装，并没有多深刻。就更不用说痛则思痛，更进一步应用面向对象和面向组件方法。因为写的代码量并不多，还没有遇到问题，所以也就不需要更高级的方法。许多人写面向对象和面向组件的代码，是由于现在的3GL开发语言和IDE所决定，自然而为之，而不是程序员自己主动要面向对象或面向组件。不过有些觉醒者开始模仿使用面向对象了，但真正对面向对象的好处理解还不是很深刻，还处于照猫画虎的阶段。很多人写过COM+，写过EJB，但都是人家IDE工具和人家的组件规范确定的，自己内部写的代码思路并没有与之相匹配，还是代码的堆积。

所以，在这个层面阶段，让大家再用面向服务，很多人肯定不理解，觉得没有必要。也有一些赶技术时髦的公司开始使用面向服务开发，但思路仍然停留在写COM+的样子，也就是代码外壳是面向组件的，但内在的代码思路和面向组件没关系。

技术是为了解决问题的，而不是显摆时髦的。客户并不理解技术，如果你的技术并没有为客户带来明显价值好处，客户也不会为你的技术成本付出而买单。过去是有一批客户的CIO人员，挺关注最新技术的产品，如果你是PB做的，他是.net做的，就会买.NET做的。但是现在中国信息化比较全国风行，实施的项目案例比过去多了N倍，也就有N倍的项目死亡或者宣告失败。已经有不少惨痛教训，让不少盲目没有目的的追求技术的软件公司和CIO们吃亏。

SOA在程序员写代码看代码这一层次看起来是面向组件的另一个高度，但SOA非常复杂。如果你没有面临复杂业务和业务投资，少碰SOA为佳。

上次写的博客，我是从程序员写代码的层次上给大家讲面向组件的来历。但从另一个方面，从架构上来看，面向组件并非我讲的只是代码多了需要更上一层封装这么简单。

在业界，有OMG组织，也就是对象管理集团。这个组织的支撑大佬是IBM、HP、BEA之类的公司，几乎全世界顶级IT公司都加入了进来。所有业界统一的认识就是，软件的世界，应该是各个功能封装成一个个的组件，程序员只要把组件内部实现好，封装好，实现的内部规格和外部接口规格符合统一标准就OK。那么，这一个个的组件就需要插入到一个组件平台上。这就好比什么显卡、声卡、网卡，都有标准的接口，都能接受主板的信号调度，所以都插入到主板上，接受主板数据总线的统一管理。所以，业界认为软件也应该是这样的，才能实现软件的灵活性。这是从架构的高度来讲面向组件的好处的。我上次并没有从这个角度讲，因为大部分人还是程序员，他们比较关注自己代码如何更灵活的修改，对于架构，觉得有些空和远。所以，有了上一篇的铺垫，本篇就好讲多了。

大家都知道，COM+有组件规范，EJB有组件规范，.NET有组件规范，CORBA也有组件规范。而这个软件主板是什么，在COM+中有COM容器，过去叫MTS，现在叫组件服务。.NET的组件容器就是.NET平台，里面有Framework，有虚拟机，有组件容器。微软实现成一个包装里，就是为了屏蔽技术细节，这样大家才觉得微软的产品简单。而JAVA一方呢，就怕所有模块都绑在一起，所以每个模块都分开，EJB组件容器独立成了中间件，JAVA还有虚拟机和Framework。

我知道很多人在混淆WebService和SOA。SOA也有组件规范，那就是SCA，全称就是服务组件架构。讲的就是面向服务的组件应该是什么规格。过去制定的CORBA组件规范，是面向组件的，而非面向服务的组件。面向服务的组件，比面向组件更多了一层服务的高层搭建。

有组件规范了，还得有组件之间的通讯规范。CORBA有ORB，EJB有中间件规范，COM+有实际的落地，但由于微软对此技术的封闭，我没有看到太多的这方面的规范。到了SOA，有没有组件之间的通讯规范呢？

有。但是SOA并没有自己制定独立的一套通讯规范。这就是SOA的一个很好的开放的心态。既然现在有了这么多规范了，我们干吗还要重新发明轮子呢，我们何不利用这些规范呢，这样也保护投资。于是，SOA利用了WebService的通讯规范，也可以应用JMS通讯规范。这就是很多人容易混淆WebService和SOA的根源所在。

但WebService仅仅定义了接口是怎么回事，你必须统一，但你内部代码怎么写，webService不管你。本来WebService的发明是为了异构调用，这是WebService的目标，也是重点。所以WebService并没有组件规范。因为世界上，三大主流.net、EJB、CORBA，都有自己的组件规范，何必再重造组件规范呢。

很多人认为，你管我内部怎么写代码的，我告诉你webService接口，你调用能返回你想要的结果不就OK了么？对，对于调用服务的一方来说，并没有什么，能调用能实现需求就OK。

但是，管你内部怎么写代码，是容器的需要。如果你把webservice都放在了一堆，然后这些webService互相调用，这只能算是一个整合平台。整合平台关注的是如何管理这些webservice。

而SOA想做到的不仅仅如此。它是一整套思想体系。它不仅仅想管理你的接口，你的组件之间的通讯，还想管理你的组件。

更进一步来说，SOA还想管理你的数据交换。

过去用WebService，交换的是XML，但是XML内部也得有个格式，而这个格式过去是没有规范的，只要双方约定好怎么解析就OK了。但是SOA不这样看。它还制定了SDO。规定了你的交换的数据的内部格式。很多人看到这里，应该想明白SOA为什么要定义SCA规范了吧。大家都知道，交换数据，如果内部格式统一，这样就非常利用交换数据，而不是自己自定义一套，还不知道定义的灵活不灵活，严谨不严谨。SCA的制定也是出于同样的目的，如果大家内部写代码，都是任凭自己的想法随便代码堆砌，那么即使应用了SOA，也无法达到面向组件的灵活性。

我们都想搭建一个业务平台，希望我们的功能能够灵活修改，而不是动一发牵全身。但是，如果没有一个规范，我们怎么可能搭建一个可灵活可扩展的平台呢？我们现在大家都是在凭自己的经验来搭建业务平台，来感觉自己搭建才灵活。但人家业界已经给出了标准，这样搭建平台，用这样的思想，用这样的规范，搭建出来的平台就能达到灵活性。但偏偏许多人还在自己冥思苦想什么样的架构可以达到灵活。

SOA是个很开放的面向服务的组件的架构。不管你是COM组件，是EJB组件，是.NET组件，是CORABA组件，是用的.NET虚拟机，还是JVM，只要符合这个SCA/SDO规范，就可以搭建灵活的平台了。而且已经有了灵活的平台，那就是ESB。ESB也不是一个很新的东西，它也是混合了WebService技术、消息中间件技术、组件容器技术、BPEL流程引擎技术、组件容器技术。其实质就是把组件容器中间件+消息中间件+流程编排中间件+WebService整合在一起，如果符合SCA/SDO标准，那么这个ESB就可以说是一个SOA ESB。

SOA是尽量保护现有投资，不另造独立王国，现有的虚拟机、中间件、WebService、整合技术，都不用荒废。而可以实现更高层次的统一。你当然可以把现有的.NET组件或EJB组件包装成SCA组件，也可以直接开发SCA组件。

我们过去面对了如此多样的技术，我们眼界迷离，无从选择。现在我们有了SOA，只需要选择这一种更高层面更抽象层面的规范，我们就可以实现组件和组件平台，就可以像硬件主板和显卡的关系一样灵活。

当然，这样的平台只是给了我们一个基础平台，我们想开发我们的业务，还需要在此基础上搭建我们业务功能需要的基本功能，我们的具体业务功能，需要基于我们自己的业务基础层来开发，而非在ESB上直接开发SCA组件。这个很好理解，我们也不是在.NET平台上直接开发我们的业务功能，而往往会搭建一个业务基础类库，大家在这个业务基础类库之上再开发业务功能就轻松许多。当然，这个业务基础类库搭建的不怎么样，没有架构，没有顺应组件架构，那么这个基础类库也会让业务开发人员感到很变扭，还不如不做这一层基础代码。

所以说，理解了，顺应了，才感觉到顺畅与自由。不理解，无法顺应思想，强制要基于之上开发，只能感到变扭，觉得干吗要这一层这么碍事。

SOA，面向服务的、组件的、架构。这三个关键词。架构，就肯定是分层分块的。所以有组件容器，有组件，有组件通讯协议，有组件服务串联编排工具和执行引擎。

不过，我总觉得现在服务编排还不大好。因为我过去面向组件开发的时候，有业务组件，也有流程组件。而BPEL，就是致力于流程组件这一目标。现在看着BPEL的XML，总觉得变扭。我自己隐约感觉这还不是最好的编排方式，XML适合配合，但不适合描述流程。描述流程，现在最适合，也最通用，最灵活的，应该是javascript。

我个人的观点相信，未来的焦点决战，肯定是javascript。而javascritp的决战，不仅仅现在已经烧到了chrome浏览器，烧到flex action script，烧到open API，烧到比Restful WebService更有前途的atom APP上，未来，还会烧到企业市场的SOA中。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友