soa

SOA甚至是所有软件人员的一个梦:将中间层再进行抽离，在中间层作一个跨技术架构的元数据和业务逻辑，使之成为跨技术架构的、可长期继承、并不断积累的企业业务库和最宝贵的信息资产，也就是面向服务的组件库，而且这个服务组件库也可以被其它企业复用，且不依赖于任何一种技术架构。夸张一点说，如果所有软件企业都使用SOA架构，那么世界软件业将会发生彻底的改变。显然，这样一个框架不是一种产品，也不仅仅是一种技术，而是一种解决问题的方法论

 

SOA是一个伟大的思想，它试图定义一个大家（各种软件厂商）都"认"的、都"遵循"的法则，大家都使用这样的方法来进行互联互通，从而实现无界限的联通，以及服务组件库的继承和复用，解放无效和重复劳动。打一个不那么恰当的比喻，就像人类的语言一样。SOA或许就像《圣经》中那个著名的"通天塔"的故事：人们用同一种语言交流产生的威力是如此之大，以至于他们在巴比伦几乎要修成一个"通天塔"，直达上帝所在的天庭

 

 

函数和变量写多了，自然也就发现有些函数和变量互相粘在一起很高耦合，而与其它的一些却没多达关系，于是为了显性化让其他的开发人员知道哪些函数和变量确实关联性很紧密，于是创造了类。

 

但接口思想的风潮在90年代刮起了。起闹的原因就是类被滥用，子类不断继承，发现随着企业业务发展变化，父类中实现的功能已经无法适合新时代业务了，现今业务和过去业务差异很大。而因为万丈高楼不能动父类中的方法功能了，否则子类就都瘫痪了。为了避免这个问题，就不让父类负责功能了。所以大量出现虚方法的父类，只有一个空的函数申明，函数里什么也没有。到最后发现只需要申明一下就可以，连函数这个空壳也不需要了，于是正式提出接口。

 

到了2000年以后，互联网兴起。XML从HTML中脱胎而出，HTML专门发展成为可视化界面展示技术，XML走向纯粹数据表示，但都是文本型，便于通过HTTP在互联网上传输。IT人员为了程序更灵活，于是让接口申明也不用代码表示了，直接用XML表示了。接口中需要的参数，如传入一个订单需要修改，那么这个订单数据也被XML表示。另外，这些接口方法怎么串联在一起执行一个完整的业务流程，也用XML表示了。至于XML怎么和代码动态绑定在一起，那就让底层技术去想吧。于是，IT公司和企业IT部门只要一起谈某个业务的处理流程、每步处理方法、处理的输入和输出就OK。把这些谈好的画出来，存储的时候保存成XML格式就OK，就如同咱们OFFICE2007就可以把EXCEL另存为XML格式一样。从这样来看，现在的IT软件开发公司和企业IT部门已经越来越一致的以业务来谈，而不是以技术来谈。一致面向业务来谈、XML式定义与动态绑定而不用去管用什么具体技术来实现这些功能，这是最关键的特征进步。这就是SOA。

 

从一步步来看，软件公司的开发人员的需求分析方式、软件设计方式、代码开发实现方式都已经变化很多了。面向业务流程和业务数据来谈，接口定义，内部实现具体编码类就OK。底层框架真正负责这些XML接口定义和具体组件的绑定、创建、销毁、内存回收、并发、池化、序列化、访问安全、事务保证。这个底层就是中间件。过去有EJB中间件服务器、COM+中间件服务器（MTS）、CORBA中间件服务器。现在加入了功能接口、业务数据的动态XML绑定以及业务流程的动态解释执行，就被升级命名为ESB，意思就是希望通过XML定义和传递，来达到不同技术的组件（EJB、COM+、CORBA）都能互通。这和XP升级到VISTA或WIN7一样的，都是继承性发展过来的。但就是叫不同的名字，就要把WIN6叫做VISTA，就要把WIN5叫做XP。

在10年前，很多人问过我：“你的软件是三层的吗？你的软件是面向组件的吗？”。好像意味着面向组件就可以灵活组装软件。现在又有人问我：“你的软件是面向SOA的吗？”。我在想，我的软件UI界面是XML描述的、Report是XML描述的、功能函数是XML申明的、业务处理流程也是XML定义的，数据也是XML定义的，而且也是工具来画出来保存成XML而无需手工直接编写XML。但就是这样也不是普通人员能够搞的，几千个业务数据定义、几千个功能函数、复杂的业务处理流程，不是熟练手天天搞是很难直接下手修改并且调试确保正确的。从本质来说，XML不就是把写死的代码换成有固定规格的文本了么？在程序员眼里，源代码也是ABCD的文本，XML也是ABCD的文本。