COM + Web service: Route to XML Web Services (3) (Microsoft China) through the check box)

Limitations and differences between SOAP and DCOM
One of the purposes of. NET Remoting is to provide a rich distributed environment in which developers can combine and match the serialization protocol (formatter) and network protocol (channel .. The COM + Web service in NET Framework 1.0 only supports one formatting program (SOAP) and one channel (HTTP ). This does not mean that other channels and formatting programs cannot use ServicedComponents or COM +, but that they are not automatically configured to provide client and server endpoints for these standby channels and formatting programs.
Currently, a large number of COM + components have been compiled in various languages. If you can use COM + Web services to enable all these components as Web services, that would be great. However, just like using the. NET Framework version 1.0, not all existing COM components can use the COM + Web service. Although most existing components with the type library can work normally, this version does not support some components, such as Windows Script Component (WSC) components. Some complex types of libraries (whose interfaces have multiple inheritance levels or depend on multiple types of libraries) may not work properly. In addition, due to the limitations of type library conversion, only the default interfaces in the type library can be used as Web services.
COM + Web services are not a complete solution for all existing unmanaged COM + components. Most of the existing unmanaged COM + components are written in multiple programming languages. Since it is impossible to test all possible types of libraries (generated by various compilers that support COM + ), therefore, some unmanaged COM + components cannot be correctly published using COM + Web services. One of the purposes of COM + Web services is to minimize the time and effort required to make such an assessment. By releasing an unmanaged COM + component as a COM + Web service, developers can quickly determine whether it can be used as a Web service. If problems occur, you can use several alternative methods to handle existing unmanaged components. These alternatives include writing hosted or unmanaged wrappers that provide compatible interfaces that can be published as Web services. In most cases, writing such a package requires much less work than writing a new component. This minimizes the development and testing required to apply existing applications to XML Web Services.
When using an unmanaged (Visual Basic 6.0 or Visual C ++) server, the sooner you bind a hosted client application and SOAP, the better you can work. In some cases, the generated metadata may not work properly if it is used as a remote agent for a later binding across computers.