The services|web|xml| check box compiles and runs this Visual Basic. NET application, producing the same output as the previous two VBScript samples.
Because the server application publishes components as CAO and Wko two forms, the remote client chooses the activation method. Although it may only make sense for academic research, a single client computer can indeed use two remote activation methods of the same component to access the virtual root of the same SOAP publication on a remote server.
The limitations and differences between SOAP and DCOM
One of the purposes of the. NET Remoting is to provide a rich, distributed environment in which developers can combine and match serialization protocols (formatters) and network protocols (channels) in this environment. COM + WEB Services in the. NET Framework version 1.0 support only one formatter (SOAP) and a channel (HTTP). This is not to say that other channels and formatters cannot use servicedcomponents or COM +, but that they are not automatically configured to provide client and server endpoints for these standby channels and formatters.
A large number of COM + components have been written in various languages today. If you can use COM + Web services to enable all of these components to be Web services, that would be great. However, as with the. NET Framework version 1.0, not all existing COM components can use COM + Web services. Although most existing components with type libraries work correctly, some components, such as Windows scripting Component (WSC) components, are not supported in this release. Some complex type libraries whose interfaces have multiple inheritance levels, or that depend on multiple type libraries, may not work correctly. In addition, because of the limitations of type library conversions, only the default interfaces in the type library can serve as WEB services.
COM + WEB Services is not a complete solution for all existing unmanaged COM + components. A large portion of the existing unmanaged COM + components is written in a variety of programming languages, and because it is not possible to test all possible type libraries (generated by various compilers that support COM +), some unmanaged COM + components cannot be published correctly 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 simply publishing an unmanaged COM + component as a COM + Web service, the developer can quickly determine whether it can be used as a Web service. If you are experiencing problems, you can work with existing unmanaged components in a number of alternative ways. These workarounds include writing managed or unmanaged wrappers that provide a compatible interface that can be published as a WEB service. In most cases, writing such a wrapper is much less work than rewriting the entire component. This minimizes the development and testing effort required to apply existing applications as XML Web Services.
When you use unmanaged (Visual Basic 6.0 or Visual C + +) servers, the sooner you bind managed client applications and SOAP, the better you can work. In some cases, the generated metadata may not work correctly if it is used as a late-bound, cross-computer remote agent.
With the SOAP formatter used via HTTP, many options are still available (depending on the target deployment environment). COM + WEB Services generates an xml-based remote configuration file for server and CAO client configuration. (Wko-activated URLs refer to client proxies that have been embedded in the build, so no configuration files are required.) COM + WEB Services generates intuitive, functional profiles that can be customized by the user to meet any requirements that are not met by direct SOAP traffic over HTTP. The areas that can be customized include user authentication, as shown in the following example:
<?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>
The highlighted row added in the previous example can use the user's identity when activating a COM + component (called Via SOAP). (By default, the IIS virtual root uses standard IIS authentication.) This enables the COM + partition (a COM + Windows. NET Server feature) to be implemented while using SOAP so that different components can actually be invoked based on the identity of the user.
Another area that can be customized includes the lifetime management of client-activated objects, as shown in the following example:
