Dan Hay
Microsoft Corporation
September, 1999
Summary: Queued Components, a key feature of COM+ and based on Microsoft Message Queuing Services (MSMQ), provides an easy way to invoke and execute components asynchronously. (3 printed pages)
Queued Components, a key feature of COM+ and based on Microsoft Message Queuing Services (MSMQ), provides an easy way to invoke and execute components asynchronously. Processing can occur without regard to the availability or accessibility of either the sender or receiver. A home shopping network is an example of the type of application that might benefit from asynchronous processing. In this asynchronous, disconnected scenario where viewers phone in to several operators, orders are taken en masse and are then queued for later retrieval and processing by the server.
In the past, an in-depth knowledge of marshaling was necessary to queue, send, and receive asynchronous messages. Queued Components marshal data automatically in the form of an MSMQ message by using method calls that are easily understood and used by component developers. Because Queued Components offer built-in support for transactions, in the event of a server failure data cannot be compromised. Queued Components enhance the COM+ programming model to provide an environment in which components can be invoked either synchronously (real-time) or asynchronously (queued)—the component need not be aware of this environment.
Queued Components consists of:
In a typical Queued Components scenario, the client calls a queued component. The call is made to the Queued Components recorder, which packages it as part of a message to the server and puts it in a queue. The recorder records all of the method calls for an object. In its role as proxy for the server component, the recorder selects interfaces from the queueable interfaces described in the COM+ catalog. A representation of the recording is sent to MSMQ as a message to be sent to a server. MSMQ accepts delivery of the message only if the client-side transaction commits.
The Queued Components listener retrieves the message from the queue and passes it to the Queued Components player. The recorder marshals the client’s security context into the message and the player unmarshals it at the server side before making the call. The player invokes the server component and makes the same method call. The method calls are not played back by the player until the client component completes and the transaction that recorded the method calls commits.
When designing new applications, developers must consider the implication of coding components for real-time (or synchronous) processing versus queued (or asynchronous) processing. Ultimately, the choice depends on the requirements of the specific application and determining which method better serves the underlying business logic of the application. Using queued processing offers advantages for certain applications, while writing an application using real-time, synchronous processing could be the best choice for another application. As a guideline, queued processing offers the following advantages over real-time processing:
A component may not be available because of server overload or networking problems. In a real-time processing application, if just one component of the transaction is not available, the entire process is blocked and cannot complete. An application using queued components separates the transaction into activities that must be completed now and those that can be completed at a later time. Messages are queued for later processing while the requesting component is free for other tasks.
An application using queued components allows the server component to operate independently of the client. As a result, server components can complete more quickly. In a real-time system, the server component exists from the time it is created until the object is finally released. The server waits for the client to make method calls and for results to be returned, which negates the rapid cycling of server objects and limits server scalability.
Sales of laptops, notebooks, and palm computers have created a need for applications that service occasionally-connected clients or mobile users. In a queued system, these users can work in a disconnected scenario when not connected to the server and later connect to the servers or databases to process their requests.
The queue manager is a powerful tool that uses database techniques to protect data in a robust way. In the event of a server failure, the transactions are rolled back so that messages are not lost.
An application using queued components is well suited to time-shifted component execution, which defers non-critical work to an off-peak period. This was the same concept used in traditional batch mode processing. Similar requests can be executed contiguously by the server, rather than requiring the server to react immediately to a wide variety of requests.
The following sample shows how easy it is to implement a Queued Component into your Visual Basic program. The sample sends out an order to purchase the contents in a shopping cart.
Private Sub ShoppingCart_Purchase(ByVal AccountID As Long)
Dim objShoppingCart As FMSStore.ShoppingCart
Set objShoppingCart = GetObject("queue:computername=clbserv-1/new:FMSStore.ShoppingCart")
objShoppingCart.ExecuteBuy AccountID
Set objShoppingCart = Nothing
End Sub
A developer implementing this code for production could also use the Windows 2000 Directory Services to store and retrieve the name of the Queue Server dynamically.