对象标准COM和CORBA论长道短(3) COM提供了两种机制来取代实现继承性，这两种代码重用机制叫作抑制／代理和聚类，在前一种机制中，一个对象（外部对象）只要把内部使用的对象当作服务提供者来使用就可以使自己（外部对象）成为其他对象的客户了，外部对象的客户是绝不能看到内部对象的，这就是说某个对象的内部对象对于该对象的客户来说是完全隐藏的，这正是封装性的体现。在聚类机制中，一个聚类对象实际上是一个合成对象，由外部对象和内部对象合成，外部对象把内部对象直接呈现给外部对象的客户，这时内部对象就象外部对象中的一部分一样，所以说聚类机制是一种特殊的抑制／代理机制。4．本地透明性和远端透明性 COM允许客户透明地与对象通讯，客户在与对象通讯时并不知道对象在何处，客户访问对象完全是通过接口指针的，指针当然是在过程中的，而且每一次对接口的调用都要先与过程中的一些代码打交道。如果对象是在过程中的那么就可以直接调用该对象，若对象在过程之外，那么调用先与COM提供的代理对象打交道，产生一个远程过程调用，以调用其它过程中的或其它机器上的对象。5．COM库 COM的核心就是规范说明对象及其客户的接口，COM本身也包含了一些系统级的代码，因此COM也有自己的实现，COM库就是系统组件，提供了COM机制。微软公司在Windows平台上的COMOBJ．DLL就是COM库的实现，WindowsNT和Windows95平台上COM库的实现是OLE32．DLLE。 三、COM与CORBA的比较这两种标准的主要区别在于它们实现接口的方式：COM规定了一系列组件必须实现的接口，组件对象之间的相互作用必须经由这些接口，所有这些接口都必须由基接口IUnknown导出；CORBA则不规定基类，各厂商可以根据自己的意愿去实现自己的类。CORBA标准没有关于引用实现的规定，这是OMG考虑到各厂商切身利益而故意忽略的，而没有关于实现细节的明确规定这既是一大优点同时也是具有很多局限性的，因为在为厂商提供实现灵活性的同时，也招致了许多麻烦。如无法统一管理、ORB不兼容、和缺乏可移植的服务器等问题。与此相反，COM则非常明确地规定了实现细节，但这种严格控制也能导致不良后果：解决方案不是最优方案。COM与CORBA另一差异在于对实现继承性的不同处理，实现继承即是面向对象技术利用类层次中而实现的类的继承。接口继承性是指能够不依赖类层次而重用对象接口的能力，它体现了OO中的封装性的概念。微软则不以为然，它认为把实现继承应用到相互作用的对象模型中去是不恰当的，所以COM只支持接口继承而不支持实现继承。IBM则声称一个真正的面向对象系统必须支持实现继承性，IBM在其SOM中实现了实现继承性。SOM是CORBA家族中的第一个成功产品，它诞生于1991年，IBM认为SOM是面向对象的，而COM则是基于对象的。关于COM和CORBA这两大标准，还有一个不容忽视的问题———产品的级别和产品的种类。CORBA有许许多多的产品，支持跨网络的对象的相互作用。微软的OLE是COM产品，但它还不支持跨平台的对象的相互作用。综上所述，Microsoft身为OMG成员却不支持CORBA标准而另辟COM标准，使COM成为CORBA及其已实现组件OpenDoc的直接竞争者。由于OMG的其他成员都没有把桌面软件作为战略重点，加上微软在桌面软件行业中已成为事实的霸主地位，COM实际上就成为桌面市场的工业标准。Digital已决定把COM移植到OpenVMS和OSF／1平台上，并建造沟通COM和CORBA的桥梁。微软正雄心勃勃地发展WindowsNT操作系统，以图取代Unix操作系统在服务器领域的地位，鉴于微软的实力及其市场占有率，这种可能性是很大的。如果在几年后，微软的愿望成为现实，大多数服务器厂商以WindowsNT做为服务器品质操作系统，那么分布式COM也就成为分布式互操作对象领域中的主角了。对于许多应用和开发环境来说，为了平衡基于组件开发的优势，COM可能是明智的选择，在软件愈来愈复杂和专用的今天，基于组件的开发是不破坏整体性而控制软件复杂性的行之有效的方法。
