In March, OnJava.com published JBoss Seam, an article by Thomas Heute that gives a quick introduction to Seam from the Seam project lead at JBoss. Last week, DevX published Discover Seam and Sew Up Your Java Projects Faster than Ever, an article by Mark Smith, which describes Seam from a user's perspective.

Seam is an application framework intended to bridge the gap between JSF, the web layer, and EJB 3.0, the persistence layer. It defines several contexts that can hold objects for the application:

• Stateless context - for stateless objects, primarily stateless session beans
• Event (or request) context - for objects associated with one web request
• Page context - for objects associated with one instance of a rendered page (including during the initial rendering and any subsequent incoming events from the page)
• Conversation context - for objects associated with unit of work for one user. A conversation may span several web requests and database transactions
• Session context - for objects associated with the user's login session
• Business process context - for objects associated with a long running business process, which may involve multiple users, web requests, and database transactions
• Application context - the servlet context, useful for storing static information, such as configuration data

Seam enables you to mark up your classes with annotations that will cause Seam to inject components from a context, and—since these are stateful components—to "outject" components back into a context.

The notion of conversation is central to Seam. From the Seam documentation:

A conversation holds state associated with "what the user is doing now, in this window". A single user may have multiple conversations in progress at any point in time, usually in multiple windows. The conversation context allows us to ensure that state from the different conversations does not collide and cause bugs.

Managing conversational state has been challenging to web application developers, because the browser back button allows a user to back up to previous pages (which may represent earlier states in the conversation that are no longer valid). In addition, the user can open up multiple windows and attempt multiple conversations at the same time. If you save conversational state in an HTTP session object between requests, that state may be out of sync with the browser if the user hits the back button. Moreover, if a user attempts to hold two conversations of the same type at the same time in two browser windows, the state of those conversations may collide.

Seam addresses this challenge by giving each conversation an identity and associating conversational state with the conversation, not simply the user's session. What do you think of this idea? What other approaches have you taken that deals with the problem of tracking user conversations over HTTP?