Web Services: ATL vs. ASP.NET

Introduction

Both the ASP.NET and ATL Server frameworks represent the current state-of-the-art in processing HTTP requests on the Windows platform. Each of these frameworks builds upon the time-tested ISAPI architecture that emerged nearly a decade ago. ASP.NET and ATL Server map their file extensions to specific DLLs. The ASP.NET DLL is ASPNET_ISAPI.DLL. The ATL Server DLL is generated by the ATL Server, but for the most part, it is boilerplate code. One advantage ATL Server has in this respect is that you may actually review (and change) the raw ISAPI request-handling code for your particular application.

While you may use either framework to write generally equivalent applications, the standard trade-offs apply here. It's usually very straightforward to develop an ASP.NET application using a managed language and the ASP.NET Framework. However, you are at the mercy of the framework (though ASP.NET mitigates the flexibility issue by being very extensible). On the other hand, once your ATL Server application has gotten past IIS, it consists mostly of a bunch of DLL calls—a very high-performance proposition. ATL Server applications are written in C++, so you have a great deal of control, along with the requisite responsibility.

Description

The following table provides a brief summary of comparisons between the two frameworks.

Comparison Criteria	ASP.NET Web Service	ATL Server Web Service
Thread Pool Management	In-built	To be coded
Receiving and parsing SOAP messages from a client and sending out a well formed SOAP response to the client	In-built	In-built
Message Formatting and Encoding. Read www.ibm.com for more details on message formats, and strengths and weakness of each message format	Supports both Document and RPC[1] style messages for communication. This allows for flexibility and extensibility and a loosely coupled communication environment.	Supports only RPC encoded style messages. RPC encoding will soon be obsolete [2].
Caching and preserving global data	Use global variables or the in-built `Application` object.	Use global variables.
Performance No performance tests or comparisons carried out for evidence	Good	Because the code is written in native C++, the performance is expected to be better than managed code, i.e., ASP.NET.
Control over code	CLR acts as an intermediary, so generally we are bound by the framework. Nevertheless, .NET runtime is very extensible, and can be customized. Also, we will be using Managed C++, so we can also write blocks of unmanaged code in it, i.e., memory management routines can be coded instead of relying on the Garbage Collector. On a positive side, we can leverage all the features of the CLR. Any additions in future versions of the .NET framework can also be leveraged seamlessly.	Complete control over the code as we start from ground up.
Interoperability with other systems	Flexible	RPC-encoded messages are trouble for interoperability. This is because SOAP encoding has been implemented differently by different vendors.
Future support	Supported well	Might not be supported. See Conclusion in this MSDN article for details.
WSI complaint See http://www.ws-i.org	Yes	No

Conclusion

Both the frameworks are fairly effective when it comes to building Web Services, and both are comparable in functionality. The ATL Server and ASP.NET provide access to session state and support BLOB-style data caching and SOAP methods and headers.

It's generally much easier to get a Web Service going using ASP.NET. Writing managed code tends to be simpler than dealing with pointers and the other minutiae involved with C++ code. On the other hand, if you find yourself firmly bound to C++ without the option of going to managed code, or if you need very fine control of the code in your application, ATL Server is an attractive option for building websites and Web Services. It's important to note, however, that when "Indigo" (code name for the communications subsystem for the next release of Windows) was announced, Microsoft articulated the plans for migrating code from a variety of technologies to Indigo. These include ASMX, but not ATL Server.

[1] RPC – Remote Procedure Call.
[2] In the current SOAP 1.2 specification, Section 5 (which defines RPC encoding) is completely optional. More toolkits are moving towards doing doc literal–style Web Services, and are leaving out RPC encoding altogether.