X
Business

Process requests more efficiently with the Asynchronous Invocation Application Block

The Asynchronous Invocation Application Block can help you boost efficiency and improve the user experience when you're calling XML Web services. Here's a look at how you can use the AIAB for your projects.
Written by William Sempf, Contributor

The Asynchronous Invocation Application Block (AIAB) is a sophisticated tool designed to handle calling XML Web services asynchronously. Its primary use is to back up large middleware structures that implement Web services where the architect doesn't want to use the standard StartFunction and EndFunction methods available with the .NET Web service proxy.

Getting started
You can download the AIAB from the Patterns and Practices pages on MSDN. You must load the project after installing the package and build the blocks using Visual Studio .NET or the command line SDK. You must also reference the resulting DLL in your project to utilize it, and you'll need an assembly reference on each file or form. The sample code in Listing A illustrates using various aspects of the AIAB:

The AIAB consists of six projects: the four namespaces listed above and two Windows services. The Windows services are the real magic behind the blocks. They represent the requesting and monitoring entities. Let's take a more detailed look at these pieces.

Basic components
Three intelligently designed components make up the AIAB, working together to perform a complex task in a highly scalable and configurable manner. These include a SQL Server database to save the state of the requests, the Windows services, and a series of classes to access these devices.

Database
The SQL Server database for the AIAB is designed to track agents and their requests, as well as the responses. It is accessed with the Data Application Block. As the ORM diagram in Figure A shows, the database stores RequestDetails by running ServiceAgent, referenced by the ServiceAgentExecutionDetail. RequestResults are stored in a lookup table for ease in customizing the block.


Figure A

Windows services
The two Windows services are what make the AIAB a deployment hassle. Installing Windows services is still fairly complex and not for simple projects. However, these services are well designed to request service and monitor for response, thus taking this functionality away from your application. Using StartFunction and EndFunction not only leaves your program with the programming, but it also leaves you with the coding.

Classes
The four classes provided in the sample code as part of the application block download for integration are used by our custom Service Agent. This agent is the middleware class that will do all of the invocation work at the business logic layer level. In the sample application included in the download, look at the code for the CustomizedServiceAgent (CustomizedSA.cs) for insight into use of the Command and Dispatcher classes.

The agent implements IServiceAgent and, essentially, calls Web services and stores a record of the request in the database. It is really a simple, straightforward system, all in all.

Usage strategy
Despite the simplicity of this system, however, deploying it is something of a strenuous exercise. It is not for the average project. In my opinion, this block is probably best utilized as Microsoft intended—as part of a deployment that includes Caching Blocks or Aggregation Blocks.

There are some situations where this block could become useful. For instance, if your product is an orchestration project in and of itself—a BizTalk clone—this block will save you many hours of coding time. But in the case of a project that just needs to call a single service in an asynchronous manner, the built-in start and end functionality inherited from System.Web.Services should be good enough. The state information for that implementation is stored in the local project memory space, whereas this system stores the state of the request in a SQL Server database accessible by other systems. This gives more power at a cost of higher complexity.

Final thoughts
Although the AIAB might not be the kind of sample code everyone needs on a day-to-day basis, it is a strong case for the Patterns and Practices team at Microsoft. The sample code provided and the database and static structure design are stellar examples of the "right way" to code for .NET.

Most important is the need to understand what is happening under the covers if you're using the Caching or Aggregation Blocks. When you're customizing, or just compiling and deploying, a real understanding of how this system works goes a long way toward solving potential problems.

So whether using this block for itself, implementing other blocks that ingrate AIAB, or just studying asynchronous schemes, the Asynchronous Invocation Application Block provides a feast of functionality and source code.








Editorial standards