JBoss SEAM 1.0: rethinking web application architecture

Posted by Floyd Marinescu on Jun 13, 2006

Sections

Operations & Infrastructure,

Enterprise Architecture,

Development,

Architecture & Design

Topics

Web 2.0 ,

Data Access ,

Web Frameworks ,

Java

Tags

Web Beans ,

JBoss Seam ,

JBoss

JBoss SEAM 1.0 final was released today at JBoss World. 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.  InfoQ spoke to SEAM and Hibernate creator Gavin King and got some more background on SEAM.

Key features and differentiators of SEAM include:

1. A unified component model centered around EJB. SEAM breaks down the distinctions between the web tier and the business tier, breaking down the idea that every time you have a new technical concern you need a new component model.  Gavin gave some examples: '"My technical concern is web pages, I have a component model for that. My technical concern is transactions, I have a technical model for that.  My technical model is ESB and now I need this SCA thing? No! We should be applying all of these technical concerns to the same component model."  In SEAM, everything revolves around EJB as a component model which tightly integration with JSF, AJAX, and jBPM.Session beans can be used as JSF action listeners / backing beans. Entity beans can be directly bound to  forms.
2. Raises the semantic level of development.  "We don't want to write code dealing with technical concerns like  XML vs. Java code.  We want to use DSLs like process definitions from jBPM or Drools where appropriate.  The platform is going in the direction of having more and more DSLs. Previously jBPM was a framework/API you'd call to do stuff, but now it's become an aspect, factored out like a concern that you apply on top of your component model using an EL.  Going forward I'd expect to see scripting languages become a part of this view."  A more meaninful context model, explained in the next point, also provides a more meaninful, higher level abstraction for managing state than HTTPSesssion.
3. A new contextual component model / higher level state management over HTTPSession.  A key thing SEAM intoduces on top of JSF / Servlets is Conversation and Process contexts, which provide more meaningful abstractions for state management than  HTTPSession. SEAM manages the propagation of these contexts between events associated with the same context and cleaned up when a context ends. This eliminates a whole bunch of bugs caused by back buttons, refresh buttons, double submits, multi-window browsing, post then redirects, "these all vanish when you have conversations".  Conversation contexts was implemented using an ConversationID that goes back and forth between client and server and pulls out state out of the HTTPSession using the ConversationID. SEAM integrates deeply into JSF to make the ConversationIDs transparent. Stateful session beans are also transparently integrated.
4. DRW-style AJAX EJB invocation and the ability to recieve JMS messages in the browser. EJB 3.0 session beans appear as simple JavaScript objects in the browser and can be called invoked via AJAX, hiding the complexity of XML and the XMLHttpRequest API. Web clients may even subscribe to a JMS topics and receive messages published to the topic as asynchronous notifications.  SEAM re-implemented the ideas of DWR for SEAM. A re-implementation was needed because "at the time it didn't provide an annotation based approach", but also because they needed integration with SEAM's stateful conversations. 
5. Support for process-driven applications. JBoss Seam integrates transparent business process management via JBoss jBPM. Future versions of JBoss Seam will allow for the definition of presentation-tier conversation flows by the same means
6. Portal integration. Portlets can be published via Seam.
7. Testability. Seam supports testability as a core feature of the framework. JUnit or TestNG tests can be written which reproduce a whole interaction with a user, exercising all components of the system, and run them inside your IDE.

On the relationship between Java EE and SEAM and whether they compete, Gavin explained that "EE gets us to the point of being able to run all these different models in one environment, by adding an extra layer of integration on top of that (SEAM), we are now able to unify the progamming models together.  SEAM provides integration at the programming model instead of the runtime/execution environment level. That's why this stuff belongs as part of the standards," hence the submission of Web Beans which would standardize this integration.  "It's great to innovate in open source, but there are a great mass of developers that can't use stuff unless it's blessed by a big company like Sun and IBM. If we want to solve problems for these people then it needs to be part of the standards."

Why JSF as the webframework?:

Because I love EL, if you look at SEAM you see the use of EL everywhere.  Java has had the EL for more than 5 years but it was never done very well and it never migrated beyond web pages.  JSF has this wonderful binding constructs to be able to say 'this box in the UI is bound to this attribute of this component' by an EL. It's such a strong construct, and nothing else has expressed it this strongly.   Tapestry sort of does this but couldn't be used because it's not POJO based and couldn't be integrated with EJB 3.   Action-based frameworks don't have this nice loose coupling via an EL, you know, strong binding but loose coupling.  I just think the component based approach is much more elegant, it's real MVC, it's fine-grained eventing and it results in much more loosely coupled applications.  JSF isn't perfect but nor is it non-resuable, we've built a bunch of stuff into JSF which solves peoples most common problems.

SEAM is meant to be run inside a Java EE application server and also run on Tomcat using the JBoss embeddable EJB 3 container. "To counter all the FUD against application servers, we've made sure that SEAM applications can run on Tomcat using the JBoss embeddable EJB 3 container".   Gavin had some strong opinions on Tomcat being less productive than an application servers and less suitable for production given concrns like management, monitoring and deployment. "I'm not advising anyone to run applications just on top of Tomcat, but if they want to, they'll be able to do it."   The JBoss embeddable EJB container is "more of a demonstration that there is nothing about the EJB or Java EE programming model that is any more heavyweight than lightweight containers."

While eliminating the distinction between the presentation tier and the business tier can result in a lot of simplifation, where does that leave the services layer in a typical design? Gavin responded with three answers:

1. Not all applications need layering. If you're building a simple data-driven application where there isn't much business logic to speak of, you've often got only presentation logic and persistence logic.
2. Layering is not the only way to separate concerns, a much nicer way to separate concerns is to use objects - refactor business logic into your domain model or other objects. You don't need to impose a heavy weight layer to achieve separation.
3. The technical concerns of flow and business process can be pulled out into jBPM process definitions. What then remains in Java code is clean, pure abstracted business logic. It's not for all tastes but it provides a nice separation of concerns.

In future directions, SEAM will address integration onto JBI/ESBs.   "If you look at the constructs in SEAM such as orchestration, conversations, stateful components, events, they are just as applicable in the context of ESB as in the context of user interactions." SEAM will look at integrating EJB as the component model for SOA, allowing the use of EJBs as web services endpoints and using SEAM to add conversation support on top of JBI. 

1. Back to top

   Thank you

   by Jim Hazen

   Congrats Gavin and the Seam team. Amazing amount of work.
   
   To other developers currently doing work with JSF, take look at Seam, if only to thumb through the documentation. The documentation is quite good, as is the forum support. Nearly every forum question is answered by a Seam developer, most by Gavin himself.
   
   Key features: Loose coupling of entity and controller managed beans, additional scoped contexts (conversation, business process), annotation driven data binding, integrated JSF lifecycle support for EJB3's JPA extended persistence context...and much more.

   Reply

2. Back to top

   printer friendly

   by anjan bacchu

   hi there,
   
   when you're busy and wanna take a hard copy, it would help if there was a printer-friendly view.
   
   thank you,
   
   BR,
   Anjan Bacchu

   Reply

3. Back to top

   Re: printer friendly

   by Alex Popescu

   Anjan we are working on it now :-). You can always submit the feature requests/suggestions/bugs to bugs[at]infoq[dot]com.
   I guess other users would really like to see that the threads are kept related to the content.
   
   thanks for the feedback and understanding,
   
   ./alex
   --
   :Architect of InfoQ.com:
   .w( the_mindstorm )p.

   Reply

4. Back to top

   Re: Thank you

   by nikhil thakur

   Key features: Loose coupling of entity and controller managed beans, additional scoped contexts (conversation, business process), annotation driven data binding, integrated JSF lifecycle support for EJB3's JPA extended persistence context...and much more.
   
   Loose Coupling between layer? Can you explain how is that possible? Does Seam allow loose coupling? How? I thought it tightly couples the two layers.

   Reply

• Older >