Search for [TSE] in weblog rd

2006 - A Year in Review

2006-12-31T15:05:56-07:00

Looking back at 2006, it's amazing to see everything that happened. One of the main reasons I started this blog was to provide a history of my life. Now it's time to cash in on that cool feature and look back at the last 12 months.

In early January, I finished working on the Vongo project. I eventually had to shut off comments for my post on Vongo because there were so many complaints. The good news is I didn't work on the UI or service part of it, just the Spring/Hibernate/XFire backend. A week later, Apple announced the MacBook Pro and I purchased one immediately. I still have the same machine and couldn't be happier. A week after that, I quietly released AppFuse 1.9, went to the Broncos vs. Patriots game, then left the next morning for Cancun to celebrate my dad's 60th. I got to watch the Broncos season end after returning from Cancun. January 2006 is one for the books - I scored good tickets to two playoff games and spent a week in Cancun! I'd relive that month without hesitation.

In February, I began playing with Maven 2 , figured out how to use Tiles with WebWork and did a fundraiser for the CSS Framework design contest. I even posted some pictures of my ride to work. Prior to freezing my ass off, Jack had a rough week with Rotavirus and ended up in the Emergency Room.

At the end of February, I received my MacBook Pro and fell in love with everything but the wireless. My posts on the MacBook Pro and wireless issues still get comments weekly from other folks having similar problems.

On February 22nd, Daniel Steinberg's daughter Elena died of bacterial meningitis. Julie made me stop reading Daniel's Dear Elena blog because I was such an emotional wreck. I saw Daniel at a couple of conferences this year, but didn't talk to him until The Spring Experience in December. I didn't know what to say to him. He erased all my apprehensions with a simple "Thanks", a smile and a handshake. It's good to see you're still writing about Elena Daniel. I still have a hard time reading your posts.

February ended with a beautiful 72°F day.

In March, I started the CSS Framework design contest, rode to work in the rain and flew to Boston and Vegas. Memories of St. Patrick's Day in Boston with friends still brings a smile to my face. TheServerSide show in Vegas was a lot of fun and it was the first BOF I hosted with free beer. I later got to meet Mike Stenhouse (the inventor of The CSS Framework) in December and hosted two more "BOFs with Beer" at the Colorado Software Summit and The Spring Experience. Cost difference? Vegas: $800, Keystone: $350, Hollywood, FL: $220.

At the end of March, I came down with a nasty case of Carpal Tunnel. After seeing a specialist that massaged the hell out of my arm, everything was back to normal. I haven't had any issues since - but I also haven't had many multiple-no-sleep-night coding sprints in a while either.

In April, I quit working on AppFuse and moved to Rails. I posted my Tips for Productivity and Happiness at Work (my most popular blog entry of all time), shipped my bus off to the shop and celebrated Julie and I's 6th anniversary. Then I rebooted this site and lived it up in New York City.

May brought CSS Design Contest winners and a 2-week trip to San Francisco for The Ajax Experience and JavaOne. The highlight of that trip was the weekend I spent in Wine Country.

In June, AppFuse 1.9.2 and Seam 1.0 were unleashed. Tim O'Brien had an interesting post titled What Web Application framework should you use?. I responded and Struts became a more focused project. Shale moved to a TLP shortly after. We started planning Raible Road Trip #10 and I began traveling to Washington, DC for a project. Going for beers at Brickskeller was the highlight of our trip that week.

July introduced me to cancelled flights and redeyes and Jason Carreira started JSR 303. AppFuse 1.9.3 was released and Julie sold her house to the first people that looked at it. At the end of the month, Jim Goodwill and I drove to OSCON in Portland. Having beers with Bryan and Scott at The Kennedy School was a highlight of that trip. Following OSCON, the family and I headed to Montana for a week.

August was great, probably because I'd just hit 7 states in 7 days. I published an article on IBM developerWorks and had a device-free weekend (which I definitely need to do more often). I began working on AppFuse 2.0, a new sushi restaurant moved into our neighborhood and I got a new EVDO card (which I later lost in November). Jack turned 2 on August 28th.

In September, we got a new puppy. I traveled to the drunkest city in America, Las Vegas and New England. Julie met me in Boston and we had a blast at our good friends' (Chris and Julie's) wedding.

October brought the release of Spring 2.0 and a 2-week project for me at OpenLogic. Abbie and Jack got their pictures taken at school and I spent at week in Keystone at The Colorado Software Summit.

In November, my sister Kalin brought some hard cider to Abbie's 4th birthday. I attended Denver's NoFluff and hugged my kids. Jack and I had a boys weekend and we headed to The Cabin on Raible Road Trip #11.

To end the year, I did a bit more travel - first to Boise then to Florida for The Spring Experience. After a week of vacation in Florida, we returned to Denver for The Blizzard of 2006. Finally, we drove up to Steamboat for Christmas and took the kids skiing.

All in all, it's been a fabulous year. Watching the kids grow up, start to play together and even have conversations with each other has been very cool. I traveled more than I wanted to, but I also got to visit a lot of cities that I'd never been to. My goals for the year? To be happy, ski more and enjoy a few car bombs with family and friends.

Back in Denver

2006-12-18T08:43:15-07:00

After living out of a suitcase for most of December, it was nice to arrive back in Denver last night. I left here on December 3rd to travel to Boise, Idaho to teach a Spring course. From there, I flew to Ft. Lauderdale, Florida to attend The Spring Experience. This was an excellent show, and I blogged most of the sessions I attended. To read about my AppFuse talk on Saturday night, see my Spring Live blog.

After TSE, I spent the next week with my family in Florida. We drove up to Disney World on the 2nd day of our vacation and had a blast. No one was there, so lines where short and the kids couldn't stop smiling.

While watching the kids' faces light up at Disney was cool, driving Julie's Mom's Cayenne Turbo S around all week was a highlight for me. It was definitely a gas-guzzler, but 520 horses is an awful lot of fun. It rained a lot the remainder of the week - almost 8 inches in 12 hours one day. Even when raining, the temperature still hovered around 80°F all week long. As crazy as it sounds, I'm actually happy to get back to the cool weather in Denver (high of 30°F today).

I'll be in the office all week, trying to tie up some loose ends before the end of the year. This weekend, it's back to vacation mode for another week. This time we'll be heading up to Steamboat for skiing, holiday cheer and (hopefully) lots of snow.

[TSE] Hop into Real Object Oriented (ROO) with Ben Alex

2006-12-10T10:32:04-07:00

This session's goals are to:

To detail the "ROO" DDD architecture
To show you how productive ROO can be
To profile an Australian project using ROO

ROO is more of an implementation than an architecture. So what is ROO? It's not an Australian marsupial or an Australian airline. It's a Domain-Driven Design (DDD) implementation.

Real Object Oriented (ROO) is both an architectural approach and a framework with code generation. ROO uses 4 (UI, middle-tier, domain model and persistence) layers instead of 3. Most of of the code is in the domain model. In the persistence layer, most DAOs only differ in finder methods. Rather than DAOs, "Repositories" (from DDD) are used.

Since most of the code is in the middle-tier DO layer (including business), the middle-tier is primarily used to "export" interfaces for remoting, the middle-tier facade and DTOs. Almost all of the interfaces in the ROO architecture are generated or require trivial coding.

Compare ROO to Traditional Approach (normal way people develop with Spring).

Transparent persistence usually not used , it is in ROO
Persistence layer name: DAO, Repository in ROO
Finder method location: DAO, Finders in ROO
State integrity: None, DO layer in ROO
Business logic: Service Layer, DO Layer in ROO
Form backing objects: "DO" layer, DTO layer in ROO
DO and SL pattern names: Misused, Correct in ROO

ROO uses more layers and types than traditional Java. Traditional Java isn’t a fair comparison (patterns are not very OO, and can be less efficient). Ben believes the ROO approach is justifiable for 3 reasons:

Layers have well-defined purpose (OO justification)
Types mostly auto-generated (efficiency justification)
Architecture uses patterns (precedence justification)

Patterns used in ROO:

Strategy
Façade
Domain Object (“DO”)
Data Transfer Object (“DTO”)
DTO Assembler
Repository

There are many problem with code generation, but quality code generation is attainable.

How is ROO different from other things?
It was designed to scratch an itch. Ben wrote it because he was tired of writing code using the same old architecture patterns. He didn't write it because he wanted to start another open source project. It was also designed to scratch other people's itch (do we really need the service layer?). ROO is founded on a few philosophies: domain first, infrastructure 2nd, convention over configuration, embrace OO and modern capabilities.

Ben is now doing a video demo of ROO. In the video, he's created a project using a Maven 2 archetype (I've seen this used a lot at this conference) and imported it into Eclipse. From there, he creates Entity classes and shows how Eclipse generates Hibernate mapping files and DTOs (as well as tests) for the entities. The one pain (currently) is you do have to copy the generated mapping files back into your classpath. Most of the POJOs that Ben is creating for his domain model extend some ROO parent classes (i.e. AbstractDomainObjectLong). While he does write getters in these classes, he only provides setters for those fields that can change. Then he creates a public constructor that contains the required fields.

It looks like Ben has wired up some sort of external tool (or maybe a Maven plugin) to do the code generation. Later I found out it's Java class that's merely run from Eclipse or Maven. ROO is Java 1.3 compatible.

For the tests that ROO generates, it creates abstract methods for any business logic methods that need testing. It's then up to you to subclass this test and implement the abstract test method. ROO also seems to generate population classes that populate your database for tests. I don't know how it figures out sample address information, but I'm assuming this data somehow existed in the Maven archetype.

To create Finders with ROO, you implement a FinderSpecification class and implement a public FinderDetails[] getFinderDetails() method. The code in this method is more like EasyMock's API than Hibernate's Criteria API.

For the code generation, the life of a type is very important. Not only are types created initially, they're updated when you touch them. Some class are generated as Abstract classes when they need you to provide additional information.

ROO generates custom finders, classes, and the Spring XML. It does not generate Hibernate User Type interfaces, but it does generate classes for user types. It generates DTOs, middle-tier facades, classes and Spring XML. It also generates test data and tests for all the generated code.

Ben just did a survey of the room asking who's using Ant vs. Maven. Surprisingly, Ant only slightly beats Maven.

Persistence in ROO

Key Principles:

Think of them as DAOs with transparent persistence
Transparent persistence engine is essential
Domain objects always attached to unit of work (UoW)
Persistence layer may be injected into domain objects (although mostly finder types will be injected, not repositories)
Persistence layer is unaware of DTOs

The Repository:

Global, shared repository
Transparent persistence, API agnostic interface
Method naming convention (read*, find* and make*)
Some methods exported to middle tier facade

Finders:

Typically fine grained and domain object specific
- public User[] findUserBySurname(String surname) )
Easy to dynamically mock and DI
Returns domain objects attached to UoW
ROO generates finder via criteria-like API

Middle Tier Exporting

Repository contributes its read* methods to facade
Finders contribute all methods
Facades returns DTOs
- Not domain objects
- Conversion via DTO Assembler
- DTOs are normal JavaBeans
- DTOs lack lazy loading semantics

Domain Objects

Key Principles:

Most of your work and code occurs in domain objects
Domain objects are your only 1st class citizens
Code generation is mostly driven by domain objects
DI is certainly possible

Encapsulation:

Fully encapsulated
Distinguish state managed fields
Persistence layer uses field-level access
Public constructors reflect mandatory fields

For the DTO Assembler in ROO, they use Dozer. Initially, they had a fair amount of issues with it, but the latest releases have solved all of those.

In addition to the code generation for DTOs, Facades, etc., ROO generates middle-tier metadata that's all available via JMX. There is enough information provided by this metadata to build a Naked Objects implementation (or possibly even a web UI).

Interestingly enough - it looks like the Maven archetype for this project is able to manipulate the launchers and external tools that are configured in Eclipse. I confirmed with Ben afterwards that Maven's archetypes (or maybe it's the Eclipse plugin) are capable of configuring Eclipse's launcher configurations.

Woolworths in Australia (not the same as Woolworths in the US) is using this system. They've used ROO on 3 different projects, from simple to very complex projects. For the complex project, ROO had to add support for composite primary keys. Many of the issues ROO had with Dozer were fixed and contributed back to the project by Woolworth's developers.

My Thoughts
ROO looks like a pretty cool system. It reminds me a lot of Grails' GORM except that it requires more tooling. Ben said most of the code generation is driven by a Java class. I wonder if it has templates (i.e. FreeMarker) that can be modified? If ROO ever becomes an open source project, I'm guessing it will be very polished and well-received. I'm sure we could use ROO in AppFuse and make a lot of Java developers very happy.

[TSE] Building Modern Web Applications with Mike Stenhouse

2006-12-10T08:51:40-07:00

Mike Stenhouse is the creator of the CSS Framework we use in AppFuse¹. Mike is going to talk about the tools he uses to develop web applications. Mike works solely on the front-end, no backend work.

"In 2007 we’ll witness the increasing dominance of open internet standards. As web access via mobile phones grows, these standards will sweep aside the proprietary protocols promoted by individual companies striving for technical monopoly. Today’s desktop software will be overtaken by internet-based services that enable users to choose the document formats, search tools and editing capability that best suit their needs." -- Eric Schmidt, CEO Google

Web Standards is a methodology and philosophy, not just valid CSS and XHTML. The main philosophy behind web standards is progressive enhancement. The methodology behind web standards is a 3-step process.

Figure out what the content means
Code the HTML accordingly, ignoring the design
Then write your CSS to realise the design
Finally, add a sprinkling of Javascript to tune the interaction

HTML
X/HTML is where you get most of your benefits from. It should be content only, nothing else. If your content and XHTML sucks, CSS is probably not going to be able to help a whole lot. HTML vs. XHTML have small syntax differences, the main differences show up with the mode of the doctype. HTML 4 Strict, XHTML Transitional and XHTML Strict are all good. HTML 4 Loose sucks.

HTML is the skeleton and isn't as easy as people think it is. Tables and nested tables are some of the worst offenders of bad HTML. When people move from table-based layouts to standards-based layouts, it's usually a disaster because of meaningless classes on div tags. A lot of times, adding classes to HTML elements is completely meaningless. The less classes and ids, generally the better. By removing classes, your HTML becomes much more readable (save for input tags and such).

This is what's called semantic HTML. It has nothing to do with the Semantic Web. Using HTML for what it's designed for. Headings are in order, paragraphs, lists, inputs, labels, fieldsets. Tables are used only for tabular data.

To write semantic HTML, use the following guidlines:

Look at your content and figure out its meaning
Think of the document outline mode in Word -the headings are used to navigate
Group form elements and work out what order they should be filled in
If it’s too tricky there might be a problem with the design

Using these guidelines will help you write cleaner code. The CSS Zen Garden is a poor example of semantic HTML - there's just too many classes. You should try to push classes and ids upwards. For example, you can convert the following HTML from:

<ul>
    <li><a class="navlink" href="x">
    <li><a class="navlink" href="y">
    <li><a class="navlink" href="z">

To:

<ul class="nav">
    <li><a href="x">
    <li><a href="y">
    <li><a href="z">

The first example only allows you to style with "a.navlink", whereas the 2nd gives you more elements to style (ul.nav a, ul.nav, ul.nav li).

Another suggestion is to use multiple classes on your HTML elements. <body class="order final sales"> can be controlled with body.sales, body.final and body.order.final CSS classes. CSS class names should be almost like metadata - they should relate more to the content to the design.

By using web standards-based design, you get the benefits of debugging (W3C Validator). In addition, you get SEO benefits from good HTML. If you use proper semantic HTML, machines can make better sense of your HTML. Headings are one of the most important things for SEO. It's amazing how simple this stuff is and how few people understand it.

Microformats
Microformats are a way of adding metadata to your HTML. They basically say to use classes, rels and refs, and use them in a specific way. The Semantic Web community has recently started forming ties with the microformats community. A few uses are currently in existence: hCard, hReview, hCalender, hResume, XFN, XOXO, rel-directory, rel-pavatar, rel-nofollow, rel-tag and xFolk.

To conform to a microformat, you simply need to add add certain classes to your existing markup. For example, here's an address in hCard format:

<div class="box vcard">
   <h3>Contact Details</h3> 
   <a class="fn url" href="ttp://adactio.com/">
       <span class="given-name">Jeremy</span> 
       <span class="family-name">Keith</span>
    </a> 
    <p class="adr">
        <span class="street-address">57/58 Brunswick Road</span> 
        <span class="locality">Hove</span>
        <a class="postal-code" 
           href="http://maps.google.co.uk/maps?q=bn3+1dh" title="map">BN3 1DH</a> 
        <span class="country-name">England</span>
    </p> 
</div>

If you feed this into Technorati, it can give you back a vCard. It can also work by specifying a URL that contains HTML with this microformat.

Even Bill Gates said "We need microformats". They're definitely starting to get a lot of traction. The beauty is they're very simple to use and implement.

CSS
What's important about CSS is it allows you to redefine how your HTML elements behave and display on a page. Firefox actually uses CSS (including some CSS 3.0 stuff) to control how HTML renders. With CSS, you can extract your design from the HTML. It's the icing on the HTML cake.

CSS allows you to separate the front from the back. It can very useful for designers and developers. Developers do the HTML, designers do the CSS. The CSS Zen Garden is the best example of how powerful CSS is.

CSS allows you to retask-content. For example, supplying a different CSS file for printing is a great use. There's also support for mobile devices and projectors, but they're not as well supported.

CSS allows you to define your display once and reuse more. DRY for HTML. You can even get re-use between sites by using "modular CSS". Mike generally breaks his CSS down into groups using @import:

@import url("tools.css");
@import url("typo.css"); 
@import url("forms.css");
@import url("tables.css"); 
@import url("layout.css");

Other breakdowns: site sections, color, old browsers vs. new browsers and layout (CSS Framework). Basically, use a different stylesheet to separate these different breakdowns.

Mike invented the CSS Framework as a "set of standard naming conventions for the HTML and an example set of layout stylesheets".

The CSS Framework gives you a massive head start on small projects, but may not be as useful for large projects. Mike is working with Clay Loveless to create an updated version of The CSS Framework. The first thing I'd suggest is a new name, while "the CSS Framework" is a descriptive name, it's too much of a mouthful. Look at what the term "Ajax" did for XHTML, JavaScript, CSS and XHR.

Hacks for the different browsers: the only one that Mike uses regularly is "* html" for IE. He generally applies "height: 1%". Occasionally he needs \ for IE 5.x.

w\idth: 50px; 
width: 40px;

The final hack is to put your IE-specific rules in ie.css, but Mike's not a big fan of it.

Rules of thumb to avoid browser-compatibility issues:

Avoid margins and padding on elements with a width
Use % font-size on the body and ems for everything else
Avoid PNG and alpha transparency
Avoid too much styling on form elements (can be a nightmare to do cross-browser)

IE7 fixed the * html parsing error so filter doesn't work in IE7. They haven't fixed "hasLayout" or conditional comments. "hasLayout" is a bug in IE that adds padding around list elements whenever they have any CSS styles applied to them. I'm sure there's more too this, but I didn't get a chance to write it down.

Triggering hasLayout cures similar problems to height: 1% in previous versions. You can manipulate programmatically using object.currentStyle.hasLayout.

Conditional comments are still a problem. Mike likes it because it allows you to put all your IE hacks in one place. He doesn't like it because it requires you keep an extra things in your head.

JavaScript
JavaScript has gotten a bad name because it was used to add a lot of crap to web pages for so many years. It used to be used to create atrocities, whereas now it's used to create very elegant sites.

The first thing that brought back Ajax is "DOM Scripting". DOM Scripting is methods for accessing and modifying the DOM. The DOM is an HTML page represented as a tree of objects.

History: DOM0 was not a standard. DOM1 is a standard for navigation and manipulation. DOM2 is XML and events (onclick, onblur, etc.).

The 2nd thing that brought back JavaScript is Ajax. There's a number of different Ajax techniques:

XmlHttpRequest object
IFrames
Flash Remoting
Applets
Comet

Mike is using applets on a project right now for heavy visualization. They use Ajax with applets so it doesn't unload the VM and they're calling it "AppleJax".

The main problems with Ajax when it first came out where: network latency, usability, JavaScript off, SEO and Accessibility.

Frameworks can help you get around a lot of the issues with Ajax. The problems with frameworks is there are so many. A few of the best: Dojo, Prototype, YUI, MochiKit, Moo Tools and jQuery. Mike's favorite is jQuery.

Dojo is great, but almost does too much. Mike is afraid to use it because he doesn't understand how they do some things.

Dojo:

Devilishly clever
Application-like functionality in the browser
Includes stuff like client-side storage
Massive
Not much documentation
Black magic

YUI:

The full weight of Yahoo! behind it
Extremely well documented
Modular
Lacking in sex-appeal
Can get very heavy

MochiKit:

Modeled after Python
Quite heavy
Highly rated but hasn’t experienced the sort of adoption the other frameworks have seen

Prototype:

Built into Rails (the main reason Mike used it)
Good Ajax
Quite heavy, especially with Scriptaculous
Dispersed documentation but readable source code
Missing some basic helpers (addressed by Low Pro)

Moo Tools:

Modular
Functional
Very compact

Mike mentions Moo Tools because friends have recommended it that are "in the know".

jQuery:

Lightweight
Uses CSS syntax
Perfectly suited to progressive enhancement
Functional design
Well documented
Basic Ajax

However, Ajax frameworks can be dangerous. It's the problem of leaky abstractions - if you don't understand what the framework is doing, it can be difficult to debug and refactor. Mike recommends writing JavaScript the long way and then refactor it to use a framework after you understand it.

Unobtrusive JavaScript is why Mike came here to talk today. It allows you do "progressive enhancement for your applications". To use progressive enhancement, your JavasSript should be kept separate from your HTML and CSS. Everything should work without JavaScript. It should be possible to use progressive enhancement with full-blown Ajax applications.

Inline JavaScript sucks:

<a href="#" onclick="lightbox('/show_email/224899'); return false;">Daily Call</a>
<a href="#" onclick="lightbox('/show_email/138512'); return false;">Access Card Information</a> 
<a href="#" onclick="lightbox('/show_email/83407'); return false;">Can UBS Tame Enron's Wild Traders?</a>

A better solution is:

<a href="/show_email/224899">Daily Call</a>
<a href="/show_email/138512">Access Card Information</a> 
<a href="/show_email/83407">Can UBS Tame Enron's Wild Traders?</a>

<script type="text/javascript">
window.onload = function() { 
    if (!document.getElementsByTagName) return;
    var links = document.getElementsByTagName(&lsquo;A&rsquo;); 
    each (link in links) {
        link.onclick = function() { lightbox(this.href); return false; }; 
    }
}; 
</script>

onready is a better way to do window.onload as it will fire as soon as the HTML has come down. Hijax embraces this idea. The approach is as follows:

Make a rock-solid, Web 1.0 app
Good, old fashioned GETs and POSTs that will work in any browser and on any platform
Just HTML styled with CSS
Add a layer of Javascript attached via the DOM to enhance the experience

It might take a little more work to develop this way, but it's a much more solid foundation. If your JavaScript/Ajax starts to break, the app should still work. A good example is Odeo. Apparently, one of their releases, they forgot to deploy the JavaScript and the whole site continued to work - no one even told them.

Other benefits: your app doesn't depend on JavaScript so it'll work on devices that don't support it. There's no way you can possibly account for every use someone might put your site to (mobile phone, accessibility devices, set top boxes, etc.).

Keep your JavaScript and CSS separate. Don't manipulate styles with JavaScript, just switch CSS classes.

Back to Eric Schmidt's quote. If you use "progressive enhancement", it's an excellent way to leverage web standards. The better the browser, the better the experience.

1. At the end of his talk, Mike mentioned that he got invited to this conference because we use the CSS Framework in AppFuse. Cool!

My Thoughts
After Mike's talk, I walked up and introduced myself. I thanked him for the CSS Framework and we chatted a bit about his talk. I really like his recommendations of progressive enhancement (or Hijax) and plan to use it a lot more when developing UIs. Mike was an excellent speaker and one of those guys you instantly want to have a beer with.

[TSE] Keynote: The Bigger Picture with Adrian Colyer

2006-12-09T19:26:49-07:00

We've seen a lot of things over the last few days, but what about the big picture? It's not just about the Spring Framework anymore, but there's also a lot of sub-projects: SFW, SWF, SWS, S-OSGi. Then there's Enterprise services: clustering, persistence, messaging and scheduling. Industry trends: SOA, Web 2.0/RIA, RAD stacks.

Agenda

Spring portfolio: unifying themes, fitting the pieces together (by layer) and future direction
Facing the feature: my boss says I need a SOA, from auto-suggest to RIA and the quest for ever-increasing productivity

The first thing that's Spring has done is to give you a triangular simple object. Because a triangle is one of the strongest shapes, this is why Spring holds up to heavy loads and lots of users. Triangles work much better than circles.

Spring is built on "simple objects" and 3 principles: Dependency Injection, AOP and Portable Service Abstractions.

The "blueprints" that Spring provides are a great way to understand applications. If a a team uses simple objects + blueprints, chances are an experienced Spring developer can understand how most of the application works.

Data Access Layer
Spring supports JDBC, iBATIS, JDO, Hibernate, TopLink. In addition, Spring 2.0 has JPA Support, including OpenJPA, TopLink Essentials and Hibernate. Further enhancements coming for 2.1: JPA namespace and support for common non-standard features (for example, criteria API and user types).

Other backends: Spring also has support for accessing enterprise systems, CICS and IMS. Spring has JCA CCI support with the CCiTemplate.

Spring LDAP project adds support for interacting with LDAP servers. I've worked with Spring LDAP and it certainly does work nice. The only thing I found painful was that it didn't support transactions, but neither does LDAP, so that's to be expected. If you've never used Spring LDAP, you probably already know a lot about LdapTemplate, even if you haven't used it.

Service Layer
You all know how to define business services, but what about scheduling, asynchronous messaging, ESBs, etc? Spring has support for scheduling with JDK Timer and Quartz. You can run jobs in background with cron expressions or simple triggers. MethodInvokingJobDetailFactoryBean makes it trivial to execute an operation on a bean.

Asynchronous tasks can be run by TaskExecutor. It can be kicked off programmatically or by a scheduler. Simple confugiration change to switch from thread pool to commonj work manager.

Messaging: Spring 2.0 extended Spring's JMS support. JmsTemplate + Message-driven POJOs. It's fully Java EE compliant, can participate in a transaction and process a message and send a reply in one unit of work.

For XML payloads, you can use Spring Web Services to do OXM (Object XML Mapping).

Is all this heading towards an ESB-like system? In a sense, so why not just use a full-blown ESB like Mule. Mule 2.0 is being re-written to be entirely based on Spring.

ESB - Mule integration: Spring application context support simple event framework: ApplicationEventPublisher and ApplicationEventPublisherAware, ApplicationEvent and ApplicationListener. Simple for a bean to publish and listen to events. Mule can integrate into this as a custom event multi-caster.

Configure a bean to listen only to events of interest using MuleSubscriptionEventListener. You can publish events to mule using a normal ApplicationEventPublisher interface and create a MuleApplicationEvent to publish.

Clustering

Tangosol Coherence and Coherence Data Grid for Spring: You can use a <datagrid:member> to register application context as a member of a DataGrid. Application events are grid-wide. <bean id="..." scope="datagrid">: bean operations "in-place" in the grid. There's no need for cluster-wide locking (b/c it's fast). DataGridBean transaction management. <datagrid:cache/> allows you to define a datagrid as a bean. Furthermore, there's Java and .NET interoparability for DataGrid beans.
GigaSpaces 5.2 was announced last week. Use POJOs as space entries, full Spring transaction integration. There's also a PlatformTransactionManager implementation. You can access their DataGrid using a JdbcTemplate and GigaSpaces' JDBC Driver, or you can use the GigaSpacesTemplate. You can access the GigaSpaces MessageGrid via Spring's JMS abstraction. You can submit jobs to the ComputeGrid, which is a parallel processing engine. It works with Spring AOP to create proxy to remove service and uses a DelegratingWorker from Spring modules for task execution.
Terracotta: Allows you to cluster any singleton Spring bean. Beans named in Terracotta configuration file, and clustering is completely transparent to Spring and to your application. The state of that bean will be shared across the cluster. You can publish ApplicationEvents across the cluster - where application events are propogated to all listers in each JVM. Terracotta allows clustering Spring Web Flow to enable failover of conversation state. AOP + clustered beans + Spring JMX = cluster management view (view local vs. clustered data). Now free and open source!

Security impacts all layers. It starts in remote and web interfaces and can be useful for role-based method-invocations in service layer and data layer. Furthermore, Acegi's ACLs can be very useful for fine-grained security on domain objects. "Spring Security is one of the hidden jewels in the bunch here."

Presentation Layer
Spring Rich Client is another member of the Spring family that allows you to leverage Spring ideas in a Swing application. Has support for GUI builders and many other features that allow you to write Swing easier.

Spring MVC is great for free navigation and has a nice Controller hierarchy. Supports many more view options than just JSP. When developing wizards, it gets a bit more complicated. If you're stressing AbstractWizardFormController even a little bit, it's time for Spring Web Flow.

Spring Web Flow is for controlled navigation. You can model a web interaction as a flow and declare states and transitions between them. By modeling that flow in a blueprint and declaring the various states and transitions, you can easily abstract and compose how to navigate between pages. SWF can be used with servlets, portlets and multiple web frameworks. It supports post-redirect-get automatically and browser buttons "just work".

Where is future for SWF: even simpler flow definitions for common patterns (higher level of abstraction in configuration. Also, first class JSF support. Apparently, the JSF support is not as good as they'd like it to be.

Spring IDE has support for code-completion in XML, the "p" namespace and composing web flows graphically. Spring IDE also will have AOP support, much like AJT gives you for AspectJ (this is very cool IMO). With the AOP support, you can navigate between an Aspect and the XML configuration that defines it.

Web 2.0 / Ajax / RIA - what about creating the better using experience with these tools? Ajax ingredients are UI toolkits, effects and a means of communicating with the server. To return XML from Spring MVC, you can use AbstractXsltView (with no styleSheetLocation set). For converting model objects to XML, you can use Spring Web Services OXM stuff. It can get simpler than that - just use DWR and JSON-RPC. If you want to secure DWR, Spring Security will allow you to do that. Acegi is apparently looking at doing better support for Ajax and DWR. DWR 2.0 has a new Spring <dwr:*> namespace that allows you to easily nest a <dwr:remote> tag in a bean definition and expose that bean as a JavaScript object.

If you need a real web service, Spring supports that. Use XFireExporter for simple RPC style services. For everything else, there's Spring Web Services. It has an Object/XML mapping abstraction, a framework that resembles Spring MVC and it supports WS-Security with Spring Security. Interface21 has heard from many customers that Spring WS is one of their favorite pieces of the Spring portfolio.

OSOA (Open SOA Collaboration) is made up of a number of companies: BEA, IBM, Oracle, SAP, Sun ... and ... Interface21.

Service Component Architecture - course grained SOA. It has an assembly model with service components, references and wires everything together. It also contains a policy framework that supports QoS. Service implementation and client API can be Java, C++, BPEL, EJB or Spring.

AOP
Spring 2.0 delivered close integration between AspectJ and Spring AOP. It's also easy to use the full power of AspectJ with Spring application if you need it. AOP + JMX is particularly compelling - take a look at the Glassbox project for an example of this. Juergen has also been working on integrating load-time weaving as your application context is being initialized.

Spring-OSGi - allows you to use a SOA across application context within the same application. Allows a very strong module system, versioning, concurrent deployment (of different versions) and hot re-deploy.

Rapid Application Development: Spring 2.0 supports beans written in alternative languages: JRuby, Groovy and Beanshell. ROO (Real Object Oriented) application. Domain first, infrastructure second. Full static rapid development and has been validated with clients to great success.

Summary
Spring has consistent themes and approach. More than just "The Spring Framework". There's over 20 projects in addition to core Spring that allow you to do great things and build applications easier. Eight of these projects are lead by Interface21. Next year, they're hoping to do something like Callisto where all Spring-related projects can do a simultaneous release.

My Thoughts
Interestingly enough, many of the web frameworks that build on Spring aren't listed here (AppFuse, Grails, Trails, etc.). That makes sense since these projects are most useful when doing greenfield development and I doubt Interface21 does much of that.

With all of the Spring projects, Interface21 is starting to look like JBoss. However, one of the major differences between I21 and JBoss is the majority of Spring projects are actually not lead by Interface21.

This was one of my favorite talks of the show because it talked about the future of Spring and what's on the roadmap for many sub-projects.

[TSE] Spring-OSGI with Adrian Colyer

2006-12-09T14:29:58-07:00

Adrian has CTO as his title on his slides. Wasn't he hired as "Chief Scientist" originally? I wonder why his title changed? Maybe having the CTO title is a better way of getting more cash when the buyout happens? What buyout you ask? I don't know, but I can't help but think that Interface21 is on the radar of major organizations like Oracle and BEA. While it might suck for those guys to answer to a larger organization, it would be nice to see Rod, Juergen, et. al. benefit ($$) from all their hard work.

Agenda

What is OSGi?
What problems does it help us to solve?
How does it work?
Where does Spring fit in?
Spring-OSGi

One of the first questions people ask about OSGi is "what the heck is it?"

The 2nd question is "what's with the lowercase i?" Seriously - does anyone know?

Most people don't even know what it is. OSGi stands for Open Services Gateway initiative. From the very beginning, it was designed to be lightweight and dynamic. This is the major difference between it and other containers. It's always been designed to have things added and removed. Now it's tagline is: "The Dynamic Module System for Java".

It's designed to allow you to partition a system into a number of modules (a.k.a. bundles). There's strict visibility rules (similar to protected and private). There's a resolution process (dependencies are satisfied) and it understands versioning.

It's dynamic! Modules can be installed, started, stopped, uninstalled and updated - all at runtime.

It's even service oriented (no wonder IBM loves it). Bundles can publish services (dynamically). The Service Registry allows other bundles to find services and bind to them. Services come and go at runtime, all taken care of for you.

Where does OSGi come from? It's backed by the OSGi Alliance. Unfortunately, this site makes it difficult to figure out exactly what OSGi is. The founders of OSGi understood it needed to be lightweight and dynamic from day one. It started in 1999, and was originally focues on embedded Java nd networked devices. In 2003 it was exteneded to support to mobile devices. In 2004, it had significant ope source community opttion with Eclipse. In 2006 and 2007, it's moving into server-side Java.

Who's doing OSGi containers?

Open-source implementations: Equinox, Felix (Apache), Knopflerfish
Significant Enterprise usage: Eclipse, IBM (WebSphere, Lotus), JOnAS, interest from BEA and Oracle

So what? What problems does OSGi solve?

Visibility By default, a bundle is a black box. It's completely protected and you can't see inside it, not even with reflection or any other classloading trickery. Only exported packages are visible outside of the exporting bundle. This stops unintended coupling between modules, enables independent development, faster development cycles and security.

Operational Control
An OSGi container allows you to see all modules and their status - using the OSGi console or JMX. You can get information on wiring, install new bundles, activate bundles (and publish services), deactivate bundles (and unregister services), refresh bundles, stop bundles and uninstall bundles. The beauty? You can do all of this without stopping or restarting the application!

What is an OSGi bundle?
It's just a jar file. There's no complicated tools or sophisticated packaging required. All you need is a symbolic name in your META-INF/MANIFEST.MF file. For example:

Bundle-SymbolicName: org.swf.beans

There are a number of other attributes you can specify, but the SymbolicName is the only required one.

There's a Maven OSGi Plugin. The major change from a regular JAR project is <packaging>jar</packaging> -> <packaging>osgi-bundle</packaging>.

Sidenote: You have to love how Maven is so Google un-friendly. Searching for Maven OSGi Plugin doesn't seem to provide a definitive answer to the Maven plugin that Adrian is talking about. I'm guessing Maven has OSGi support natively?

Eclipse has fantastic tooling support for OSGi via "plug-ins". You can create a new "plug-in project" and use Eclipse to create/edit your OSGi manifest. Eclipse calls bundles "plug-ins" - so creating a plug-in project is the same thing as creating a new bundle.

Export-Package is a header (a.k.a. manifest entry) used to export types for other bundles to use. If it's not exported, it's not visible. For example:

Export-Package: org.xyz.m1.service, 
                org.xyz.m2.service, 
                org.xyz.m3.service

You can also specify a version by adding a semicolon after the package and specifying "version=#". For example:

Export-Package: org.xyz.m1.service; version=1.0, 
                org.xyz.m2.service; version=1.0, 
                org.xyz.m3.service; version=1.0

In addition to specifying specific versions, there's syntax to control a specific versions. For the examples above, OSGi will actually get any version 1.0 and above.

For the next 10 minutes, Adrian talked about how class-loading and resolution works. He also pointed out how to bootstrap a bundle (using the BundleActivator interface) and the basics of the Service Registry. The BundleContext allows you to get and remove services.

What about JSR 277 (Java Module System)? It's a very crude version of OSGi with its "RequireBundle" mechanism. The key problem is the lack of dynamics (loading/unloading of modules). Peter Kriens (of the OSGi Alliance) shares his thoughts on this in his JSR 277 Review. JSR 291 (Dynamic Component Support for Java SE) may kill 277 because it relies on OSGi. Its goal:

Establish a JCP specification for a dynamic component framework supporting existing Java SE environments based on the OSGi dynamic component model specifications. "

What about Spring?
OSGi offers an excellent foundation for building enterprise applications. How can you exploit the power and sophistication of OSGi w/o adding complexity? How can you split your application into a number of OSGi bundles? Between bundles, you need an easy way to expose bundles as services and wire service references b/w them. What about testing? How can you test bundles w/o running them inside an OSGi container?

Spring-OSGi hopes to allow you to build on OSGi, but deploy in Tomcat, WebSphere, WebLogic or any other application server. Basically, it gives you an "OSGi powered Web Application".

Project Goals: Bring the benefits of OSGi to enterprise applications and use Spring to configure modules/bundles. In addition, make it easy to code your applications w/o depending on OSGi APIs and make it easy to unit and integration test.

Project Collaborators: Adrian is the lead, and there's active committers from BEA and Oracle. Input to the project's specification has been gathered from OSGi Alliance (technical director and CTO), BEA, Oracle, IBM, Eclipse Equinox, Felix and many individuals.

Spring modules (spring-core, spring-beans, spring-aop) will be shipped as OSGi bundles in Spring 2.1. All the necessary import and export package headers will be pre-defined. This will enable an OSGi application to import and use Spring packages and services.

OsgiBundleXmlApplicationContext is a Spring application context based on an OSGi bundle. It uses the bundle context and classloader to load resources and implements Spring's resource abstraction for OSGi. There is a "bundle:" prefix for specifying an explicit path.

To do integration testing with Spring-OSGi, you can extend ConfigurableBundleCreatorTests. This automatically creates an OSGi bundle containing the tests on the fly. This class handles starting an OSGi container, installs all bundles and runs tests inside OSGi. Currently, it supports Equinox, Felix and Knopflerfish. If you're using Maven, it's simple to switch containers with profiles (i.e. -Pfelix). Adrian did a demo in Eclipse. I didn't seem the OSGi container starting (or him specify which one to use) but the test seemed to finish rather quickly.

To interact with OSGi, there are a number of conveniences that Spring-OSGi provides: BundleContextAware, <osgi:property-placeholder>, <osgi:bundle> (starts other bundles), <osgi:virtual-bundle> (bundle created on the fly).

OSGi-based web applications
It's entirely possible to run an OSGi container embedded in another container. Remember it's lightweight enough to run in a phone! Even OSGi in OSGi is supported.

Equinox is the only OSGi container that currently supports web applications. It uses a "bridge servlet" that acts as a front controller and dispatches servlet requests to bundles. To package your application as and deploy it to Equinox, you basically have to create a WAR with the bridge servlet as the only entry in web.xml and the only JAR in WEB-INF/lib is servletbridge.jar. Everything else is packaged under /WEB-INF/eclipse. Here's what that looks like:

WEB-INF 
    web.xml  
    lib/servletbridge.jar 
    eclipse 
        launch.ini 
        configuration/config.ini 
        features 
        plugins 
            <your-bundles>

Adrian did a demo showing a simple "Hello World" example deployed into an OSGi container. The output from the demo in the browser wasn't much. However, he showed how you could use an OSGi Console to interact (start/stop/refresh) all the different bundles. The fact that you can do this all at runtime has some pretty interesting implications.

My Thoughts
The demo makes Servlet/EJB containers look somewhat primitive. Will OSGi containers be the next generation of application servers? It seems somewhat likely, but as Adrian said, most of this stuff is on the bleeding edge (or even "razors edge" to quote Adrian). My guess is OSGi will be a very interesting space in 2007. However, I don't see myself deploying WARs to OSGi containers anytime soon. Maybe in 2008.

Can OSGi power a web application's plugin architecture? It doesn't seem like it. The web application would have to be deployed in an OSGi container to make this possible. Either that, or the web application would have to be an OSGi container itself.

[TSE] The Holy Grails of Web Frameworks with Guillaume LaForge

2006-12-09T12:31:25-07:00

I only made it to the 2nd half of this talk because I got stuck in traffic on I-95.

Under the hood, Grails uses Spring MVC. It has support for "flash scope" between requests.

I find it funny that flash scope is so popular these days, we've had this in AppFuse for four years. However, web frameworks didn't add native support for it until it had a name (provided by Rails). To be fair to Struts Classic, they had support for it before Rails was even invented.

Rather than JSPs, Grails uses Grails Server Pages, which look much like JSPs. Grails uses SiteMesh by default and allows you to easily change the layout used with a meta tag.

<meta name="layout" content="main"/>

Most of the dynamic attributes in a GSP are rendered using the various "g" tags. There's dynamic taglibs for logic (if, else, elseif), iterating, linking, ajax (remoteFunction, remoteLink, formRemote, submitToRemote), form (select, currencySelect, localeSelect, datePicker, checkBox), rendering (render*, layout*, paginate), validation (eachError, hasError, message) and UI (i.e. richtexteditor).

Grails also allows you to write your own taglibs with a much simpler syntax. For example:


class MyTagLib { 


    def isAdmin= { attrs, body-> 

        def user = attrs["user"] 

        if (user!= null && checkUserPrivs(user)) 


            body() 

    } 

}

Then you can use it in your GSP:

<g:isAdmin user="${myUser}"> 
    some restricted content 
</g:isAdmin>

Is Grails Enterprise Ready?
Yes, because it uses existing Java libraries. Since you can create a WAR from your Grails project (using "grails war"), you can "protect your investment" and deploy it to your expensive app server. Although Grails is based on Groovy, it's a very easy language to learn for Java developers. In fact, there's hardly anything to learn. Most of the learning involves learning simpler ways of doing things. You can also use GORM (and its dynamic finder methods) outside of Grails. You can re-use the EJB3 annotated mapped beans and even the taglibs in your JSPs - it's all Java bytecode in the end.

More to come! On the roadmap: DSL for scripting Spring, plugins, flow/conversation concept with Spring Web Flow, JPA support, Web Services convention, customized URL mapping, JSP custom taglib support and finer-grained DB schema control. "It's up to you to vote for and prioritize new features!"

Books: Groovy in Action will be printing next week and The Definitive Guide to Grails will be out early next year. The existing documentation for Grails is 224 pages - so there's lots of information freely available as well.

My Thoughts
I didn't know that Grails allows you to generate Canoo WebTest tests for your UI. I agree that WebTest is an excellent way to test UIs, but I think Selenium is better. The major reason they're using WebTest seems to be because one of the WebTest guys happens to be a Groovy committer. I plan on learning (and hopefully using) Groovy and Grails in 2007.

The reasons for the Groovy and Grails projects seem kinda strange. I created AppFuse to solve my needs when starting new Java projects. Rails was extracted from Basecamp because it solved problems for DHH. Grails seems to be invented as a Rails clone. It doesn't actually solve a problem - except that Groovy needs a "killer app" like Ruby has with Rails.

Regardless of Grails' reason for living, I still plan on adding it to my toolbox as it seems like a very nice way to develop web applications. Maybe that's its reason for living? My question is this: do its developers use it to write real-world applications, or is this another project (like Craig McClanahan and Struts) where the lead guys don't actually write real-world applications?

[TSE] Good ol' I-95

2006-12-09T11:44:34-07:00

I left West Palm Beach at 11:30 this morning, seemingly plenty of time in order to make the afternoon sessions at The Spring Experience. Unfortunately, a truck caught on fire on the side of the freeway and stopped traffic for a good hour. So it took me two hours to get here. Damn. I just walked into Guillaume LaForge's talk on Grails, hopefully I can learn something in the last 30 minutes of his presentation.

Update: It looks like I missed a good talk on testing this morning.

[TSE] Designing Stateful Web Application Control Flow with Erwin Vervaet

2006-12-08T15:47:49-07:00

Spring Web Flow (SWF) does not fit into an application or a feature where free-flow navigation is required. It works best where you need to lock down and control navigation. SWF is not designed to be a web framework, but rather to solve the specific problem of navigation and state management between many pages.

Erwin is a Senior consultant at Ervacon and has extensive experience using Java SE and Java EE. He is the inventor and co-lead of the Spring Web Flow project.

Core Functionality

Navigation is controlled by a flow (complete navigational control)
Automatic state management (scoping, cleanup)
A flow is a reusable application module (fully encapsulated: input/output contract, black box)

Spring Web Flow provides Navigational Control. A flow definition controls the entire conversation. The flow is the controller and drives all navigation. When user input is required, the flow pauses and a view is rendered. Clients signal events and are unaware of overall navigation rules. The flow reacts to user events and decides what to do next. A flow is a simple Finite State Machine (a set of states with transitions b/w them). SWF is not a general purpose workflow engine. It's simplified for use with web conversations and lacks features like split and join.

SWF provides state management with web continuations. What is a web continuation you ask?

A continuation is a saved snapshot of the executable state of a program at any given point in time. It is possible to restore this state and restart the execution of the program from that point onward.

The flow execution repository takes a snapshot of flow execution for each request. In a sense, the flow execution becomes a continuation.

Spring Web Flow is a very advanced state management mechanism. It has fully automatic state management with scopes (converstation, flow, flash, request), cleanup, compatible with browser buttons (back, forward, refresh, new window). Finally, flows are observable using FlowExecutionListener.

To link to services (or call service-level beans), you can simply use your normal bean ids. You can subclass SWF's Action and inject your services into it. However, in most cases, you can simply use SWF's FormAction class. SWF can bind to any POJO method. For example:

<bean-action bean="phonebook" method="search"> 
    <method-arguments> 
        <argument expression="flowScope.searchCriteria"/> 
    </method-arguments> 
    <method-result name="results"/> 
</bean-action>

This might bind to the following interface, which is wired up as the "phonebook" bean.


public interface Phonebook { 


    public List<Person> search(SearchCriteria criteria); 

    public Person getPerson(Long id); 


    public Person getPerson(String userId); 

}

To deploy a flow definition, you first have to define your flows in a flow registry.

<flow:registry id="flowRegistry"> 
    <flow:location path="/WEB-INF/flows/**-flow.xml"/> 
</flow:registry>

A flow id is assigned by convention. For example, /WEB-INF/flows/search-flow.xml becomes "search-flow".

To execute a flow, you need to define a flow executor that manages flow on behalf of the client. It loads flow definitions (from flowRegistry), drives flow executions (launch, resume, refresh) and saves/loads flow execution b/w requests (execution repository and state management).

<flow:executor id="flowExecutor" registry-ref="flowRegistry" 
    repository-type="continuation"/>

Finally, you'll need to configure a "Flow Controller". This is specific to the web framework you're using. Below is an example for Spring MVC:

<bean name="/phonebook.htm" class="org.springframework.webflow.executor.mvc.FlowController"> 
    <property name="flowExecutor" ref="flowExecutor"/> 
</bean>

SWF exposes some variables to the view model, namely "flowExecutionContext" and "flowExecutionKey". To participate in a flow execution, you have to submit _flowExecutionKey and _eventId parameters in every request. For a form, these can be hidden fields:

<form:form action="phonebook.htm" commandName="searchCriteria" method="post"> 
    <input type="hidden" name="_flowExecutionKey" value="${flowExecutionKey}"> 
    <input type="submit" class="button" name="_eventId_search" value="Search"> 
    ... 
</form:form>

For links, you'll need to include these parameters as well:

<a href="phonebook.htm?_flowExecutionKey=${flowExecutionKey}&amp;_eventId=select&amp;id=${colleague.id}"> 
${colleague.firstName} ${colleague.lastName}</a>

NOTE: This morning, I asked Rob Harrop if the _flowExecutionKey hidden field will ever be auto-generated by the <form:form> tag. His response was that they are doing something to make this more automatic, but it may not happen in the context of the <form:form> tag.

Best Practices

By default, SWF does redirect after POST. To change it, you can configure the flowExecutor bean a bit differently.

<flow:executor id="flowExecutor" registry-ref="flowRegistry" repository-type="continuation"> 
    <flow:execution-attributes> 
        <flow:alwaysRedirectOnPause value="false"/> 
    </flow:execution-attributes> 
</flow:executor>

You can also explicitly use the "redirect:" prefix in the view name. In other words, the best practice of "Redirect after POST" has been built-in for you.

SWF comes with 4 repository (storage) implementations:

simple: single flow execution per converstation (flowExecutionKey changes on every request), low resource usage, no browser button support. Use when you can lock down the browser and resources (memory) are scarce. By default, displays a nice stack trace (PermissionDeniedFlowExecutionAccessException) when you click back. Use case: your company has removed the back and forward buttons from end-user's customized browsers.
singleKey: same as simple repository, but keeps same flowExecutionKey over the lifecycle of the flow. Tricks the browser into thinking it keeps refreshing the same exact page - there is no browser history. They do this by using the exact same URL for every page. The nice thing about using this repository is it really does disable the back and forward buttons. Use case: low memory available and want to block back/forward button usage.
continuation: the default implementation if you don't specify the "repository-type" attribute on your flowExecutor. Allows free browsing in a controlled way. The downside is high memory usage because many snapshots are taken. Snapshots contain all the data associated with the conversation; more than just request parameters. Use when you have enough resources available and browser buttons need to be supported. The flowExecutionKey is different for each and every request in order to record the unique id of the snapshot.
client: flow execution stored in the flowExecutionKey and on the client. It's nice because there's low resource usage on the server. However, it only supports POST (b/c of GET URL length limits). It also requires more bandwidth, has security concerns and has no support for double submit out-of-the-box.

Best practice? Use the correct repository for your situation! Somebody asked if SWF provides the information to build a "breadcrumbs" type of menu. Erwin says "yes", but there's no way to easily access that information (i.e. with JSP tags). Another audience member asks if it's possible to invalid snapshots? Erwin says "no", but it is possible to configure the maximum number of snapshots to store. They are considering adding support for invalidating certain snapshots after you pass a certain state in the flow.

Even though I knew a lot about SWF going into this talk, I was very impressed with Erwin's presentation. He did an excellent job at doing live demos that showed the different features of SWF. Even better, he did them with SWF's "phonebook" application, so it should be possible to reproduce many of his demos. At the end of his presentation, Erwin listed a number of resources for Spring Web Flow:

I recently updated Spring Live's Chapter 13 for SWF 1.0, but Erwin and Keith's Expert Spring MVC and Web Flow (by Seth Ladd, Darren Davison, Steven Devijver and Colin Yates) is much better than my 10-page example. My updated chapter is currently in tech edit, so you may have to wait another couple weeks before it's in a released version.

[TSE] Using Dynamic Languages with Spring with Rod Johnson and Guillaume LaForge

2006-12-08T13:27:43-07:00

Spring 2.0 has dynamic language support. To make it work, you do need a Java interface as a contract between callers and dynamic beans. There's no special requirements on the interface. It's a "POJI" and doesn't have to extend or implement anything. For example:



public interface Messenger {

    String getMessage();

}

There's 3 ways of configuring Groovy beans:

GroovyScriptFactory <bean> element defining source location and properties
<lang:groovy> element from a <lang> namespace
POBD (Plain old <bean> definition) - this is unique for Groovy since it can be compiled into Java bytecode

Any of these three options can take injected properties.

To configure a dynamic language component using the GroovyScriptFactory, you need to do the following:

You need a ScriptFactoryPostProcessor to ensure that dynamic bean definitions are processed at startup
Create bean definitions using generic GroovyScriptFactory or other language-specific factory

<bean class="org.sfw.scripting.support.ScriptFactoryPostProcessor"/> 

<bean id="messenger" class="org.sfw.scripting.groovy.GroovyScriptFactory"> 
    <constructor-argvalue="classpath:org/sfw/scripting/groovy/Messenger.groovy"/> 
    <property name="message" value="Hello World"/> 
</bean>

The 2nd way to configure Spring to use a bean from a dynamic language is to use the <lang> namespace. A namespace handler is appropriate when you need to create multiple beans to configure a single feature. Another indication that a namespace is appropriate is when your bean definitions follow a certain pattern (i.e. GroovyScriptFactory always requires a constructor argument). Using the <lang> namespace allows the ScriptFactoryPostProcessor to be registered automatically.

<lang:groovy id="refreshableMessenger" 
    script-source="classpath:org/fw/scripting/groovy/Messenger.groovy"> 
    <lang:property name="message" value="Hello World!"/> 
</lang:groovy>

Using the namespace, it's also possible to tell Spring to refresh the bean definition periodically. With this, callers can hold a reference to the bean, which is thread-safe. It's possible to do this because Spring uses its AOP and proxy system to dynamically replace the "target" object. Refreshing is made possibly by using the "refresh-check-delay" attribute.

<lang:groovy id="refreshableMessenger" 
    refresh-check-delay="5"
    script-source="classpath:org/sfw/scripting/groovy/Messenger.groovy"> 
    <lang:propertyname="message" value="Hello World!"/> 
</lang:groovy>

Another feature with the <lang> namespace is using "inline" scripts. Rod says this can be useful for writing stubs, but he generally doesn't recommend using it. You don't want to program in XML, do you?

The last option, which is only possible with Groovy, is to use POBD to define Groovy components. This is only possible with Groovy, because it produces Java classes.

Why would you want to use Groovy?

May be more concise and simpler than Java to implement a component. Groovy has closures!
When the interface doesn?t change but the implementation might, for example with MVC Controllers. This can allow you to rapidly develop web applications.
To use DSL and other capabilities that offer something Java does not.

The capabilities of developing a DSL in Java is pretty limited. Java 5 and annotations allow you to develop a DSL-ish system, but nothing like what a dynamic language can do.

It's not Rod's job to sell us Groovy, so he's now turning it over to Guillaume. Guillaume is the Groovy Project Manager at Codehause and the JSR-241 Spec Lead. I think it's interesting that James Strachan invented Groovy and doesn't seem to be involved with Grails. Instead, he's helping to create Able. I digress...

To get started playing and working with Groovy is pretty simple. Download, install, add GROOVY_HOME to your environment variables and GROOVY_HOME/bin to your path. I'm downloading it now. The 1.0-RC1 release is around 13 MB.

Groovy is a dynamic and agile scripting language for the JVM. It's an OSS project hosted by Codehaus. It was inspired by Ruby, Python and Smalltalk. It generates bytecode for the JVM so it natively integrates with Java libraries. Groovy differentiates itself with its GDK and MOP. The GDK (Groovy Development Kit) has additional libraries to simplify complex APIs and MOP (Meta Object Protocol) has advanced meta-programming features.

Groovy Syntax and Language Constructs:

Expressive Java-like syntax (flat learning curve)
Same OO model as Java
Properties support
Supports ?duck typing?, and strong typing
Native syntax constructs for Lists, Maps, regex
Permits operator overloading
GStrings: interpolated strings
Closures: reusable and assignable code blocks

Sample class and script:


class Speaker { 

    String name 

    def age 

    String toString() { 


        "My name is $name and I'm $age" 

    } 

}



def speakers = [


    new Speaker(name:"RodJohnson", age:36), 

    new Speaker(name:"GuillaumeLaforge", age:29) 


]



def upper = { it.toString().toUpperCase() } 



speakers.findAll{ name -> name =~ /.*od.*/ } 


        .collect(upper).each{ println it }

At this point, I pretty much tuned out. The slides I have in front of me match most of what Guillaume was saying. In other words, I was able to read the slides and know what I was going to learn for the next 20 minutes. I generally blog these sessions because I've found it's a good way of capturing the information w/o having to pack around the printed slides. However, now that I have all the presentations in PDF form, I'm a little less motivated. I wonder if there's any rules against me simply uploading the PDFs to this site?

Comment from Rod: "This is the 2nd presentation I've co-presented today and the 2nd enhancement I've recognized we should add." Apparently, he received a number of suggestions from Mike Keith in their JPA talk earlier today. I'm not sure what Groovy-support enhancement was suggested.

One nifty thing I did see in Guillaume's demo was a Groovy Plugin for IDEA. Not only does it provide syntax highlighting, but it seems to allow compiling and running Groovy classes as well.

My take away from this presentation? Spring 2.0 allows you to easily use a dynamic language in your application. This can allow you to externalize business rules, programmatic configuration and possibly even write your UI layer with it. With a backend that can CRUD any object (we have this in AppFuse 2.0), a front-end in a dynamic language could be one heck of a combination. Of course, I could just use Grails. I like the ideas behind Grails, but I expect it'd be hard to sell to clients - many of mine haven't even heard of Tapestry!

[TSE] Rapid Web Application Development with Rob Harrop

2006-12-08T11:42:37-07:00

There's a couple of other sessions I should probably go to, namely Juergen's talk on Transactions and Mark Fisher's Message Driven POJOs Rock! However, transactions is generally a pretty boring topic and I don't see myself developing any MDPs in the next two weeks. If you don't use your knowledge in two weeks, you generally lose it, so I'll wait to learn more about MDPs until someone pays me to. I know a fair bit already, so I don't know that there's a whole lot more to learn.

I'm attending Rob Harrop's Rapid Web Application Development Essentials talk. With any luck, I'll learn some new tips that we can use in AppFuse.

Agenda:

The recipe for rapid development is an easy compile/test cycle (eliminate deployment), an easy deployment for view testing (hot deploy, auto-detect changes) and reduce repetition (can often be fixed with convention over configuration, especially by defaulting model and view names). In addition:

Encapsulate common patterns: binding and validation, multi-page navigation, redirect after POST
Reusable tools for common tasks: site-wide formatting, layout, testing and monitoring
Plan and design for maintenance: profiling, tracing, monitoring
Aspects and JMX are the perfect solution

Basic Tool Set

Why do we need tools? To reduce the compile/deploy/test life-cycle. This is live testing, not unit testing. Many ideas also support view creation, code completion in view pages and previewing.

What can you do without tools? Test, test and test some more. Unit and integration testing should be possible out-of-container.

First thing you should is get a good IDE! Rob recommends IDEA and used it for all his demos. Make sure your IDE has the following features:

View creation support: JSP, Velocity, JSF
App server integration: Tomcat, Jetty, WebLogic, WebSphere; deploy/debug from the IDE
Good candidates: IntelliJ IDEA, Eclipse with WTP/MyEclipse or NetBeans
Webapp aware - so you can simply click "run" to view it in a browser

Jetty is your friend! It allows you to rapidly deploy, it's resilient to hot deploy, starts everything in about 2 seconds and integrates with everything.

Maven is your other friend. It allows you to kick-start a web project very easily. It also has Jetty integration that allows you to hot deploy. The Jetty plugin also detects changes and redeploys automatically. It even creates project files for IDEA and Eclipse.

Caveats with Maven: Its online repositories are full of junk: many different versions of POMs. To solve this, use mvnrepository.com to browse and find the right JARs. Also, lots of things are missing from the central repo: Trying finding a full Jamon distro.

Solution: Get your own in-house repo (easy to manage, overcome missing dependency woes).

Now Rob is doing a Maven QuickStart demo. He's using the maven-archetype-webapp to create a web application with Maven. He then added the Jetty Plugin and showed how it's easy to get started. For those of you that aren't aware, there's also a Tomcat Maven Plugin that allows you to use Tomcat instead of Jetty. There's also a debate ensuing on whether Cargo should have this functionality or whether these plugins are better. I'm currently leaning towards the plugins since their easier to setup and configure (and they work too!).

Accelerating Spring MVC Development

Important existing features: testing outside the container and controller infrastructure
Important new features in Spring 2.0: code by convention, JSP form tags, quick prototype with dynamic languages

Spring has many different Controller options: Controller/AbstractController, MultiActionController and SimpleFormController/AbstractWizardFormController. All of these can be tested outside the container. Unfortunately, SFC and AWFC are not so simple to test. Rob recommends using with Controller and MultiActionController and using Web Flow for most other things.

The fact that Rob doesn't recommend using SimpleFormController is quite interesting. I've never liked that I have to use Controllers for displaying data and SimpleFormController for forms, and apparently the Spring guys don't either. Rob says that if you're new to Spring MVC, it's better to skip learning/using SFC and use Web Flow instead.

Testing outside of the container is one of the best things in Spring MVC (I agree). Spring Mock provides the necessary infrastructure with MockHttpServletRequest and MockHttpServletResponse. The most value can be gained from transaction integration in tests (using my favorite class - AbstractTransactionalDataSourceSpringContextTests). Mock test are useful to test error conditions and hard-to-reproduce conditions, but integration tests are better in the web tier.

Code by convention: Spring 2.0 introduces many Code by Convention features: view names, model parameter names, URL mappings. This reduces duplication and increases uniformity.

JSP form tags: Creating forms in Spring 1.* was painful. The <spring:bind> tags were verbose and unclear. Spring 2.0 introduces new <form:*/> tags. These tags are much easier to read and write. They clearly express the intent and handle all the common cases such as binding and error handling.

Dynamic Languages: Spring 2.0 introduces support for beans written in other languages: JRuby, Groovy and BeanShell. These are just plain beans: inject into them, advise them and expose them via JMX. Change detection is built in (see live changes). Difficult integration is taken care of. For example, how do you call methods in a dynamic object from Java.

Now Rob is doing a demo of developing with Spring MVC and using CoC.

One of the new things in MultiActionController is you don't have to return ModelAndView - you can return Map or have void methods as well.

The ControllerClassNameHandlerMapping is a new class in Spring 2.0 that figures out the URLs for you based on Controller names. If you're using a MultiActionController, the URL is the first part of the name and anything after it, for example: /catalog/*. By configuring an additional property, you can make * map to method names. For regular Controllers, the mapping doesn't have the trailing slash (i.e. /catalog.html).

Another new class in Spring 2.0 is ModelMap. This class figures out your model names based on the simple class name. Single objects are simply lowercased, whereas collections of objects are available as objectnameList (i.e. a Set of User objects will be userList).

A method in AbstractTransactionalDataSourceSpringContexts that's quite useful is countRowsInTable(tableName).

To debug from your IDE is generally pretty easy. If you setup your IDE to debug a "Remote Application", it'll tell you the parameters you need to start that application with. For example, to debug the Maven Jetty Plugin in IDEA, create a new Remote Application in IDEA (Run -> Edit Configurations -> Add -> Remote) and then copy the command line arguments (listed below as well) into your MAVEN_OPTS environment variable.

-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005

After doing this, you should be able to restart Jetty and set breakpoints in your IDE.

Now Rob is showing us a JRuby example, where he's writing a Controller in JRuby and changing it/refreshing it in his browser. The code looks fairly simple and the configuration (in his *-servlet.xml file) looks like the following:

<lang:jruby id="stocklistController" 
    script-source="WEB-INF/script/StocklistController.rb"
    script-interfaces="org.springframework.web.servlet.mvc.Controller"
    ... />

Unfortunately, I didn't get a chance to write down the entire bean definition, but hopefully you get the idea.

Summary: Rapid Development with Spring MVC

Use a project template: Build your own (simply create a ZIP file) or use Maven 2 archetypes.
Make sure you can deploy quickly and frequently: Jetty is the way to go here.
Build deployment into your build script: slapped wrists for using Tomcat Manager!
Adhere to a code/test cycle: create mock tests to test error conditions. Use integration tests to verify end-to-end functionality.
Code by Convention reduces repetition and increases uniformity.
Dynamic languages: rapid prototyping, take advantage of additional language features
JSP form tags: Largely replace <spring:bind/>

Exploiting Web Flow

What is Web Flow?

A component for defining and managing interactions with the user. Typically long-running interactions. Workflow for the web.

Integration with traditional MVC frameworks: Spring MVC and Struts. SWF was originally designed to work with Struts.

Why bother using Web Flow?

Productivity! It removes plumbing from your code: state management, flow management, allowed actions/security, isolation and concurrency. By removing this plumbing, it allows you to focus on the business code.

Key Components of SWF:

Flow Definition: A definition of a process in the application. For example: checkout, register and CRUD.
State: A single state in the execution of a flow.
View State: A pause state that displays a view to the user and typically prompts for input.
Action state: A stat that executes on or more actions and then moves to another state (where the logic happens).
Decision state: a routing state, evaluates or or more expressions (against data in the various scopes) and routes to a given state.
Action: The logic inside the Action state that gets executed.
Event: The user signaled event (submit, cancel, process, etc.).
Transaction: a movement from one state to another in response to some event.

The three configuration elements of Spring Web Flow are: Flow Executor, Flow Repository and Flow Registry.

One of Robs favorite things about Web Flow is the Testing support. SWF provides full testing support with AbstractXmlFlowExecutionTests. This class provides an API for you to start and stop the flow. It also allows you to override the registerMockServices() method to register mock implementations of your services. You can also override createFlowServiceLocator() to do integration testing. There are also a number of useful testing-related methods available on AbstractXmlFlowExecutionTests to verify things are happening correctly within your flow execution. The MockParameterMap makes it easy to set parameters to pass into the flow.

Cool and useful stuff

SiteMesh: Apply site-wide formatting, use it in conjunction with a CSS Framework (Rob is using the same one that AppFuse does - Mike Stenhouse's CSS Framework).
AspectJ: Great for adding in filtering, monitoring and profiling.
Jamon: Great in conjunction with AspectJ.
JMX: Adds in management functionality.

If you liked the ideas that Rob presented in this talk, don't miss my talk on Saturday night. AppFuse 2.0 will have most of these components and ideas built-in by default.

This was an excellent talk by Rob. I certainly enjoyed myself, which is likely obvious since I wrote almost everything down. ;-)

[TSE] Domain Driven Design with Eric Evans

2006-12-08T08:37:28-07:00

I've arrived at The Spring Experience, 45 minutes late for the first talk. I tried to get up early, but decided I'd rather get 6 hours of sleep instead of 4. I'm now sitting in Eric Evans' Introduction to Domain-Driven Design talk and the room is packed. I've never seen Eric talk before, but he seems a bit unprepared. His PowerPoint presentation is not in full-screen mode, so you can see where he hasn't finished slides and such. He's also very soft-spoken and seems to have an interesting way of convincing the audience his ideas are good. I feel like I'm sitting in some sort of NPR Seminar.

This hotel is pretty damn nice, as well as huge. It reminds me of some sort of Vegas hotel, with the grand entrance and all. The wireless network doesn't seem to work, but it's probably a problem with the network and my MacBook Pro. Luckily, connecting via Bluetooth through my phone seems to work.

"Not all of a large system will be well designed". Any sort of design methodology that assumes that will be doomed. Sometimes this leads to failure, but most often it leads to mediocrity. The best thing to do is use pragmatic, strategic design. You have to decide where the utility of your model is extremely high. Then define boundaries around that model so you can build anti-corruption layers. When doing modeling, you shouldn't look for the model, but simply a model.

Meaning is specific to a context.
Usefulness is specific to some set of scenarios.
Practicality is determined by enabling technology.

Technology should enable rich and precise model expressions.

Modeling does not suggest an upfront design phase. Models are distilled knowledge about the domain and tailored to the situation you're in. At the beginning of a project, you don't have that knowledge. An Upfront Design Phase is an excellent way to design your system on the highest level of ignorance your team will have.

Technology should enable evolutionary change of the model.

Spring is getting more minimalist as it progresses. The amount of XML that J2EE makes you use to get something done is ridiculous - Spring fixes much of that and makes it much more manageable.

We need tools that let us express models without getting bogged down in technical detail. If you use a modeling approach, you've chosen to use a sophisticated approach and tools won't dumb it down for folks that aren't as skilled to develop. You'll still need skilled developers to develop this type of system and make it successful.

We need tools to help raise the level of abstraction of programming. However, we don't need Visual Programming or UML Extensions. Language is our fundamental abstraction tool. Language starts with talking ... and coding.

Eric's Favorite Modeling Tools (currently available)

Whiteboard (with a digital camera for persistence)
IDE
Unit tests
Our Mouths and Ears

The ultimate technology would be one that got out of your way so much that you wouldn't even be aware of it.

Talks on Domain Driven Design today (and throughout the weekend) can be found on the session schedule. From the talks in this track, Ben Alex's talk on Sunday sounds pretty interesting. From this talk's description:

In this presentation we'll study an internal web application developed by a major Australian corporation. The application uses a "real object oriented", or ROO, architecture. That means we swapped out those anemic domain objects, fat services, and those repetitive DAOs for rich domain objects that utilize transparent persistence and encapsulate business rules.

Back in Denver

2006-11-28T01:41:57-07:00

Raible Road Trip #11 was an excellent vacation. Our plan to drive through the night worked out splendidly. Not only did I make it to 7:30 a.m. (with the help of a bit of Red Bull), but I got to jam to my favorite tunes all night long. We left at 11 p.m. and I handed over the reigns to Julie just outside of Billings. She drove for the next 3 hours, and I took over again for the final 3. Total time: 14 hours.

We arrived at the cabin at 1:00 p.m. on Wednesday. Actually, I should say we got stuck at the cabin at 1:00 because we made it all the way up the "bumpy road", but didn't make the last hill. 40 minutes later and at 40 miles an hour, I made it up the last hill. The next 3 days at the cabin were great. We took Cookie the Dog and she loved it as much as the kids did. The drive home over the last 2 days wasn't nearly as pleasant as the drive there, but listening to "Little Einstein's" on the DVD player is never as much fun as listening to your favorite tunes.

Click on the images below to view pictures from The Cabin.

The next couple weeks will likely be hectic. This week I'll be writing AppFuse 2.0 documentation. Next week I'll be delivering a Spring + Hibernate class in Boise, Idaho with Country Bry and Scott from Virtuas. Then I'll be flying to The Spring Experience on Thursday for a weekend in paradise. Better yet, I'll be spending the following week in Florida on vacation.

Livin' it up in NYC

2006-05-05T14:34:36-06:00

I'll admit, this week has been exhausting. There's nothing like doing consulting 9-6 everyday for a client - especially when you're presenting or talking 90% of the time. My final presentation I delivered to the client was 600 slides. Yikes!

Even while this week was tough, I did manage to have a good time. I have a couple college buddies that live here, so they're always fun to hang out with. Wednesday night, we all met up at one guy's house for dinner and reminisced about the good ol' days. Last night, I hung out with my relatives from Beacon.

After finishing up with my client, I met my Aunt Mary in the lobby of the New Yorker Hotel. We walked outside, and when I started hailing a cab she said "What are you doing? I got a limo!" "WTF?!", I said out loud. I turned around to see Mary had brought my cousins along and they'd rented a limo for the night. Needless to say, we had a great time riding around, eating a fancy dinner and ended the night with champagne and cheesecake in Little Italy. It was truly awesome and definitely made my whole week.

Now I'm at the airport bar in Laguardia, sluggin' down a few before I head back to Denver. The next couple weeks are guaranteed to be hectic - I leave on Wednesday for the Ajax Experience, followed by JavaOne the week after. While traveling to clients isn't the most glamorous job in the world, getting paid to learn about Ajax/Java for two weeks in San Fransisco isn't a bad gig.