services|web|xml| check box | microsoft
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
servicedcomponentsor COM +, but 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, Cultur E=neutral, Publickeytoken=9c6052078b454cee "objecturi=" SCTrans.SCTransSQL.soap "/> <activated type=" S Ctrans.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:
<?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, Cultur E=neutral, Publickeytoken=9c6052078b454cee "objecturi=" SCTrans.SCTransSQL.soap "/> <activated type=" S Ctrans.sctranssql, Sctrans "/> </service> <lifetime leasetime=" 30S "renewoncalltime=" 30S "/> </appl Ication> </system.runtime.remoting></configuration>
The highlighted row added in the Web.config file changes the lifetime of the client-activated object in this IIS VRoot from 6 minutes to 30 seconds. If you put
wellknownElements of
SingleCallproperty is changed to
Singleton, the activation behavior is changed to route all incoming method calls to a component instead of activating a new component for each method call.
. NET Remoting (similar to the rest of the. NET Framework) supports garbage collection and does not support reference counting. This means that, in some cases, the unmanaged transaction COM + component behaves differently when using COM + Web services and DCOM. For a transaction method that is published through a single call to Wko, call the
SetCompleteor select AutoComplete (automatically deactivate the object when this method is returned by selecting the Component Method property page check box) is extremely important because the component cannot be freed before it is garbage collected. When using DCOM, a reference count usually causes the transaction to be committed or discarded when the component is disposed, even if the rule is ignored. When moving to a COM + WEB service environment, in a garbage collection environment, this is not guaranteed until the transaction times out. If you call
SetCompleteFailure, or configuring the method to fail automatically, proves that its own intermittent cannot commit the transaction because the transaction timed out before the component was garbage collected.
Matters needing attention in design
In COM + WEB services, if you select the
Uses SOAPcheck box (using the Component Services Administration tool), you will provide two different activation models on the IIS virtual root: Wko and CAO. Which model is better? Which one should the user use?
Wko a single invoke activation model seems rather cumbersome. Each method call needs to create a new component that completes the method call, and then sends the component to the memory collector. However, if you pay special attention to performance and can only use Wko to process your business, the buffered
servicedcomponentsor buffered unmanaged C + + components can greatly mitigate the process of a single invoke activation. When using a buffered component, WKO activation retrieves the object from the buffer pool, completes the call, and then returns the object to the buffer pool. The stateless nature of this protocol and the use of buffer pools increase the likelihood of extensibility. In a single invocation of an Wko object, the lifetime of the object is limited to the calling procedure.
CAO, on the other hand, provides the performance advantage of a single activation on the server and can continue to communicate with a single instance of a component. You can avoid the disadvantages of activation by making multiple-method calls to the server from the client. If the server component (
ServicedComponentor unmanaged C + + component) is buffered, the object is retrieved from the buffer pool, and then the object is returned to the buffer pool when the method call is complete. If the object is not buffered, the object lifetime depends on the lease life specified in the Web.config file, or is programmed by the component itself. The life cycle is important because the garbage collector frees up memory for the component until the lifetime expires. In a high-capacity CAO configuration, this can affect some design decisions of the developer.
Further
If you just want to publish or use a Web service that has COM + Web services applied, you can stop here. However, if you want to customize, extend, or simply understand the processes used, continue reading the following. The following information is not required to use this feature, but this information can be useful if you want to manually extend some features. COM + WEB Services is a simple wrapper that can be easily extended by developers or administrators through a fairly rich set of services provided by the. NET Remoting.
Server IIS Virtual root
To use this feature, a hidden hook was not added to the. NET Remoting, but COM + code was written to make the necessary configuration to publish the COM + endpoint as an IIS virtual root. On the server, this includes creating a physical directory for the server as a virtual root and generating Web.config files to access the components through Remoting. If the unmanaged component (Visual C + + or Visual Basic 6.0), the proxy metadata is also generated so that Remoting can access the component. If the Windows XP system directory is C:\Windows, the server configuration file and all the metadata that is generated are stored in the following directory tree:
C:\windows\system32\com\SoapVRoots\
VrootnameWhen a SOAP endpoint is published on a server, the following generated files are placed in this directory:
- web.config: VRoot's basic Remoting profile, which includes a number of options that can be added or edited by a developer or system administrator to adjust Remoting performance and security.
- Default.disco: If you are developing a managed-code client, you can use this file with Visual Studio. NET to generate a reference to a published Web service. This is especially useful if your business partners want to develop their own clients on an enterprise outreach network.
- Default.aspx: simple Microsoft asp.net page, you can publish each component as a hyperlink.
All of the above files are generated by default. If you want to remove some of these features, simply edit or delete the appropriate files. (However, if you delete the Web.config file, all SOAP publications from the IIS virtual root will stop.) ）
All generated metadata is placed in the following directories and in the GAC:
C:\windows\system32\com\SoapVRoots\
Vrootname\ Bin
In. NET Remoting, the bin directory is a very special location. When an HTTP request enters IIS, the assembly is searched for in this directory, so publishing in the bin directory is the only necessary step in many cases. However, when the SOAP endpoint is published, the resulting assembly is also put into the GAC, because the scope of the virtual root's assembly solution is limited to the bin directory and the GAC. If your code passes a reference from one virtual root to another on the same computer, the reference solution in the target virtual root will fail unless the assembly is in the GAC. If you are using the generated metadata for unmanaged visual Basic 6.0 or Visual C + + components, you can remove the generated assembly from the GAC if no reference is passed.
One particular point that this version of the. NET framework needs to pay attention to is that if you load an assembly and use the
System.ReflectionTo access the assembly file, the file is locked in memory until the process is finished. Reflection is used when dynamically generating the WSDL to generate the proxy, so you can lock the assembly file for the active IIS virtual root that will be accessed by the client process. This is not a problem in the operating environment, but it should be borne in mind for the developers who are constantly changing the components.
If you are working with a COM + Web service
servicedcomponents, you also need to place the assembly in the GAC, unless you initially put the assembly in the bin directory and run the Regsvcs.exe for the assembly in that directory. If you have already loaded the Microsoft. NET Framework SDK, you can use the Gacutil.exe command-line utility to
ServicedComponentinto the GAC; if you have windows. NET Server built into the. NET Framework installed, or if you loaded the. NET Framework for redistribution on a Windows XP computer, you can use the Microsoft. NET Framework to configure the user interface (available from
Administrative ToolsMenu access, add an assembly to the GAC.
Also, when you are using Windows XP or Windows. NET Server, make sure that IIS is installed and configured to provide ASP.net application services. These settings are required to provide the dynamic content necessary to use SOAP.
Generated agent assembly Cache
For unmanaged COM + components that are to be published through. NET Remoting as SOAP endpoints, you need to build agents that allow unmanaged components to be used in the. NET Framework. This can be accomplished by programming the same steps as Tlbimp.exe, which is used to convert an unmanaged COM + type library into a. NET Framework SDK tool for the proxy metadata assembly. However, to successfully activate a client through SOAP, the client and server computers must share a signature metadata agent with the same enhanced name. Therefore, when you build a managed proxy assembly for an unmanaged COM + component, the enhanced name keyword is also generated and used to sign the proxy assembly.
The enhanced name keyword can only be generated once, and there is no notion of a strengthened name keyword in an unmanaged COM + component. That is, if you generate the agent multiple times, you can create different enhanced name keywords. This creates a different managed identity for the same unmanaged COM + component, and to avoid this, write all the proxy assemblies that are generated for the unmanaged COM + component into the following Soapcache directory:
C:\windows\system32\com\SoapCache\
componentdirectory\
Proxymetdata.dll
which
componentdirectoryThe format should be:
Atltrans.dll_40960_2001_6_27_15_4_16
The directory name is created from the file name, file size, and date and time of the last compilation. This scenario is based on the assumption that if you recompile an unmanaged COM + component, you need to generate a new proxy. This is based on the assumption that if you want to make changes to your code, you can only recompile the code in the operating environment.
Because the Soapcache directory exists, unmanaged components located in the cache are reused if different virtual roots of the same computer publish the same unmanaged component instead of the build agent assembly. This is to ensure that the component's enhanced name signature (and the resulting identity) can be shared through the virtual root.
If a SOAP-enabled unmanaged COM + component is exported as a server application and then imported to another server, the cached proxy metadata is taken together so that different servers can share the same managed identity of the same unmanaged assembly. In addition, if a user wants to generate or write and sign his or her own agent, it simply puts the metadata into the appropriate cache directory, which is used when a SOAP publication occurs on the server. The basic rule applied here is to avoid unnecessarily spreading the signed proxy for the same unmanaged component, if there is an alternative file in the cache, the assembly is not generated.
Client Configuration
Client configuration is also required, and the simplest scenario (at least from the user's workload) is the first program example given in this article:
Set soapobj = GetObject ("soap:wsdl=http://www.xmethods.net/sd/temperatureservice.wsdl") WScript.Echo "Fairbanks temperature =" & Soapobj.gettemp ("99707")
When a WSDL moniker is processed, the following steps are raised:
- Check to see if there are any agents that were previously generated for this URL. If it exists, it is used again. (Skip to step 4.) ）
- If it does not exist, the WSDL is retrieved from the URL and the C # Agent is generated. This is essentially the same logic used by the Soapsuds.exe command-line utility (included with the. NET framework SDK).
- C # programs are compiled into DLLs and named with names that match URLs (illegal characters are converted to acceptable characters in the file name).
- The generated proxy is then used to communicate with the. NET Remoting (WKO) to the remote server specified in the WSDL.
These agents are generated and saved in the following folder:
C:\windows\system32\com\SoapAssembly in the case of client activation, the client Agent imports the required exported COM + applications on the client computer. Export/import of this application will bring the signed metadata assembly that is required for client activation from the server. The import process also generates a configuration file and puts it into the soapassembly directory. Typically, the client configuration file takes the following format:
<configuration> <system.runtime.remoting> <application> <client url= "Http://MyServer/VB6Soap" > <activated type= "vb6soapsoaplib.calcclass, vb6soapsoaplib"/> </client> </application> </sy Stem.runtime.remoting></configuration>
The COM + Web service reads this profile before activating the component so that it can potentially change the activation model on the client computer by modifying or replacing this profile.
It 's all just beginning .
COM + WEB services are designed to simplify the process of combining. NET Remoting and COM + services (both Windows XP and the windows. NET Server family contain this service). It's just to simplify common tasks, not all of the options or the various situations that users might encounter. Similar to creating programs in Visual Studio. NET using wizards, some advanced tasks are left to the user to resolve themselves. In order for the user to expand, the resulting items are rarely completely deleted. In addition, the XML class is used to edit the generated configuration file, and if a configuration file already exists, the node is added or removed from the file to reflect changes from the Component Services Administration tool or the Microsoft COM + management SDK. COM + WEB services are designed to make it easy for users to extend or customize what has been generated.
In summary, COM + WEB services are existing Visual Basic and Visual C + + components, as well as newly managed
servicedcomponents, providing a simple way to implement XML Web Services and SOAP
