Adding Web Service Support to COM+ Applications
Existing COM+ applications can be easily converted into a Web Service if they have a stateless interface and if they only use simple types, such as dates, numbers of any form, strings, and arrays of these types. If you transmit byte arrays, the existing tools will even encode them as base64 data. Overall, the base64 encoding bloats the content by 30 percent but conserves on space, because each byte in the array will not have a separate tag, such as <byte>value</byte>. Contrast this with passing arrays of any other numeric type that does have some XML surrounding each value.
NOTE
base64 encoding was developed for e-mail to handle attachments. The data is encoded to guarantee that the data can travel over a text connection. A full discussion of base64 is outside the scope of this text. If you do need information on how it works, look at RFC 2045, section 6.8 (http://www.ietf.org/rfc/rfc2045.txt).
If your application exports special data types, you will need to create a custom type mapper for each data type. A custom type mapper knows how to translate to an object to and from XML. Chapter 10 covers the SOAP Toolkit in detail.
If your hardware uses Windows 2000 or earlier, the easiest way to turn a COM+ application into a Web Service is to use the Microsoft SOAP Toolkit v2. The toolkit comes with a WSDL Generator tool that reads a COM type library and turns that information into WSDL. To deploy the application, make sure that the IIS user has access to the COM+ application. The IIS user on a given computer is the anonymous account created during installation of IIS that is named IUSR_[machine name]. Place the WSDL and WSML files into the same directory and make sure that directory is mapped to a virtual directory on your Web server. That's all there is to it.
If you have Windows XP or Windows .NET Server and the .NET Frameworks installed, exposing the same application is even easier. To expose an existing COM+ application in this situation, you need to look no further than the property pages for the application. To demonstrate this, add the Ch11ComPlusEx example into the COM+. You will need to be running Windows XP or later, and you must have the .NET Framework SDK installed on your machine. We will step through the entire setup, just in case you have never installed a COM+ application.
1. |
Open up Component Services. You can access this via the Control Panel. Assuming you have the Category View enabled, select Performance and Maintenance, Administrative Tools, Component Services. |
2. |
In the Component Services Console, expand the tree so that this node is exposed: Component Services, Computers, My Computer, COM+ Applications. Figure 11.1 shows the tree expanded to this point. Figure 11.1. Getting ready to add an application to COM+.
|
3. |
Right-click the COM+ Applications node and select New, Application. This brings up the COM+ Application Installation Wizard. |
4. |
Click Next, and then select Create an Empty Application. |
5. |
Name the application Ch11ComPlusEx. Leave the default settings alone. Click Next twice and then click Finish. |
Now that the application has been created, you need to add the Ch11ComPlusEx DLL to the application. If you have not copied the project from the companion Web site to your machine, do so now. Back in the Component Services Console, find Ch11ComPlusEx in the list of applications and perform the following steps:
1. | |
2. |
Click Next, and then choose Install New Component(s). |
3. |
Navigate to the directory where you stored the Ch11ComPlusEx project on your hard drive. Select Ch11ComPlusEx.DLL and click OK. The screen should be similar to the one shown in Figure 11.2. Figure 11.2. Getting ready to add an application to COM+.
|
4. |
Click Next, Finish. The component has been installed. |
The last thing you need to do is allow others to connect to this COM+ application using SOAP.
1. |
Right-click the Ch11ComPlusEx application and select Properties. |
2. |
Select the Activation tab. |
3. |
In the SOAP group box, click the Uses SOAP check box. For the name of the SOAP VRoot, type in Ch11ComPlusEx. The tab should be setup as shown in Figure 11.3. Figure 11.3. Enabling SOAP activation for the COM+ application.
|
4. |
Click OK and wait. It may take a little while for the SOAP VRoot to be created. A VRoot or virtual root is a logical mapping between an IIS directory and a location on a disk drive. For example, an HTTP request to the local machine might have the URL http://localhost/someDir. The part of the URL that is someDir is the virtual root and can be mapped to any directory that the computer can see, even if that directory is on a different computer. |
These last steps create a COM Interop assembly and then constructs some code that will make the DLL usable through .NET Remoting. If the COM+ application was already a .NET Remoting endpoint, you could serialize and deserialize complex CLR objects. However, with traditional COM endpoints, this only works for the basic data types (number types, strings, dates, and byte arrays).
The COM object contains two functions—HelloWorld and Add. Listing 11.1 shows the complete implementation of these two functions.
Listing 11.1. Code for the COM Object Exposed Using SOAP Activation via COM+
Public Function HelloWorld() As String
HelloWorld = "Hello World"
End Function
Public Function Add(ByVal a As Long, ByVal b As Long) _
As Long
Add = a + b
End Function
|
As you can see, the code is pretty simple. With minimal work on the COM+ application properties, we now have a WSDL file and virtual root ready to accept connections. The files are located in the %WINDIR%system32ComSOAPVRoots directory. On my machine, the new directory is named C: WINDOWSsystem32ComSOAPVRootsCh11ComPlusEx. This directory has a few files in it that were created to do anything needed to make SOAP work.
web.config Contains information for .NET Remoting to be able to access the COM object as a Web Service.
default.aspx Contains C# code required to display a test page for the service.
default.disco Contains discovery information for the Web Service.
bin[COM+ Application Name]SoapLib.dll The COM Interop assembly generated by COM+. This will not be generated when you use the same technique to expose COM+ applications that use managed code.
All of this machinery allows .NET Remoting to generate a WSDL file on demand. To see this file, navigate to the virtual root on your machine at http://localhost/Ch11ComPlusEx/ and select the one link on the page. After you have the WSDL file, you can use it like any other to access the Web Service.