Distributed COM Applications

Distributed COM+ Applications

Probably one of the most important uses for COM+ is in distributed applications. Creating application proxies was always one of the easiest ways to implement a distributed application. The number of choices in .NET might seem somewhat daunting by comparison. Not too worry, though. The increased choices are all designed to address certain deficiencies of the WinDNA platform and technologies such as DCOM and RDS and to make it easier to create distributed COM+ applications.

COM+ and Remoting

The process of creating server applications that run through remoting is fairly straightforward, if not obvious. Remember that remoting requires a host process to handle registration and configuration. This is still true for COM+ applications. Granted, you are already halfway there because any component derived from ServicedComponent has MarshalByRefObject as a base class a prerequisite for all objects to be made available through remoting. The Architecting for Remoting example demonstrates how to register a ServicedComponent with the common language runtime. Support for the COM+ context and other services is implicit through remoting, and there really isn t anything extra that you need to do for it to work.

Using SOAP Services

Publishing a ServicedComponent through Remoting is powerful, but it requires you to do your own work to register the individual components that are intended to be available. There is an alternative: SOAP. The self-registration process in .NET for ServicedComponents provides the ability to mark your entire COM+ application as publishable through SOAP Services (essentially an XML Web service interface). Your COM+ application is then published through a virtual root of the IIS server the application is registered on. This technique is powerful, but it has greater implicit calling overhead than a binary format such as Remoting. On the other hand, using SOAP Services allows you to publish your COM+ application in a simple and straightforward manner. Recall from Chapter 16 how important attributes are to COM+ applications. The SOAP Service is made accessible through the ApplicationActivation assembly attribute. There is a default property that you can set in this attribute that instructs the self-registration process to create a SOAP proxy for your application (and any ServicedComponent contained within the Assembly). This property allows these ServicedComponents to be activated through a Web Service.

Limitations of SOAP Services

While using SOAP Services is a painless way to publish your COM+ application as an XML Web service, it does lose some of its abilities. For example, the COM+ transaction context ends at the XML Web service boundary. This means that you cannot have a transactional client call the XML Web service and have the transaction context propagate from the client to the server. COM+ essentially begins and ends at the XML Web service boundary. Although your COM+ application can take advantage of all of the COM+ Services available, those services are not available to any calling clients. As far as any client is concerned, there is nothing COM+ about the XML Web service.

Included on the CD is the Soap Services example. It contains a simple class, SoapServicesTest, that defines the COM+ application.

Imports System.EnterpriseServices Imports System.Reflection <Assembly: AssemblyKeyFile("SoapServicesTest.snk")>  <Assembly: ApplicationName("COM+ SOAP Services Test")>  <Assembly: ApplicationActivation(ActivationOption.Server,  SoapVRoot:="SOAPServicesTest")>  Public Class SoapServicesTest    Inherits ServicedComponent    Public Sub New()       MyBase.New()       Debug.WriteLine("SOAPServicesTest::New()")    End Sub    Public Function HelloWorld() As String       Return "Hello World"    End Function End Class

When this class is registered (by using RegSvcs.exe or loading it via another process), the COM+ self-registration process will create the IIS virtual directory and build all the necessary support files for an XML Web service, including the inspection page (accessible through a Web browser).

	Windows XP will require Service Pack 1 before the included sample application will function as expected. At the time of this writing, the SOAP Services attribute is not supported for Windows 2000. Support exists only for Windows XP and the Windows .NET server product family.

COM+ Application Proxies in .NET

Using COM+ application proxies has always been an easy way to implement DCOM in your applications. Such proxies enable you to create remote components that you can deploy and program against as though the components resided on the local machine. COM+ allows you to register your component on a server in a COM+ application and generate an export package that can be registered on virtually any client (domain security issues aside). As a result, you can avoid the whole issue of creating COM proxy stub packages and implementing custom object marshaling COM+ does it all for you.

You will be relieved to discover that nothing has changed in Visual Basic .NET. After a ServicedComponent is registered on the server, it is possible to create an export package, deploy it to the client, and use it as you always have. You will need the assembly containing the class and interface definitions on the client (unless you want to everything to be late bound), but COM+ will still marshal the objects through DCOM for you. There really isn t a lot more that needs to be said here. It just works. Create your export package, register it on the client, and you re done.

	There is a caveat to the just works mantra for COM+ proxy applications. It turns out that there are some platform requirements for this to work correctly. Because of problems in Windows 2000, support for .NET-based application proxies will not be available until Service Pack 3 has been released. At the time of this writing, Service Pack 2 is the most recent available. Application proxies will work just fine on Windows XP and the Windows .NET server product family.