(untagged)

Designing Asynchronous Processing Using COM+ Queued Services

Partha Kuchana

0.00/5 (No votes)

31 May 2003

An introduction to COM+ queued services.

Introduction

Before the introduction of COM+, developers were responsible for handling thread allocation, security and other resource management tasks. By providing features such as object/ thread pooling, transaction support (across multiple databases over a network), JIT object activation and other important aspects, COM+ makes applications more scalable and ensures the data integrity. In this context COM+ can be seen as the next step towards enhancing the Microsoft� Component Object Model (COM) and Microsoft Transaction Server (MTS).

Queued Components further enhance the COM+ programming model by providing an environment in which components can be invoked either synchronously (real-time) or asynchronously (queued). The component need not be aware if it is being invoked in a queued or a real-time context.

More About COM+ Queued Components

The COM+ queued service is very tightly integrated with the MS message queuing services and provides a way of invoking a server side component and executes its methods in an asynchronous manner. The receiver component does not have to be available when the sender invokes the receiver component. Similarly, the sender does not have to be available when the message is actually processed by the server side receiver component.

In general, an MSMQ queue is a storage area where MSMQ saves messages from different sender objects. These are message is available for receiver objects to be collected at a later time. A receiver object does not have to communicate directly with the sender to receive the sender messages. The communication between the sender and the receiver is indirect and is made possible through queues. This type of indirect communication provides a very low degree of coupling allowing both the sender and the receiver to operate independently.

Similarly, when using COM+ queued services, a client object can access a component from a COM+ server application and invoke its methods, even when the server application is unavailable at the time of the request. The fact that the server application is not available does not result in an error. The client request is saved inside a queue. When the server application becomes available, the request gets processed.

Not all real-world business scenarios are suitable for asynchronous queued processing.

Case - I

Let us consider the typical case of submitting URLs to a web based directory listing service. Some directory listing services conduct manual verification when a user submits a URL; it is not added to the search process immediately. In addition to the URL information, users may submit other data such as the company/last name, address, phone and email.

Implementing the task of storing the user submitted data in a database as a real-time operation could keep the client waiting until the database operation is complete (or) times out. Queued processing can be applied in this scenario, where the database save operations are queued and carried out at a later time (not in real-time), preferably when there is a lesser load on the server. This increases the scalability of the submission process significantly.

Case - II

In contrast to the above example, the order processing at an online store selling phone cards is usually in real-time. Users are presented with the phone card number right after the processing is completed.

Advantages

As can be seen from the cases 1 and 2 above, not all business scenarios are suitable for queued processing. When applied, the COM+ queued processing has the following advantages:

Very Low Degree of Runtime Dependency
- When using the COM+ queued service all client requests are stored in a queue to be retrieved and processed by the receiver. There is no requirement for the receiver to be available /accessible when the client is sending a request and vice versa.
Guaranteed Delivery
- COM+ queued components are built on the foundation of MSMQ. With built-in capability to protect data MSMQ offers reliable, guaranteed message delivery. Thus when a client request is sent to an MSMQ queue, the request delivery to the server is guaranteed. MSMQ rolls back transaction in case of a server failure in order to prevent any message loss.
Better Load Balancing
- Most applications (in particular web application) implement some kind of load balancing to improve the application scalability and availability, where user requests are distributed among several servers.
  
  Identifying and applying queued processing to processes that do not require immediate, direct processing can enhance load balancing. A separate server(s) can process all queued requests. This reduces the load on server(s) processing real time requests.
  
  In applications with n-tier architecture, most often, the business logic is encapsulated into a set of business services objects. These components are used to process both the real-time as well as queued requests. Carrying out queued request processing at off-peak times puts lesser loads on the server hosting these components.
High Degree of Availability Despite Server Failures
- The very characteristic of the client and the server not being connected directly makes it possible for the client application to proceed with its request as if the server application is available (even if there is a server failure).
Ease of Use
- With out using COM+ queued services, it is possible to send messages from the client to the server achieving the same degree of reliability as with COM+ queued services. But doing so would require custom programming to interface with MSMQ queues. COM+ queued components hide all the MSMQ mechanics. When using COM+ queued services, sending messages to MSMQ is no different from invoking a method call on a COM object. On the server side, it requires no additional programming to retrieve client requests from the queue.

Limitations

Available only on Microsoft Win2K and Win XP.
In a setup with Windows NT 4.0 clients and 2000/XP servers, you will be required to create and send messages to MSMQ explicitly using custom code on the client side. On the server side custom coding is required to create your own listener service.

Comparison with DCOM and Middleware Messaging Software Apps

In contrast to the COM+ queued service, a method call using DCOM results in an error if the associated server application is not available at the time of the method call. Even though middleware messaging software applications provide the necessary mechanism for a client to send its request, when the server is not available, they do require an explicit message construction (most often, in the form of XML) by the client. The client will not be able to make a method call on the remote server object in a transparent manner.

Request Processing Using Queued Services

The following three components together on both the client and the server side constitute the COM+ queued component service.

Recorder on the client side, which serves as a proxy for the server component.
Listener on the server side.
Player on the server side.

Figure 1: Flow of method call execution in the context of COM+ queued service

When a client object invokes a queued component's method, the call is first received by the proxy (recorder). The recorder stores method calls as part of a message and puts it in an MSMQ queue. Also the recorder marshals the client security context in to the message.

On the server side, the queued component listener retrieves this message and hands it over to the queued component player.

Once the client component completes and the transaction that recorded the method is committed, the player

Unmarshals the client security context
Invokes the server side COM component
Makes the method call

Requirements

MSMQ is installed on the computer with the component
All methods inside a class, which is intended to be used as a queued component must meet the following requirements
1. Methods cannot have a return value i.e., you can only use methods that are defined as sub-routines.
2. All method parameters must be input parameters i.e., all parameters that are passed to the subroutines must be specified as ByVal.

Since the server component processes requests asynchronously, some times the client may not be available when the actual processing takes place. During such times, the server computer will not be able to communicate back with the client in any direct manner. By enforcing the above requirements, COM+ queued service eliminates the possibility of attempting any such direct communication back with the client.

Response back to the client

From the requirements section above, it can be seen that there is no two-way communication possible during asynchronous processing. But at times a client may want to be informed after its request is processed. This can be implemented in a variety of ways depending on the underlying business requirement.

The simplest could be sending an email to appropriate recipients. This is mostly done in cases where an end user needs to be informed of request processing.

Figure 2: An E-Mail notification back from the server to the user

Alternatively, a series of one-way communications can be used to send reply from the server to the client. This can be accomplished by having the server side queued component instantiate a component that is actually residing on the client computer using DCOM/COM+ queued service. This can be done directly (or) through an intermediate component.

Figure 3: Response back to the client through a series of one-way calls.

Deployment & Configuration

A component must be configured as a queued component for its methods to be invoked asynchronously. This can be done using the component services administrative tool of win2k with the following series of steps:

Create a new empty COM+ server application (e.g., QCOM).
Add your components to this application.
Select the COM+ application -> Right click and go to properties of the COM+ application -> Click on the queuing tab -> Select the queued property -> Select the listen property.

The queued option � Allows client objects to call the server component asynchronously.

The listen option - Makes the server component process client requests.
Now the actual COM+ component interface needs to be marked as queued.

Select the COM+ application (e.g., QCOM) -> Expand the COM+ application -> Expand the Components folder � Expand the COM+ component (e.g., qc.sm) -> Expand the interfaces folder -> Select the component interface to be marked as queued � Right click and go to properties -> Click on the queuing tab -> Select the queued property.

Note: If you see the queued check box disabled, check to make sure that all of component methods satisfy the method rules mentioned under the Requirements section above.

Work Group Mode Limitations

The work group configuration does not allow COM+ queued components service to support application security. Hence the security must be disabled on each of the COM+ applications accessed in this configuration. When you have the Microsoft message queuing configured to run in work group mode (as opposed to working with a domain controller) this can be accomplished by setting the authentication level of the COM+ application to none with the following series of steps.

Open the component services MMC snap-in.
Select the COM+ application -> Right click and go to properties -> Click on the security tab -> Select none for authentication level for call.

Example Application

Let us consider the example of an online employer registration process at a fictitious online job site. The registration process works as below:

Users (employers) can sign up on line by providing their details.
Users are not registered immediately. User submissions are queued and the administrative unit of the job site does manual checking on the authenticity of the employer company. An email will be sent to valid applicants with userid/password. The example code given below demonstrates user submission and retrieval out of the message queue at the server side. For simplicity, the server component simply writes employer details to a flat file NewEmployer.txt.

Assumptions

MSMQ is installed.
Both client (named ClientComputer) & server (named ServerComputer) are operating on win2k

Construction

Create the Registration User Interface

Save the following HTML to a file NewRegistration.html

<HTML>
<HEAD>
<TITLE></TITLE>
</HEAD>
<BODY>

<form action="ProcessRegistration.asp" method="post">

<table width=350 border=0 bgcolor="#2B61AE">
<tr>
   <td align=center colspan=2>
       <font size=+1 color=#FFFFFF>
       New Employer Registration</font>
   </td>
</tr>
<tr>
   <td colspan=2>
       <font size=+1>
        </font>
   </td>
</tr>
<tr>
   <td>
       <font color=#FFFFFF>First Name</font>
   </td>
   <td>
       <input type="text" name="FName" width=15>
   </td>
</tr>
<tr>
   <td>
       <font color=#FFFFFF>Last Name</font>
   </td>
   <td>
       <input type="text" name="LName" size=15>
   </td>
</tr>
<tr>
   <td>
       <font color=#FFFFFF>Company</font>
   </td>
   <td>
       <input type="text" name="Company" size=25>
   </td>
</tr>
<tr>
   <td>
       <font color=#FFFFFF>Email Address</font>
   </td>
   <td>
       <input type="text" name="EMail" size=25>
   </td>
</tr>
<tr>
   <td>
       <font color=#FFFFFF>Phone</font>
   </td>
   <td>
       <input type="text" name="Phone" size=10>
   </td>
</tr>
<tr>
   <td>
       <font color=#FFFFFF>FAX</font>
   </td>
   <td>
       <input type="text" name="FAX" size=10>
   </td>
</tr>
<tr>
   <td colspan=2>
       <font size=+1>
        </font>
   </td>
</tr>
<tr>
   <td colspan=2 align=center>
       <input type=submit value="Register">
       <input type=reset>
   </td>
</tr>
</table>

</form>

</BODY>
</HTML>

Keep this file in the IIS default root directory c:\inetpub\wwwroot (or any other directory that is accessible through the IIS) on the client computer.

Create the Server Side Component

Create a visual basic ActiveX DLL project to create the COM+ queued component.

Project name =qc

Class name =sm

Copy the following code into the sm class module.

Const FIELD_SEPARATOR = ""

Public Sub Save(ByVal FName As String, _
    ByVal LName As String, _
    ByVal Company As String, _
    ByVal EMailAddress As String, _
    ByVal Phone As String, _
    ByVal FAX As String)
    
    Dim FileID As Integer
    Dim DataLine As String
    
    FileID = FreeFile
    DataLine = FName & FIELD_SEPARATOR & _
    LName & FIELD_SEPARATOR & Company & _
    FIELD_SEPARATOR & EMailAddress & _
        FIELD_SEPARATOR & Phone & _
        FIELD_SEPARATOR & FAX
    
    '//Write the data to a database

    Open "c:\NewEmployers.txt" For _
        Append As #FileID
    Print #FileID, DataLine
    Close (FileID)
End Sub

Create the DLL (qc.dll).

Deploy and configure the above component qc.dll as queued, on the server computer as specified in the Deployment & Configuration section with the COM+ application name as QCOM
Export the COM+ Application

Open the component services MMC snap-in -> Select the QCOM COM+ application -> Right click -> Export (export as an application proxy)
Install the Proxy on the Client Computer.

Copy the exported .msi & .cab files on to the client computer. Install the proxy by simply double-clicking on the .msi file.

Note: Make sure that there is no COM+ application with the name QCOM already present on the client computer. Use a different name in step 3 above, if one is already present.

Create the Client Side Application

Save the following script to ProcessRegistration.asp on the client computer c:\inetpub\wwwroot directory

<%
dim fname
dim lname
dim company
dim email
dim phone
dim fax

fname=Request.Form ("fname")
lname=Request.Form ("lname")
company=Request.Form ("company")
email=Request.Form ("email")
phone=Request.Form ("phone")
fax=Request.Form ("fax")

�//specify the queue moniker

set obj=getobject ("queue:FormatName=DIRECT=" & _
   "OS:ServerComputer\PRIVATE$\QCOM/new:qc.sm")

obj.save fname,lname,company,email,phone,fax
set obj=nothing

%>

<center><font color=#cc0000>
Your registration information has been 
sent successfully.
<br>
Registration at our website requires 
manual verification.
<br>
We will contact you shortly.
</center>

Incase of the example setup, the component is created from a remote computer (i.e., client and server machines are different) and MSMQ is installed in work group mode and hence the queue moniker is specified using the DIRECT format name as

set obj=getobject ("queue:FormatName=DIRECT=" & _ 
  "OS:ServerComputer\PRIVATE$\QCOM/new:qc.sm")

Otherwise, the simple form of the moniker (as below) should work.

set obj=getobject ("queue:/new:qc.sm")

Testing

Access the URL http://ClientComputer/NewRegistration.html
Fill in the data and submit
A file should be created on the server side c:\NewEmployer.txt with the data entered.

The following steps outline the testing process for the scenario where the server is not available:

Shutdown the server computer
>Access the URL http://ClientComputer/NewRegistration.html again.
No error will be reported when the form is submitted. Method calls will be stored as MSMQ messages.
Now start the server computer.
Go to the component services MMC snap-in on the server computer
Activate the COM+ application.
1. Select the QCOM COM+ application � Right click � Start
The queued component processes queued messages and the new data will be appended to the data file c:\NewEmployer.txt.

Automated Component Activation

The activation of the queued component seems to be tedious as it involves manual intervention. This task can be automated with the following steps.

Create a VB project named StartApp. Add a reference to the COM+ Admin Type Library

Add a module to it and paste the following code:

Sub main()
Dim catalog As COMAdminCatalog

Set catalog = New COMAdminCatalog

catalog.StartApplication _
("{44AC1CF9-A6D2-4CF1-937E-BF1557F1FB50}") 
End Sub

The argument to the StartApplication method is the ApplicationID of the COM+ application to be activated. This can be got from the properties window of the QCOM COM+ application.

Set the startup object as Sub Main using the project properties window. Create an exe.

When run, this executable starts the specified COM+ application. It can be scheduled to run as required using the windows scheduler.

Conclusion

COM+ queued service is an exciting new feature in the world of component object model. It leads to a more scalable, easy to build and reliable asynchronous processing model for a web application. An important step in this direction would be to identify & analyze the areas of an application where asynchronous processing can be applied in the context of the business requirements of an application.

This article is aimed at providing the necessary details about queued processing for you to get started. This does not cover all aspects of the COM+ queued processing. As with any other technology, there is no better way to learn than hands-on experience. The best way to approach this topic is to start with small, simple applications and continue to explore the other aspects as you progress.

History

June 1st, 2003: First revision.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here