An apartment is neither a thread nor a process. It is an execution context in which components exist. Different types of apartments define how a class object can be accessed from different threads in the same process.

An apartment can be an STA (single threaded apartment) or an MTA (multithreaded apartment). As the name suggests, objects in an STA can be accessed by only one thread at a time. If more than one thread tries to access the object in an STA, the requests are queued in a message pump and access is given serially. The advantage here is that because the access is serialized, you can be sure a component created in this model will never be accessed by more than one thread at a time.

In the case of an MTA, it is possible for multiple threads to enter the apartment, that is, more than one thread can access an object in an MTA. Here, the onus of protecting the data in an object from concurrent access and possible corruption is on the programmer.

A process can have multiple STAs, but only one MTA. The first STA created in the process is called its main STA. When a component is created using the single threaded model, it is forced to run on the same thread that initialized it or on the main STA of the process. This is the least flexible of the COM threading models.

When a component is created as apartment threaded (STA), the object can be loaded into any STA in the process. This ensures that access to the object is synchronized. When a component is created as free threaded, it will be loaded into the process-wise MTA. It is possible for multiple threads to access it simultaneously. The programmer is responsible for creating thread-safe code.

In case a component is created to support both apartment threading and free threading, any client that supports either of these models can access the class object. However, the access to the data must be synchronized by the developer.

Windows DNA

Now that I have gone though the basics of COM, I will introduce you to COM+. Before that, I will take a quick look at Windows DNA (Distributed Internet Applications) architecture. Windows DNA is the application development for the Windows platform. It specifies how to develop robust, scalable, distributed

applications using the Windows platform and to extend existing data and external applications to support the Internet.

Windows DNA describes the technologies that provide a complete integrate n- tier development model and the set of services that developers require to build scalable enterprise-level applications on the Windows platform. Figure 34-1 shows the Windows DNA model.

FIGURE 34-1 Windows DNA architecture

Windows DNA addresses the requirements at all tiers of modern distributed applications: presentation, business logic, and data. The presentation services include all applications and technologies that can be used to provide access to the application. They can be HTML, dynamic HTML, and JavaScript viewed through a Web browser (thin client) or a Windows application developed using Win32 API and distributed as executables (rich client).

The application services tier is typically composed of components that bind the presentation and the data layers. The technologies involved in this layer are IIS, COM, ASP, and MTS. This layer handles the business logic and other application services.

The data services layer enables the application to store and retrieve data. The technologies involved in this layer are ADO+ and OLE DB.

Some of the benefits of Windows DNA include:

Windows DNA provides a very comprehensive, integrated platform for building distributed applications. Commonly needed middle tier services are provided to developers, doing away with the burden of having to build commonly used services.

Applications can be built faster by using a common services infrastructure of the Windows platform.

Windows DNA supports a number of programming languages and development tools, providing the developers with a wide variety of choice.

Windows DNA is designed to provide a high level of interoperability with existing applications and legacy systems.

The core of Windows DNA is the integration of Web and client/ser ver application development models through the COM. Windows DNA defines a common set of services, including components, dynamic HTML, Web browser and server, scripting, transactions, message queuing, security, directory, database and data access, systems management, and user interface. These services are exposed in a unified way through COM.

The application services, infrastructure services, and common interfaces operate in a multitier framework. COM and other protocols and services act as the bond between the application and data layer.

From a technology that was initially designed to promote code reuse, COM has made a very successful transition to design software components that encapsulate business rules and logic. Today, system services are provided through COM.

Microsoft Transaction Server (MTS)

COM was a component technology designed to enable efficient code reuse. With the release of DCOM in Windows NT 4.0, the technology was expanded to support distributed applications by means of remote component instantiation and method invocations.

This was followed by release of MTS, which allowed developers to build and run their components in MTS as its middle tier. In addition, it provided much needed support for distributed transactions, integrated security, thread pooling, and improved configuration and administration.

COM+

One of the problems faced by developers building multitier applications is deciding when to use MTS and when to use COM. COM is shipped with Windows NT, whereas MTS needs to be installed as an add-on.MTS is not a part of COM. Moreover, MTS and COM have quite different programming models of their own. MTS is a layer on top of COM, but COM was not modified to accommodate MTS. However, the two are not tightly integrated.

In Windows 2000, COM and MTS have been unified into a single run-time layer and support a common programming model. The new run time has been named COM+. COM+ is a part of Windows 2000.

COM+, just like COM, is based on binary components and interface-based programming. Method calls are remoted across process and computer boundaries using a transparent RPC layer. COM+ components can be upgraded and extended in production without affecting the client applications that use them. They also support distributed transactions and role-based security. Additionally, COM+ provides a built-in thread-pooling scheme and uses attribute programming as its programming model.

In addition to transactional services and integrated security, COM+ exposes services such as synchronization and object pooling. COM+ provides new features, such as queued components and COM+ events that are exposed through configurable attributes and a new threading model called neutral apartment threading. I will now discuss each of these features in brief.

Role-Based Security

COM+ supports role-based as well as process-based security. A role represents the security profile of one or more users in an MTS application. At design time, a developer can set up security checks programmatically through roles. At deployment time, an administrator maps a set of roles to user accounts and group accounts inside a Windows NT domain. Therefore, in role-based security, access to parts of an application are granted or denied on the basis of the logical group or role to which the caller has been assigned. The role-based security model of MTS provides more flexibility than the security model provided by COM.

Threading

COM+ includes a new threading model, neutral apartment threading. You can use neutral apartments for projects with no user interface. In case of neutral apartments, objects follow the rules for MTAs. However, they can execute on any kind of thread. Each process can have only one neutral apartment.

Object Pooling

This is a service that enables you to configure a component to have instances of itself kept alive in a pool, ready to be used by clients accessing the component. You can configure and monitor the pool by specifying characteristics such as pool size and creation request timeout values. COM+ manages the pool while the application is running, handling object activation and reuse based on the criteria you have specified. This object reuse leads to significant performance and scaling benefits.

Queued Components

Queued components are a feature of COM+ that is based on MSMQ (Microsoft Message Queue Se rvice). Queued components provide a simple way to invoke and execute components asynchronously. Processing can take place without having to bother about whether the sender is available or not at the other end. With MSMQ, a client application can send request messages even when the server application is offline, and a server can respond to request messages after all client applications have gone offline. In environments where client applications and servers can become disconnected for any number of reasons, this capability allows the distributed application as a whole to stay up and running.

However, this results in extra code for creating, preparing, and sending messages from client applications. It also requires you to write a server-side listener application.

On the other hand, COM+ provides a service, named queued components, that allows you to take advantage of MSMQ without having to explicitly program using the MSMQ API.The queued components service is a layer built on top of MSMQ. The COM+ queued components services enable you to create components that can execute immediately, provided the client and the server are connected or the execution can be deferred until a connection is established.

The benefits of queued processing are:

Shorter component life span

Message reliability

Reduced dependency on component availability

Efficient server scheduling

COM+ Events

Events are used to manage a connection between a publisher and one or more subscribers and then manage the delivery of events to those subscribers. In the COM+ event model, applications that send out event notifications are called publishers. Applications that receive event notifications are called subscribers. The COM+ queued components service is used to make the publisher and subscriber processing time independent by queuing the publisher’s message and later replaying it to the subscriber. COM+ events are often called LCEs (loosely coupled events) because publishers and subscribers do not have any knowledge of one another. Publishers and subscribers know about event classes, but not about eac h other. Whether or not you need to use the queued components service depends on the underlying business logic of your application. If you need to have events that are time-independent, you can create them by composing COM+ events with COM+ queued components.

Working of COM+ Events

Suppose you author an event class that implements one or more interfaces. The methods that are defined in these interfaces represent a set of events. You write subscriber components to implement these interfaces and respond to events when they are triggered. Next, you write a publisher application to create objects from the event class and call various methods when it wants to fire events. The event service takes care of processing the method and delivering the events to every subscriber.

COM+ events store event information from different publishers in an event store in the COM+ catalog. Subscribers query this store and select the events that they want to hear about. Selecting event information from the event store creates a subscription. When an event occurs, the event system looks in this database and finds the interested subscribers, creates a new object of each interested class, and calls a method on that object.