本书不仅介绍了C0M的基本原理及其扩展知识，还讲述了MTS及COM＋的一些知识。全书分为三部分，第一部分为C0M基础，第二部分为C0M扩展，第三部分为COM应用与发展，介绍了组件化程序设计思想以及多层软件结构模型。读者在学习了COM的基本原理之后，结合MTS和C0M＋所倡导的一些概念，就可以从更高的层次来理解和使用C0M及C0M＋了。片断：nbsp;C0M，即组件对象模型，是一种以组件为发布单元的对象模型，这种模型使各软件组件可以用一种统一的方式进行交互。C0M既提供了组件之间进行交互的规范，也提供了实现交互的环境，因为组件对象之间交互的规范不依赖于任何特定的语言，所以COM也可以是不同语言协作开发的一种标准。即使读者对COM还不太了解，我想读者对OLE（objectlinkingandembed出ng，对象链接和嵌入）应该不会陌生。OLE技术以COM规范为基础，OLE充分发挥了COM标准的优势，使Windows操作系统上的应用程序具有极强的可交互性。如果没有OLE的支持，Win－dows操作系统则会逊色很多。但是，C0M规范并不局限于OLE技术，实际上，OLE技术只是COM的一个应用而已，这几年，网络技术飞速发展，OLE技术在进行网络互连时显示出了很大的局限性，而C0M则表现出了极强的适应能力，因此，这两年伴随着网络的发展，COM也得到了展示的机会。继OLE之后，Microsoft又推出了一系列以COM为基础的技术，并统称为ActiveX技术，这也充分说明了COM的应用价值。本章将对COM作概括性的论述，使读者对COM有一个基本的认识。1.1COM的起源作为组件化软件模型，COM的发展过程非常有趣。Microsoft最初并没有刻意发展一种组件化系统，但是，随着桌面窗口系统中应用程序之间的交互不断深入，就在0LE技术的发展过程中产生了COM。而且后来进一步的发展表明，COM所定义的组件标准其广泛性远远超过了OLE所具有的能力，因此，从这个意义上讲，在组件化软件发展进程中，Microsoft走了一条捷径。从一开始，C0M就具有很好的应用前景。可是，在这几年软件发展过程中，虽然COM能很好地胜任组件化软件的模型标准，但实际进展并不顺利。我想，原因可能在于0LE技术太复杂，OLE程序太复杂，一般人难以窥探到OLE的底层，尤其是通过OLE来学习C0M，那更是本末倒置了，所以我们也可以说OLE掩盖了COM技术，甚至OLE的一些缺点掩盖了C0M的优点。不过这种情况已经有了很大的好转，人们逐渐意识到C0M符合了当前软件业的发展需要，用COM进行软件架构是一种理想的应用方案。而且，脱离开0LE之后，COM自身又得到了很大的发展，现在已经遍布于Microsoft的各种软件产品中。1.1.1OLE的发展历史从字面上来看，OLE所表达的是复合文档（compounddocument）的概念，而且，OLE的第一个版本即OLE1也仅限于此。需要指出的是，在OLE1中，组件程序和客户程序之间进行通信并没有使用COM规范，而是使用了一种被称为动态数据交换（DDE，DynamicDataExchange）的机制，DDE建立在Windows操作系统的消息机制基础上，其最大的缺点是效率低，而且稳定性不好，使用也不够方便。DDE的这些缺陷也限制了OLE1的发展，于是，在第二个OLE版本即OLE2中，Microsoft重新编写了底层代码，放弃了DDE，采用了新的COM模型，因此，OLE2成了第一个用COM架构的软件系统。由于采用了COM，OLE2比OLE1效率更高，稳定性和灵活性有了很大提高。在以后OLE的发展过程中，由于采用了COM作为其底层结构，使用COM接口（inter－face）作为程序之间通信的标准，因此，OLE模块定制和扩充变得非常方便。这里我顺便提一下软件版本的升级方式。一般的应用系统在升级版本时，往往用新的软件模块全部替换老的程序模块，因此，升级就意味着全部更新，例如OLE2对0LE1进行升级，不仅软件模块作了替换，连基本技术也变了。但是在OLE2之后，由于采用了组件化的软件模型，因此，每一个底层模块可以单独升级，而且在原来软件模块的基础上，可以添加新的组件模块而不需要改变原有的组件模块。因此，在0LE2之后，0LE技术不再局限于“对象链接和嵌入”，不再局限于复合文档，而变成了在桌面系统上进行程序通信的一个技术统称。因此，当人们正在等待“OLE3”出现的时候，OLE已经不再是最初的OLE了。并且，用户计算机中的0LE系统也正悄悄地在进行更新。1.1.2组件的产生在计算机软件发展的早期，一个应用系统往往是一个单独的应用程序。应用越复杂，程序就越庞大，系统开发的难度也就越大。而且，一旦系统的某个版本完成以后，在下个版本出来之前，应用程序不会再有所改变。而对于庞大的程序来讲，更新版本的周期很长，在两个版本之间，如果由于操作系统发生了变化，或者硬件平台有了变化，则应用系统就很难适应这样的变化。所以这类单体应用程序已经不能满足计算机软硬件的发展需要。从软件模型角度来考虑，一个很自然的想法就是把一个庞大的应用程序分成多个模块，每一个模块保持一定的功能独立性，在协同工作时，通过相互之间的接口完成实际的任务。我们把每一个这样的模块称为组件，一个设计良好的应用系统往往被切分成一些组件，这些组件可以单独开发，单独编译，甚至单独调试和测试。当所有的组件开发完成后，把它们组合在一起就得到了完整的应用系统。当系统的外界软硬件环境发生变化或者用户的需求有所更改时，并不需要对所有的组件进行修改，而只需对受影响的组件进行修改，然后重新组合得到新的升级软件。图1.1体现了这样的一个升级过程。
鄂公网安备 42010302001612号 