OLE Component Object Model
0 Intended Use
OLE (and its Component Object Model) provide a basis for application interoperation in the Microsoft Windows environment.
1 Basic Concepts
Microsoft#39;s OLE provides an application integration framework for Microsoft Windows. OLE defines the Component Object Model, which specifies a programming-language-independent binary standard for object implementations (i.e., it specifies what the implementation of the objects has to look like). Any object conforming to this standard is a legitimate Windows Object, no matter what language is used to implement it. The programming model is synchronous, based on a 'Lightweight Remote Procedure Call' (lightweight because, at least at the moment, the calls are not really remote; they are all made on one machine).
In the Component Object Model, the concept of interface assumes great importance. An interface is 'a set of semantically related functions implemented on an object' [Bro94a]. The Component Object Model uses the word 'interface' by itself to refer to the definition (signatures) of those functions. An implementation of an interface is an array of pointers to functions. Any code that has a pointer to that array can call the functions in that interface. A Windows Object implements one or more interfaces, i.e., provides pointers to function tables for each supported interface.
Users of objects always obtain and act through pointers to object interfaces; users never obtain pointers to an entire object. For example, when the user of some object first obtains a pointer to the object, the user actually gets a pointer to one of the object#39;s interfaces. This pointer allows the user to call only the functions in that one interface#39;s function table. Through this pointer, the user has no access to any state of the object, nor does the user have any direct access to functions in other interfaces.
OLE defines a standard function, called QueryInterface, through which the user of one interface of an object can obtain a pointer to another interface of the same object. QueryInterface is part of an interface called IUnknown, which defines a group of fundamental functions that all Windows Objects support (thus IUnknown is supported by all objects). All other interfaces in OLE are derived from IUnknown, so all interfaces contain the QueryInterface function. This insures that navigation is always possible between the interfaces of a given object.
Using QueryInterface, the user of an object can discover the capabilities of that object at run-time by asking for pointers to specific interfaces. This enables an object to implement as many interfaces as it wants. Because all Windows Objects implement at least IUnknown, there is always some basic way for a user to communicate with any object.
The function table that implements an interface is designed to have a layout that is identical to the one generated by many C compilers. This layout allows a single indirection (-gt;) on the pointer to call an interface function. However, while this makes the use of C to program OLE convenient, this is not a requirement. An object implementation is only required to provide separate function tables for each supported interface. How these tables are created can differ, depending on the particular language used. Because neither use or implementation of a Windows Object is dependent on the programming language used, the Component Object Model is referred to as a binary standard. This provides for language independence without involving the definition of a separate language (e.g., an Interface Definition Language).
2 Objects
The Component Object Model specifies a programming-language-independent binary standard for object implementations (i.e., it specifies what the implementation of the objects has to look like). Any object conforming to this standard is a legitimate Windows Object, no matter what language is used to implement it.
Users of objects always obtain and act through pointers to object interfaces. An implementation of an interface is an array of pointers to functions (the functions themselves are implemented by the object). Any code that has a pointer to that array can call the functions in that interface. A Windows Object implements one or more interfaces, i.e., provides pointers to function tables for each supported interface. Users never obtain pointers to an entire object. For example, when the user of some object first obtains a pointer to the object, the user actually gets a pointer to one of the object#39;s interfaces. This pointer allows the user to call only the functions in that one interface#39;s function table. Through this pointer, the user has no access to any state of the object, nor does the user have any direct access to functions in other interfaces.
A Windows Object is any object, in whatever form, that supports at least one predefined interface, called IUnknown. As part of the IUnknown interface, OLE defines a standard function, called QueryInterface, through which the user of one interface of an object can obtain a pointer to another interface of the same object. QueryInterface takes as input a pointer to an interface identifier (IID) for the desired interface, and either returns an error (and a NULL pointer), meaning the object does not support the interface, or a valid pointer to the new interface. [See entry under 6. Identity, Equality, Copy for a discussion of IIDs.] All other interfaces in OLE are derived from IUnknown, so all interfaces contain the QueryInterface function (the other two functions of IUnknown are AddRef and Release). This insures that navigation is
全文共27129字，剩余内容已隐藏，支付完成后下载完整资料
OLE组件对象模型
OLE（和COM，组件对象模型）在Microsoft Windows环境中提供了应用程序间相互操作的功能。
1 基本概念
Microsoft的OLE为Microsoft Windows提供了一个应用综合化框架。OLE定义为组件对象模型，它为对象的执行指定了一个独立的编程语言二进制标准（即，它指定了对象的执行必须和服务器对象是一样的）。符合这个标准的任一个对象都是合法的Windows对象，而不管它是用何种语言编写执行的。根据“远程调用”（至少在同一时间内，调用并不是遥远的，因为它们都处于一个系统内），设计模型是同步的。
接口的概念在组件对象模型（COM）中显得十分重要。接口是“在对象中相互作用的一套程序” [Bro94a]。组件对象模型用“接口”这个词来定义（署名）它们的功能。接口的执行是一些程序接口的作用，在接口程序中定义了接口的代码列可以叫做一个函数。一个Windows对象执行一个或多个接口，即，为每个支持的接口提供接口功能。
对象的使用者一般是通过程序的接口来获得和操作该对象的，用户不需获得整个对象。例如，当一些对象的用户首先获得对象的接口时，用户实际上是得到了该对象的一个接口。这个程序接口只允许用户访问该接口多对应的功能。通过这个程序接口用户不能进入对象的任何一种状态，用户也不能直接存取其他接口的功能。
OLE定义一个标准的功能，称为QueryInterface，通过对象的一个接口用户可以获得一个程序接口到其他相同的对象的接口中。QueryInterface是接口的一部分称为IUnknown，它定义一个Windows对象所支持的一些基本作用（所有的对象都支持IUnknown）。在OLE中所有其他的接口都来自IUnknown，所以所有的接口都包含QueryInterface的作用。这确保了在一个指定对象的接口之间通信成为可能。利用QueryInterface，使用对象的用户通过访问程序接口对具体的借口在执行时间内能发现该对象的功能。这使对象能在它需要的时候实施许多个接口。因为所有的Windows对象执行都有（至少是一个IUnknown接口）一些基本的方式使用户在各个对象间进行通信。
设计好的执行接口的函数是通过用C 编译器设计的。这种设计允许程序接口间接的访问接口功能。但是当这用C 来编程的时候，这就不需要了。对象的执行只需要为每个支持接口提供不同的函数。用不同的语言，怎样创建不同的函数。因为无论是使用或执行Windows对象都要依靠编程语言的使用，组件对象模型是制一个二进制标准。这提供了不介入分开语言的独立性（即，接口限定语言）的定义。
2 对象
组件对象模型为对象的执行指定了一个独立编程语言的二进制标准（即，它指定了对象的执行必须和对象服务器一致）。任一个对象符合这个标准的都是一个合法的Windows对象，不管什么语言来执行它。
使用对象的拥护获得和执行它们要通过对象的接口。接口的执行是通过一些函数来完成的（函数是通过对象来执行的）。在这个接口中具有要点的一些代码被称为函数。Windows对象执行一个或多个接口，即为每个支持接口提供了参数到函数中。用户不能获得参数到整个对象中。例如，当一些对象的用户第一次从对象中获得一个参数，用户实际上的获得了一个对象接口的参数。这个参数允许用户只能访问接口函数组。通过这个参数，用户不能进入任何对象的状态，用户也不能直接进入其他接口的函数。
Windows对象是指在任何形式下至少支持一个预定义函数的接口，叫做IUnknown接口。作为IUnknown接口的一部分，OLE定义一个函数标准，叫做QueryInterface，通过它使用对象接口的用户能够获得一个参数到另外一个相同的对象的接口。QueryInterface接口通过一个输入参数到一个接口标识（IID），目的是为了得到需要要的接口，并且返回错误（NULL参数），意味着对象不支持这个接口，或者对于一个新的接口它是一个无效的参数。[看一下在6.同一性，等同性，拷贝。为IIDs的讨论]在OLE中所有其他的接口从IUnknown里被导出，因此所有的接口包含QueryInterface函数（IUnknown的其他两个函数是AddRef和Release）。这确保在两个给定的对象中，两个接口之间的通信是可行的。
Windows对象必须为每个它支持的接口提供独立的函数组。IUnknown函数的执行在每个它支持的接口必须对整个对象明白。因为它们必须能进入在对象中的所有其他的接口，并且能影响对象所涉及的数据。
在复合对象库（COMPOBJ.DLL）的执行提供一小部分基本API函数，API函数允许叫做组件对象的创造物，特殊类型的Windows对象用一个独一无二的类标识符，这个类标识符通过一个在文件系统里的特定的DLL或EXE连接一个对象。Windows对象不需要像一个复合对象那样被建立为了COMPOBJ.DLL中的API函数能够创建它。诸如API函数的使用仅仅有一个方式，通过这个方式这个对象能够获得最初的参数。
与C 不同，对象被定义为用户定义类型所产生的类定义，Windows对象被定义在这期间它们支持的接口。因为所有对象支持至少一个接口（IUnknown），因此所有的Windows对象也至少是IUnknown类型，并且能够像其他类型靠用不同的接口一样对待。因为这个机制，这里没有单独的用户定义类型和Windows类连接，而是用C 类来连接。事实上，没有特殊的方式去辨别一个特殊的对象，这是因为对象涉及（参数）在Windows对象中不是涉及到对象它本身，而在C 中，对于一个对象的接口而言对象是涉及到参数的。对于一个接口它给定的参数，用户只能进入到那个接口包含的函数中。用户永远不能拥有整个对象的参数（因为这没有一个整个对象的用户可视定义），所以这里没有直接进入状态的途径，并且在C 中没有'friend'这个概念。通过IUnknown接口，用户可以获得参数到对象也支持的其他接口，但是这意味着获得不同参数，这些参数提及（间接地）到相同的对象。每个参数对于一个接口指出一个函数组用对象连接，并且没一个组仅仅包含一个特定接口的函数。因为对于Windows对象的一个参数一直指出一个函数组，像参数也能够被用作在程序内部编写语言不单单是C ，也可以是C或者其他简单的代码。
具体类对象支持接口的名单在一个具体对象的终身之内是仅恒定的，并且能在同类的对象的不同接口之间变化。如果类X的对象1支持特殊套接口，它不能假设类X的对象2同样也可以。（注意'类' 表示应用提供对象的实施, 不是套接口(型) 支持）它同样也无法假设, 如果类x 的对象曾经支持接口Y, 他们会一直这样进行, 因为对象也许以后会改变。这为QueryInterface 动态机制发现接口提供证明。它总是可能发现关于对象支持的其它接口; 因而, 如果对象被获取作为事例'superclass', 它是可能通过在运行时间审查其它接口发现什么具体' subclass '。没有要求总对待一个通过最初被获取的对象作为型(接口的) 事例
2.1 操作
操作类似标准C 函数, 并且被定义为接口定义的一部分。如2. Objects下的词条所描述的那样，操作通过接口,总被间接地祈求。
2.2 请求
请求类似调用C 函数。但是, 如2. Objects下的词条所描述的那样，通过接口函数总被间接地调用。
2.3 消息
2.4 关于行为的语义学的规格
2.5 方法
方法在组分对象模型根本上是等值对C 成员作用。
2.6 状态
状态在组分对象模型包括一组被存放值从根本上说是等值于C 数据部分。
2.7 对象终身
在C , 对象被使用类的构建函数构建。有很多方法创造窗口对象, 但有一个共同的方法就是使用class factory object。一个class factory object代表一个具体类标识符, 由一个具体的OLE函数获得, 并且支持一个被命名为IclassFactory的接口。IClassFactory 接口包含一个名为CreateInstance的函数, 对于那个对象通过了期望的接口标识。IClassFactory::CreateInstance的描述 是C #39;s new的 逻辑等效。
在C , 对象通过在一个对象参数上调用删除操作被毁坏（最后导致对象自毁的那个函数要被调用）。释放窗口对象(从根本上称为自毁)的对应的函数是一个被称为Release.的函数。这个函数是IUnknown 接口的一部分, 并因此而存在在每个接口。但是, 调用Release不一定毁坏对象。在内部, 对象维护一部分存在于它的任何接口的参考。创造一个接口参数来增加参考数量 但是Release却会减少它的数量。当数量被减少到零, 对象释放它自己, 叫做它自己的自毁。
2.8 行为/状态编组
组分对象模型实施一个古典对象模型。
2.9 通信模型
对窗口对象编程的模型是同步的, 根据'轻量级远程过程调用' (轻量级是因为, 至少在当时, 调用不是真正远程的; 他们是全部做在一个机器上) 。更进一步的发展将允许轻量级RPC 由真正(分布的) RPC 代替。
2.10 事件
OLE通过一个叫advise sink 的对象发布处理通知，也就是说一个对象从一个源头收取通知。建议栏不仅处理通知为数据变动, 而且它一般被用来检查变化在其它复合文件对象上, 譬如当它被保存, 被关闭, 或改名的时候。
具体地, 一个对象是对被通报关于对以IAdviseSink 接口实施一个对象的具体数据对象变动感兴趣的的对象, 并且通过参数对这个接口对数据对象使用IDataObject 接口的DAdvise 作用(参见9.2 attributes之下的词条) 。每当它的数据改变, 数据对象在已经被通过了的IAdviseSink 接口调用OnDataChange 函数。(IAdviseSink 接口也包含其它通知函数, 譬如OnRename 、OnSave, 等。)
执行一个有IAdviseSink接口的对象 ，通过一个指向这个接口数据对象使用DAdvise函数IDataObject接口的指针（请看登陆口9.2下的属性）。只要它的数据变化，数据对象访问OnDataChange函数在IAdviseSink接口已经通过了。（IAdviseSink接口同样包含其它的告示函数，例如OnRename, OnSave,等)
3 绑定
绑定，其含义就是为了反映需求选择一种方法来执行，在要求中它被直接访问称作目标函数识别。对象链接和嵌入不会支持执行继承（请看登陆口8的下面。继承和委托），因此通过搜索类层次，这里没有分派。术语“绑定”在对象链接和嵌入的上下文中使用时，有一些不同的含义。涉及到使用一种称为在对象耦合中使用的对象。请看登陆口9.6的下面。
4 多态
对象模型的成分是多态的在某种意义上呈现出相同的要求，即能被送到任何合乎操作要求的接口；接口不需要涉及到相同种类的对象。然而，不像模型所需要的让对象都有一个专一的接口的“传统的”图表类型机械装置，接口在视窗上仍然是明显的。通过指针到Y接口，对象作为X不能被操作，即使对象同样拥有X接口。与之代替的是，使用者必须明白获得一个指针指向X接口。同样请看登陆口8下面。
5 封装
只有通过操作对象一个已经定义了的表面才能访问这个对象。而且，假设提及到一个接口，只有在那个接口操作可能使用，在开始获得的那个接口的参考后，其他接口的操作才可能使用。
6 统一性，等同性，拷贝
对象参考（指针）在窗口中不再被提及到对象本身，在C 中，被称为指针而不是对象的一个表面。事实上，这里没有明确的方式来识别一个明确的对象。（也就是，只可能获得对象的参考面，而不是整个对象）。假定一个接口作为指针，使用者仅仅只能进入包含在那个接口的成员函数。使用者永远不可能在整个对象上用一个指针。（因为这里没有直接使用者—“整个对象”的明显的概念），因此，这里没有直接的数据库入口，在C 中也没有“友员”的概念。通过IUnknown接口，使用者能够获得对象也同样支持的其它接口的指针，但是，这就意味着对同一个对象获得不同的指针（间接寻址）。每一个接口的指针在对象中都指向一个函数表，每一个函数表都仅仅包含明确接口的数据库。因为窗口对象的一个指针一直指向一个函数表，这一指针除了在C 编写语言的内部程序中能够同样被使用外，在C或者集成代码中也能被使用。
任何接口都和接口标识符或者IID相关联的，一个IID就是普遍的独一无二的标识符特别的情形，或者是UUID。普遍的独一无二的标识符也被认为是全局标识符，或者是GUID。GUIDs是128字节用定义GUID宏创建的。任何一个接口和对象类为了辨认使用一个全局标识符。在OLE SDK中所描述的美国微软公司将会为了满足开发者高级使用要求分派256位全局标识符一个或者更多的接收址。作为选择，一个拥有网卡的使用者能够驱动能够提供一个基于时刻的256位的GUIDs UUIDGEN.EXE工具，数据，和独一无二的包含在网卡里的数据[Bro94a]。
OLE为每一个标准的接口定义了IIDs连同每一个标准对象类定义了类标识符。当访问一个函数时，询问IID or CLSID即可，而事实上传递的是存在于过程空间的GUID结构的一个实例的参考（使用参考类型REFIID or REFCLSID)。比较GUID和IID或者是CLSID，评估他们的等同性，函数IsEqualGUID, IsEqualIID,和IsEqualCLSID都使用了。在C 中，'=='操作符能够用来代替超负荷。
查询接口函数必需一直依照明确的规则，在别的事
全文共9159字，剩余内容已隐藏，支付完成后下载完整资料
资料编号：[11740]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
