Less Useful COM Services

Less Useful COM+ Services

Unfortunately, not every COM+ feature is as easy to use as instance management and automatic transactions. Although in principle it is possible to use any COM+ feature with a .NET-serviced component, some place additional restrictions, don't play well with other .NET technologies, or just aren't needed anymore.

The following sections describe several features of COM+ that .NET developers probably won't use, at least in this release of .NET. Keep in mind that these are general recommendations only. You might develop a design that uses one or more of these features effectively. However, most of these features are constrained by .NET interop issues and aren't as important as they are in the COM-based world of programming.

Note

Some of these COM+ features will have improved support in future versions of the .NET Framework. Others might be replaced by new features written entirely in managed code.

Currently, COM+ services are used by the CLR but are provided by the COM+ runtime, not the CLR. In the future, the managed equivalent of COM+ services will most likely be integrated directly into the CLR, as garbage collection is in the current .NET Framework. In fact, this design was initially planned for the first release of .NET, but it couldn't be accomplished in the set timeframe.

Queued Components

Queued components enable you to use Message Queuing to communicate between components. To your code, a queued call looks like an ordinary method call. But behind the scenes the call is recorded, queued, and then replayed on the real object sometime in the future. Queued components are very scalable, provide automatic message retransmission, and can transmit role-based security information from the caller.

Queued components work best with a dedicated COM proxy. If you don't use COM/DCOM, all calls must flow through a .NET layer, like an XML Web service or a .NET Remoting component host. This .NET layer reduces the value of queued components because it means that the server can't be off line when the call is made. The problem is that even though the component itself is queued, there is no way to create a queued XML Web service or .NET Remoting host.

One alternative is to access Message Queuing directly, as described in Chapter 8. This provides the same functionality as a queued component but forces you to write tightly coupled code that uses specific Message Queue objects. In the future, a .NET Remoting channel may be developed that flows over Message Queuing, allowing developers to communicate transparently with queued components once again.

Role-Based Security

Role-based security allows you to define logical roles for your application such as Administrator, Manager, and so on. After you associate a role with an object, interface, or method, COM+ ensures that only the users in the appropriate roles can access the object. Best of all, the process of creating and associating roles is performed through the Component Services utility so your component doesn't need to contain security code. Unfortunately, role-based security information isn't available to nonserviced components and does not flow over a .NET Remoting channel. This makes it unsuited for any system that isn't entirely built on COM+. .NET provides other role-based security systems, including ones based on Windows accounts or an ASP.NET configuration file. These are generally less powerful but better integrated into the .NET Framework. Chapter 13 discusses the options and shows you how to build your own custom role-based authentication.

Synchronization

Synchronization controls how multiple threads can access your object simultaneously. It isn't required in most .NET scenarios. Instead, you can use .NET threading, which isn't declarative and requires dedicated threading code. .NET includes ample features for handling locks, synchronization, and so forth, as described in Chapter 7 and Chapter 8.

Loosely Coupled Events

A loosely coupled event is a publisher-subscriber event model in which COM+ handles the event delivery, and the sender is unaware of whether or not specific clients receive the event. This event handling model is very scalable, but it suffers from some limitations (such as no intrinsic support for firing events across machine boundaries). It's also much more work to implement in .NET.

Instead of using COM+ loosely coupled events, you can use .NET events or callbacks and bidirectional .NET Remoting channels where needed. These communication methods also have limitations, but certain techniques (such as using the <OneWay> attribute) can help ensure scalability and optimum performance, without the complexity of COM+ integration.

Object Construction String

An object construction string enables you to specify a string of configuration information in Component Services. This string is then provided to the component. This feature is still available in .NET. However, .NET already enables you to set configuration information without recompiling the code through XML configuration files, which is generally a more convenient approach.

SOAP Services (Only in COM+ 1.5)

SOAP services allow you to expose a COM+ application as a .NET XML Web service if you configure it in the Component Services tool. This feature uses the .NET runtime. It's not needed in .NET. You have more flexibility using .NET Remoting or XML Web services directly.