Click here to Skip to main content
Click here to Skip to main content

Web Services: ATL vs. ASP.NET

By , 4 Nov 2007
Rate this:
Please Sign up or sign in to vote.

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.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

About the Author

Aman Sura

India India
No Biography provided

Comments and Discussions

 
GeneralATL Server is obsolete Pinmemberaxelriet5-Nov-07 4:31 
GeneralRe: ATL Server is obsolete PinmemberV.S.5-Nov-07 7:05 
GeneralRe: ATL Server is obsolete Pinmemberaxelriet5-Nov-07 12:36 
GeneralRe: ATL Server is obsolete PinmemberGeorge L. Jackson5-Nov-07 14:21 
GeneralRe: ATL Server is obsolete PinmemberV.S.7-Nov-07 5:39 
GeneralRe: ATL Server is obsolete Pinmemberaxelriet7-Nov-07 11:24 
GeneralRe: ATL Server is obsolete PinmemberV.S.8-Nov-07 6:14 
Thank you, Axel.
V.S.
GeneralRe: ATL Server is obsolete Pinmemberaxelriet20-Nov-07 1:52 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web01 | 2.8.140415.2 | Last Updated 5 Nov 2007
Article Copyright 2007 by Aman Sura
Everything else Copyright © CodeProject, 1999-2014
Terms of Use
Layout: fixed | fluid