Enterprise Services: System.EnterpriseServices

< BACK NEXT >

[oR]

Enterprise Services: System.EnterpriseServices

Modern multitier applications often locate the bulk of their business logic in the middle tier . Much of the time, writing this logic with a technology such as ASP.NET is perfectly adequate. In some cases, however, especially for applications that need to be very scalable and require features such as distributed transactions, more is required. Prior to .NET, the Microsoft technology that provided these services was known as COM+. With the advent of the .NET Framework, those services are still available to CLR-based applications. In fact, the services themselves haven't changed at all, but two things about them have: how they're accessed and what they're called. Now commonly referred to as Enterprise Services, the traditional COM+ services for building robust, scalable applications are also usable by applications written on the .NET Framework.

The types in System.Enterprise-Services allow access to COM+ services

Through the classes in the System.EnterpriseServices namespace, all COM+ services that are available to Windows DNA applications on Windows 2000 are also available to .NET Framework-based applications. Unlike most of the .NET Framework, however, the code that provides COM+ services was not rewritten as managed code. Microsoft tells us that this rewrite will happen eventually, but in the Framework's first release, the classes in System.EnterpriseServices provide a wrapper around the existing implementation that allows managed objects access to these services in a natural way.

All traditional COM+ services are available

For a class to use COM+ services, that class must inherit from EnterpriseServices.ServicedComponent. Because of this, a class using these services is referred to as a serviced component. Serviced components have access to the full range of services COM+ provides, including the following:

Support for (possibly distributed) transactions
Just-in-time activation (JITA), which optimizes server resources by allowing objects to exist only when they're needed
Object pooling, which allows instances of a class to be pooled and reused rather than being destroyed and recreated
Role-based authorization services that allow COM+ to verify a client's role and then grant services only to clients in specific roles

Classes that use COM+ services are known as serviced components

Serviced components can also use COM+ services that aren't directly related to building robust server applications, such as queued components, which is effectively an API to Microsoft Message Queuing (MSMQ); an event service; and others. ^[6] The key point is that .NET Enterprise Services allows managed code to use all COM+ services, but those services are unchanged -the .NET Framework doesn't add any new features in this area.

^[6] For a more detailed look at the services provided by COM+ in Windows 2000, see Chapter 8 of my earlier book Understanding Windows 2000 Distributed Services (Microsoft Press, 2000).

One of the innovations brought by COM+ (or more correctly, by Microsoft Transaction Server, the original incarnation of this technology) was the ability to control what services a component received by setting attributes in a configuration file. To control how transactions are used, for example, a developer using COM+ can set a transaction attribute to Required, indicating that all methods in this component should be run within a transaction. When the component is executed, COM+ reads this attribute and provides the requested transaction support. In traditional COM+, these attributes are stored in something called the COM+ catalog, and they're typically set using the COM+ Explorer, a configuration tool designed for this purpose.

Traditional COM+ uses attributes to specify what services an application needs

In the .NET Framework, however, attributes are supported directly. As described in Chapter 3, every assembly can have extra metadata represented as attributes. Also, attribute values can be set in the source code of a CLR-based application -there's no need for a separate configuration tool -and those values can be read at runtime using reflection. Built-in support for attributes matches well with how COM+ provides its services, and so .NET's Enterprise Services exploit this feature of the CLR. Developers are now able to specify how COM+ services should be used by including attributes directly in their code. And because it's sometimes useful to be able to change a component's attributes after the assembly that contains it has been installed, the COM+ Explorer can still be used to set or modify a component's attributes if desired.

Serviced components use the CLR's built-in attributes to specify what services an application needs

Here's a simple VB.NET class that shows how attributes can be used to control the use of COM+ transactions:

<Transaction(TransactionOption.Required)> _
    Public Class BankAccount
        Inherits ServicedComponent

    <AutoComplete()> _
    Public Sub Deposit(Account As Integer, _
                        Amount As Decimal)
        ' Add Amount to Account
    End Sub

    <AutoComplete()> _
    Public Sub Withdrawal(Account As Integer, _
                            Amount As Decimal)
        ' Subtract Amount from Account
    End Sub
End Class

This class, called BankAccount, inherits from ServicedComponent, as is required for any CLR-based class that wishes to use COM+ services. The class definition is also preceded with an attribute indicating that this class uses the Required setting for transactions. This means that whenever a client calls one of the class's methods, COM+ will automatically wrap the work done by that method in the all-or-nothing embrace of a transaction.

The two methods in this simple class, Deposit and Withdrawal, each begins with the AutoComplete attribute (and since this is just an example, the code for these methods is omitted). This attribute indicates that if the method returns an exception, the serviced component will vote to abort the transaction of which it's a part. If the method completes normally, however, this component will vote to commit the transaction to which it belongs. Note that different attributes are applied at different levels. The Transaction attribute, for example, can be applied only to a class -it can't be set per method -while AutoComplete can be applied only on a per-method basis. If the developer of this application wished to add a method to check the balance, she might well choose to put this method in some other class. Adding it to the BankAccount class would require the method to use a transaction, which isn't generally necessary for this kind of simple read operation so it would needlessly hurt performance.

Attributes can be used to specify a class's transactional requirements

Many other attributes are available for controlling aspects of a serviced component's behavior. For example, the JustInTimeActivation attribute allows turning just-in-time activation on and off (although this feature is automatically turned on for classes that use transactions), while the ObjectPooling attribute controls whether pooling is used and, if it is, how large the pool will be. Other available attributes set application-wide options such as the name of the application as seen by COM+.

Attributes can also be used to specify the use of other COM+ services

In standard COM+, an interface called IObjectContext contains fundamental methods that components can use. Perhaps the most important of these are SetComplete and SetAbort, the two methods that allow a component to cast its vote in a transaction if the autocomplete option isn't used. In .NET Enterprise Services, these same methods are available through a class called ContextUtil. If a transactional method wishes to control its commitment behavior explicitly, it can do so by directly calling these methods.

The methods in the traditional IObjectContext interface are still available

As mentioned earlier, the implementation of COM+ services is not managed code in the first release of the .NET Framework. In spite of this, serviced components are able to use those services without leaving the managed environment. As Figure 5-9 shows, key COM+ services such as transactions are provided using context information maintained by COM+ itself in un managed code. When this context is accessed, such as when a serviced component votes to commit or abort a transaction, that request flows across the boundary between managed and unmanaged code. Interactions among serviced components, however, remain completely within the managed environment provided by the CLR. Since crossing into unmanaged code incurs a slight performance penalty, this ability to remain almost entirely within the managed space is a good thing.

Figure 5-9. COM+ maintains context information for serviced components, allowing it to provide services across the managed/unmanaged boundary.

COM+ has not been completely rewritten as managed code

Enterprise Services also has a few more artifacts of its foundation in unmanaged code. For example, when a serviced component is accessed remotely, that access relies on DCOM rather than on .NET Remoting. Similarly, serviced components must have entries in the Windows registry, like traditional COM+ components but unlike other .NET classes. These entries can be created and updated automatically by the Enterprise Services infrastructure -there's no need to create them manually -but requiring them at all betrays this technology's COM foundations. It's likely that all of these limitations will change in a future release of the .NET Framework when COM+ is completely rewritten in managed code.