services|web|xml|复选框
编译并运行此 Visual Basic .NET 应用程序，将产生与前面两个 VBScript CAO 示例相同的输出内容。
因为服务器应用程序将组件发布为 CAO 和 WKO 两种形式，所以由远程客户端选择激活方法。虽然可能只对学术研究有意义，但是单一客户端计算机确实可以使用同一组件的两种远程激活方法，访问远程服务器上同一个 SOAP 发布的虚拟根。
SOAP 与 DCOM 的局限性和区别
.NET Remoting 的目的之一是提供丰富的分布式环境，使开发人员能够在此环境中对序列化协议（格式化程序）和网络协议（频道）进行组合与匹配。.NET 框架 1.0 版本中的 COM+ Web 服务仅支持一种格式化程序 (SOAP) 和一种频道 (HTTP)。这并不是说其他频道和格式化程序不能使用 ServicedComponents 或 COM+，而是说没有自动配置为这些备用频道和格式化程序提供客户端和服务器端点。
目前已经有用各种语言编写的大量 COM+ 组件。如果可以使用 COM+ Web 服务将所有这些组件启用为 Web 服务，那就太好了。但正如使用 .NET 框架 1.0 版本一样，并非所有现有的 COM 组件都可以使用 COM+ Web 服务。虽然多数具备类型库的现有组件可以正常工作，但是此版本不支持某些组件，例如 Windows 脚本组件 (WSC) 组件。某些复杂的类型库（其接口具有多重继承级别，或依赖于多个类型库）可能无法正常工作。此外，由于类型库转换的局限性，只有类型库中默认的接口才可以作为 Web 服务。
COM+ Web 服务并不是适用于所有现有非托管 COM+ 组件的完整解决方案。现有非托管 COM+ 组件中有一大部分是使用多种编程语言编写而成的，由于不可能测试所有可能的类型库（由支持 COM+ 的各种编译器生成），因此某些非托管 COM+ 组件不能使用 COM+ Web 服务正确发布。COM+ Web 服务的目的之一就是最大程度减少做出这种评估所需的时间和精力。只需将非托管 COM+ 组件发布为 COM+ Web 服务，开发人员就可以迅速判断是否可以将其用作 Web 服务。如果遇到问题，则可以通过若干替代方法来处理现有的非托管组件。这些替代方法包括编写托管或非托管的包装程序，这些包装程序提供的兼容接口可以发布为 Web 服务。多数情况下，编写这样的包装程序的工作量比重新编写整个组件要少得多。这就尽可能减少了将现有的应用程序应用为 XML Web Services 所需的开发和测试工作。
使用非托管（Visual Basic 6.0 或 Visual C++）服务器时，通常越早绑定托管客户端应用程序和 SOAP，越能更好地工作。在某些情况下，如果将生成的元数据用作后期绑定的跨计算机远程代理程序，它可能无法正常工作。
在通过 HTTP 使用 SOAP 格式化程序的情况下，仍然可以使用许多选项（取决于目标部署环境）。COM+ Web 服务为服务器和 CAO 客户端配置生成基于 XML 的远程配置文件。（WKO 激活的 URL 引用已嵌入生成的客户端代理，因此不需要配置文件。）COM+ Web 服务生成直观的功能性配置文件，可由用户自定义以满足任何通过 HTTP 的直接 SOAP 通信所不能满足的需求。可进行自定义的区域包括用户身份验证，如下例所示：
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.runtime.remoting>
<application>
<service>
<wellknown mode="SingleCall" type="SCTrans.SCTransSQL, SCTrans,
Version=0.0.0.0, Culture=neutral,
PublicKeyToken=9c6052078b454cee"
objectUri="SCTrans.SCTransSQL.soap" />
<activated type="SCTrans.SCTransSQL, SCTrans" />
</service>
</application>
</system.runtime.remoting>
<identity impersonate="true" />
</configuration>
上例中添加的突出显示的行可以在激活 COM+ 组件（通过 SOAP 调用）时使用用户的身份标识。（默认情况下，IIS 虚拟根使用标准的 IIS 身份验证。）这样在使用 SOAP 时可以实现 COM+ 的分区（一种 COM+ Windows .NET Server 功能），从而可根据用户的身份标识来实际调用不同的组件。
另一个可以自定义的区域包括客户端激活对象的生存期管理，如下例所示：