MTS组件的创建过程
lostall·COM集中营
一个MTS组件的创建过程包含以下几个步骤：
1。一个客户机为在MTS中注册的COM对象调用CreateObject
2。这个COM对象的注册表设置表明它是一个MTS对象，所以创建交给MTS
Executive(MTS执行者)
3。COM运行时间将MTS Executive加载到MTS代理中，MTS代理是mts.exe
4。MTS Executive加载COM DLL，并创建它的一个类厂实例。MTS还为这个类厂
生成一个包装程序
5。然后MTS Executive创建Object Context(对象环境)和Context Wrapper(环境包装)
对象Context Wrapper实现真正务器对象请求的界面。
6。MTS Executive将Context Wrapper对象指针返回客户机。注意此时客户机以为它
创建一个组件对象实例，实际上并没有创建对象。
7。当客户用得到的Context Wrapper对象指针调用组件的一个方法时，MTS
Executive这时才从Object Context获得类厂包装程序，并真正的创建一个组件对象实例
。客户通过MTS执行者来调用组件对象实例的接口指针。
8。MTS Executive调用COM组件的IObjectControl::Active函数以通知组件它已经被
激活了，组件可以在这个时侯获得它的Object Context指针。
9。客户方完成对组件的方法调用
10。组件对象根据方法调用的结果决定是提交还是中止，SetComplete or SetAbort
。
11。MTS Executive调用组件的IObjectControl::Deactivate，并从Object Wrapper中删除对
象，把对象放入对象池中。注意客户这时持有的组件接口指针并不为空，因为这个指
针是MTS Executive对象指针，当然没有释放了。
12。当客户再一次调用组件方法时，MTS Executive从对象池获得一个对象，然后
调用Active,
然后在新的组件对象上完成方法调用。
注意：由上可见，客户只有在调用了IObjectControl::Active之后，才标志真正得到
了COM组
件对象的指针，才能进行方法调用，在此之前都是假的。每次组件被激活都要重新得
到
IObjectContext指针，因为组件是从对象池取出来的，可能已经不是上一次用过的组件
了。
其他：
1。把组件加入到MTS时，可以选择让DLL在创建者进程中被? 。注意这个创建者
进程不是指远程的客户机程序，对WEB应用来说，MTS的客户机是IIS。
2。当调用一个软件包里的某个组件时，这个软件包内的所有DLL都将被加载。如
果其中有个DLL加载失败，则整个调用失败。
3。一个交给MTS管理的COM DLL可以只是个普通DLL，既它不继承
IObjectControl，在它的程序里也没有利用IObjectContext，尽管它可以通过
GetObjectContext()得到对象上下文。该组件仍然可以从MTS中获得比如JIT(既时激活)
的功能。而一个一开始就设计成MTS组件的DLL则会从IObjectControl继承，并得到对
象上下文指针，从而可以MTS的一些功能，比如事务管理等。
4。一个MTS组件如果想能调试的话，需要把这个组件所在的软件包的激活类型改
为库应用程序。
5。MTS中的连接点问题。
看看这样的调用顺序：
a.创建组件
b.Advise建立连接
c.调用组件某个方法
d.断绝连接，释放组件
跟踪发现，在调用Activate时连接点并未建立，而调用组件的方法一时连接点已经
建立了。这说明了在真正调用组件的方法时组件才被创建，所以b没有效果，所以当调
用Activate时不能使用连接点。当调用Activate结束后，再真正的建立起连接关系。执行
d释放组件时，如果组件具有池特性的话，组件并没有真的被释放，而是放到了对象池
中，下次再创建时就直接从池中取出。因为连接先于释放断掉，所以COM+调用
Deactivate()时也不能再利用连接点了。
6。COM+中每个软件包都是个应用程序，都是一个进程。可以设置是否在空闲时
也启动服务器进程，或者闲置几分钟就关闭服务器进程。要注意的是，启动一个服务
器进程是非常慢的。可以在Component Service中改变应用程序的这一设置，观察它的
运行状态，以及不断的创建组件来体验创建速度与服务器进程是否处于运行中的关系
。可以发现，若服务器进程在运行，则创建非常快，否则苈?br>
MTS组件的用法与COM+中的相关部分几乎是一样的，也许有一些细节不同。有
的书上说MTS2.0不支持对象池特性，MTS组件只能是Aparment型的。我没有试过，不
过COM+中如果组件要支持对象池的话，最好是Free或Neutral型，因为可能会有不同线
程类型的客户来使用它，这样效率较高。也有的书上说必须不能是Aparment型，但我
做的试验似乎并非如此。另外组件的创建过程也不一样，COM+中重写了COM基础设
施，包括CoCreateInstance。创建时COM+要先判断组件是否在COM+目录中注册，既是
否在Component Service中加入到一个Application中。如果注册了的话就启动Dllhost.exe
，并在它里面创建组件。MTS显然不会是这样，估计是在组件的AppID中设置了代理
为mts.exe，这才启动mts.exe作为代理。我觉得既然COM+已经出来了，MTS慢慢地也
就要退出历史舞台了，所以一切都应以COM+为准，MTS不管它也罢。
