下,它也应礼貌地
报告一条出错消息,比如“控件未找到”等等;一般不会莫名其妙地挂起或死机。
在这些情况下,我们的组件是在独立的可执行代码文件里实现的:DLL或EXE。若服务器对象在一个独立的可执行代码文件里实现,就需要由操作系统提供的一个标准方法,从而激活这些对象。当然,我们并不想在自己的代码里使用DLL或EXE的物理名称及位置,因为这些参数可能经常发生变化。
此时,我们想使用的是由操作系统维护的一些标识符。另外,我们的应用程序需要对服务器展示出来的服务进行的一个描述。下面这两个小节将分别讨论这两个
问题。
1. GUID和注册表
COM采用结构化的整数值(长度为128位)唯一性地标识
系统中注册的COM项目。这些数字的正式名称叫作GUID(Globally Unique IDentifier,全局唯一标识符),可由特殊的工具生成。此外,这些数字可以保证在“任何空间和时间”里独一无二,没有重复。在空间,是由于数字生成器会读取网卡的ID号码;在时间,是由于同时会用到系统的日期和时间。可用GUID标识COM类(此时叫作CLSID)或者COM接口(IID)。尽管名字不同,但基本概念与二进制结构都是相同的。GUID亦可在其他环境中使用,这里不再赘述。
GUID以及相关的信息都保存在Windows注册表中,或者说保存在“注册数据库”(Registration Database)中。这是一种分级式的数据库,内建于操作系统中,容纳了与系统软硬件配置有关的大量信息。对于COM,注册表会跟踪系统内安装的组件,比如它们的CLSID、实现它们的可执行文件的名字及位置以及其他大量细节。其中一个比较重要的细节是组件的ProgID;ProgID在概念上类似于GUID,因为它们都标识着一个COM组件。区别在于GUID是一个二进制的、通过算法生成的值。而ProgID则是由程序员定义的字串值。ProgID是随同一个CLSID分配的。
我们说一个COM组件已在系统内注册,最起码的一个条件就是它的CLSID和它的执行文件已存在于注册表中(ProgID通常也已就位)。在后面的例子里,我们主要任务就是注册与使用COM组件。
注册表的一项重要特点就是它作为客户和服务器对象之间的一个去耦层使用。利用
注册表内保存的一些信息,客户会激活服务器;其中一项信息是服务器执行模块的物理位置。若这个位置发生了变动,注册表内的信息就会相应地更新。但这个更新过程对于客户来说是“透明”或者看不见的。后者只需直接使用ProgID或CLSID即可。换句话说,注册表使服务器代码的位置透明成为了可能。随着DCOM(分布式COM)的引入,在本地机器上运行的一个服务器甚至可移到
网络中的一台远程机器,整个过程甚至不会引起客户对它的丝毫注意(大多数情况下如此)。
2. 类型库
由于COM具有动态链接的能力,同时由于客户和服务器代码可以分开独立发展,所以客户随时都要动态侦测由服务器展示出来的服务。这些服务是用“类型库”(Type Library)中一种二进制的、与语言无关的形式描述的(就象接口和方法签名)。它既可以是一个独立的文件(通常采用.TLB扩展名),也可以是链接到
执行程序内部的一种Win32资源。运行期间,客户会利用类型库的信息调用服务器中的函数。
我们可以写一个Microsoft Interface Definition Language(微软接口定义语言,MIDL)源文件,用MIDL编译器编译它,从而生成一个.TLB文件。MIDL语言的作用是对COM类、接口以及方法进行描述。它在名称、语法以及用途上都类似OMB/CORBA IDL。然而,Java程序员不必使用MIDL。后面还会讲到另一种不同的Microsoft工具,它能读入Java类文件,并能生成一个类型库。
3. COM:HRESULT中的函数返回代码
由服务器展示出来的COM函数会返回一个值,采用预先定义好的HRESULT类型