漫谈组件技术:从OLE到COM到ActiveX到SOAP
时间：2010-09-16 来源：kgisme170
漫谈组件技术: 从OLE到COM到ActiveX到SOAP
世界上有两种计算机思维方式。基于文本的和基于二进制对象的。
Unix把一切信息都组织成为文本，用户需要自己清楚如何判断这些文本信息。所有的设备都被看成上一个可以读写的文件。
Unix天生就青睐脚本: 系统中有各种各样的可执行程序，利用标准输出做IO，通过管道来进行组合，无须特别的面向组件技术。
Unix为什么要这样做? 简单，对于管理人员，对于程序员来说，简单。
Windows把一切都看成是一个二进制对象，用户需要知道如何得到这些对象然后操控他们。所有的功能都是通过对象的调用完成。
所以，区别就来了。
Windows呢? 系统中存储了一群对象。问题是这些对象如何获取? 这可不是Unix的shell命令行那么简单的(敲命令输出)。
Windows是面向用户的，它要求效率，要求用户透明。至于是不是给管理人员和程序员平添了很多烦恼，这不是Windows关心的。
-----------------------------------------------------------------------------------
OK，OLE隆重出场。
我们在编程序的时候，如果要把一个文件的内容进行修改，例如把"123456"改为"123a456"，那么实际上我们是重写了一遍这个文件。如果文件很大很复杂，修改的地方又很多呢，那么不但程序运行费时费力，而且磁盘读写次数还多。微软为复杂文档，例如word/excel想了一个办法。借用了文件系统的概念，一个word/excel文档本身，就可以看作是一个很小的文件系统。word/excel文件的内容，就是由很多个小的部件，像挂在一棵树上一样，组成了.doc/.xls文件的。当一个对象进行修改的时候，整个树并不进行重新布局，而是把一个对象位置描述符重新定位到文件的末尾，创建这个新对象的内容，极大地减轻了IO的负担。不过，这样做会有一个坏处，就是即使是修改而不添加，文件的尺寸仍然会持续的增加。相信大家有这样的经验: 一个经历了多次修改得word文件，当你"另存为"以后，新的文件尺寸变小了很多。OLE顾名思义，就是这种思想的具体实现。整个Office产品线贯穿了一套OLE便准，所以Office的对象是可以在word/excel/ppt之间互相拷贝的，这些对象本身的数据解构是统一的，用一组OLE的api来操纵。
再后来，微软不满足于把一个文档变成一个"树形"的对象系统。它要把可执行程序也变成一个"树形"的对象系统。换句话说，这是为了实现某种"自描述"的组件技术，就像水Java里面的"反射"技术一样。但是，微软实现得非常丑陋，究其原因，恐怕还是纯粹为了效率考虑。这就来到了COM(OLE2)，一个可执行的程序或者模块，本身可以通过QueryInterface的方法，得到一系列的对象/函数接口。顶层的对象又可以递归包含多层子对象，这些子对象又有自己的方法。一个可执行程序就通过一个复杂类型的实例，建造了对象树，就像多层次的名称空间一样。
写过数据库的人会有这样的经验，如果一个表有一个外键，该外键是一个文本串的话，虽然意义非常的明显，但是显然解析的效率会非常低。解决的办法是，主表增加一列，比如就是序号，从表的外键引用这个序号，这样做的效率非常高，缺点就是，如果一个从表引用了多个主表的序号列作为组合外键的话，那么语义上，这些组合代表了什么意思，基本就只有设计人员自己知道了。当然，Windows的用户是不会管程序是怎么编出来的，他们要的是体验。COM就是这样，对象不是通过一个文本方式的字符串来引用和建立实力的，而是纯粹通过一个UUID(128位数字)。编程的人记不住哪个对象对应什么UUID，所以写组件的这些人要附带一个type library，使得用这些组件做开发的人，可以用type lib直接生成一个class，这个class包装了UUID对应的实际对象，使得底层细节对程序员透明。
当然，COM组件不能自己运行，必须依赖COM管理器，客户端和服务器端的通信，是通过COM服务提供的rpc机制自动完成的，程序员不用管。
再然后，就是Automation(自动化)的COM和ActiveX。Unix下面是启动程序，打开文件。Windows和其他流行的桌面系统则是启动一个文件，打开程序。当我们进入word的时候，双击一个公式，可以看到一个公式编辑器弹出来了。这就是自动化: 符合文档本身不仅仅是文档，每个对象还要包括一种信息，就是运行什么样的程序/组件来编辑自己。符合一定的编程规范的Automation组件，就是ActiveX----例如，它必须有Paint方法，也就是必须有窗口，哪怕是隐藏的。当我们在VC的工程里面添加一个ActiveX控件的时候，即使还没有编译，我们就已经可以在资源编辑器里面看到，一个ActiveX控件，它默认的绘图方法究竟都干了什么事情。
OLE->COM(加上rpc就是DCOM)->ActiveX，在.net出现之前，这就是微软的技术演进路线，就像俄罗斯的套娃一样，一层接一层，称为Windows DNA，运行在Transaction server上面。Windows DNA依赖平台，组件因为是2进制识别的，所以需要注册和发布，非常不方便。.net的CLR出世，使得程序之间的差别仅仅是语法，运行时环境变得一致，前面那些二进制组件技术，在.net framework前面就显得苍白无力了。当然，非.net的本地代码仍然是普遍存在的，所以基于COM的程序仍然会存在下去，它毕竟提供了一种和语言无关的本地访问手段(基于某种复杂到让人崩溃的数据和程序结构)，它和.net(基于统一的运行时)是平行的。VB是为COM/ActiveX设计的，而VB.net是为.net framework设计的。二者仅仅是语法上的继承关系而已。不同点是，COM组件是服务器，程序是容器; 而在.net/j2ee中，组件运行在容器里面，程序连接服务器，服务器是个容器。他们在架构的不同，直接导致了Com/Corba技术复杂且让开发者陷入细节，必须依赖编程模版。而.net/j2ee真正实现了很多应用框架，因为组件不是"服务器"，而客户端程序也不需要成为"容器"这么复杂。
当然，微软在慢慢淘汰复杂丑陋的COM。与此同时，Corba这种omg提出的技术，以及tuxedo之类的应用服务器技术，末日也不远了。统一的访问方式，SOAP，将逐渐取代它们。用基于XML的文档信息传输，代替二进制的字节协议。这么看来Windows越来越向Unix靠拢。这应征了那一句话，不懂Unix的人，早晚也会发明一个蹩脚的Unix来，微软的Powershell就是实证。基于文本信息描述的组件化，平台的差异瞬间不再是需要考虑的问题。.net和j2ee在webservice上可以无缝互操作，不需要再为两者之间开发程序来互通。
世界上有两种计算机思维方式。基于文本的和基于二进制对象的。
Unix把一切信息都组织成为文本，用户需要自己清楚如何判断这些文本信息。所有的设备都被看成上一个可以读写的文件。
Unix天生就青睐脚本: 系统中有各种各样的可执行程序，利用标准输出做IO，通过管道来进行组合，无须特别的面向组件技术。
Unix为什么要这样做? 简单，对于管理人员，对于程序员来说，简单。
Windows把一切都看成是一个二进制对象，用户需要知道如何得到这些对象然后操控他们。所有的功能都是通过对象的调用完成。
所以，区别就来了。
Windows呢? 系统中存储了一群对象。问题是这些对象如何获取? 这可不是Unix的shell命令行那么简单的(敲命令输出)。
Windows是面向用户的，它要求效率，要求用户透明。至于是不是给管理人员和程序员平添了很多烦恼，这不是Windows关心的。
-----------------------------------------------------------------------------------
OK，OLE隆重出场。
我们在编程序的时候，如果要把一个文件的内容进行修改，例如把"123456"改为"123a456"，那么实际上我们是重写了一遍这个文件。如果文件很大很复杂，修改的地方又很多呢，那么不但程序运行费时费力，而且磁盘读写次数还多。微软为复杂文档，例如word/excel想了一个办法。借用了文件系统的概念，一个word/excel文档本身，就可以看作是一个很小的文件系统。word/excel文件的内容，就是由很多个小的部件，像挂在一棵树上一样，组成了.doc/.xls文件的。当一个对象进行修改的时候，整个树并不进行重新布局，而是把一个对象位置描述符重新定位到文件的末尾，创建这个新对象的内容，极大地减轻了IO的负担。不过，这样做会有一个坏处，就是即使是修改而不添加，文件的尺寸仍然会持续的增加。相信大家有这样的经验: 一个经历了多次修改得word文件，当你"另存为"以后，新的文件尺寸变小了很多。OLE顾名思义，就是这种思想的具体实现。整个Office产品线贯穿了一套OLE便准，所以Office的对象是可以在word/excel/ppt之间互相拷贝的，这些对象本身的数据解构是统一的，用一组OLE的api来操纵。
再后来，微软不满足于把一个文档变成一个"树形"的对象系统。它要把可执行程序也变成一个"树形"的对象系统。换句话说，这是为了实现某种"自描述"的组件技术，就像水Java里面的"反射"技术一样。但是，微软实现得非常丑陋，究其原因，恐怕还是纯粹为了效率考虑。这就来到了COM(OLE2)，一个可执行的程序或者模块，本身可以通过QueryInterface的方法，得到一系列的对象/函数接口。顶层的对象又可以递归包含多层子对象，这些子对象又有自己的方法。一个可执行程序就通过一个复杂类型的实例，建造了对象树，就像多层次的名称空间一样。
写过数据库的人会有这样的经验，如果一个表有一个外键，该外键是一个文本串的话，虽然意义非常的明显，但是显然解析的效率会非常低。解决的办法是，主表增加一列，比如就是序号，从表的外键引用这个序号，这样做的效率非常高，缺点就是，如果一个从表引用了多个主表的序号列作为组合外键的话，那么语义上，这些组合代表了什么意思，基本就只有设计人员自己知道了。当然，Windows的用户是不会管程序是怎么编出来的，他们要的是体验。COM就是这样，对象不是通过一个文本方式的字符串来引用和建立实力的，而是纯粹通过一个UUID(128位数字)。编程的人记不住哪个对象对应什么UUID，所以写组件的这些人要附带一个type library，使得用这些组件做开发的人，可以用type lib直接生成一个class，这个class包装了UUID对应的实际对象，使得底层细节对程序员透明。
当然，COM组件不能自己运行，必须依赖COM管理器，客户端和服务器端的通信，是通过COM服务提供的rpc机制自动完成的，程序员不用管。
再然后，就是Automation(自动化)的COM和ActiveX。Unix下面是启动程序，打开文件。Windows和其他流行的桌面系统则是启动一个文件，打开程序。当我们进入word的时候，双击一个公式，可以看到一个公式编辑器弹出来了。这就是自动化: 符合文档本身不仅仅是文档，每个对象还要包括一种信息，就是运行什么样的程序/组件来编辑自己。符合一定的编程规范的Automation组件，就是ActiveX----例如，它必须有Paint方法，也就是必须有窗口，哪怕是隐藏的。当我们在VC的工程里面添加一个ActiveX控件的时候，即使还没有编译，我们就已经可以在资源编辑器里面看到，一个ActiveX控件，它默认的绘图方法究竟都干了什么事情。
OLE->COM(加上rpc就是DCOM)->ActiveX，在.net出现之前，这就是微软的技术演进路线，就像俄罗斯的套娃一样，一层接一层，称为Windows DNA，运行在Transaction server上面。Windows DNA依赖平台，组件因为是2进制识别的，所以需要注册和发布，非常不方便。.net的CLR出世，使得程序之间的差别仅仅是语法，运行时环境变得一致，前面那些二进制组件技术，在.net framework前面就显得苍白无力了。当然，非.net的本地代码仍然是普遍存在的，所以基于COM的程序仍然会存在下去，它毕竟提供了一种和语言无关的本地访问手段(基于某种复杂到让人崩溃的数据和程序结构)，它和.net(基于统一的运行时)是平行的。VB是为COM/ActiveX设计的，而VB.net是为.net framework设计的。二者仅仅是语法上的继承关系而已。不同点是，COM组件是服务器，程序是容器; 而在.net/j2ee中，组件运行在容器里面，程序连接服务器，服务器是个容器。他们在架构的不同，直接导致了Com/Corba技术复杂且让开发者陷入细节，必须依赖编程模版。而.net/j2ee真正实现了很多应用框架，因为组件不是"服务器"，而客户端程序也不需要成为"容器"这么复杂。
当然，微软在慢慢淘汰复杂丑陋的COM。与此同时，Corba这种omg提出的技术，以及tuxedo之类的应用服务器技术，末日也不远了。统一的访问方式，SOAP，将逐渐取代它们。用基于XML的文档信息传输，代替二进制的字节协议。这么看来Windows越来越向Unix靠拢。这应征了那一句话，不懂Unix的人，早晚也会发明一个蹩脚的Unix来，微软的Powershell就是实证。基于文本信息描述的组件化，平台的差异瞬间不再是需要考虑的问题。.net和j2ee在webservice上可以无缝互操作，不需要再为两者之间开发程序来互通。
相关阅读 更多 +
