Understanding COM Services

[Previous] [Next]

In addition to providing a runtime environment, COM+ and Windows 2000 also include several built-in services that are important to programmers who are building multitier applications. Some multitier applications might need to leverage only one or two of these services. Others might need to use all of them. You should have a general understanding of how all these pieces fit together so that you can make informed decisions during the initial design phase. The following sections present a brief overview of the platform's most significant services for distributed applications.

Internet Information Services

Internet Information Services (IIS) is Microsoft's Web server. This product was originally created for Windows NT Server. The most recent version is IIS 5, which ships with Windows 2000. Like other Web server products, IIS handles incoming HTTP requests sent by client applications. Earlier versions of IIS were primarily used to serve up static Web pages. Today many Web-based applications leverage IIS to run customized processing behind every incoming request.

IIS exposes a proprietary API called the Internet Server API (ISAPI) for developers who want to create Web applications with customized server-side logic. Programmers who program against ISAPI directly create software modules known as ISAPI extensions and ISAPI filters. While writing ISAPI-based software provides the highest levels of performance and flexibility, this approach also has a few significant costs—it requires development in C or C++ instead of Visual Basic and typically forces programmers to deal with low-level infrastructure details such as writing a thread-pooling manager.

Many companies don't want to program directly against ISAPI because they don't have the expertise or aren't willing to invest the necessary time and money. IIS provides an alternative to ISAPI with a framework known as Active Server Pages (ASP). The ASP framework is itself an ISAPI extension that allows programmers to write server-side logic using scripting languages and Visual Basic, among other options.

You should note that Web applications built using ISAPI or ASP can provide pure HTML solutions if that's what you want. You make all the decisions about what browsers your application will support. You can create a pure HTML solution that supports a larger, Internet-style user base, or you can exploit the strengths of one browser, such as Internet Explorer, in an intranet-style environment.

Many companies have built fairly sophisticated sites using nothing but ASP. It's pretty easy to write server-side business logic and data access code using scripting languages such as Microsoft Visual Basic, Scripting Edition (VBScript), and JavaScript and a development tool such as Microsoft Visual InterDev. However, companies have also discovered that it's hard to reuse, maintain, and extend logic that's spread across many pages. This becomes more apparent as a site grows larger. A better approach is to encapsulate business logic and data access code in compiled components.

The integration between ASP and COM+ makes it easy to create and run custom business objects from an ASP page. This means that you can distribute most of your server logic using components rather than scripts embedded in ASP pages. Using components makes it easier to reuse, maintain, and extend your code. Such components can be created with Visual Basic, which offers much better testing and debugging facilities than any ASP-based development tool. Many companies have found that using ASP with Visual Basic offers the best balance between productivity, maintainability, and performance.

Microsoft Message Queuing Services

MSMQ is another important part of the platform. MSMQ is a middleware service that facilitates messaging between various processes in a multitier application. As mentioned earlier, messaging is important because it offers asynchronous and connectionless communication, which neither RPC nor HTTP can provide.

MSMQ is a messaging product based on the asynchronous delivery of messages to named queues. At a high level, messages model procedure calls between a client and a server except that either party can do its work in the absence of the other. The biggest conceptual difference is that a message moves only in one direction, whereas a COM method call involves both an RPC request sent to the object and an RPC response returned to the client.

With MSMQ, a client application can send request messages even when the server application is off line. It also means that the server can respond to request messages after all client applications have gone off line. In environments in which 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.

When would you need to use MSMQ? Let's look at a typical example. In a sales-order application, clients can submit sales orders to an order request queue even if the server application isn't running. Later the server application can open the queue and begin processing the order requests. MSMQ also makes it possible for the server application to return a response message to the sender as if it were the response to a method call. It simply takes a little more work when messaging is involved.

MSMQ is also useful to companies with users of laptop computers, who are constantly disconnecting from and reconnecting to the network. With MSMQ, you simply create client applications that send messages to a queue on the network. If a laptop computer is off line, MSMQ automatically stores messages in a temporary local queue. When the laptop reconnects to the network, MSMQ detects that the network is available and automatically forwards the cached messages to the appropriate destination queue. As you can see, the essential aspects of a store-and-forward mechanism are neatly tucked into the underlying platform.

Messaging products such as MSMQ can also provide better delivery guarantees than products based on RPC or HTTP. An MSMQ message can be sent inside the scope of a transaction to provide exactly-once delivery semantics. This means that MSMQ takes many extra precautions to ensure that your messages eventually reach their destination. It also provides extra infrastructure support to transmit failure notifications back to the sender when messages time out or can't be routed to their destination. You are guaranteed that MSMQ will deliver the message to its destination or inform you that the message couldn't be delivered. MSMQ eliminates many of the lost-message issues that affect applications based on RPC and HTTP.

Queued Components

MSMQ debuted on Windows NT Server in November 1997 with the release of the Windows NT Option Pack. Since then, Visual Basic programmers have been able to leverage MSMQ to reap the benefits of asynchronous, connectionless communication. However, MSMQ programming requires extra code to create, prepare, and send messages from client applications. It also requires you to write a server-side listener application. Compared with communicating with COM method calls, communicating with MSMQ requires noticeably more work to issue a request and get back a response.

COM+ provides a service named Queued Components that allows you to take advantage of MSMQ without having to explicitly program against the MSMQ API. The Queued Components service is simply a productivity layer built on top of MSMQ. You author queued components in almost exactly the same way that you do standard COM+ components, with one or two limitations. For example, you can't design methods with output parameters or return values.

Once you create and install a queued component in a COM+ application, you must configure an attribute indicating that the interface you're providing is supposed to be queued. You must also configure the COM+ application to be queued and to be a listener. When you do this, the Queued Components service automatically creates a special queue for the application. It also sets up a system-provided listening service to handle incoming messages as they arrive.

Once the queued component is properly configured on the server, you can write client applications that use it. A client application doesn't directly instantiate an object from a queued component. Instead, it creates a special client-side proxy object called a recorder, which looks and feels like the actual object as far as the client is concerned. The client then begins invoking method calls as usual. The Queued Components service provides an infrastructure for recording these method calls in an MSMQ message and transporting this data over the network to the computer where the queued component has been installed. The server-side piece of the Queued Components service receives the message, creates an instance of the queued component, and replays the method calls.

As you can see, the primary design goal of Queued Components is to provide the convenience of COM method calls together with the benefits of asynchronous, connectionless communication. In essence, queued components use MSMQ as an underlying transport protocol instead of RPC. Queued components can thus get around many of the limitations of a connection-oriented, synchronous protocol.

You don't need to use the Queued Components service to take advantage of MSMQ. You can always program against MSMQ directly. The Queued Components service is a productivity-oriented framework that hides many of the tedious details of MSMQ programming. And like any other framework, it provides greater productivity at the expense of flexibility.

Quite a few things that you can do with MSMQ aren't supported by Queued Components. You should use the Queued Components service only if it supports the features you need and will save you many hours of MSMQ programming. One of its most valuable features is a server-side listener service. Creating a multithreaded listener service using only Visual Basic is next to impossible, so if you want a server-side listener application that can process many messages per second and you don't want to resort to developing with C++, Queued Components is just what you need.

COM+ Events Service

Some multitier applications require that certain users or applications receive notifications of interesting events—such as the hiring of a new employee, a change in a stock price, or a drop in inventory level that requires restocking. COM+ Events is a service for sending and delivering event notifications between applications.

In the COM+ Events model, applications that send out event notifications are called publishers. Applications that receive event notifications are called subscribers. COM+ events are often called loosely coupled events (LCEs) because publishers and subscribers don't have any knowledge of one another. Instead, a set of events is defined inside the scope of an event class, and this event class is installed in a COM+ application. Publishers and subscribers know about event classes, but they never know about each other.

The decoupling of publishers from subscribers offers quite a few benefits. You don't have to worry about who's listening when you create a publisher application, so there's less code to write. And after the publisher application has been put into production, you don't have to modify it when you want to add or remove subscribers. Furthermore, you don't have to modify subscribers when you want to add or remove the publishers associated with an event class.

Here's a brief overview of how this event model works. You author an event class that implements one or more interfaces. Each interface defines a group of methods, which represents a set of events. You write subscriber components to implement these interfaces and respond to events when they're fired. Finally, 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.

There are two types of subscriptions: persistent subscriptions and transient subscriptions. When an event is delivered to a persistent subscription, the COM+ event service creates a new object from a configured subscriber component and invokes the method associated with the event. The event service wakes up the subscriber application if it's not already running. You should note that for a persistent subscription, an object is created and destroyed each time an event is fired.

The second type of subscription is a transient subscription. Once an application is running, the application can register itself with a specific event class to listen to events as they're fired. In this case, the event service doesn't create and destroy an object for each event. The main difference between the two subscription types is that a transient subscriber must programmatically create a new subscription and register a callback when it wants to listen for events.

Creating a transient subscriber requires more code than creating a persistent subscriber. Creating a persistent subscriber is easier because you can use the COM+ administration tools. Also, if the server holding the event class is rebooted, persistent subscribers continue to work without any problems. All transient subscribers, however, must create and register a new subscription.

A scalable event notification architecture requires asynchronous communication. If the publisher must wait for every subscriber to process its event notification, the system might prove to be inadequate. Also, some applications might require event notifications to be sent in a connectionless manner consistent with MSMQ. COM+ Events has been tightly integrated with Queued Components to provide the benefits of asynchronous, connectionless communication. Both publishers and subscribers can be configured to use Queued Components instead of RPC. For many applications, COM+ events are valuable only when used with the Queued Component service.



Programming Distributed Applications with COM+ and Microsoft Visual Basic 6.0
Programming Distributed Applications with Com and Microsoft Visual Basic 6.0 (Programming/Visual Basic)
ISBN: 1572319615
EAN: 2147483647
Year: 2000
Pages: 70
Authors: Ted Pattison

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net