Seam is one of the newer frameworks that has been gaining in popularity recently.  It was created by Gavin King who will already be familiar to Hibernate users.  It’s based on POJOs (Plain Old Java Objects) known as components and annotations for those components that reduce the need for extensive xml configuration files.  The components are wired together using dependency injection where components declare their dependencies, and Seam looks after getting the the components needed and injecting them for you.

While it’s still nowhere near as widespread as Spring, it brings some functionality that was missing in Spring, and can complement or replace Spring depending on what features you value in your web application.  From first experiences using the framework I can see many benefits to Seam, but would caution that it’s not quite so easy to use as some of the documentation might lead you to believe.  It can solve the problems it was designed to fix, but you have to be careful that you not only understand the problems, but also the solutions being applied.  You really need to code your application in a way that allows it to make use of what Seam is able to do well, otherwise you may inadvertantly bypass what you wanted.  If you don’t really understand the nuances of how Seam is solving typical problems, chances are your code isn’t going to be able to take advantage of what Seam does offer.  The other disadvantage is that in being able to use the framework in many different ways, a beginner can have trouble figuring out which way is best to implement something for their own particular scenario.  If you have a lot of very experienced developers on your team, these won’t be such big issues.  But it’s something to be aware of if you don’t already have Seam experience on the team.

So what problems is Seam supposed to solve?
One of Seam’s purposes is to fill in the gap between using JSF for the web tier which is usually based on stateless simple requests and responses, and EJB3 for the business tier which can deal with transactional resources.  Ordinarily to use these two frameworks together you need to write extra configuration code and backing beans.  Seam annotations allow business components to be used directly by the front end.  You use Entity objects to represent data that is mapped to a relational database table.  JSF web pages can display and capture data using the JSF Expression Language (EL) and map the data directly back to the backend.  You then have handlers that can update the data or perform business logic. There are also some extra seam tags available to use that fix some issues with JSF tags.

Another thing Seam brings to the table is more than just a Session scope or context.  The most interesting one being the Conversation scope.  The extra scopes mean that less data is stored in the session and can be managed in a wiser manner. More on the conversation scope another time as it’s a big area to get your head around.

The next solution Seam offers is to help end the LazyInitialization exceptions seen when using Hibernate (which was designed for use in Stateful applications) or other ORM (Object Relational Mapping) solutions with a Stateless framework.  These LazyInitialization exceptions occur because Hibernate is based on using objects containing data that can have other associated objects.  Lazy loading is used to avoid fetching large amounts of data that might not be used when loading a parent object that has other child objects associated with it.   The associated child objects are not loaded unless specifically requested.  But we run into a problem in a Stateless framework as the persistence context is destroyed once the parent is passed to the presentation layer.  If the presentation layer requests a child object, then a lazy loading exception is thrown as the persistence context is no longer available for the second request.  This means that DTOs (Data Transfer Objects) have to be used. Seam can keep the persistence context open until a page is fully rendered, or longer across a number of pages or a session.  So there should be no lazy loading exceptions and the performance improves when changes are only flushed to the database at the end of a conversation.

These are some of the main reasons why you might choose to use Seam in a project.  There’s a lot to cover in the Seam framework however, so this only scratches the surface before going into more detail in each area.