services|web|xml| check box Another area that can be customized includes the lifetime management of client-activated objects, as 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>
<lifetime leasetime= "30S" renewoncalltime= "30S"/>
</application>
</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 change the SingleCall property of the wellknown element to Singleton, the activation behavior changes 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 transactional method that is published by Wko a single call, it is extremely important to invoke SetComplete or select automatic completion (automatically deactivate this object when returning this method by selecting the Component Method property page) 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 the call to SetComplete fails or the method is configured to fail automatically, it 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 SOAP check box (using the Component Services Administration tool), two different activation models are available 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, buffered servicedcomponents or buffered unmanaged C + + components can greatly mitigate the process of 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 (ServicedComponent or 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\vrootname
When a SOAP endpoint is published on a server, the following generated files are placed in this directory:
Web.config:VRoot's basic Remoting configuration file contains many options that can be added or edited by a developer or system administrator to adjust the performance and security of Remoting.
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.
This version of the. NET framework requires special attention: if an assembly is loaded and the assembly file is accessed using System.Reflection, 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 using servicedcomponents with COM + WEB services, you will also need to place the assembly in the GAC, unless you originally placed the Assembly in the Bin directory and ran 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 place the ServicedComponent in the GAC, or if you have installed Windows. NET Server with the. NET Framework built into it, or has loaded a redistributable. NET Framework on a Windows XP computer, you can use the Microsoft. NET Framework Configuration user interface (accessible from the Administrative Tools menu) to 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
The format of the componentdirectory 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>
</system.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 provides an implementation XML for existing Visual Basic and Visual C + + components, as well as for newly managed servicedcomponents written in Visual Basic. NET and C #. b Services and a simple way of SOAP.
