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 

>> Because ATL Server is obsolete, as in "has no future". The present is WCF.
 
WCF (Windows Communication Foundation) is targeted on the .NET. Does it provide similar access to the system level development as ATL server does?
 
>> Last, if absolute maximum network performance truly is critical to your project then
>> maybe you should consider something different than a SOAP/XML-based protocol, perhaps roll your own binary protocol over the socket API?
 
That is precisely what we do. The problem is that small company can not afford making all "bells and whistles" available in the standard server “from scratches”. The right way is to use a majority of standard functionality from the standard server environment, and use a custom code in the most important and critical parts.
 
As far as I understand, things, as they evolve over the years in MS, are similar in both server development and client development areas. MS introduces more and more features which are not required for the majority of developers, and will never be not only used, but not even be learned by the developer communities. And the major problem here is not a qualification of developers, and not even their ability to “digest” new technologies, but the progressively increasing tendency in the so called “novel technological” solutions:
a. To reduce an access to the development at the system level
b. To reduce inheritance / succession between earlier existing technologies and the new ones.
 
The main positive idea of this article, as I see it, is that there exists still an alive technology, ATL server here, which allows developing server applications at the system level and provides at the same time a good set of standard features. That is crucially important in the number areas.
 

>>How many thousands messages per second does your application requires?
 
We are working on the HD video streaming down and up. It has to be highly scalable solution, by the factor 10^1 – 10^2 at least. So the number of messages may be in the range up to 10^4 probably per one server unit. But as far as we see, the main problem in our case is not a number of messages to be served but an effective utilizing of IP transmission bit rate , up to the last drop. That is where a low level socket programming becomes a “must do” approach.
 

V.S.
 
www.DiscoveryBiz.net
GeneralRe: ATL Server is obsolete Pinmemberaxelriet7-Nov-07 11:24 
GeneralRe: ATL Server is obsolete PinmemberV.S.8-Nov-07 6:14 
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
Web04 | 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