Tracking change and innovation in the enterprise software development community
Create REST
-enabled Web Apps
with Project Zero
from IBM.
QCon San Francisco
Nov 19-21:
+ 80 sessions & tracks
Register now
and Save $400!
IBM WebSphere
Virtualize apps
to lower costs,
Increase agility
Learn more!
Terracotta:
Scale your
Apps w/ease
Offload the DB:
Learn More!
Posted by Scott Delap on Nov 05, 2007 04:48 PM
Today the JBoss Seam team released Seam 2.0. This comes 8 month after the last major release. Among the top features that project member Norman Richards lists:InfoQ caught up with project lead Gavin King to discuss the new release. InfoQ first asked what was the most important thing learned with 1.0 that made 2.0 a better framework:
I think the biggest mistakes I made on 1.0 were:King was next asked about JSF components versus moving the entire presentation tier to the browser with something like ExtJS:(1) Going ahead and developing Seam to mostly assume an environment with JSF, EJB3 and JTA. These are all very popular technologies, no doubt, but there have still been a lot of people who've wanted to use Seam in other environments, and they've pushed us to "open up" the implementation.
(2) Not realizing just how big our built-in component library was going to grow. On the early versions, I just naively threw all the built-in components into org.jboss.seam.core. In Seam2 we had to completely reorganize the packaging structure.
Well, I think there's two major thing to consider here:InfoQ then asked about the new WebBeans JSR:(1) Do you prefer to define the user interface declaratively, or programmatically?
(2) Exactly how much functionality can really *execute* on the client side?
There's also the question of how typesafe you want to be.
These questions are almost orthogonal. For example, GWT gives you a typesafe, programmatic, client-side approach. On the other hand, Wicket gives you a typesafe, programmatic, server-side approach.
JSF gives you a somewhat typesafe, declarative, server-side approach, with the option of working in programmatic mode when you need it. Each approach has its advantages and disadvantages, or course, but here's why I think the JSF approach is compelling:
First, I much prefer to define the user interface in a declarative language. The user interface is by nature hierarchical, and I want the structure of my code to reflect that. I've simply never felt comfortable creating a user interface using swing-style code. This kind of code always looks ugly and is difficult to maintain - it's a bit like Java code that parses XML by walking the DOM tree. There's a fundamental structural disconnect there.
Sure, for very dynamic parts of the user interface, programmatic manipulation is useful. But, this is certainly the uncommon case. Most user interfaces are extremely static except at the level of individual controls. And JSF helps you even in this uncommon case, since it lets you directly manipulate the JSF component tree in Java code. And of course, you can always fall back to writing JavaScript code that works with the browser's DOM. (One of these days, someone will create a JSF implementation that enables client side access to the JSF component tree, but we're not there yet.)
Second, I simply don't buy into the idea that keeping more state and performing more application logic on the client side is going to save a lot of development effort. There's simply too many central concerns that can only be effectively dealt with on the server side: persistence, security, data-level concurrency, etc. What ends up happening if you try to bring your application code to the client side is that you end up right back where we were three or four years ago, with an architecture that features a stateless service layer, data transfer objects, fine-grained manual fetching of data and merging of changes. This is the painful programming model we just escaped by adopting stateful components and conversation-scoped persistence contexts - all server-side technology.
With RichFaces and Seam, you can create user interfaces that fetch data asynchronously, update the view interactively, respond to user interaction asynchronously and apply changes interactively, all in a well-defined optimistic transaction, without all that extra noisy boilerplate. Sure, it takes a bit more effort to learn JSF and RichFaces than some other approaches, but it will pay off in the long run.
The biggest downside I see with the basic approach of JSF today is rarely commented upon: the lack of typesafety in the use of EL to bind the view to the model. My ideal environment would be one which supported a truly typesafe declarative language for defining the user interface. Unfortunately, Java has no real support for creating such DSLs. Pity.
Web Beans features many ideas that came from Seam:
- contextual components
- conversations
- component overriding via "precedence" rules
- "deep" integration with Java EE
- binding-annotation-based interceptor bindings
- event notifications
On the other hand, it also stole the idea of binding-annotation-based dependency injection from Guice, and this had some far-reaching consequences.
Web Beans mixes all these ideas together into a very unique programming model that emphasizes "loose coupling with strong typing". You can achieve a very loosely coupled application by taking advantage of:
- contextual lifecycle management (stateful components interact as if they were services) to decouple client and server lifecycles
- deployment time component overriding to decouple client and server implementations
- event notification to decouple message producer from consumer
- interceptors to decouple crosscutting (technical) concerns
all without sacrificing typesafety. Everything is done via typesafe annotations - there's no strings, hiding under the covers, waiting to bite you at runtime :-)
In sum, Web Beans builds on the tradition of Seam, but I believe it's an even more compelling model. I'm blessed with a great expert group :-)
Finally King was asked about if using Seam to develop the new wiki running in.relation.to had caused the team to find any holes in the framework:
We spotted a few bugs and minor limitations. But the biggest influence the Wiki is having is in motivating us to develop a plugin architecture for Seam. By "plugin", we mean something a bit like a portlet, except for not sucking.
Scaling a Massively Multi-player Server Casestudy: Terracotta on SmartFoxServer
Scale your applications without punishing your database
Introducing application infrastructure virtualization and WebSphere Virtual Enterprise
Hibernate without Database Bottlenecks
Rainmaking - IBM's software virtualization strategy (Jerry Cuomo CTO blog)
The biggest downside I see with the basic approach of JSF today is rarely commented upon: the lack of typesafety in the use of EL to bind the view to the model. My ideal environment would be one which supported a truly typesafe declarative language for defining the user interface. Unfortunately, Java has no real support for creating such DSLs. Pity.
Hmmm, I guess I should qualify this by saying that we can achieve some of the advantages of typesafety through tooling. Of course it would be best if Java could be used to define a typesafe, declarative DSL for building user interfaces (think something along the lines of JavaFX, but for the web). However, we're reproducing some of the nice features of a typesafe language (validation, autocompletion, code navigation) in JBoss Tools. In practice, this is really nice.
MVEL has a mode to provide full type safety, via inference - static typing is also allowed. It also handles primtives, primtive object wrappers and BigInteger/BigDecimal with full coercion. So you can do mixed maths with all the three. It has support for inlined maps, arrays and lists. Which can be combined using the 'with' keyword to provide deep graph notation for complex structures. This can allow you to define a single statement to create a complex object hierarchy. The macro stuff is pretty cool, and can be combined with it's interceptor model for some interesting custom DSLs. It has the fastest lightwight interpretor around, no additional deps. You even get a powerful templating language included, to boot. Mike is working on EL compatability, or atleast a pre-processor. But the work is slow as it doesn't bring anything new to MVEL, so it's less interesting to him, he also hasn't had a strong request for it, from his existing user base. I know I've harped on about this before, but if you want a small lightweight scripting language with type safety, nothing beats MVEL. Mark http://blog.athico.com The Drools Blog
Yeah, but do you really think that kind of code is appropriate to embed in XHTML attribute values?
And that is that I just rolled out a seam 1.x project - we went live yesterday : ). In all seriousness, well done and thanks to everyone involved. I love Seam, and I look forward to playing with Seam 2 for my next project.
Congratulation for all JBoss Seam developers and thanks for this great tool. Waiting for a better documentation (well, I'm greed).
Sounds very good. Regarding new features: Does Seam 2.0 work on the current Oracle AS (10.1.3)? The previous version did not so we had to go with Spring Webflow.
About that documentation issue the reference doc is not that bad and even though it could be better it's almost one of the biggest I've seen among all the framework I've used. What is really poor is the javadoc.
Mike Brock, from the JBoss ESB team and the MVEL author, has asked me to post this reply on his behalf, as the InfoQ registration system seems b0rked: MVEL has optional type safety and an API for binding variable types to the compiler is eminently available and documented. Yes I think MVEL is a appropriate for parsing expressions embedded in XHTML. In fact, the entire purpose of MVEL from the get-go was to parse expressions embedded in JSP and XML documents. The performance of the runtime was tuned to parse many tiny expressions very efficiently. In fact, MVELs lightweight template parser, built on top of the MVEL core, shows superior performance to Velocity and FreeMarker in it's evaluation speeds. I can even go into it further. MVEL's expressions are evaluated without a session or a context, which makes using MVEL for embedded expressions even more ideal, because of the lack of need for factory caching, etc. I read your blog post about the fact you think MVEL (like OGNL) has too may language features. For a lot of stuff I agree with you. In fact, that is why we implemented a language capability API that allows you to set the capability level of the parser to restrict what MVEL can do in a particular application. For example: for embedding, you probably don't want code blocks and high-level control flow language extensions available for embedding into small expressions. Therefore, you can lower MVELs language capability level to a level that only permits property, boolean and ternary expressions. Also MVEL already has break point debug capabilities built in (which EL doesn't), as used by the Drools project in Eclipse - if you ever feel you need to build debug capabilities into your stuff.
Mark can you please ask Mike to privately email me to solve his registration problem? Thanks, ./alex -- .w( the_mindstorm )p. ________________________ Alexandru Popescu Senior Software Eng. InfoQ TechLead&CoFounder
Yes, you can use Seam 2 with OC4J; you won't get the full JEE 5 feature set but you can use JPA + Hibernate + Seam POJOs. Take a look at http://blogs.steeplesoft.com/2007/10/17/seam-and-jpa-hibernate-on-oc4j-1013/ - we're going to integrate this into both the Seam documentation and JPA example for a upcoming patch release of Seam 2.0: http://jira.jboss.com/jira/browse/JBSEAM-2123 http://jira.jboss.com/jira/browse/JBSEAM-2122
Hey, Pete, you beat me to the punch! :) I haven't forgotten about those issues. I hope to get to those soon.
Jason, that would be great. Your blog is a great resource, but having it in the Seam docs makes it more accessible :-)
Hi, Thanks to Seam team for 2.0.0 GA release. I wrote a step-by-step screencast tutorial to make Seam development as RAD - Rapid Application Development with Eclipse and Tomcat, focussing on developer productivity. http://techieexchange.wordpress.com/2007/11/11/rad-seam-development-with-eclipse-and-tomcat-step-by-step-tutorial-screencast/
Thin client paradigm characterized by web applications is a kludge that needs to be repudiated. Old compromises are no longer needed and it's time to move the presentation tier to where it belongs.
In this presentation filmed during QCon 2007, Jeff Sutherland, the creator of Scrum, talks about his visit at Google to do an analysis of Google's first implementation of Scrum.
In this article, Bryon Jacob and Chris Berry introduce AtomServer, their implementation of a full-fledged Atom Store based on Apache Abdera, which is now available as open source.
It is easy to think that virtualization applies only to servers. In reality the recent resurgence of the concept is also being applied to networking, storage, and application infrastructure.
In this article, Stefan Tilkov explains some of the most common anti-patterns found in applications that claim to follow a "RESTful" design and suggests ways to avoid them.
In this article, Adrien Louis and Marc Dutoo discuss the differences and relative merits of using orchestration vs. routing in a typical ESB setup, and discuss various implementation options.
Wayne Lund discusses batch processing, Spring Batch objectives and features, scenarios for usage, Spring Batch architecture, scaling, example code, failures and retrying, and the future roadmap.
Developer Jay Fields draws on his experiences as a ThoughtWorks consultant to describe effective user story estimation techniques.
13 comments
Reply