[TSSJS] Friday Morning: RIFE and Seam
This is my 2nd day in Vegas and so far this town is treating me fairly well. I haven't lost all of my money, but the $25/hand blackjack tables haven't been kind. Yesterday, I woke up with a glass full of Berocca next to my bed - which means I passed out before drinking it. I needed it too, Matt Filios won a poker tourney and a bunch of us enjoyed "bottle table" (with Kettle One vodka) to celebrate. Spendy and good, but painful the next day.
Last night, I heard it was Crazy Bob's bachelor party, so I went to bed early to avoid the debauchery. Julie and a good friend of mine are flying in tonight, so there will be plenty of that this evening. So after a good night's sleep, I'm up early and attending the conference. The first hour has a lot of good sessions: Introduction to Seam (Gavin), Dive into RIFE (Geert), OSWorkflow (Hani) and Transforming Enterprise Java into a Commodity (Geir).
I'm sitting in Geert Bevin's session titled "Dive into RIFE" and it's a pretty small audience - maybe 20 people. Geert is the CTO of Uwyn, a small custom application development company. He's the founder of RIFE and creator of many RIFE projects: RIFE/Crud, RIFE/Jumpstart, RIFE/Continuations, Bamboo (forum), Bla-bla List (RIA todo list), Drone (Information bot) and Elephant (blog).
What is RIFE? It's a full-stack component framework to quickly and consistently develop and maintain Java web applications.
- Integrated layers allow you to quickly get results with a minimal amount of code
- Best practices are enforced in a pleasant way, providing many additional features and a consistent approach throughout all applications
- Components can easily be resused in many contexts
- Creating maintainable applications is our first goal
- A lot of attention goes to code-level developer comfort
- Frustration reduction by instant changes and reloads
- Creative solutions for difficult problems
- Embraces established standards (XHTML, HTTP, SQL, ...)
- Geared to developing web applications and doesn't abstract away too much
- Everything besides the web engine is designed to be independently usable
- Attention to the whole life-cycle of your application
Geer is now talking about all the different pieces of RIFE - how it has a JDBC abstraction like Spring JDBC, web services support (even publishing of RSS Feeds) and a content management framework. Now we're going to look at RIFE/Jumpstart.
What is RIFE/Jumpstart? It's a source archive that you unzip and run. It makes it easy to start with new RIFE applications and contains everything you need (including Jetty). It has immediate support for more common development environments (X-develop, Netbeans, Eclipse, IDEA and Ant). Geert just showed us a video of getting started with Jumpstart and how you can easily use X-develop to build and deploy the app to Jetty. The Jumpstart application currently uses JUnit, but since the RIFE teams is starting to use TestNG more and more, it's likely they'll change in the near future. RIFE Jumpstart looks similar to AppFuse, except they have the save+reload problem solved - using JVM HotSwapping.
Now I've moved to the Introduction to Seam session. Gavin King is the presenter and the room is packed. It's a big room, so that's saying a lot. Gavin is talking about JSF, how backing beans work and what's in the faces-config.xml. How does Seam compare to J2EE? Much simpler code. There's fewer artifacts (no DTOs). Less noise (EJB boilerplate, Struts boilerplate). More transparent (no direct calls to HttpSession or HttpRequest). It's also much more powerful for complex problems.
JSF is amazingly flexible and extensive. EJB interceptors support a kind of "AOP lite" and EJB3 is a powerful ORM engine. Everything (except for the JSP pages) is unit testable can be tested with JUnit or TestNG. For testing the view layer, Gavin recommends using Selenium.
A backing bean is often "pure glue" and is just noise. Furthermore, it accounts for more LOC than any other component. It doesn't really decouple layers, in fact the couple is more coupled than it otherwise would be. Gavin calls this "wedding cake architecture." These applications look good in the window, but don't taste good when you eat them. I get his point, but have to disagree on the taste of wedding cake. It's always been good at the wedding's I've attended. ;-)
By default, web applications in general do not work in a multi-window application. To make it work, it generally requires a major architecture change. A couple of other areas for improvement in traditional web applications: application leaks memory (not cleaning up session objects) and "flow" is weakly defined. Navigation rules are totally ad hoc and difficult to visualize. How can this code be aware of the long-running business process?
JBoss Seam - what does it do? It unifies the EJB3 and JSF component models. It simplifies Java EE 5, filling a gap. In addition, it integrates jBPM and makes it more developer-friendly. Deprecate so-called stateless architecture. Decouple the technology from the execution environment. Run EJB3 apps in Tomcat or in TestNG or use Seam with JavaBeans and Hibernate. Gavin is using Tomcat for the first time and thinks it's hot-deploy architecture is totally broken. Of course, he usually uses JBoss and never has a problem with hot-deploy. It's interesting to hear this from Gavin, especially since I've heard from others that Hibernate breaks the reloading - and it's not the server's fault.
I'm going to head to another session now, but I did look ahead at some of Gavin's slides. Interestingly enough, the jPBM pageflow definition's XML looks quite similar to Spring Web Flow. Speaking of flows, I heard an interesting comments from someone yesterday after they attended Geert's continuations talk. Apparently, after seeing his talk, they think that RIFE's continuations offer a much more elegant solution to pageflow than these "XML programming" mechanisms.
I tried to go to Hani's OSWorkflow talk, but he was doing Q&A when I walked in. Apparently, he finished 25 minutes early. Then I walked into Geir's talk only to find Dan Deiphouse finishing up an XFire talk. Oh well, there's nothing wrong with having a few minutes to mingle between talks.
Several people have made this claim and they are definitely wrong. Christian investigated this problem deeply, and everyone understands that this is a problem specific to Tomcat. It is not the only problem with hot deploy on Tomcat. I've been very surprised to discover just how fragile this is. Given this, I cannot recommend standalone Tomcat as a good platform for agile development. (Of course, I know I will be flamed for saying this.)
"Interestingly enough, the jPBM pageflow definition's XML looks quite similar to Spring Web Flow."
Yes, it looks surprisingly similar. Note that jBPM predates the Spring stuff by several years.
"they think that RIFE's continuations offer a much more elegant solution to pageflow than these "XML programming" mechanisms."
Agreed, the way RIFE does this is very cool. (Unfortunately it requires bytecode level tricks.) In future, I think the best approach to this stuff will be a DSL.
Posted by Gavin on March 24, 2006 at 04:55 PM MST #
Posted by Christian on March 24, 2006 at 05:12 PM MST #
Now Geert is a smart, rationale guy, so I imagine he also acknowledged that externalizing your flow definitions using a higher-order DSL does has its own advantages as well. I hate I missed his presentation...
With a flow DSL you work with a fewer set of higher-level constructs, instead of working in green-field java (typically by extending from a framework-specific base class). So there is more structure for the developer, structure you get with a DSL focused on the problem of expressing linear flow. The result is you end up with these self-contained flow definitions that define the progression required to complete a user task. These definitions drive execution of java code--your business logic (via method binding expressions). The task orchestration logic itself is expressed in the flow definition language, typically in a externalized form. This makes it very easy to see what the task orchestration logic is and change it without effecting your clients or your business tier; the orchestration document itself is highly toolable, and independent of framework-specific APIs. And readable; in fact, readability is central--take a look at Spring Web Flow's 1.0 EA sample applications and be the judge on flow readability.
Because we're talking about a dedicated flow language, we also have built-in control structures not present in Java; a "goto" like control structure, for example. So from step 7 of the flow if user clicks the "go!" button I can "goto" step 2 in a controlled manner. That's not easily possible in Java, as there *is* simply no goto...
XML is favored by SWF users because it's so pervasive and so naturally toolable; and it just reads well. The SWF engine itself runs on Java-based domain specific control structures independent of XML--and I agree with Gavin, at some point you'll likely see dedicated flow defintion languages emerge for this that engineer into those structures a flow execution engine can consume...
Keith
Posted by Keith Donald on March 24, 2006 at 10:35 PM MST #
It may well be worth having various people in the community getting together and agreeing on some kind of base DSL for expressing pageflows. I have a feeling that there would be fairly broad agreement on what is needed here.
Posted by Gavin on March 25, 2006 at 01:06 AM MST #
Posted by Mike on July 02, 2007 at 08:49 PM MDT #
Yes, its true that *eventually* you'll get a permgen failure - that's a problem with Sun's JVM - but it should not significantly affect day-to-day debugging and development. Actually its been months since I was personally affected by this problem.
Posted by Gavin King on July 25, 2007 at 11:12 PM MDT #
I know this article is a bit dated, but it seems that RAD Frameworks are becoming en vouge, and I'm curious to know if, other than attending these lectures, you've actually had the time to get your hands dirty with any of the frameworks?
Have you played w/ Click (http://click.sourceforge.net)?
Which ones do you like for simplicity, learning, curve, etc.?
Posted by Alamgir Kahn on April 03, 2008 at 10:46 AM MDT #