分布式组件对象模型（DCOM）

在过去的二十年里，面向对象和分布式组件导向的架构方式发生了巨大的变化。 为了满足这一需求，微软开发了分布式组件对象模型。 DCOM可以被定义为包含了一根长线的COM技术。实际上，DCOM是组件对象模型（Component Object Model）的一种扩展形式。 DCOM——分布式组件对象模型——它通过一种名为“对象远程过程调用”的协议来实现远程对象的通信。 每天，有1000万人在网络环境中使用Windows操作系统。DCOM作为一种被广泛使用的技术，其主要作用就是支持那些可以动态激活的组件的开发，同时还能让这些组件能够与其他组件进行交互。 DCOM对象模型是基于各种接口的实现而构建的。 (DCOM)中的对象和组件模式涉及到许多问题。

1. Interoperability
2. Versioning
3. Language independence
4. Size and complexity of system 

动态数据交换：动态数据交换技术，即DDE，最初是为Microsoft Windows操作系统而设计的，其目的是让各种应用程序能够交换各种类型的信息。不过，由于DDE协议本身相当复杂，因此需要借助许多软件厂商来解析这一复杂性。为了解决这一问题，人们开发了动态数据交换管理库（DDEML）。该库简化了与DDE协议的接口操作，同时为所有开发者提供了统一的接口方式。DCOM架构：DCOM结构是为了促进软件的互操作性而设计的。

• 该架构支持一种“软件总线”机制，通过这种方式，可重复使用的软件组件可以被有效利用，同时这些组件也可以与其他组件无缝集成在一起。
• 为了为这个可重复使用的软件组件提供支持，其完整的对象模型完全基于基于对象的编程模型来构建的。
• 过去，选择某个对象模型的原因在于该模型无法实现继承功能。
• 这意味着，这种架构成功地避免了在不同模型中存在的“脆弱的基础类综合征”问题。
• 所谓的“脆弱的基类综合征”，指的是当一个类继承了其他类的成员和功能时出现的现象。
• 提供成员函数和行为的类被识别为基类，而其他类则被识别为派生类。
• 如果基类中的成员和功能发生了改变，那么派生类的行为和成员函数也会相应地发生变化。
• 这样的修改会导致必须修改基础类本身，而这就又需要重新编译所有依赖的类。
• 如图1.0所示，DCOM架构具有一种特殊的基础设施，这种基础设施有助于实现持续性的存储功能。

DCOM的工作原理：在DCOM的运作过程中，COM对象需要能够在两台计算机上都被有效配置。因此，通常不需要多次卸载和重新安装这些对象，就能让它们能够在特定任务中正常发挥作用。Windows注册表中包含了与DCOM相关的配置信息，这些信息通过三个标识符来表示：CLSID、PROGID和APPID。

1. CLSID –类标识符或CLSID是一种全局唯一的标识符，用于为某个实体创建唯一的身份。Windows会将该类的CLSID存储在一个程序中，以便执行特定的任务。当你想要运行某个类时，你需要正确的CLSID，这样Windows就能知道该去哪里查找该程序了。
2. PROGID –程序化标识符或PROGID是一种非强制性的标识符，也可以说是一种可选的标识符。程序员可以将其作为复杂且严格的CLSID的替代方案来使用。通常情况下，PROGID的读取方式较为简单，易于理解。对于具有相同名称的多个PROGID来说，并没有任何限制，不过这有时也会引发一些问题。
3. APPID –应用程序标识符或APPID，是一种用于唯一标识每个可用应用程序的标识符。这种标识符在确保应用程序的安全性和真实性方面起着重要作用。它能够识别所有与某个应用程序相关的类，以及访问该应用程序所需的权限。如果APPID不正确，那么DCOM就无法正常工作。因此，为了使DCOM能够正常运行，必须确保APPID准确无误。根据我的经验，尝试创建远程对象时，很可能会遇到权限相关的错误。