Overview

The complexity of Enterprise Services and the different configuration options (many of them are not needed if all the components of the solution are developed with .NET) can be more easily understood if you know the history of Enterprise Services. This chapter starts with that history. After that, you get an overview of the different services offered by the technology, so you know what features could be useful for your application.

The topics covered in this section are:

• History

• Where to use Enterprise Services

• Contexts

• Automatic transactions

• Distributed transactions

• Object pooling

• Role-based security

• Queued components

• Loosely coupled events

History

Enterprise Services can be traced back to Microsoft Transaction Server (MTS), which was released as an option pack for Windows NT 4.0. MTS extended COM by offering services such as transactions for COM objects. The services could be used by configuring metadata: the configuration of the component defined whether or not a transaction was required. With MTS it was no longer necessary to deal with transactions programmatically. However, MTS had a big disadvantage. COM was not designed to be extensible, so MTS made extensions by overwriting the COM component registry configuration to direct the instantiation of the component to MTS, and some special MTS API calls have been required to instantiate COM objects within MTS. This problem was solved with Windows 2000.

One of the most important features of Windows 2000 was the integration of MTS and COM in a new technology with the name COM+. In Windows 2000, COM+ base services are aware of the context that is needed by COM+ services (previously MTS services), so the special MTS API calls are no longer needed. With COM+ services some new service functionality is offered in addition to distributed transactions.

Windows 2000 includes COM+ 1.0. COM+ 1.5 is available with Windows XP and Windows Server 2003. COM+ 1.5 adds more features to increase scalability and availability, including application pooling and recycling, and configurable isolation levels.

.NET Enterprise Services allows you to use COM+ services from within .NET components. Support is offered for Windows 2000 and later. When .NET components are run within COM+ applications, no COM callable wrapper is used (see Chapter 23, “COM Interoperability”); the application runs as a .NET component instead. When you install the .NET runtime on an operating system, some runtime extensions are added to COM+ Services. If two .NET components are installed with Enterprise Services, and component A is using component B, COM marshaling is not used; instead, the .NET components can invoke each other directly.

Where to Use Enterprise Services

Business applications can be logically separated into presentation, business, and data service layers. The presentation service layer is responsible for user interaction. Here, the user can interact with the application to enter and view data. Technologies used with this layer are Windows Forms and ASP.NET Web Forms. The business service layer consists of business rules and data rules. The data service layer interacts with persistent storage. Here, you can use components that make use of ADO.NET. Enterprise Services fits both to the business service layer and to the data service layer.

Figure 38-1 shows two typical application scenarios. Enterprise Services can be used directly from a rich client using Windows Forms or from a Web application that is running ASP.NET.

Figure 38-1

Enterprise Services is also a scalable technology. Using component load balancing makes it possible to distribute the load of the clients across different systems. Component load balancing requires Microsoft Application Center Server. You can read more information about Microsoft Application Center Server at www.microsoft.com/applicationcenter.

You can also use Enterprise Services on the client system, because this technology is included in Windows Vista and Windows XP.

Contexts

The base functionality behind the services offered by Enterprise Services is the context. The context makes it possible to intercept a method call, and some service functionality can be carried out before the expected method call is invoked.

Contexts are discussed in Chapter 37, “.NET Remoting.” .NET Remoting contexts also play an important role with Enterprise Services, because these contexts are used for intercepting .NET objects configured with Enterprise Services. However, because COM components can be configured with Enterprise Services in a similar way as with .NET components, the COM+ context exists in conjunction with the .NET Remoting context. This way, a COM component and a .NET component can participate in the same transaction.

Automatic Transactions

The most commonly used feature of Enterprise Services is automatic transactions. With automatic transactions, it is not necessary to start and commit a transaction in the code; an attribute can be applied to a class instead. By using the [Transaction] attribute with the options Required, Supported, RequiresNew, and NotSupported, you can mark a class with the requirements it has for transactions. If you mark the class with the option Required, a transaction is created automatically when a method starts and is committed to or aborted when the root component of the transaction is finished.

Such a declarative way to program is of particular advantage when a complex object model is developed. Here, automatic transactions have a big advantage instead of programming transactions manually. Assume that you have a Person object with multiple Address and Document objects that are associated with the Person, and you want to store the Person object together with all associated objects in a single transaction. Doing transactions programmatically would mean passing a transaction object to all the related objects so that they can participate in the same transaction. Using transactions declaratively means there is no need to pass the transaction object, because this happens behind the scenes by using the context.

Distributed Transactions

Enterprise Services not only offers automatic transactions, but the transactions can also be distributed across multiple databases. Enterprise Services transactions are enlisted with the Distributed Transaction Coordinator (DTC). The DTC supports databases that make use of the XA protocol, which is a two-phase commit protocol, and is supported by SQL Server and Oracle. A single transaction can span writing data to both a SQL Server and an Oracle database.

Distributed transactions are not only useful with databases, but a single transaction can also span writing data to a database and writing data to a message queue. If one of these two actions fails, a roll-back is done with the other action. You can read more about message queuing in Chapter 39, “Message Queuing.”

Important 

Enterprise Services supports promotable transactions with .NET 2.0. If SQL Server 2005 is used and just a single connection is active within one transaction, a local transaction is created. If another transactional resource is active within the same transaction, the transaction is promoted to a DTC transaction.

Later in this chapter, you see how to create a component that requires transactions.

Object Pooling

Pooling is another feature offered by Enterprise Services. These services use a pool of threads to answer requests from clients. Object pooling can be used for objects with a long initialization time. With object pooling, objects are created in advance so that clients don’t have to wait until the object is initialized.

Role-Based Security

Using role-based security allows you to define roles declaratively and define what methods or components can be used from what roles. The system administrator assigns users or user groups to these roles. In the program there is no need to deal with access control lists; instead, roles that are simple strings can be used.

Queued Components

Queued components is an abstraction layer to message queuing. Instead of sending messages to a message queue, the client can invoke methods with a recorder that offers the same methods as a .NET class configured in Enterprise Services. The recorder in turn creates messages that are transferred via a message queue to the server application.

Queued components and message queuing are useful if the client application is running in a disconnected environment (for example, on a laptop that does not always has a connection to the server), or if the request that is sent to the server should be cached before it is forwarded to a different server (for example, to a server of a partner company).

Loosely Coupled Events

Chapter 37, “NET Remoting,” discussed how to use events with .NET Remoting. Chapter 23, “COM Interoperability,” describes how to use events in a COM environment. With both of these event mechanisms, the client and the server do have a tight connection. This is different with loosely coupled events (LCE). With LCE the COM+ facility is inserted between client and server (see Figure 38-2). The publisher registers the events it will offer with COM+ by defining an event class. Instead of sending the events directly to the client, the publisher sends events to the event class that is registered with the LCE service. The LCE service forwards the events to the subscriber, which is the client application that registered a subscription for the event.

Figure 38-2