SOA离我们有多远？——by Vega

 

序言：在参加完IBM的SOA初赛之后，在这个过程中浏览了很多文档，也参与了团队的一些讨论，尤其在做完设计文档之后，才发现自己对SOA有了跟前面完全不同的认识，在接下来的一段时间，我会逐步把自己在设计过程中的一些认识过程和变化做一个总结，希望对这方面感兴趣的人也能够加入到对SOA的一些讨论。  

前些天跟一个同学聊天的时候说到，SOA和AJAX恐怕是本年度IT技术领域最红火的两个词汇了。AJAX红火的原因，是因为Gmail和Google Earth的出现，引发了一场web2.0的网络革命，而SOA红的一个原因，并不是有什么引人注目的技术产品的出现，反而是因为它的争议性。在网络上搜索一下SOA，无一例外的是几乎所有的文章都承认它是软件开发的未来，可是这个未来离现在有多久，却没有人敢肯定。SOA无疑是一种优秀的设计思路，但正是因为它的设计过于完美，它的知识体系过于博大精深，对于讲究敏捷和快速应用的当代软件开发来说，SOA就像一个美丽而虚幻的梦。

两个月之前，我对于SOA可以说只有字面意义上的理解，知道众说纷纭的好，也知道众说纷纭的困惑，但到底好在哪里，我一无所知。在准备大赛的两个月时间里，在IBM的学习网站看了很多的资料，也在BEA、ORACLE还有MSDN看了其他大公司就SOA的一些方案，最让我困惑的地方就是，几乎到处都有SOA的理论和设计方法，可是却难以找到一个真正引入SOA设计的现成方案。

对SOA的真正理解来源于IBM网站上面的一篇文章《面向服务的分析与设计原理》，记得当初看完这篇文章后有种茅塞顿开的感觉，不过奇怪的是，这么优秀的一篇学习资料却没有被IBM放进这次比赛提供的学习资料里面，我是在查阅其中一篇资料然后偶然链接到那里去的。

文章最重点的地方，就是讨论了如何从OOAD上升到SOAD，也就是如何从面向对象的开发升华到面向服务的开发。面向服务并不是说代替了面向对象，而是以面向对象为基础，把软件设计的着眼点上升到服务的范畴，也可以这样认为，面向服务与面向对象是一种包含与被包含的关系。而这种关系有点像电子电路设计里面的自顶向下开发和自底向上开发的关系，传统的电路开发都是自底向上开发，先是设计好一个物理元件，一个模块，然后再把这些模块组合到一起成为一个电路板；但现代的超大规模电路设计沿用这种设计方式后，在效率和耦合方面碰到了瓶颈，做好了模块再来组合，肯定不是最优化的设计，所以现在的电路设计提高到了系统级别，也就是自顶向下的设计。同样的，在程序设计方法从面向过程上升到面向对象之后，OO就成了软件程序设计的定律，而且它也在很长一段时间内解决了很多问题。但是当软件商用化之后，特别是引入企业的大规模平台之后，面向对象的方法就遇到了瓶颈。因为面向对象解决不了商业逻辑。商业逻辑可以说是一种关系和联系，虽然面向对象可以通过泛化和友元等来实现这种关系和联系，但是问题在于这种关系是限定的，在确定需求之后这些关系都必须是确定的，而商业逻辑却是随需应变的。当需求一变化，所有对象的关联都发生了变化，那么一个软件设计可能就不得不推倒重来。OOAD另一个瓶颈在于，程序开发人员往往并不精通业务，如果没有对商业逻辑有很深刻的理解，他们很难把握好各种对象之间的关系，在迭代开发里面，程序员总是无止境的陷入修改代码和变更需求的过程中，造成这个过程的一个很重要原因就是在设计阶段他们没能准确的把握需求，他们只能在深入开发之后才能理解业务逻辑。SOAD的着眼点就在于对需求进行建模，事实上它并不是一门新的技术，只不过把软件建模的对象从模块上升到服务。先抓住商业逻辑，再有的放矢的进行设计。

所以说SOA的优秀和先进是勿庸置疑的。但在现实情况下，SOA的推广却遭遇了很多的困难，所以即使SOA喊了好几年的口号，即使IBM、BEA都提供了很多和成熟的开发环境和优秀方案，真正应用了SOA的案例却少之又少。其中第一个原因，是需求的界定。程序员总是说，客户的需求是无止境的。就算再精通的业务员，也无法在很短的时间内为他的业务做一个需求界定。软件开发的瀑布模型延伸出迭代模型，很大的原因在于需求总是在开发过程中不断的发生变化，而SOA的设计思路就是先确定好需求再进行开发，如果需求总是在不停变化的话，SOA相对于以前的方法就没有多少优势可言了。另一个原因是SOA缺乏成熟的开发路线，OO引领的一系列开发路线已经使用了数十年，引进SOA就意味着需要为这条开发路线作出很大的改动，但没有成熟可靠的开发路线出来之前，没有企业愿意去冒这个险。最后一个，也可能是最重要的一个原因就是，SOA的全面应用意味着现有系统的全部更新。全面部署SOA要求企业重新去考虑自己的业务，自己的需求，而不是在原有系统上面的修修补补。一个大型企业内部可能会有数十个系统同时存在，虽然SOA的方案可以解决这些系统之间的冗余，但要全部代替这些系统的代价是很高的。所以尽管SOA的潮流不可避免，但是现在大部分的企业都是保持着观望的态度。

在思考到SOA的这些矛盾的时候，我在准备SOA的大赛就碰到很多的困惑，虽然IBM给的需求很简单，就是整合企业内部的ERP和CRM。但思考最多的地方就是，该如何去整合呢？最开始我的一个错误思路就是想着去实现无缝的整合，所以我把所有ERP和CRM拥有的服务都提取出来，就想着把这些服务整合到一起。在这个过程中，碰到的一个问题就是，数据应该交给谁来管理？系统？ERP？或者是CRM？系统在里面应该起着一个什么样的作用呢？结果就是这个问题一直得不到解决，才让我重新定位系统在里面所起的作用，最后我得出的结果就是，系统不是要去整合ERP和CRM的作用，ERP要干的活还是ERP去做，CRM要干的活还是CRM去做，而系统呢，一个作用就是对ERP和CRM里面的数据进行同步，ERP修改的内容都会同步到CRM里面去；另一个作用呢，就是信息聚合，就是让用户不用登录ERP或者CRM，都能够在系统浏览到ERP跟CRM里面的信息；还有一个作用，就是信息交互，交互的过程对于用户是不可见的，具体点说，是一个工作流，信息随着工作流在不同部门之间流动，但用户并不知道信息从何而来，往何而去，他们只是看到处在他这个阶段的信息。这三个作用使得系统像一张网，把ERP跟CRM从方方面面链接起来，它既不干涉ERP或CRM的应用，但ERP和CRM又可能通过它更好的发挥作用。

所以在完成大赛的设计和文档之后，我对SOA的应用之路有了新的理解。也许SOA并非要替换现有的系统，它独特的设计思路对于企业现存的系统也许是一种互补，它可以完成企业中数据的同步、交互和聚合的功能。SOA完全替代企业系统的应用还有很长的一段时间，但这个过程可以循序渐进，也许先把它当成企业遗留系统的辅助是一条很不错的道路，再慢慢把其它系统淘汰并完全实现SOA的设计。