Often, web applications require storage of user-specific session state at the server. Depending on the application setup, the server will typically issue a session id which is mapped to the user-specific state data on the server. The session id is either transmitted as cookie or encoded in the URL and sent back to the server with each request the browser makes until the session is invalidated (explicitely by code or by timing out) or the browser is closed. Traditional Web applications with integrated AJAX features, utilize the session managament options of their underlying technologies; they work just as when using the base technology without AJAX enhancements.
The ultimate flexibility of an DHTML-only UI, however, comes at a price: All server calls are stateless by default, and there is no built-in mechanism to establish a user session. At QAT we typically use two approaches with great success: Integrate with a server-side technology that offers session and security management (like ASP.NET or JSP) or use the QAT WebDaptive Session service. Each of these solutions has their advantages, and sometimes we even use both at the same time. I will go into detail in my next posts.
- Anke
Written by: Anke Doerfel-Parker |
Connect with us: