Enterprise Services is the name of the Microsoft application server technology that offers services for distributed solutions. Enterprise Services is based on the COM+ technology that has already been in use for many years. However, instead of wrapping .NET objects as COM objects to use these services, .NET offers extensions for .NET components to take direct advantage of these services. With .NET you get easy access to COM+ services for .NET components.
Enterprise Services also has a great integration story with WCF. You can use a tool to automatically create a WCF service front-end to a serviced component, and you can invoke a WCF service from a COM+ client.
This chapter covers the following topics:
- When to use Enterprise Services
- What services you get with this technology
- How to create a serviced component to use Enterprise Services
- How to deploy COM+ applications
- How to use transactions with Enterprise Services
- How to create a WCF front-end to Enterprise Services
- How to use Enterprise Services from a WCF Client
The complexity of Enterprise Services and the different configuration options (many of the mare 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:
- Where to use Enterprise Services
- Automatic transactions
- Distributed transactions
- Object pooling
- Role-based security
- Queued components
- Loosely coupled events
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 since 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 24, “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 44-1 shows two typical application scenarios. Enterprise Services can be used directly from a rich client using Windows Forms or WPF or from a Web application that is running ASP.NET.
Enterprise Services is also a scalable technology. Using component load balancing makes it possible to distribute the-load of the clients across different systems.
You can also use Enterprise Services on the client system, because this technology is included in Windows Vista and Windows XP.
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. For example, a transactional or a synchronization scope can be created before the method implemented by the component is invoked.
With the contexts here, a COM component and a .NET component can participate in the same transaction. All this is done with the help of the base class Service Component that itself derives from Marshal By Ref Object to integrate .NET and COM+ contexts.
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, Requires New, and Not Supported, 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 over 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.
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 SQLServer and Oracle. A single transaction can span writing data to both a SQLServer 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 rollback is done with the other action. Youcan read more about message queuing in Chapter 45, “Message Queuing.”
Later in this chapter, you see how to create a component that requires transactions.
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.
Using rote-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 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 7, “Delegates and Events,” explained the event model of .NET.Chapter 24, “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 44-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.