Bogdan Crivat

Getting User Input

Web applications have advanced quite a bit in recent years. Although early attempts were purely informational (providing a magazine-style experience), modern Web applications are expected to be fully interactive. In fact, for many traditional, rich client applications where installation was difficult and time-consuming, distribution over the Web has become the perfect mechanism for reducing costs.

Cookies and Session State

Web applications are by nature stateless because they communicate with users using HTTP, which is a stateless protocol. However, all but the most simplistic applications need to maintain some kind of state as users make requests. ATL Server provides two features for managing this information: session state and cookies.

ATL Server FAQ

This chapter presents some of the frequently asked questions (FAQ) we’ve received about ATL Server. Many of these questions have been posted on various newsgroups. We’ve grouped them here by component. Some of the answers we present direct you to a specific chapter in the book or to articles posted on the Web. We’ve tried to keep the answers here as short and concise as possible. Whenever possible, we try to point you to a place where the information we’re referring to is presented in more detail.

Deploying an ATL Server Web Application

This chapter focuses on deploying an ATL Server Web application (or Web service) on your development machine or testing area. Although this chapter contains information on automating deployment to multiple machines, this system isn’t intended for deployment to production environments.

Interoperability with ATL Server Web Services

The idea behind Web services is to offer a lingua franca for communication between heterogeneous pieces of software over the Internet. This idea can work only as long as all the implementations respect the rules of the game. This means that for each given SOAP message, a SOAP payload generated by one implementation must be semantically similar to one generated by any other implementation.

Debugging ATL Server Applications

The MSDN documentation for ATL Server contains several articles on debugging ATL Server applications. They explain how to set a breakpoint in an ISAPI Web application or in a Web service, how to attach the debugger to the IIS process running a specific Web application, and how to trace debug information in a server-safe manner (i.e., using the WebDbg sample that comes with Visual Studio.NET to avoid blocking pop-up assertion dialog boxes).

Advanced Request Handlers

The ATL server infrastructure is designed so that you can easily choose the level of complexity that’s suited to your needs or that you’re comfortable working with. In this chapter, we explore ways of increasing this level of complexity and illustrate how doing so can help you develop your application.

Introduction to ISAPI Services

So far we’ve treated the ISAPI DLL as a request dispatcher. Your ISAPI DLL receives requests and hands off the processing to the appropriate application DLL. Your ISAPI DLL is also the place to expose your ISAPI services.

Securing Your Web Application

Security is one of the most important “features” of any Web application. All Server is designed for high-end Web applications and services, and these mission-critical applications almost always require mission-critical security.

ATL Server and Passport .NET

Passport is a unique service offered by Microsoft that allows users to create an identity that they can use to authenticate themselves with any Passport-enabled applications. This allows users the convenience of creating and using one identity across a number of unrelated applications. As a developer, instead of spending valuable development time developing an authentication system and user database, you can use Passport and focus your efforts on your application development.