|< BACK NEXT >|
Modern multitier applications often locate the bulk of their business logic in the middle
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
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
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
Role-based authorization services that allow COM+ to verify a client's role and then grant services only to
Classes that use COM+ services are known as serviced components
Serviced components can also use COM+ services that aren't directly
 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
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
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
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
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.
Remote access to serviced components is via DCOM
|< BACK NEXT >|