A: Most other web frameworks store all application state in the HTTP session, which is inflexible, difficult to manage and a major source of memory leak. Seam can manage business and persistence components in several stateful
scopes: components that only need to live across several pages are placed in the conversation scope; components that need to live with the current user session are placed in the session scope; components that require interactions from multiple users and last extended period of time (i.e., survive server reboots) are placed in the
business process scope. The advanced state management facilities allow us to develop web application features that are previously not possible, or very difficult, to implement.
A: Yes. Seam supports fine-grained user state management beyond the simple HTTP session. It isolates and manages user state associated with individual browser window or tab (in contrast, HTTP session is shared across all windows of the same browser). So, in a Seam application, each browser window / tab can become a separate workspace
that has independent history and context. Multiple user “conversations” can be supported for the same browser. This behavior is similar to that in rich client applications. To see this feature in action, just run the
booking example application and try to book several hotels via several browser tabs in parallel — you can see that each tabs retains its own progress in the booking conversation.
A: Yes, it is very easy to expose REST style bookmarkable URLs in a Seam application. In addition, the Seam
application can initialize all the necessary backend business logic and persistence components when the user loads that URL. This way, the RESTful URL is not only an information endpoint but also an application interaction start point.
Q: I heard Seam conversations are propagated through JSF POST request. Can I do redirect-after-post or even GET in the same conversation?
A: Yes, on both accounts! To use redirect-after-post, you just need to enable the
web.xml. To propagate a conversation through a GET request,
pass the conversation id in a request parameter named
conversationId. By default, GET (non-faces) requests always occur in a new conversation.
A: No, Seam has something much more powerful: a conversation context. The Seam conversation context is propagated across redirects (even when no long-running conversation is in progress), so you can use the conversation context to store success messages and the like.
A: A jBPM “wait state” is a continuation. Each node in a pageflow definition or node in a business process definition is a jBPM wait state. Speaking more approximately, you might like to think of the
conversation state as a continuation. (We do not usually talk in this kind of language because it is too mysterious-sounding and obfuscates simple concepts to make them seem more impressive.)
A: Seam 1.1 includes a Ruby on Rails style command line tool that makes it easy to set up a new Seam project, create some simple actions, and even reverse engineer a data driven application from an existing
IDE integration is also a major focus for us. JBoss Eclipse IDE provides a sophisticated, template-driven database reverse engineering tool
which can generate an entire Seam application in minutes and a graphical jPDL editor for editing Seam pageflows and workflow definitions. More to come, stay tuned.