Flex And Session State Management

One question that keeps coming up when presenting Flex (especially to those porting existing apps to Flex) is "how do I maintain session state in a Flex application?".

This is an interesting question. Interesting less because of the problem itself, and more because it demonstrates just how webified we have become. So, let's step back a bit ...

Web apps (powered by ColdFusion, ASP, JSP, PHP, or just about anything else) often need to maintain session state. If a user logs in you need to maintain that information so that it persists across requests or else the user will be prompted to login on each and every request, if a user puts items in a shopping cart that cart must be stored within a user session or else the cart will be empty each time the page changes, and so on.

The reason that session state needs to be maintained is because the web is stateless, each request stands on its own two feet, and within a request there is no awareness or knowledge of prior requests. Each time a page is requested a connection to the server is made (often multiple connections) to retrieve the needed elements, and then that connection is broken. This allows HTTP servers to respond to lots of traffic (far more so than if connections were always kept open), but the down side is that web pages are not aware of any activity performed by the same client previously.

To allow data to persist in the stateless web we've grown accustomed to taking advantage of what might be best described as a hack. In web apps, data to be persisted is stored on the server, so that it'll be present on subsequent requests. Of course, this necessitates that there be a way to associate a specific block of data on the server with a specific client, and so web applications (or application servers) create session identifiers which are sent to the client, and which must be sent back to the server on every subsequent request. These identifiers are most frequently stored in cookies or embedded in URL tokens or hidden form fields. But where they are stored is less important then the fact that they are needed, and must be submitted from the client (the web browser) back to the server on every subsequent request or else session state will be lost.

Life was not always this convoluted, things used to be simpler. Desktop applications and client-server apps never had to rely on state being maintained on the server. In those apps the client itself is stateful - it is not a set of loosely coupled scripts sitting on a server, rather it is an actual application running on the client, an application which does not completely reload when items are selected or clicked on. Requests are indeed made back and forth between the client application and the server as needed, but the client is always present and always running. And so preferences can be stored on the client, as could shopping cart contents, as could login details.

In other words, session state management is not preferred behavior at all. Rather, it is an unfortunate side effect of how the web operates, a way to compensate for the statelessness of the web.

Now back to Flex. Flex applications (or more rightly, Flash applications) are usually served by web servers and run inside of web browsers. But Flex applications are functionally a lot more like client-server applications than they are web applications. Like desktop client-server applications, Flex applications are loaded and the remain running as long as the app is in use. Like desktop client-server applications, Flex applications connect to back-ends and request or interact with data as needed. Like desktop client-server applications, Flex applications do not suffer the limitations of running in a too-thin client. And like desktop client-server applications, variables defined once in the app can remain defined, and objects instantiated can remain so (until you kill them, or until the application terminates).

In other words, Flex apps are stateful, much like desktop applications and client-server applications. If you need to remember user preferences, just create a variable or object to store these in and keep it around for the duration of the application execution. If you need to track shopping cart contents, keep these locally within the Flex app until checkout time when they'll be submitted to the server. And so on.

(As a side note, if you need to maintain values across application usage, then you can even store values locally in local shared objects - the Flash Player's equivalent to browser cookies).

So, the answer to the question "how do I maintain session state in a Flex application?" is "as a rule, don't!".

 

Comments (1) | Trackbacks (0) | Print | Send | del.icio.us | Linking Blogs

 

Related Blog Entries

 

• Flex And ColdFusion Session Variables (November 15, 2007)

TrackBacks

There are no trackbacks for this entry.

 

No trackback URL. Trackbacks are only allowed via interactive form.

 

[ Add Trackback]

Comments

[ Add Comment] [ Subscribe to Comments]

Without a server side session, how does a server know if a client is timed out and instruct it to re-authenticate? The server doesn't even know what client a remoting request comes from without keeping track of sessions. Simply put, if there is no sessions, there is no session time outs.

Also, Flex data services are implemented as servlets. It means a remote server call is still over HTTP, albeit in binary form. To the server exposing a service, there is no difference if the client is a flex app or a web app. While a flex app is a rich client, you can't do away server side sessions. It's simply an illusion.