1?span lang=EN-US>DCOM
COM的进E透明Ҏ表现在lg对象和客L序即可以拥有各自的进E空_也可以共享同一个进E空_COM负责把客L调用正确传到lg对象中,q保证参C递的正确性。组件对象和客户代码不必考虑调用传递的l节Q只要按照一般的函数调用的方式实现即可。如果进一步拓展进E透明Ҏ,考虑lg对象与客L序运行在不同计算Z的情形,把进E透明性拓展ؓ位置透明性,形成分布式组件对象模型,UCؓDCOM?span lang=EN-US>
DCOM?span lang=EN-US>COM的扩展,它可以支持不同计机上组件对象与客户E序之间或者组件对象之间的怺通信Q这些计机可以在局域网内、广域网上?span lang=EN-US> Internet上。对于客L序而言Q组件程序所处的位置是透明的,我们不必~写M处理q程调用的代码,因此Q?span lang=EN-US>DCOM也是COM的无~扩展?span lang=EN-US> DCOM处理了底层网l协议的所有细节?span lang=EN-US>
2、从COM转向DCOM
q程内组件与客户E序之间的通信q程比较单。本地进E外lg与客L序之间的通信q不是直接进行的Q而是用到了操作系l支持的一些跨q程通信Ҏ?span lang=EN-US>
DCOM只是单地把本地跨q程通信用一个网l协议传输过E来代替Q只是中间数据传递的路线更长一些。当Ӟ|络通信比单机系l环境下的跨q程通信要脆弱得多,所以ؓ了保证协作过E的可靠性以及程序对异常事g的应变能力,客户E序和组件程序需要考虑更多的细节?span lang=EN-US>
3?span lang=EN-US>DCOM对象的定?span lang=EN-US>
客户E序调用COM库的基础创徏函数Q比?span lang=EN-US>CoGetClassObjectQ创E组件对象需要知道远E机器名和对?span lang=EN-US>CLSID?span lang=EN-US>
有两U方法可以得到远E对象的机器名信息:一是在创徏函数的参C指定COSERVERINFOl构Q二是?span lang=EN-US>DCOM配置工具指定q程机器名?span lang=EN-US>
COM库的创徏函数得到了远E对象的位置信息后,再把对象创徏的Q务交l?span lang=EN-US>SCMQ由SCM通过RPC与远E机器进行通信?span lang=EN-US>SCMQ程序名?span lang=EN-US> Rpcss.exeQ也?span lang=EN-US>COM库的一部分Q但它是一个单独的q程?span lang=EN-US>SCM负责创徏新的COM对象Q也负责建立lg对象与客L序之间的q接。如果要创徏q程对象Q它会通过RPC调用q程机器上的SCMQ由q程机器上的SCM启动lgq程Qƈ创徏lg对象Q然后返回到客户机器?span lang=EN-US>
当然Q远E组件对象被创徏之后Q它在返回到客户机器的途中Q还要经q列集和散集的处理,包括创徏代理对象和装载存根代码等Q这些处理与本地q程外组件对象的处理完全一致。一旦组件对象被创徏完成之后Q客户与lg之间的通信不再l过SCMQ而是直接通过代理对象和存根对象以?span lang=EN-US>COM库提供的底层传输机制来完成?span lang=EN-US>
4、列集与散集
列集与散集是实现COMlg对象跨进E特性的关键技术,它包括标准列集法和自定义列集法。同L技术也适用?span lang=EN-US>DCOMlg对象与客L序之间的通信Q两者的区别在于列集数据包的传递方式有所不同Q对于本地组件对象?span lang=EN-US>LPC传递,而对?span lang=EN-US>DCOMlg对象使用RPC传递?span lang=EN-US>
DCOM提供了一套复杂的列集和散集机Ӟ它徏立在RPC的基上。由?span lang=EN-US>RPC被定义ؓDCEQ分布式计算pȝQ标准的一部分Q?span lang=EN-US>DCE RPC定义了所有常用数据类型的数据表达方式Q即|络数据表示法(NDRQ?span lang=EN-US>network data representationQ。ؓ了存根代码和代理对象能够正地对参数和q回l果q行列集和散集,它们应该使用一致的数据表示?span lang=EN-US>NDRQ以便在不同的操作系l环境下也能够远E调用?span lang=EN-US>
5、对?span lang=EN-US>RPC
DCOM协议也被UCؓ对象RPCQ?span lang=EN-US>ORPCQ?span lang=EN-US>object remote procedure callQ,它徏立在DCE RPC协议的基上,可用于各U基于组件的分布式系l?span lang=EN-US>ORPC建立了一套面向对象的q程调用规范Q指定了如何在网l上q行调用、对对象的引用如何表C和如何l护?span lang=EN-US>ORPC协议已经被作?span lang=EN-US>Internet草案递交?span lang=EN-US>IETFQ?span lang=EN-US>Internet Engineering Task Force Q?span lang=EN-US> Internet 工程部)?span lang=EN-US>
?span lang=EN-US>Internet?span lang=EN-US>Intranet|络环境下,ORPC仍用标准的RPC数据包,附加上专用于DCOM的一些信息――接口指针标识符Q?span lang=EN-US>IPIDQ?span lang=EN-US>interface point identifierQ、版本信息和扩展信息――作用和q回的附加参数进行传送,其中IPID表示调用被处理的q程机器上特定对象的特定接口?span lang=EN-US> DCOM客户E序必须周期性地“pinging”q程机器上的对象Q以便保证客户与对象一直处于连接状态?span lang=EN-US>
6?span lang=EN-US>DCOMҎ?span lang=EN-US>
DCOM可以作ؓ分布式应用系l的基本架构Q客L序与DCOMlg对象之间形成了客P服务器关p,q一步可构成多层软g模型?span lang=EN-US>DCOMlghCOM lg的一些基本特性,包括重用性、语a无关性等。而位|透明??span lang=EN-US>DCOM的一个基本特性?span lang=EN-US>DCOM的其他特性如下:
Q?span lang=EN-US>1Q可伸羃性。一斚wQ?span lang=EN-US>DCOM利用操作pȝ本n的可伸羃性;另一斚wQ?span lang=EN-US>DCOM提供了灵zȝ配置ҎQ允怸同的lg对象允许在不同的服务器上Q?span lang=EN-US>DCOM的位|透明性保证了q种变化可以不必修改lg源程序?span lang=EN-US>
Q?span lang=EN-US>2Q可配置性。安装和理是分布式软gpȝ的两个重要环节?span lang=EN-US>DCOM提供了一个图形界面的配置工具E序Q?span lang=EN-US>DCOMCNFG.EXEQ,可客户E序和组件程序在不改变代码的情况下适应不同的网l环境?span lang=EN-US>
Q?span lang=EN-US>3Q安全性?span lang=EN-US>DCOM使用?span lang=EN-US>Windows NT提供的可扩展安全性框Ӟ在非NTq_上实现的DCOM也包括了一个与NT兼容的安全提供器?span lang=EN-US>DCOM实现的安全性分问安全性和Ȁzd全性,讉K安全性指定那些用户可以调用组件对象,Ȁ发安全性指定哪些用户可以在一个新q程中创建新的对象?span lang=EN-US>
Q?span lang=EN-US>4Q协议无x?span lang=EN-US>
Q?span lang=EN-US>5Q^台独立?span lang=EN-US>
7、对象激z?span lang=EN-US>
Ȁz(activationQ一个组件对象包括两U情形:一是创建新的组件对象,二是建立已有lg对象与客户之间的q接?span lang=EN-US>
COM扩展?span lang=EN-US>DCOM之后Q远E对象的创徏q程有所不同。ؓ了标识一个远E对象,仅仅提供一?span lang=EN-US>128位的GUIDq不够,q必L供远E对象所在的机器名,也称E服务器?#8220;RemoteServerName”?span lang=EN-US>
Q?span lang=EN-US>1Q创?span lang=EN-US>DCOMlgҎ一
通过DCOM配置工具指定q程服务器名Q这U方式?span lang=EN-US>DCOMlgh位置透明性。在Windowspȝq_上,q程服务器名?span lang=EN-US>RemoteServerNameD保存在系l注册表HKEY_CLASSES_ROOT\APPID键下?span lang=EN-US>
?span lang=EN-US>CLSID?span lang=EN-US>AppID键的l构可以看出Q每?span lang=EN-US>AppID可用于多个组件对象,通常它代表了由多?span lang=EN-US>CLSID׃n的进E,该进E中的所有对象共享同L配置信息Q包括远E服务器名以及安全信息。在DCOM中引?span lang=EN-US>AppID概念可以避免太多的注册表关键字?span lang=EN-US>
Q?span lang=EN-US>2Q创?span lang=EN-US>DCOMlgҎ?span lang=EN-US>
用第一U方法ƈ不是总能满应用的要求,有些应用要求在程序运行过E中控制要连接的服务器,比如多h游戏E序、网l远E管理工L。对于这L应用Q?span lang=EN-US>DCOM允许在创建函C指定q程服务器名字。可以指定远E服务器名字的创建函敎ͼCoCreateInstanceEx?span lang=EN-US> CoGetClassObject?span lang=EN-US>CoGetInstanceFromFile?span lang=EN-US>CoGetInstanceFromeIStorage?span lang=EN-US>
在程序中指定服务器名字的另外一个功能是实现分布式应用系l的动态负载^衡。目?span lang=EN-US>DCOMq很难以实现自动负蝲qҎ,但我们可以徏立一个分z服务组件对象,所有的客户都创建指定机器上的分z服务组件对象,由它创徏另一个真正实现应用功能的q程对象Q在把此q程对象q回l客L序,以后客户E序不再使用分派服务lg对象Q而直接调用远E对象。而分z服务组件对象可以根据当前的负蝲状态,从一l服务器中选择负蝲最ȝ服务器作为目标,创徏q程对象?span lang=EN-US>
8、远E创E内lgQ代理进E(surrogateQ?span lang=EN-US>
Zq程q行q程内组件即DLLlgQ要求在q程机器上有代理q程Q?span lang=EN-US>surrogate processQ。除了可以远E启动进E内lg之外Q代理进E还提供了下面的Ҏ:
l q程内组件程序中的严重错误只影响代理q程Q不会客户q程崩溃Q?span lang=EN-US>
l 一个代理进E可以同时ؓ多个客户提供服务Q?span lang=EN-US>
l 客户可以保护自己避免靠不住的lgE序代码Q只讉KlgE序提供的服务;
l 在代理进E中q行q程内服务可?span lang=EN-US>DLL享有代理q程的安全性?span lang=EN-US>
Windows引进了缺省的代理q程Q以及编写自定义代理q程的协议规范。缺省实现的代理q程是一个合线E模型、伪COM服务E序。当多个DLLlg被装入到单个代理q程Ӟ该进E按照注册表中指定的U程模型Ҏ?span lang=EN-US>DLLlg对象q行实例化。如果一?span lang=EN-US>DLLlg对象支持两种U程模型Q则COM选择自由U程模型?span lang=EN-US>COM卛_以控?span lang=EN-US>DLLlgE序的卸载,也可以终止代理进E?span lang=EN-US>
如果一个进E内lg满下列条gQ则它将被装入代理进E:
l pȝ注册表中Q在lg对象?span lang=EN-US>CLSID关键字下必须要指?span lang=EN-US>AppID|以及对应?span lang=EN-US>AppID关键字;
l 客户E序在创建对象实例时Q必设|?span lang=EN-US>CLSTX_LOCAL_SERVER标志Q?span lang=EN-US>
l lg对象?span lang=EN-US>CLSID关键字下不指?span lang=EN-US>LocalServer32?span lang=EN-US>LocalServer?span lang=EN-US>LocalService|
l lg对象?span lang=EN-US>CLSID关键字包?span lang=EN-US>InProvServer32子键Q?span lang=EN-US>
l ?span lang=EN-US>InProcServer32子键中指定的DLL文g必须存在Q?span lang=EN-US>
l lg对象对应?span lang=EN-US>AppID键下指定DllSurrogate倹{?span lang=EN-US>
如果lg对象?span lang=EN-US>CLSID键下?span lang=EN-US>LocalServer?span lang=EN-US>LocalServer32?span lang=EN-US>LocalService值指CZEXE的存在,?span lang=EN-US>EXEE序被优先执行Q?span lang=EN-US>COM不再启动代理E序?span lang=EN-US>
9、利用名字对象(monikerQ连接到q程对象实例
通常COM对象实例是不可相互替代到Q或者说不可怺交换的。它通过自己Ҏ的状态区别于同一cȝ其他对象实例?span lang=EN-US>
在第8章中介绍?span lang=EN-US>COM命名和绑定机制对于远E对象同样适用?span lang=EN-US>
10、连接管理——远E对象生存期的控?span lang=EN-US>
COM控制对象的生存期最基本的机制是引用计数Q利?span lang=EN-US>IUnknown?span lang=EN-US>AddRef?span lang=EN-US>Release成员函数控制对象的生存期?span lang=EN-US>DCOM优化了远E对象的AddRef?span lang=EN-US>Release的调用。优化过E用了OXIDQ?span lang=EN-US>object exporter identifier Q对象管理标识符Q对象?span lang=EN-US>OXID是一?span lang=EN-US>64位|通过OXID可以?span lang=EN-US>RPC串绑定调用到它们的目?span lang=EN-US>IPID。但是,在执行调用之前,调用q程必须?span lang=EN-US> OXID转译成ؓ底层RPC可以解释的一l绑定?span lang=EN-US>
在每台支?span lang=EN-US>DCOM的机器上Q都有一个被UCؓOXID解析器(OXID ResolverQ的服务Q它负责向客h供用于连接到OXID?span lang=EN-US>RPC串绑定信息,也负责接收远E发来的“pinging”信息?span lang=EN-US>OXID解析器之间通过RPCq行通信Q它实现?span lang=EN-US>RPC接口IOXIDResolverQ不?span lang=EN-US>COM接口Q?span lang=EN-US>
11、连接管理—?span lang=EN-US>pinging机制
如果不考虑客户q程可能会非正常l止Q则利用q程引用计数控制对象生存期已l够了。ؓ了检客L序是否非正常l止Q?span lang=EN-US>DCOM提供了一U简单的Ҏ “pinging”。在现在实现?span lang=EN-US>DCOM版本中,pingPeriod=2Q分Q且numPingsToTimeOut=3Q这些g能被改变?span lang=EN-US>
12、连接管理——连接点理
许多实际的分布式应用都需要在两个对象之间q行双向通信。由?span lang=EN-US>DCOM是对COM的无~扩展,在第6章中介绍?span lang=EN-US>COM提供的连接点机制同样适用于远E对象的情Ş?span lang=EN-US>
13、连接管理——连接传?span lang=EN-US>
用分z服务组件对象来实现分布式应用的负蝲qҎ实际上用到了连接传递特性?span lang=EN-US>
q接传递不{于q程对象创徏的传递,DCOM不支持位|透明方式下对象创建的传递过E,但可以利用连接传递特性,通过E序控制服务器名字的方式实现q程对象创徏的传递?span lang=EN-US>
14、ƈ发管理——线E模?span lang=EN-US>
COM本nq没有线E模型,可以认ؓCOM借用?span lang=EN-US>Windows操作pȝ提供的线E模型,Win32E序设计模型把线E分?span lang=EN-US>UIU程和辅助线E,相对应地Q?span lang=EN-US>COM把线E分成套间线E和自由U程。套间线E?span lang=EN-US>CoInitialize API函数执行COM库的初始化,COM在套间线E内部创Z一个隐藏的H口Q此H口的窗口过E函数负责把客户对套间中的组件对象的调用发送到正确的成员函C?span lang=EN-US>
15、ƈ发管理——消息过滤器
COM?span lang=EN-US>DCOM的线E模型我们了解C客户E序与组件对象调用过E中的线E切换,但调用可能会dE序Q甚至得客L序无法正常进行。ؓ此,COM提供了消息过滤机Ӟ它既可用于客L序,也可用于lgE序Q允许它们对于入调用和出调用有所选择?span lang=EN-US>
COM把调用分Zc:W一U是同步调用Q这是最常见的调用类型,客户调用lg对象Q一直等到对象执行完所有功能后再返回;W二U是异步调用Q客戯用组件对象,但不{到对象执行完功能就马上q回Q以后对象通过出接口通知客户E序Q这也就是我们在W?span lang=EN-US>6章介l的可连接对象机ӞW三Uؓ输入同步调用Q被调用对象必须在放弃控制之前返回,以便保证用户界面不受影响Q也是_在调用执行过E中Q对象不能调用Q何可能会q入消息循环的函数?span lang=EN-US>
16?span lang=EN-US>DCOM安全模型
DCOM安全性徏立在底层安全提供器基上,有些操作pȝ可以支持多个安全提供器,DCOM?span lang=EN-US>RPC也可以同时支持多个安全提供器。所有的安全提供器有一个共同点Q它们提供了一U表C安全角Ԍ一般ؓ用户账号Q的Ҏ、一U鉴定安全角Ԍ一般通过口o或私有钥匙)的方法,以及理安全角色和其鉴定数据的一套机制?span lang=EN-US>
17?span lang=EN-US>DCOM安全模型——安全性策?span lang=EN-US>
Q?span lang=EN-US>1Q访问安全性和Ȁ发安全性?span lang=EN-US>
Q?span lang=EN-US>2Q对象的安全w䆾?span lang=EN-US>
Q?span lang=EN-US>3Q保护数据?span lang=EN-US>
Q?span lang=EN-US>4Q鉴定别?span lang=EN-US>
Q?span lang=EN-US>5Q模仿别?span lang=EN-US>
18?span lang=EN-US>DCOM安全模型——安全性配|?span lang=EN-US>
DCOM提供了多U保护应用程序的ҎQ一斚wQ?span lang=EN-US>DCOM可以强制使用安全性而不用Q何对象或对象的客L序做M工作Q对象的安全性设|可以在外部配置q且DCOM会自动强制用。另一斚wQ?span lang=EN-US>DCOM把它完整的安全性结构暴露给开发者,因而客户和对象都可以通过E序控制其安全策略?span lang=EN-US>

]]>