从流水程序到SOA

从流水程序到SOA

咱就从函数代码开始谈起,更史前的Goto和汇编代码咱就不谈了。

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

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

到了90年代中期，IT软件开发公司越来越专业了，大量企业IT部门不再自己开发软件而转为购买专业软件公司的软件。这样企业IT部门的IT人员对编程对技术越来越远，渐渐偏向了业务。企业IT部门谈业务流程和业务输入输出，IT公司谈对象，这就接不上去。于是IT开发公司发明了面向组件的业务分析方法、设计方法、开发方法。不要谈对象识别、对象分解、对象继承、对象调用关系，只谈你需要什么功能。功能用接口来表明能干什么，但这些接口是在内部被哪些类实现的，类之间的关系到底怎么回事，都不用解释给企业IT部门。这是企业IT部门和专业软件公司第一次以业务视角来谈软件。

到了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的文本。