Learn how to overcome a common scalability limitation of Web Services.
Based on an article by Josh Lane
Many of the first Web Services you create are likely to be synchronous, where processing for each service invocation is handled at the time of the invocation. However, Web Services of this sort can have scalability limitations. You can overcome these issues by using Microsoft Message Queue (MSMQ) with Web Services.
Imagine you've decided to implement a help-desk-request logging system for a large IT department as a Web Service. This web service defines a single public SubmitRequest() method. The user request is processed immediately, regardless of current server load or database availability. This can limit scalability and robustness.
|
You can solve scalability problems by changing the web service from a synchronous request model to an asynchronous request model, introducing an intermediate component into the request-logging architecture that can take requests rapidly and guarantee their eventual delivery.
Such an asynchronous system can be built using MSMQ, a middleware subsystem that comes pre-installed on all Windows 2000 and upwards. It provides a means of storing messages of arbitrary content for forwarding or retrieval in operating-system-level structures called queues. MSMQ queues are Distributed Transaction Coordinator (DTC)-aware resource managers, meaning that send and receive operations against a queue can operate within a COM+ transaction. You can access the full complement of MSMQ services from the System.Messaging API in .NET.
First, you need to build a component that's triggered when the request message queue on the server receives a help request. This component removes the message from the queue and performs the processing.
The trigger calls this method each time a new message arrives in the |
Create an MSMQ Trigger Rule and register the COM+ components using regsvcs.exe. Trigger rules allow your components to be invoked automatically as a result of messages arriving at the target queue. You can use MSMQ triggers to process queue messages instead of implementing a traditional queue listenener; be sure you understand the usage semantics of each option before choosing one.
New Rule (set up in the Computer Management Console): |
Here the public web service is responsible only for receiving incoming requests and writing them to the target request queue. This simple, fast operation minimizes the work performed by the web server and allows you to maximize precious web server resources and minimize client response times. Note the use of a local transaction instead of a COM+ transaction (which would be overkill since it involves only a single resource manager - the queue).
|
Also see Using MSMQ message triggers (PDF file)
No comments:
Post a Comment