一、原DCOM应用的结构：
我用DELPHI IDE的向导正常生成一个远程数据模块（RdbDBSvr），并在其中放入AdoDataset,Adoquery等数据集控件，建立接口方法，对外 Export方法接口，为客户端提供数据查询功能，该服务器采用独立运行的进程外服务模式。客户端则利用Dcomconnection来连接此远程数据模 块。总之是一个在DELPHI中创建的标准的C/S应用程序。
需要说明的是在设计RdbDBSvr时，为保持未来的代码重用，其中没有加入直接引用主窗体变量的引用，一些为了同 步线程设置的变量，我均将其放入了一个公用变量单元中。同时，同时我还尽量使用方法而不是直接使用Provider控件来为客户提供数据。事实证明，这种 设计减轻了DCOM向COM＋对象转换的复杂程度，而且应该说是相当方便的。
在客户端，我则通过公用变量引入远程数据模块的IAppServer接口，并在大部分的代码中引用这一公用变量并调用方法。也就是说，代码中没有加入对特定远程数据提供者的直接引用。
二、现在我们对服务器进行转换。
DCOM对象向COM＋对象转换前，我事实上运用了一个事实：就是DELPHI中无论是RemoteDataMoudel还是 MTSDataMoudle，都实现了IAppServer接口，并归入Borland DataSnap Applacation server Catlog中。因此无论是MTS对象，不是DCOM对象，在使用DcomConnection控制找远程数据提供者（Remote data provider）时，都会在列表中出现。
（一） 方法一
1、用DELPHI IDE创建一个新的Transactional data moudle，并将其放入一个单独的ActiveX DLL中。
2、打开原DCOM服务器中的远程数据模块，选择其中的全部控件，并将其拷贝到你新创建的MTS数据模块中，这样你原远程数据模块中所有控件的属性都被原样复制过来了。这一步是为下一步得用DCOM远程数据模块代码做了必要准备。
3、打开Type library编辑器，将原DCOM服务器的类型库加入到引用列表中，并将新的MTS数据模块的Parent interface改成DCOM服务器中远程数据模块实现的接口。然后刷新类型库。
4、此时你的MTS接口实现单元中，将会自动加入原DCOM远程数据模块的接口声明，并加入实现代码的框架。
TDemo = class(TMtsDataModule, IDemo)
private
{ Private declarations }
protected
class procedure UpdateRegistry(Register: Boolean; const ClassID, ProgID: string); override;
//以下是我的原远程数据模块的接口表，DELPHI自动将其复制到此单元中，并且生成了代码框架
procedure FindPersons(const Name, UnitNo: WideString;
out RDataset: OleVariant); safecall;
procedure GetFieldsName(const TBName: WideString; out FDNames: OleVariant);
safecall;
procedure GetLaborage(const PersonNo: WideString; out Records: OleVariant);
safecall;
procedure GetOtherInfo(const TableName, PersonNo: WideString;
……
public
{ Public declarations }
end;
……
procedure TDemo.FindPersons(const Name, UnitNo: WideString;
out RDataset: OleVariant);
begin
end;
……
5、现在，返回到原DCOM远程数据模块的实现单元，将其方法的具体实现代码复制到此单元。并将复制代码中的原 DCOM对象的类名替换成MTS对象的类名。同时注意：如果原DOCM远程数据模块引用了公用单元（如我自己引用的公用变量单元），将你还需将引用的公用 单元加入到USER列表中。
6、至此，你的与DCOM数据模块相同功能的MTS数据模块完全实现，请编译并注册该MTS对象。
三、客户端：
打开你的客户端应用程序源代码，并打开客户端数据模块中的DCOMConnection对象的ServerName 属性列表，此时，你将可以看到MTS对象出现在了列表中，选择它，并重新编译你的客户应用程序。如果你在客户端代码中没有加入对ServerName的引 用硬编码，则你将看到客户端不需任何改变就能够正常运行，而此时它引用的已不是DCOM对象而是运行在COM＋环境中的MTS对象。为证实这一点，你可以 运行DCOMCNFG。在本地计算机中“正在运行的进程”列表中，你将看到MTS正在欢快的旋转。
四、注意的问题：
1、上述方法是将原DCOM 应用服务器的类型库导入到MTS服务器中，再实现类型库中的方法。因此，如果你将新生成的MTS服务器组件发布到其他计算机上，并且没有将原DCOM应用 服务器拷贝并注册到该计算机上，将你的客户端将会收到“找不到类型库”的错误提示。解决这一问题的办法是将原DCOM应用服务器的*.tlb文件复制到该 计算机上，并用tregsvr.exe –t （server）.tlb 来在该计算机上注册类型库（server用你原服务器名代替）。另一种方法是，在编辑MTS对象类型库时，直接引用原服务器的TLB文件，而在分民MTS 对象将该TLB文件与MTS包随同分发。
2、以上转换事实上只能对比较简单的DCOM对象进行。如果你的DCOM代码中加入了与后端数据库相关的事务支持代 码，则你必须修改其代码，使之使用MTS提供的事务管理功能，这样才能充分发挥MTS资源管理、事务协调的强大功能，当然，如果你的DCOM对象没有使用 与MTS相容的线程模型，则你的修改工作量将会更大。
3、在转换成MTS对象后，你就能直接运用MTS基于角色的安全功能，对你的MTS的安全属性实施细微的控制，并且不用增加任何代码，当然如果你的代码中加入了原基于DCOM的特殊安全设定，你可能还要进行微调。但是，COM＋会兼容这些安全代码。
4、转换成MTS对象后，建议你重新确定你的COM默认发生的“最低安全限制”属性和你计算机的防火墙设置，以免它停止工作或“拒绝访问”。