Features of Component Services

Let’s look at the features of Component Services in a little more detail:

Automatic transaction processing  This feature enables your components to participate in transactions that require coordination of code from multiple components. If an error occurs in any of the code that is enlisted in a given transaction, all the intermediate work that had been done up until that point will be rolled back. If all the code completes successfully, the changes (such as writing database updates) will be committed, or made permanent.

Just-in-time activation  The feature improves performance and scalability by automatically deactivating an object—and releasing its resources—as soon as a method call is complete, even if the calling application does not release the reference immediately. The object’s context is still maintained on the server, so the calling application still has a valid reference if it wishes to make another method call. If the calling application does make another method call, the server will activate a new instance of the object.

Object pooling  This feature improves performance and scalability by maintaining a defined number of objects in memory at all times, ready to be activated when a calling application makes a request. You can tune application performance by adjusting the minimum and maximum number of objects to be maintained by the pool.

Object construction  Object construction enables you to enter a construction string into the Component Services management console for a class in your component. This string is then passed as a parameter to the constructor method each time an object is instantiated for that class. This is useful when you need to provide information that might change after your component was installed, such as a database connection string. It enables the string to be changed by an administrator and doesn’t require that the source code be updated.

Role-based security  This feature enables you to define which groups of users (roles) are allowed to make calls on a component, class, or method. You can apply role-based security in source code through properties and methods of the System.EnterpriseServices.ServicedComponent base class, you can apply a SecurityRoleAttribute to your class, or you can assign roles administratively through the Component Services management console. This topic is discussed further in Chapter 10, “Deploying, Securing, and Configuring Windows-Based Applications.”

Synchronization  Synchronization manages multiple clients who want to use your component at the same time. This feature enables a developer to concentrate on business logic and not worry about complex threading issues.

Compensating Resource Managers (CRMs)  CRMs provide transactional support for simple resources, such as disk files or the system Registry, so that changes to these resources can be committed or rolled back as a normal part of automatic transaction processing.

BYOT (Bring Your Own Transaction)  This feature can be used in special circumstances when your component must participate in a transaction that was started by an external transaction manager, not Component Services.

COM Transaction Integrator (COMTI)  This feature enables your components to interact with applications running in certain legacy mainframe environments.

Loosely Coupled Events (LCE)  Unlike traditional event notification, LCE does not require that the event “subscriber” components stay running in memory waiting for notification. Component Services can start components when an event that they are subscribed to is fired by another component.

Private components  A component marked as Private can be called only from other components in the same application (in-process calls). It cannot be called from outside applications.

Queued components  This feature enables applications to make asynchronous calls on components. The information about the call is placed into a message queue (persistent storage) on the server, and the component processes each message when it is available. This is useful for making calls on an application on a remote server that might not always be online or for balancing peak workloads. Messages wait in the queue until the server component is connected and is able to process them.

Simple Object Access Protocol (SOAP) services  These services enable you to create an XML web service interface for existing components.

XA interoperability  XA interoperability supports the X/Open transaction-processing model. X/Open is part of the Open Software Foundation’s Distributed Computing Environment, which is a set of standard middle-tier components that enable multi-vendor, multi-platform system integration.

Now that you understand the range of functionality that is offered by Windows Component Services, this chapter will concentrate on those that are most commonly used:

• Automatic transaction processing

• Just-in-time activation

• Object pooling

• Object construction

  Note 

  Chapter 10 covers role-based security.

Real World Scenario—Using Queued Components and Transactions

You are a software developer for a large organization. One of the tasks that you frequently face is transferring data from one application to another. The application that you are currently designing has a business requirement to generate summary information about transactions that have been entered each day. The application will run on a local server in each of your organization’s 50 branch offices. Each of these branch offices must then send the information to an application at headquarters that consolidates all the branch office information.

You have looked at various models for transmitting the application and you have a few concerns. The first concern is that all 50 branches will be trying to connect to headquarters at about the same time each day; this might cause serious delays, and some connection attempts might fail. Your second concern is how to guarantee delivery if an error occurs at any point during either processing or data transmission. You have decided that .NET Enterprise Services and Queued Components can address these two design goals. You will create a message queue on the headquarters server that will accept the branch office data. This enables the branches to quickly connect to headquarters and submit their data without waiting for earlier requests to be processed. The application that consolidates all the data can process messages from the queue one at a time.

Support for distributed transactions within Enterprise Services makes sure that all the steps in processing, up to final delivery to the message queue, are a part of a single transaction. If an error occurs at any point, the entire operation is rolled back. You will not have to worry about sending partial results or a failure during message delivery.