Key features and differentiators of SEAM include:
- 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.
- 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.
- 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.
- 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.
- 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
- Portal integration. Portlets can be published via Seam.
- 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.
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:
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.
- 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.
- 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.
- 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.