BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

JBoss Seam 1.1 Indepth: An Interview with Gavin King

by Floyd Marinescu on Nov 21, 2006 |
Seam 1.1 CR1 has just released, with the full GA coming within a couple of weeks. Major new changes include the ability to run SEAM without EJB making it useable in any appserver and even Tomcat, a new concurrency model, ICEFaces/Ajax4JSF integration, and Rails-like code generation/command line tools.

InfoQ spoke to SEAM creator Gavin King (who is also speaking at the QCon conference in London in March) to go indepth on the new release and what matters. For more background context, see also InfoQ's Seam 1.0: Rethinking web application architectures coverage.  

Gavin talked about what's new and cool in SEAM 1.1 from his perspective:
First, platform support. Seam 1.0 was extremely well received in the JBoss community and has been adopted by lots of JBoss users and also by quite a number of people who use Seam with Hibernate on Tomcat. There are also a few people using Seam on GlassFish today. But there were some teething problems on GlassFish, and it just plain didn't work on J2EE environments like WebLogic. We heard a huge amount of feedback that people wanted to use Seam, but couldn't because they were stuck on an application server that did not yet support EJB 3.0.

So, Ram Venkataraman (one of the product managers at JBoss) called me up and knocked some sense into my stubborn head. I was arguing that EJB 3.0 integration was a central part of the vision and that we would look confused and silly if we started to back off of that. He finally said "you know as well as I do that Seam works anywhere!". Well, that was not quite true then, but it is true now. You can even run it on WebSphere.

Second is the new concurrency model. With the death of the old paradigm of coarse-grained synchronous request/response, the assumption that concurrent requests in the same session are very rare is totally turned on its head. It's now absolutely essential to have strong constructs for managing session-level concurrency.

Third is the integration of ICEfaces and Ajax4JSF. Seam is the killer platform for Ajax. Without a conversation model, Ajax can't possibly scale. Most people don't realize this yet. If all those little fine-grained requests have to hit the database each time, you are in trouble. You need to have contextual state cached on the server, either in memory or on local disk.

Fourth, James Williams (one of the SEs at JBoss) has got Rails envy and wanted us to have a commandline tool. Much earlier on, I had put together an Eclipse-based reverse engineering tool using Hibernate Tools that could create a Seam application from an existing database, but I was never really happy with it. The generated code was over-complex and we did a bad job of keeping it up to date with Seam releases. So, I put together a simple application framework (think of it as a DAO framework if you like), James built a Grails-style commandline tool using Ant, and we merged the code into the main Seam distribution. It's now super-simple to get started with Seam, create a project, create some simple actions, reverse engineer an application from the database.

There are too many other new things to list. Asynchronous methods, an enhanced XML configuration format, atomic conversations, features for building RESTful applications, much more.
SEAM developer Michael Yuan also blogged more about SEAMs POJO component model (an alternative to EJB), eliminating the appserver dependency.

Asked about Atomic conversations, Gavin explained:
An atomic conversation is basically a conversation where you can make changes to your persistent objects over many requests to the server, but those changes only become persistent when the conversation ends (or at some other well-defined point). This is a really common thing to want to do in Ajax-based applications.

The first thing to consider is that it only works with Hibernate. We fought really hard to get this functionality into the EJB 3.0 spec, along with Sun, Sybase and others. Some other members of the expert group decided they didn't like this stuff or were scared of it because they didn't quite understand it completely and they blocked it, and that is a real loss to the community. Hibernate offers this feature as an extension to the spec. Seam 1.1 supports this in its conversation model, but only when Hibernate is the underlying JPA provider.
SEAM also improved it's clustering abilities for developers building apps using POJOs:
The most important thing is that Seam-managed persistence contexts (these are conversation-scoped persistence contexts) can be clustered extremely efficiently, without the need for a lot of state replication. We can actually do this more efficiently than the EJB container can cluster extended persistence contexts, because the EJB3 spec requires certain behaviors that it probably doesn't need to require (we will try to get this changed in the next rev of the spec).

If you're already using EJB stateful session beans, not much else is new in the clustering model. But if you aren't using EJB, you don't have stateful session beans, and you have not traditionally had good constructs for holding state across requests in a clustered environment. But we wanted people stuck on J2EE application servers to be able to use Seam! This meant that we had to really work on a model which would support efficient clustering of plain JavaBean components, for people who couldn't use stateful session beans. So now we have a solution which is not quite as efficient as SFSBs in JBoss, but at least can be used anywhere
On the new concurrency model in Seam:
The most important element of it is that Seam serializes the processing of all requests that take place in the same long-running conversation context, on the same machine. We also provide robust constructs for serializing access to components that have a scope larger than a conversation (eg. session scope). Note that Java synchronized keyword does not count as robust since it has no deadlock detection.
Gavin told InfoQ that Seam has been well adopted within the JBoss community and is recieving over 5000 downloads a month. One reason it never got far out of the JBoss community is because Java EE 5 support is not yet widely available across the appserver ecosystem, which is why the EJB 3 dependency was made optional in Seam 1.1.   Gavin compared Seam's current maturity and community as the early days of Hibernate, except that:
What is completely different about Seam is that people have started to build really serious and interesting large-scale applications with it, right off the blocks, because for certain types of requirements you almost can't live without it. If you're using jBPM for business process management in a web application, you're crazy to not use Seam. If you already use EJB 3.0 and JSF, Seam will simplify your life so much that you would be silly to not use it. If you want to build an Ajaxified JSF application using ICEfaces or Ajax4JSF, you will run into all kinds of performance and concurrency problems if you don't use Seam. And there is simply no comparable alternative solution for any of these cases, apart from build-it-yourself.
Talking abut specific interesting customer use cases, Gavin mentioned Lexicon Genetics, a life sciences company who built a workflow management system Seam and JBPM for managing the lifecycle of batches of mice used as test subjects. Another example is Nuxeo 5 who migrated their popular content management product from Python & Zope Java with Seam (see InfoQ coverage). "Their comment was that Seam helped them get their new platform up and running in just a few months. These were guys who were coming from a Python/Zope background, they were used to a highly productive environment. So don't let anyone tell you that enterprise Java can't be productive. A lot has changed in the past 18 months."

Gavin acknowledged that "the riskiest bet we made with Seam was picking JSF for the view layer," particularly considering the poor adoption and perception it had in the community at the time. JSF had no clear Ajax strategy and had some missing features Seam had to find workarounds for.  However, looking back Gavin explained how the choice to use JSF worked out for the better:
The bet paid off. JSF created an ecosystem of quality addons like Facelets, ICEfaces, Trinidad, Ajax4JSF, RCFaces, Seam, XULFaces, etc. A lot of this stuff is starting to get really mature and the various projects are talking to each other and trying to make sure everyone works smoothly together. This is exactly why you need standards. Without the JSF standard I would have had to have built JSF, Facelets, ICEFaces and Seam from scratch by myself. This would have taken a really long time. That's exactly why there is no comparable ecosystem for any of the other web frameworks out there. So JSF has leapfrogged the competition in the past year. The recent opensourcing of ICEfaces ups the ante again.

Look around. No other programming environment in any language offers anything remotely as rich in terms of user experience, back-end grunt, developer productivity, scalability, operational manageability as the stack of Facelets/ICEfaces/JSF/Seam/jBPM/EJB3/JavaEE. Ruby on Rails is so 2005.
Gavin also clarified the difference between Seam and the Web Beans (JSR 299). Web Beans is a JSR to formalize some of the same ideas that were implemented in Seam into the JCP standards. JBoss will provide the RI for Web Beans, based on the Seam codebase. "It's much too early to say how similar the final specification will be to what you see in Seam today."

Future versions of Seam will focus on Seam/Security and Seam/WS:
Seam/Security is a dynamic ACL-based security model for Seam that Shane Bryzak is building on top of Drools. Today, Java EE security is a disaster, and one of the weakest links in the platform (along with the truly atrocious Servlet spec)."

Seam/WS brings Seam's conversation, orchestration and stateful component model to SOA. You'll be able to write stateful components that take part in a Web Services conversation, and orchestrate the conversation using jBPM. Of course you'll get all the same nice Seam functionality that people love so much using Seam for web applications.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Cool by Rick Hightower

Seems like a good release. I need to try things out. I work with some people who love Seam. It seems nice.

Seam/Security by Matt Raible

Why build Seam/Security when Acegi Security works so well? You chose JSF because of its ecosystem? Why not choose a proven security solution like Acegi?

after reading this, I feel a bit dirty by matthew hawthorne

I find Seam and a lot of the surrounding concepts very interesting -- but to me, the tone of Gavin's comments are a bit too "sales-pitchy".

Stop spending so many words telling me that Seam is great. Spend some more energy just telling me what it does.

Re: Seam/Security by Gavin King

Why build Seam/Security when Acegi Security works so well? You chose JSF because of its ecosystem? Why not choose a proven security solution like Acegi?


We looked very closely at Acegi and eventually rejected it for several reasons:

(1) It is tightly coupled to Spring, and not trivial to "untangle"
(2) We decided it just doesn't have the ease of use that Seam "tradition" demands
(3) Along the way we had a some really cool ideas (at least we think they are cool) that pushed us in a different direction

Of course, if Acegi would provide EJB3 support, people would be able to use it with Seam, but so far I have not heard that they are interested in doing that.

Note: this was an answer to a question, not a diss to Acegi, which from all accounts is a very capable solution.

Re: after reading this, I feel a bit dirty by Gavin King

Stop spending so many words telling me that Seam is great. Spend some more energy just telling me what it does.


You can find that information here.

Re: Seam/Security by Dan Diephouse

Why build Seam/Security when Acegi Security works so well? You chose JSF because of its ecosystem? Why not choose a proven security solution like Acegi?


There seems to be this opinion that Acegi is the end all be all of security. While it works, I find it hard to understand and hard to use. And I don't think thats the type of thing you want in your security framework, as you're bound to configure it wrong. So I really can't fault anyone for coming up with something different... There is more than one way to skin a cat, let many flowers bloom, etc etc

Re: after reading this, I feel a bit dirty by Matt Raible

I agree Acegi is not as easy to configure as it could be. I also agree that "Java EE security is a disaster". Hopefully your solution turns out to be easier to configure, as well as useable in projects not using Seam.

Re: after reading this, I feel a bit dirty by Gavin King

I agree Acegi is not as easy to configure as it could be. I also agree that "Java EE security is a disaster". Hopefully your solution turns out to be easier to configure, as well as useable in projects not using Seam.


Hum, this is not a goal of the work we are doing now, and to be honest it had not thought about it. The thing is we plan to leverage a lot of existing Seam functionality to build it, so I'm not sure how easy it would be to do the separation. Perhaps if it turns out to be really popular, we can revisit the question later...

Tried Seam, loved it on first sight. by Maurice Zeijen

I have been playing with Seam the last couple of months. Except for setting up a project (configuring everything so that it works together like jsf with facelets) it is a very cool and easy framework. That is a very strong point of the framework. It is easy but still versatile. I loved it so much that I made my colleagues try it out also. Now they love it too. Our next project will probably be build with Seam.

I haven't gotten the time to try out the new Seam release but I hope that setting up a project has gotten easier. It would be really great if Seam would use Maven2. This tool would just be perfect too solve those problems. It would maybe be a little too much to ask to adopt the complete Maven2 philosophy because that would mean that the whole seam project structure would need to be restructured. But offering some archetypes would be great. This way the Maven2 user can setup a project very easily. There are some forum posts on this but nothing official.

Re: Tried Seam, loved it on first sight. by Gavin King

I haven't gotten the time to try out the new Seam release but I hope that setting up a project has gotten easier.


seam-gen makes it *super* easy, at least for EJB3 on JBoss users. We will be working on expanding the functionality of seam-gen to support other usecases (JavaBeans+Hibernate, Tomcat, J2EE, etc).

It would be really great if Seam would use Maven2. This tool would just be perfect too solve those problems.


I don't really know Maven, but I do know that setting up something really re-useable would be a lot of work. For now, there are other higher priorities. Perhaps this is something that the community could work on...

Acegi, JBoss, and the JBoss microcontainer Re: Seam/Security by Rick Hightower

Gavin,

Of course you might be right. But I've worked with Acegi a bit, and I think all it needs from Spring (mostly more explanation later) is the Spring "container". Could't you use Acegi with the JBoss Microcontainer (which looks very similar to Spring IoC support)?

Then Acegi provides several interception models: Spring (AOP Alliance), AspectJ and the Servlet Filter. You could use an EJB 3 method interceptor with an EJB 3 pointcut.... Oh wait... EJB 3 does not have pointcuts. (cheap shot) Couldn't you just write a JBoss AOP interceptor in its stead?

How else does Acegi depend on Spring? According to the docs, the dependencies are minimal and mainly around the need for Spring style configuration which you could accomplish with the JBoss Microcontainer.

One reason the Spring project is so popular is they don't seem to feel the need to reinvent the wheel. They seem to like to integrate with best of breed solutions (like Hibernate, Acegi, Quartz, etc.).

Acegi, Easy to setup by Rick Hightower

Acegi not being easy to setup might be an understatement. They are adding XML schema support in the next version (but you already know that). Although, it may not be enough since the reason that is so hard to setup is b/c it has so many options (which is a real good thing).

(Another reason it is hard to setup is the constant refactoring where they change the class names from .9 to 1 to 1.1.)

See you in Florida....

Re: after reading this, I feel a bit dirty by Rick Hightower

If your biggest complaint about Seam is that its Sales-Pitchy, then I guess Gavin is doing a really good job. (I always felt it was too tied to EJB3, but I guess that is not the case anymore).

It is nice to know that countless hours (blood, sweat and tears) are spent producing a "free" framework, and its marketing bothers you.

It is likely that some other sales-pitchy person keeps you employed so you have time to go online and bust b@lls.

Re: after reading this, I feel a bit dirty by Paul Rivers

Rick,

I think you're going off into "cranky comment land". Mattew commented about the article, and said nothing about Seam itself, which doesn't seem to have prevented your from taking it as both personal attack and as an attack on Seam in general, which it was neither.

He said that after reading the article, he felt a bit dirty. I agree 100%. I was hoping to find out what Seam does, and this article is a lot less informative than I like.

It's been very well received in the JBoss community!
But what does it do?

We changed it so it doesn't require EJB 3.0!
But what does it do?

It integrates with ICEfaces and Ajax3JSF! It's great for ajax!
But what does it do?

We built a command line tool to use Seam! It works with Ruby on Rails and uses ANT! It's very easy to get started with!
Great...but what does it do?

There are too many other new things to list. Asynchronous methods, an enhanced XML configuration format, atomic conversations, features for building RESTful applications, much more.
What does it DO?

Seam-managed persistence contexts ... can be clustered extremely efficiently...if you're already using EJB beans...conversation scope...
What does it do, though?

What is completely different about Seam is that people have started to build really serious and interesting large-scale applications with it, right off the blocks...
What does it do?

JSF created an ecosystem of quality addons...maturity...No other programming environment in any language offers anything remotely as rich in terms of user experience, back-end grunt, developer productivity, scalability, operational manageability as the stack of Facelets/ICEfaces/JSF/Seam/jBPM/EJB3/JavaEE...
What does it do?

Gavin also clarified the difference between Seam and the Web Beans (JSR 299). Web Beans is a JSR to formalize some of the same ideas that were implemented in Seam into the JCP standards.
What "same ideas"?

Future versions of Seam will focus on Seam/Security and Seam/WS...
Again, what does it do?


I'm kind of offended that you took the original comment as some sort of personal attack against Gavin or SEAM. Personally, I met Gavin when he did a talk here in Minnesota, and the poor guy seemed waaaay overworked. He talked about how it was really to bad that with so many users, he and others on the project just didn't have time to answer all the posts that they wanted to on the hibernate forum because there were simply waaaay to many to have the time to respond to. He seemed like a really great guy. And project-wise, I've been using Hibernate for a couple of years. I want express my appreciation for all the time the hibernate team has put into writing it, fixing it, updating it, and giving me someone thing learn that looks good on my resume that's used in half the jobs I'm currently interviewing for! Thanks!

Hibernate has a long tradition of being less "hypey" and more "Look, this is what Hibernate does and doesn't do well. If something else does better and you'd rather use it, go for it." It's one of the things that usually makes reading about hibernate enjoyable.

But this particular article gives me no motivation to try out Seam, as it doesn't tell me what problem Seam actually solves.

Re: after reading this, I feel a bit dirty by Rick Hightower

I guess I see your point. Seems the article was a teaser to get you to read the manual.

Re: after reading this, I feel a bit dirty by Floyd Marinescu

Matthew, I did link to an background article where we explained what Seam is and the motivations of it, see InfoQ's first interview on Seam

Re: after reading this, I feel a bit dirty by Floyd Marinescu

Guys, I had linked to InfoQ's last interview about Seam in the first paragraph for background, but perhaps I should have included some of the intro material here:
SEAM represents a redefinition of web application architecture that extends the POJO + annotation-driven and configuration-by-exception programming model of EJB 3.0 into the entire web application stack, while unifying JSF, EJB, AJAX, and business process management (jBPM) into one tightly-integrated framework.

Seam, JBoss Rules and JBoss Workflow by paul browne

I'd highly recommend Seam on the basis of it's integration with JBoss Rules and JBoss workflow alone (separate projects , will also run well on non-JBoss app servers). It's addressing the same problem spot (faster development of Web and other applications) that Ruby / JRuby does , but in an Enterprise Manner.

My biggest reservation is similar to the Acegi-Security Post: at the moment , I feel I am being forced to choose between Spring and Seam , whereas I just want to be able to use the best of both

Paul , Technology in Plain English

Re: Seam, JBoss Rules and JBoss Workflow by Joost de Vries

Hear, hear. Outside of jBoss Spring is the de facto DI framework. So it's a bit of a pain to have a second DI model by just choosing SEAM, which I really want to.

Re: after reading this, I feel a bit dirty by Gavin King

I was hoping to find out what Seam does, and this article is a lot less informative than I like.


I'm sorry you didn't like the interview. I tried to answer the questions that were asked as clearly and as honestly as possible. I think probably Floyd and I were doing this from the perspective of someone who already knows what Seam is and is interested to get uptodate on the latest activity of the project.

I wish I could give you a one liner explanation of what Seam "is", like I can say "Hibernate is an O/R mapper", but that works OK for Hibernate because people already know what an O/R mapper is or does, whereas Seam is kinda in its own niche.

But let me take a shot:

It is a web application framework built around JSF.
It is an integration layer for technologies like JSF, EJB3, jBPM, Drools, Hibernate, WS, ESB.
It is a stateful component model that is designed to support conversations, orchestration (of pageflow, business process and eventually WS conversations), transactional resource access and direct binding to the view layer.

But I think its fair to say that this doesn't go far toward capturing the whole picture. The best way to learn is to check out the sourcecode of the booking demo, the dvdstore demo, the contactlist demo, and think about trying to reimplement the functionality of these applications in whatever frameworks you are using today.

Re: Seam, JBoss Rules and JBoss Workflow by Gavin King

Outside of jBoss Spring is the de facto DI framework. So it's a bit of a pain to have a second DI model by just choosing SEAM, which I really want to.


Ahem, except that Seam applications don't use dependency injection. They use bijection. :-)

The very core of everything we are doing with Seam is the stateful component model. Dependency injection is suitable for stateless services. It is fundamentally mismatched to working with stateful contextual variables.

Outside of JBoss there are actually very many different DI implementations. Of course there is Spring. Then, JSF has a DI solution based around the EL (which is actually pretty cool, and is completely integrated with Seam OOTB). Java EE 5 has a standard dependency injection mechanism layered over JNDI. Tapestry has its own DI layer. Last time I looked at WebWork, it also had its own implementation. Etc.

It is really very trivial to integrate any of these DI containers with Seam (if you wanted to inject Spring stateless services, for example). All you need it do is add a VariableResolver to JSF 1.1 (or an ELResolver to JSF 1.2). This is basically about 10 lines of code and 1 line of XML in faces-config.

And most of those containers would also let you inject a Seam component into one of their components through some analogous mechanism.

Re: Seam, JBoss Rules and JBoss Workflow by Gavin King

I guess I should say that for a "full" integration of Seam and Spring you would want to at least be able to:

(1) inject Spring services into Seam stateful components
(2) orchestrate Spring services via jBPM pageflow and processes
(3) inject Seam-managed persistence contexts into Spring stateless services

The first two parts are handled by the VariableResolver. The second one is also very easy, but I just want to point it out because without that you would not be able to take advantage of Seam's conversation-scoped extended persistence contexts and atomic persistence contexts, and you would be stuck with all the same old problems (LazyInitializationException and friends) that Spring users have to deal with today.

Re: Seam, JBoss Rules and JBoss Workflow by Gavin King

The second one is also very easy


Ugh, I mean the third one, or course.

Re: Seam, JBoss Rules and JBoss Workflow by William Louth

Hi Gavin,

I have just wrote up a new blog entry after performing a quick performance and transaction analysis of the sample booking application shipping with Seam and JBoss 5.0 beta. The blog does raise a concern with the growing usage of Ajax and it not directly a criticism of your work on Seam. I did like the new incremental searching capabilities within the demo application but I think it is important for application architects to be fully aware of potential costs of such inclusions. As more and more developers embed Ajax enabled components within their applications it will become extremely important to have early comprehensive testing of resulting server and database interactions patterns.

Ajax: A Performance Problem in the Making
blog.jinspired.com/?p=30

Kind regards,

William Louth
JXInsight Product Architect
JInspired

"Java EE tuning, testing, tracing, and monitoring with JXInsight"
www.jinspired.com

Re: Tried Seam, loved it on first sight. by Maurice Zeijen

I am working on a Maven2 version myself. It would be cool if we could discuss it, when it's done.

Re: after reading this, I feel a bit dirty by Dan Allen

In Gavin's defense, he writes some of the best documentation you are going to find. While it is interesting to read the same thing 10 different ways, there really is no need. Just go read the Seam documentation and you will have all the depth you require.

Re: Seam/Security by Paul C

Well, the people from Spring would have to stop hating EJB and everything around it before Acegi can support EJB3. That's not likely to happen any time soon.

Paul C
Sr Developer
jBilling - The Open Source Enterprise Billing System

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

27 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT