King Says Seam 1.0 Will Unify Java Components

Seam 1.0 creator Gavin King sees his latest project takes on a big problem for Java devs -- how to better build end-to-end web apps that offer state, orchestration and reliability. Seam would cut dev code by at least 30% by unifying the component models for EJB, JSF and other frameworks. IDN speaks with King, father of Hibernate, about his latest project.

Tags: Seam, Component Model, Frameworks, Business, Integration, Apps, EJB,

Seam 1.0 creator Gavin King sees his latest project takes on a big problem for Java devs -- how to better build end-to-end web apps that offer state, orchestration and reliability. Seam, would cut dev code by at least 30% by unifying the component models for EJB, JSF and other frameworks. IDN speaks with King, father of Hibernate, about his latest project.

In a broad discussion, King speaks with Integration Developer on the eve of the Seam 1.0 release to discuss how Seam came into being, how it will help enterprise Java devs and the status of the Seam project:

ESB-CON III -- Enabling Business Critical Integration and SOA -- March 1, 2007

Experts from ESB leaders BEA Systems, IBM, Progress Software and Oracle Corp. share their latest insights and news on tools, trends and F1000 Use Cases for deploying ESBs and SOA. This fast-paced event covers Feature Upgrades, Best Practices and Blueprints for using ESBs to deliver cost-efficient business-critical integration for your current assets, and for preparing for SOA. Click here for your complimentary ESB-CON III registration.

An Integration Developer News interview
with Gavin King, founder of
Seam, Hibernate Open Source Projects

IDN: What is the overall vision for Seam?
King:: Quite simply, Seam is a an abstract architecture for stateful, event-driven apps which can be equally applicable to J2EE and SOA applications. The new web-based apps that are coming need to support events, orchestration, stateful components and conversations, and so we need to simply how devs work with different component models.

With Seam, we provide a [framework] to integrate the component model of EJB transactional components and JSF web based components. We unify the 2 sides of the fence, so that lets the developer write a component that handles events in a unified way. I call that meaningful, integration.

TheServerSide Symposium - Europe ?Barcelona, Spain -- June 21-23

The Java Symposium-Europe offers exclusive access to an all-star speaker lineup, featuring experts chosen for the weight of their contributions to the Java community. At TSS-Europe attendees will hear: John Davies, Gavin King , Simon Phipps, Gregor Hohpe, Rod Johnson, Bela Ban, Jonas Bonèr and Ross Mason For information and registration Click here


IDN: What are the architectural pieces of Seam that provide this capability?
King:: We have several aspects to Seam.
A component model that understands all types of state. Even though I may have good implementations for handling tractions that might run for months or years, and others for handling calls to the UI what I want is a unified model and architecture to support all these different contexts.
The second major part of Seam is the pieces that integrate the disparate technologies I need for an end-to-end application, and we have a strong beginning on those, including JSF (for interface), AJAX remoting (to call components directly from JavaScript), EJB 3 (for transactional state), and jBPM (for orchestration business process) and

IDN: So is Seam an intermediary to all required frameworks?
King:: Seam binds these frameworks together into a unified component model. And there is lots of value in doing that. By avoiding the need for developers to write directly to all these frameworks, we can cut the amount of code they need by 2-3 times.

IDN: What is the biggest near-term problem you see for Seam?
King:: Today, one of the biggest things that Seam emphasizes for UI is conversations. This is a critical thing that is missing today. So many apps are broken as soon as I try to work in multiple windows, and that is because of conversations. State management is an absolute disaster. People building desktop applications used to be able to attach state to the screen and the UI and when we went to the web we lost the ability to do that.. Seam looks to bring that back with something we call 'contextual components?which make it possible to manage different states in a single application.

IDN: So, my state management for the UI and my state management for a transaction could both be created and managed in Seam?
King:: State management is such a deep part of what apps do that devs need strong semantics, as well as very strong constructs and modeling. Seam offers 'strong?constructs for conversations, business process, web services conversations. And, yes, all these things require different handling in implementation.

IDN: Where else do you see the need for 'meaningful integration?for these new types of web-based apps or services?
King:: In the Seam context, when I talk about integration, I mean addressing a problem that has grown up in the JCP [Java Community Process], where individual Expert Groups create specifications and programming models to solve narrowly-defined problems. For example, we have a spec for EJB for writing business components that uses transactional resources. We have another expert group, JSF, that concentrates on writing components that can be bound to a UI. And, we have an ESB group addressing the problem of how different applications and systems interact with each other. Often what happens is that these people build individually strong specs, but the trouble is that the only component model that all can agree on is fairly week, and that makes it difficult for a developer to do everything he needs for one application -- access transactional resources, bind to a UI and interact with other services connected to the ESB.

IDN: So the expert groups these days no longer reflect how real-world developers develop?
King: I think that's right. I mean today developers are thinking about their business problem and what I want is when I write my code to solve that business problem, all the things I need will be provided to me as a unified programming model. They aren't just thinking is terms of technolog[ies] anymore. They want to solve a problem.

IDN: And as technology, how would you describe Seam?
King:: At the moment Seam has a component model, which is very strong and very different. It is a component model that embraces state management. Existing frameworks do not provide good mechanisms to allow you to control state. So, the Seam component [model] defines stateful components in a well-defined context. Stateful, contextual component model is core to Seam.

IDN: And how "real?is Seam at this point?
King:: We have submitted a JSR going through approval for the piece that integrates JSF with EJB 3 with BPM. I will be doing a 1.0 release at JBoss world.

IDN: All of this will be on the agenda at TSS-Europe?
King:: We are doing a 1 hour talk and 3 hours of training to get into the nitty gritty.

IDN: So, now that we have the picture, let's talk hands-on. How does Seam look to solve these dev problems?
King:: With Seam, I talk about the difference between having an integrated platform and having a meaningful integrated platform. Yes, I can in JavaEE to use web services, persistence and write a web based UI and write AJAX clients But I don't have a single programming model that unifies all these services in a deeply integrated way that would give me access to all this functionality.

Today, to solve their problem, developers are forced to sit down and make their frameworks happy. If I am writing a J2EE app the way I think about my problem is in terms of the individual structural concerns. So, I sit down and write a Struts action in a Struts action form, then I sit down an EJB for the transactional logic, or even write a web service. With Sea, we are trying to get away from the idea of de-constructing my code for individual frameworks and instead bind all these services to a different unified component model, which then would interact with the frameworks.

IDN: How do I write applications with Seam?
King:: Your business components need to be given a name and a context, whether their state is associated with a user interaction, an over-arching business process, a single event, and so on. That gives enough information top Seam that it can completely manage the lifecycle of this object. When you have this rich stateful component model it takes away the problem with using different frameworks that expect different ways of working with them. Seam collapses it all down into a system where the components are loosely coupled together, and their lifecycle in managed by the infrastructure, so things like orchestration, page flows, service orchestration, BPM and UII are loosely bound onto them.

IDN: Could you share an example?
King:: Today if I want to write a business component that lets me make an order, and I need to expose this component as a service. In a J2EE architecture, I need to write an EJB which holds the transactional logic, then I need to create whole bunch of web framework classes to bind my components to the UI and a bunch of classes that know how to control the life cycle of my EJB component. Then I might need to also work to another component model, like SCA, that would expose this as a service. All I want to develop is an app that knows how to create an order, but I am stuck having to have special knowledge of my web framework, this other component model SCA,

This is nuts. What we should do is now that we have an EJB 3 component model, which already knows how to do persistence and transactions very well, we should ask 'How can we bind the functionality of orchestration and assembly onto this component model?'

IDN: What trends are afoot that you see that will show Seam to have big payoffs for developers?
King:: There are 2 architectural changes happening.

The first is that the multi-tier architecture where we run different layers of an app could run in separate processes is kind of discredited. The second, is the idea that communications between different processes would happen by EJB remoting. Remoting has its place, but as a default architecture that is discredited.

IDN: And what is taking over?
King:: What is coming to the forefront is a problem that has always been there ?and what CORBA tried to solve. That is the problem of integration of systems built by different groups to solve different problems. Integrating data from different systems. Looking at it that way, SOA is not completely new. CORBA and MOM has been trying to solve this problem for a long time. But, what is new is an emergence of a web services stack, and the coming together of the Microsoft world and the non-Microsoft world for interoperability.

IDN: So, instead of developers having to make different frameworks happy, you want to simplify that?
King:: Yes, For example, when I write a single component (just a Java Bean), and the only metadata specified is the context its state is associated with. Then using an expression language as a loose binding you can apply orchestration to this component by writing some process definition or page flow definition that loosely binds the component into this, and write a UI by just writing a screen which does the same thing. The idea here is that things like orchestration and UI are loosely bound onto this natural underlying business model, and what we have is a component model that is rich enough and expressive enough to encapsulate all the kind of lifecycle semantics the other frameworks will need.