COM+ Web 服务：通过复选框路由到 XML Web Services(3) （微软中国）

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，越能更好地工作。在某些情况下，如果将生成的元数据用作后期绑定的跨计算机远程代理程序，它可能无法正常工作。