Gavin King leads the Ceylon project at Red Hat. Gavin is the creator of Hibernate, a popular object/relational persistence solution for Java, and the Seam Framework, an application framework for enterprise Java. He's contributed to the Java Community Process as JBoss and then Red Hat representative for the EJB and JPA specifications and as lead of the CDI specification.
Gavin now works full time on Ceylon, polishing the language specification, developing the compiler frontend, and thinking about the SDK and future of the platform. He's still a fan of Java, and of other languages, especially Smalltalk, Python, and ML.
You can follow him on G+.
In the spirit of
stages of grief, these are the
stages of adoption of new software development techniques:
UPDATE: Hopefully this does not look too much like a bite of Gartner's Hype Cycle.
- Stage 1, Rapture: The
shiny new toyphase, where we first discover a new idea, and realize how powerful it is. As we get confident, we start trying to use it for /everything/.
- Stage 2, Disillusion: Inevitably, as we start trying to apply this new approach to more and more complex and obscure problems, we start to run into cases where it doesn't quite fit - either because the expression of the idea (the current implementation) is still immature and imperfect, or because in our excitement, we're simply misapplying it.
- Stage 3, Insight: The shiny toy is now just another gadget in our toolbox. We finally have the experience to know when and when not to use it. We understand not only the limitations of the idea, but also /why/ the limitations exist.
The earliest release of Seam was a whole year ago, and Seam is now I guess the fastest growing framework in Java (500 downloads each day and rising). But the ideas in Seam - contextual components, state management, conversations, BPM - are still new to most people and the Seam community is still in the process of understanding exactly how and when to apply these ideas. This is actually the most exciting phase for a project like Seam. I loved the early days of Hibernate, when the community was still developing the patterns (and finding the language for describing those patterns) that are now formalized into books and examples and known to most enterprise Java developers.
Today I got an email from a user who had just hit Stage 2, Disillusion. He asked:
- If is best to use page flows or is normal JSF navigation in faces-config.xml enough?
- Is there a one sentence explanation on how to use @Begin and @End? I think most of my problems are due to misunderstood and invalid usage of conversations.
I spent more than a year thinking about conversations and optimistic transactions and designing Seam's conversation model before I actually sat down and wrote my first two Seam example applications a year ago. Even so, I got it wrong in both cases! I actually managed to screw up the conversation model on the first release of our beloved Booking demo. My lame-ass excuse is I was trying to illustrate the /idea/ of conversations, while keeping the actual conversation model extremely simple. But of course the worst way to illustrate the power of an idea is to misapply it. Mea culpa.
A year later, I think we're finally at the point where we can start to formalize a set of rules of thumb on where to use conversations, where not to use them, where to begin them, where to end them. We now have the hard-won practical experience to go with the idea and its implementation.
It's very difficult to define a correct state management model without interaction with the users. The first thing we need to understand is how the users want the application to work: what tasks should be multi-taskable, what pages need to be bookmarkable or exchanged in email, when should work become persistent, etc.
My first stab at
when should I start a conversation? is the following:
Start a new conversation if you are at page X, and:
- the user is expected to want to navigate to page Y using
open in new tabor
open in new window, and
- you want some state that is retrieved while rendering Y to remain in memory on the server, but isolated to the tab or window.
We need to supplement this with the following additional rule:
- If page X already has a conversation, and page Y needs access to the state held in X's conversation, then make it a nested conversation. Otherwise make it a whole new toplevel conversation.
Well, those rules are really just a restatement of the definition of
nested conversation. They don't really tell you anything you didn't already know (though it is perhaps a more friendly formulation). What we really need is a characterization of the kinds of things that X and Y can be. So, when I'm developing frameworks, I really need to think about the following canonical cases:
- Search/list screens: these let the user find and navigate to the entity instances they are interested in. Search screens often support sorting.
- Item detail pages: these let the user view not just an instance, but also associated objects. Sometimes these pages can be complex views driven by a treeview control and requiring lazy fetching of data possibly via AJAX.
- Edit/association management pages: these pages implement simple optimistic transactions that let the user atomically view and update an entity instance, and possibly change its association to other entities. I'll throw create and delete functionality into this bucket for now, though these should strictly have their own categories.
- Wizards: I'm not just thinking of simple linear flows here, but rather of any interactions where we guide the user through a series of steps that form a single unit of work. In fact, a
wizardcan even be something as complex as a treeview control where the user can edit data from a toplevel object and its child objects spanned over several different pages, lazily fetching data and caching edits in memory on the server, and then finally make all the changes persistent in one atomic
The answer to my Disillusioned user's first question is simple: /only use jBPM pageflows for wizards/. The stateless navigation model is much more appropriate for our other canonical cases.
But I still havn't satisfied his request for a
one sentence explanation of when to use a conversation. Instead, I'll try to sketch out a set of steps to take when designing a disciplined state management model for an application:
The first thing to consider is the search or list screens. These are extremely important, since they are the entry point to all application functionality. We need to decide where to
put the search result list. Alternatives include:
- keep their result list in a conversation - this is usually overkill
- keep the results in the session context - not good if the user needs to be able to run multiple simultaneous searches
- go stateless (use a redirect with request parameters and pull MVC) - the advantage is the results can be bookmarked; the disadvantage is that we canít easily cache the search results, which might slow performance if the user is allowed to sort and reorder the result list
- put the results in the page context (which is serialized to the client) - this can mean quite a lot of serialization overhead
On balance, my preference is for statelessness most of the time, but it depends upon the needs of your users. Session scope might be what they prefer (this is what we use in the Booking demo). Conversations don't usually have a place here.
STEP 2: When we navigate from a search screen to an item detail page, a similar choice space exists:
- keep the item in a new conversation
- stay stateless (request parameter and pull MVC)
- use the page context
Now the balance swings toward using a conversation, especially if we have some kind of complex object and need treeview-style navigation. (In this case, conversations give you transparent lazy association loading and all that good stuff.) But if bookmarkability is a requirement, statelessness is again the best choice.
Now we start getting to edit pages, association management pages, create/delete and the like. We are in the world of optimistic transactions, and so conversations rule. The main decisions revolve around conversation propagation: nested conversation? new conversation? stay in existing conversation? This depends upon how much the user wants to use
open in new tab!
Finally, wizards should always run in a conversation. In fact, it is highly likely that you want to use the
atomic conversation pattern where changes are kept transiently in memory on the server side until the conversation ends. Some wizards should use pageflows. (Remember I am using an extremely broad definition of
Hopefully this discussion helps the path from Disillusion to Insight, without scaring away the many people who have yet to experience the Rapture.
Norman Richards (super-smart/thoughtful guy doing product management stuff at JBoss) has posted a download of the Seam hands-on lab from JBoss World. This is a nice way to get started with Seam, and much more interesting than listening to me rant on about conversations and state management and unified component models for an hour and a half...
(Warning: it's a bit enormous because it bundles the appserver!)
Usually I don't like to climb into these kind of discussions - I usually keep quiet unless I have something more to add than
metoo. But forgive me for mentioning that, on balance, I agree with the many people arguing that bundling Derby in the JDK is a Bad Idea. My concern is that this decision naturally forces projects like Hibernate to have to support Derby, no matter what our better judgement as to the maturity/stability of the product at this stage. Perhaps if/when Derby has shown itself to be a truly production-ready platform, this decision could be better justified. But for now, Derby is neither usable in production, nor is it really a good choice for development (HSQL is much more usable at development time, and that is what 95% of people are using).
It would be really nice if Sun would reconsider this decision. Perhaps the solution is simply to offer two different download bundles, one with Derby, one without, and Let The People Decide :-)
UPDATE: I'm also amazed that Sun would want to risk sticking the word
Java on this product. Like the
Java Desktop, it seriously risks devaluing the brand.
Last week thousands of people downloaded Seam 1.0 and tried it out. Inevitably, they picked up on a couple of bugs of the
minorish variety. At the same time, I was getting some useful feedback from users who are already developing and/or deploying Seam applications at JBoss World. Finally, Roger Kitain from Sun reported a problem running Seam on GlassFish. So, I needed to do a 1.0.1 release:
This release has been properly tested on GlassFish.
Note that if you are using JBoss AS, Seam requires JBoss EJB 3.0 RC8. The best way to get the right versions of everything is to use the JEMS installer here:
(I know that this caused some hiccups for some people.)
Of late, the pressure on us has been to stop throwing in new features, and focus on stabilising the platform, so that people can feel confident using Seam in production. I think we are finally there now. I'm really happy with some of the applications I'm seeing built in Seam: you can really see the difference in user experience between a traditional web application and a Seam application with conversations, AJAX, business process management, etc. I was especially impressed with the workflow application built by JBoss Innovation Award winners Lexicon Genetics in just a couple of months. Doing something like that without jBPM and Seam would be a seriously much bigger undertaking. And they are pushing the limits of the environment, and helping feed me new ideas for Seam.
The Seam project is proud to announce the release of JBoss Seam 1.0 GA, an application framework for Java EE 5. Seam aims to be the most productive platform for development of enterprise and rich internet applications in any programming language.
XML hell that plagues Java frameworks designed for use with J2EE by leveraging Java 5 annotations for declarative programming.
Seam 1.0 introduces the following new features:
- Seam Remoting - an AJAX-based remoting layer for EJB 3.0 components and JMS (created by Shane Bryzak)
- Support for JSR-168 compliant portal engines such as JBoss Portal
- Elegant handling of internationalization and JSF messages via EL-based interpolation
- Helper components for JMS senders/publishers
- JSF tag library
- Redesigned XML-based configuration facility
- Support for integrating databinding architectures
- Eventing architecture for loosely-coupled components
- Seam Logging
- JBoss Cache integration for cluster-wide state replication
- Experimental Drools integration
- Compatibility with the Java EE 5 reference implementation
- Much more...
As usual, the best way to learn about Seam is to check out the example applications. Start with the registration, numberguess, booking, blog, dvdstore and chatroom examples.
Get it here:
The Web Beans JSR was approved unanimously by the JCP executive committee. You can read the proposal here:
We've already received a bunch of expert nominations from companies and individuals, and so I'm sure we'll be able to form a very talented expert group over the next few weeks. If you're interested, the nomination form is here:
This is the first time JBoss (or even Red Hat) has led a JSR, so we are very excited about this opportunity to serve the Java EE community!
The recently finalized Java EE 5 platform dramatically simplifies development of Java applications.
For example, no other programming environment in existence makes it as easy to access transactional resources - particularly relational databases - as EJB 3.0. The combination of plain Java classes, annotations and deep integration of a full-fledged O/R mapping solution leapfrogs all other contenders in this space.
Even better, EE 5 is designed for extension, so we expect to see a flowering of new open source frameworks built to run on and integrate with this new platform. Seam is a perfect example of what is possible here. The deep integration of EJB, JSF and jBPM would simply not have been possible in J2EE 1.4.
Well, it turns out that Seam has been recieved with enthusiasm. The user community is buzzing, with hundreds of Seam projects in the works, and the first crop of Seam applications going into production over the next couple of months. Seam 1.0 will be released in the next few weeks. In light of this success, we've decided the time is ripe to bring some of the ideas in Seam back to the JCP.
So we've been working with Sun, Oracle, Borland, Google and Sybase to put together
a JSR proposal for a new spec that will draw on ideas from Seam, Struts Shale and
Oracle ADF and push forward with the next layer of simplification of enterprise
Java. Today we submitted the
Web Beans JSR, which will address the problem of deeply
integrating EJB 3.0 with the web tier, including, to quote from the proposal:
* Definition of additional capabilities to be used with the EJB component model, allowing EJB beans to act as JSF managed beans in a JavaServer Faces application. * Definition of a unified annotation-based facility for manipulating contextual variables in a stateful, contextual, component-base architecture. * Definition of an enhanced context model including conversational and business process contexts. * Definition of an extension point allowing integration of business process management engines with the contextual component model. * Integration of Java Persistence API extended persistence contexts with the enhanced context model. * Collaboration with the JSF and Common Annotations for the Java Platform expert groups on the definition of Java annotation based metadata for JSF.
We're all looking forward to serving the Java community with this new work!
Read the press release here:
I've seen a couple of comments online to the effect that Seam is some kind of JBoss-only thing. This is not the case, Seam doesn't have any hard dependencies to anything other than the standard Java EE 5 APIs.
Roger Kitain from Sun has done the hard work to get Seam up and running on the Java EE 5 reference implementation. He had to make a couple of patches to the Seam sourecode, mainly reflecting the fact that I'm developing Seam on JBoss, which is currently slightly behind the final draft of the Java EE specs. This situation should be fixed sometime in the next two weeks. My plan is that Seam 1.0 final - coming /real/ soon now - will run on both JBoss and the Java EE RI (and presumably, any other Java EE 5 implementation). Thanks to Roger I now know what I need to do ;-) Of course, Seam already runs on standalone Tomcat, if you use the JBoss Embeddable EJB3 container, or if you are happy using JavaBeans and Hibernate instead of EJB3.
So, thanks Roger!
I, for one, welcome our new penguin overlords.
The last couple of months have been pretty nerve wracking. The various rumors floating about generated a fair amount of uncertainty for our customers, employees and user community at large (nevertheless, despite the uncertainty, March was a record month for sales!). In the end, Marc chose to sell to Red Hat. This is the combination that offers the greatest synergies to both companies, is most reassuring to our customers, and causes the least disruption to our overall business and technology strategy. Most of all, it clearly signals our continued commitment to Free Software. The two companies have similar business models, similar licenses and a similar record of successful evangelization and commercialization of open source.
The planned acquisition of JBoss by Red Hat will revitalize the middleware market - expect a more competitive marketplace, with all major products based on open source codebases. And expect us to be leaders in SOA. No other software company offers an open source enterprise software platform of comparable depth and maturity.
Obviously, Marc deserves all the congratulations he's getting today. He's delivered on basically everything he promised when I joined the company two and a half years ago (back when there were three people working out of our Atlanta headquaters). He's changed the middleware market for good. He's built a company where technical people have the freedom to pursue their ideas. And he's made a whole bundle of money for himself and his employees.
For a technical guy like me, JBoss is Camelot. Three years ago I was dragging myself out of bed each morning to go to my depressing job building boring web applications for organizations run by risk-averse middle managers and clueless
architects. I was thoroughly frustrated with the lack of productivity of the technology platform - always WebSphere - that was forced down my throat by these guys. And I knew I was wasting most of my life sitting in a cube reading blogs (the dirty secret is that when you sit them in a cube farm, very few developers are actually productive for more than about three of the eight hours in a workday). That was a world where an idea - however unoriginal - was valued on the basis of how many grey hairs were in evidence on the head of the person expressing the idea. But the hair was not the only thing that needed to be grey. In the world of
professional services, only the greyest personalities succeed. Passion, creativity, vision - all liabilities. Knowing no other world, I believed that that world was the whole world. At night I'd work on Hibernate, hoping that perhaps - if Hibernate became wildly successful - I might get just an ounce more respect in that world, despite my obvious lack of greyness.
My first visit to America was for a conference in Massachusetts. JBoss sent Bill Burke and Ben Sabrin to meet and recruit me. These guys are the perfect metaphor for the culture of JBoss: a culture driven equally by technology and sales. Bill is a technology guy through and through. Ben is my perfect ideal of a fast-talking American salesman. If Ben tries to sell you something, you can't possibly not buy it. Ben sold me JBoss. A few weeks later I was back in the states to meet Marc Fleury. I was expecting a difficult relationship here. I'd been warned by a several people that Marc was a difficult guy. I'm a difficult guy myself. And indeed, for a while, there were many difficult issues to work through. This was all happening during what were undoubtedly the darkest days for JBoss. A month or two earlier, three people had very noisily left the company and, through clever PR, created the impression that JBoss Group had split down the middle. The rest of the company felt deeply betrayed, angry and distrustful. But as memories of those events faded, what remained was a more unified, more motivated company. Bitterness was transformed into purposeful determination. The company grew from a headcount of less than 20 to almost 200. To my knowledge, not a single developer has left the company in the period since I joined. If you're creative, self-motivated, thick-skinned, this is perhaps the best software company in the world to work for. I look forward to seeing the continuation of this culture at Red Hat.