One kind of stuff
28/05/06 17:21 |
Work
I’ve been looking at Seam
(http://www.jboss.com/products/seam) for a while and
recently attended a seminar with Gavin King himself
talking about it. However, I never really got around
to taking the plunge.
Wired Up And Fired Up were early adopters of EJB3 and have been using it now in production systems for over a year and, yes, it really is that much better. In fact, it is with great reticence now that we undertake any kind of legacy J2EE application work (unless it’s a migration to EJB3 of course...)
But for the most part we’ve stuck with a couple of old (and bad) habits when implementing web UIs. I think this was largely because I’ve been a web programmer since the days when a thorough knowledge of the state of state management was de rigeur and so any major abstraction on top of this just seemed to confuse the issue. To be fair, most web application frameworks *DO* confuse the issue.
Seam, it seems, will enable us to redress the balance a little bit. By leveraging the JSF component model we’re now looking forward to being able to create our own suite of web components as well as buying in components when required, however that’s not all...
Seam also extends on the three basic contexts typically available to web application developers (Application, Session and Request) and brings a new ‘unified’ context model to the table (Seam’s contexts are Application, Business Process, Session, Conversation, Page and Event).
Why more contexts? Well, if you as a developer are trying to track a user across several different requests, what do you do? Put something in the session and check for it’s existence? The problem with that is that the user is then precluded from performing similar actions in a different browser or tab at the same time. Also, you need to make decisions about session time outs and ensure that you clear out the session when the user starts doing something else otherwise your application tends to get horribly confused.
The Conversation context offered by Seam allows for this, it remains scoped to a browser window instance and is accessible across multiple requests.
The Business Process context effectively connects you into the powerful long-running, multi-user state management concepts afforded by a BPM engine, see Tackling complexity with crayons
While the Event context is roughly synonymous with the traditional Request and the Page context allows you to associate state with a particular page.
All the while Seam is working away in the background like a ‘state garbage collector’ cleaning up out of scope variables and abandoned conversations.
The main beauty of Seam though is it’s unification of the main concepts of EJB and JSF allowing you to bind Session Beans to page events and Entity Beans to the same page without the need for layers of facades, managers and locators. And all the while fixing a large proportion of those frequently encountered ‘back button’ issues and interrupted page flow problems (a problem for which we once even designed an ‘interruptible dispatcher’ based on a kind of request stack).
I’ve been at this for a little while now and, while there is a learning curve, I’m convinced that this is about as productive as Java Enterprise developers have ever been able to be.
Wired Up And Fired Up were early adopters of EJB3 and have been using it now in production systems for over a year and, yes, it really is that much better. In fact, it is with great reticence now that we undertake any kind of legacy J2EE application work (unless it’s a migration to EJB3 of course...)
But for the most part we’ve stuck with a couple of old (and bad) habits when implementing web UIs. I think this was largely because I’ve been a web programmer since the days when a thorough knowledge of the state of state management was de rigeur and so any major abstraction on top of this just seemed to confuse the issue. To be fair, most web application frameworks *DO* confuse the issue.
Seam, it seems, will enable us to redress the balance a little bit. By leveraging the JSF component model we’re now looking forward to being able to create our own suite of web components as well as buying in components when required, however that’s not all...
Seam also extends on the three basic contexts typically available to web application developers (Application, Session and Request) and brings a new ‘unified’ context model to the table (Seam’s contexts are Application, Business Process, Session, Conversation, Page and Event).
Why more contexts? Well, if you as a developer are trying to track a user across several different requests, what do you do? Put something in the session and check for it’s existence? The problem with that is that the user is then precluded from performing similar actions in a different browser or tab at the same time. Also, you need to make decisions about session time outs and ensure that you clear out the session when the user starts doing something else otherwise your application tends to get horribly confused.
The Conversation context offered by Seam allows for this, it remains scoped to a browser window instance and is accessible across multiple requests.
The Business Process context effectively connects you into the powerful long-running, multi-user state management concepts afforded by a BPM engine, see Tackling complexity with crayons
While the Event context is roughly synonymous with the traditional Request and the Page context allows you to associate state with a particular page.
All the while Seam is working away in the background like a ‘state garbage collector’ cleaning up out of scope variables and abandoned conversations.
The main beauty of Seam though is it’s unification of the main concepts of EJB and JSF allowing you to bind Session Beans to page events and Entity Beans to the same page without the need for layers of facades, managers and locators. And all the while fixing a large proportion of those frequently encountered ‘back button’ issues and interrupted page flow problems (a problem for which we once even designed an ‘interruptible dispatcher’ based on a kind of request stack).
I’ve been at this for a little while now and, while there is a learning curve, I’m convinced that this is about as productive as Java Enterprise developers have ever been able to be.
|