Contexts in JBoss Seam

One of the main goals when Seam was created at first was to offer an statefuf framework which would answer the requeriments coming from many web application developers of have a more web specific framework rather than a general one as it was, and still is, Spring.

I've been told many times that all that seam can do, spring can do too. While i don't disagree at this matter, i'll also point that seam does what is needed with much lesser effort. Everything needed for build a web application is already included in seam, so we can spend more time developing the actual web application than configuring it and searching for documentation of how to do some special really hard-to-find trick for something. At the end of the day, all you can do with a technology, you can do with other too, is only a matter of preferences and simplicity.

Among one of those things needed long ago in a web application and which wasn't easy to find was an special scope which covers not only an event, page or session, but a concrete use case, a group of actions and request made by the user for a determined bussines purpose. In seam, they've got this challenge and they created a new concept of context or scope, called "coversation".

When developing a web application is important to have clear this concept in the mind so we won't waste the time saved by the tools seam provide us into silly stuff like concurrent conversations errors and so on. Every now and then you'll probably see some process for create users implemented with an scope session or a process for display a simple list with scope conversation. Because of that i'll try to explain the different context we can use with seam, first of all, thanks for some of the info taken from the seam's reference guide.

1. Event Context
The event context is the “narrowest” of the stateful context, and is a generalization of the web request context, in fact, most commonly it corresponds to the lifecycle of a JSF request. Components associated with the event context are destroyed at the end of the request, but their state is available and well-defined for at least the lifecycle of the request.

2. Page Context
The Page context allows you to associate state with a particular instance of a rendered page. The state is initialized when the page is rendered and is accessible during any event originated from that page. The state is serialized in the client, what is means that is extremely robust with respect to multi-window operation and the back button. An example of this would be a clickable list, where the list is backed by changing data on the server side.

3. Conversation Context
The conversation context is probably the most important to consider in a web application developed using Seam. The conversation scope is a particular scope included in Seam which was not present into other framework is a slice of the HTTP session that is managed by Seam and associated with a sequence of pages through the use of a special request token (known as the conversation id). The conversation provides the developer the convenience of using the HTTP session without the memory leakage concerns, since the conversation has a much shorter lifetime and is kept isolated from other parallel conversations in the same session.

In order words, is a use case which covers a specific business requirement, using single or several pages for that purpose.

Please also consider that conversation can be nested inside another one, so we can have several conversational components running at the same time. Seam implements configurable conversation timeout, automatically destroying inactive conversations, and thus ensuring that the state held by a single user login session does not grow without bound if the user abandons conversations. Seam also serializes processing of concurrent requests that take place in the same long-running conversation context, in the same process.

Alternatively, Seam may be configured to keep conversational state in the client browser.

We chose to leverage the conversation for three reasons:

• to reduce the number of times the database needs to be queried
• to ensure the record remains managed by the persistence context while being edited
• to maintain the search criteria and pagination offset

Using the conversation has the added bonus of making previously viewed result pages load faster since the records are already sitting in the persistence context (i.e., the first-level cache). An example of this would be creating an order or user, returning an item or displaying a list where we want to make some actions like edit a number or a name.

4. Session Context
A session context holds state associated with the user login session. While there are some cases where it is useful to share state between several conversations, we generally frown on the use of session context for holding components other than global information about the logged in user.

In a portal environment, the session context represents the portlet session.

5. Business Context
The business process context holds state associated with the long running business process. This state is managed and made persistent by the BPM engine (JBoss jBPM). The business process spans multiple interactions with multiple users, so this state is shared between multiple users, but in a well-defined manner. The current task determines the current business process instance, and the lifecycle of the business process is defined externally using a process definition language, so there are no special annotations for business process demarcation.

6. Application Context
An Application context is familiar with the servlet context from the servlet specs. It is useful for holding static information as configuration data or metamodels. Alternatively it can be used to hold lists which are huge and have relatively little change like locations or users, in this case we avoid making more queries to database than needed and we should combine it with cache in order to render the results as fast as possible.