Crawl Before You Walk
I've been working for the past 18 months in the "emerging web technologies" group at IBM. When I first joined, I was struck by a certain difference in attitude compared to my previous experiences at Lotus. "Eh?", I'd almost hear my colleagues say silently whenever I'd start discussing the merits of any technology. When they responded, there'd be a quite jaundiced sound in their voices. You'd notice the slightly arched eyebrow and perhaps a tightening of the mouth. It wasn't quite incredulity but it was fairly close to wariness. I speculated that this tendency was born of years evaluating countless Next Big Things and was simply the posture of experts and futurologists: "What are you selling this time? Tell me something new...". They've seen standards come and go and the various fashions that sweep the technology world. The group is a little guerrilla outpost of pragmatism, if you will, within Big Blue.
I am fairly cynical about buzzwords and the mechanics of technology adoption, but even my experiences of the Lotus side of things hadn't made me that skeptical. In any case I mention this because I was recently merrily surfing away and came upon the following bullet item in a laundry list of proposed features for Java Server Faces (JSF) 2.0.
Allow for bookmarkable JSF pages. More broadly, if HTTP GET can be used, it should be used.Quite simply I caught myself saying "Eh? Eh!". My normally sedate eyebrows even arched violently. I couldn't help it.
I haven't closely followed the technology known as JSF, but I think if you wanted to quickly evaluate its prospects as an 'emerging web technology', you could do well to simply dwell on what I've highlighted. Its history, its rate of adoption, its maturity and perhaps even its future prospects are fully encapsulated in that most remarkable passage.
It is striking that it is only in its fifth year of existence that a framework for building web applications is considering allowing bookmarking and might even use the HTTP GET method where applicable.
How can one possibly develop successfully for the web without identifying important resources? That is the first plank of the REST elevator pitch. If you can't bookmark, if you can't cache, if you are invisible to intermediaries, you are willfully ignoring the web.
Technology toli readers might remember an intervention and case study on internalizing the REST style that focused on much the same aspect in the case of WebSphere Portal and its first 3 years of existence. The benefits that I outlined once the portal embraced the web are much the same that will accrue to JSF. Ed Burns and company seem to have staged a REST intervention on JSF. Head nods to them.
My first encounter with JSF was when it was announced at JavaOne in 2002. The name seemed funny ("faces" instead of interfaces?) but I'd seen worse. My snap judgement: yet another framework for building web interfaces, oh well, the more competition the better, we'll see how it pans out.
I note that I've only mentioned JSF once: outlining how its abstractions leaked mightily when it came to html buttons and forms. Three years ago, we had been forced to use it in our forms work because it was deemed "strategic" in the IBM Software Group. I didn't have the clout to affect the decision and, well, I worked to get something to ship to customers. Inwardly however I discounted that project's prospects of success based on my experience with the first releases of JSF. A demo that looks good will get you in the door; an application that works well will actually get deployed and used by Real People™.
In the same piece, I referenced the reaction to the release of Google Web Accelerator and the way it highlighted the large number of web frameworks that were ignoring the basic principles of the web architecture. It seems that those frameworks that were deployed on the broad web and whose flaws were publicly exposed in that episode took that lesson to heart. Their creators have begun internalizing the web style to its core. To take an obvious example, the latest releases of Ruby on Rails seem to be almost religious in the fervour for the gospel of REST.
I suspect that JSF wasn't widely deployed outside of 'enterprises' two years ago hence the outcry that many other frameworks faced to "fix your damn code" wasn't heard. It appears that the message has since been conveyed and that fateful item speaks volumes. REST it is. Sun is going full bore towards embracing the web. And about time too.
Laissez-faire Dynamics
I have described REST, the web style, as being laissez faire distributed computing.
This is a blessing in that its laissez faire approach has the virtue of encouraging participation by as many people as possible. Indeed its embodiment in HTTP might be one of the most successful cases of technology adoption we have seen.
To pursue an argument by analogy on the other hand, I'll note that markets regularly fail. There are the temptations of monopolies seeking rents and that the economics of affluence and attention apply. There are bad faith actors, and you need to create spaces for market lubricants: price discrimination, market makers, arbitrage etc. Income inequality, trickle down economics are widely seen when we fetishize all things laissez faire. Still, there is almost no market which is fully laissez faire; we have laws and regulations even in the freest of markets.
The reigning tension of the low end theory is between participation and control. REST, in favouring participation almost to a fault, enforces very minimal regulations. HTTP is abused daily and advocates of the web style would catch hernias if they dwelled on the extent of the abuse and didn't simply get on with things. You'll only see gentle prodding in my handwaving take at Arrested Development
- Identify all important resources
- Use the correct verb
- Respect browser conventions
- Layer Stripping and Radical Simplification
Most of us had to crawl before we walked, or fall off the bike a few times before we learned how to ride. I only wish that certain technologies would fail faster or at least blunt their noses earlier. Contact with a mass audience on the web seems to be essential in this respect and this presents a dilemma.
Big companies have credibility by virtue of heft and inertia when it comes to purchasing decisions - the technologies they promote get in the door almost by default. Those who sell to big companies also know that, so long as they make the right noises about the strategic direction they are going in, they will get the benefit of the doubt. I would argue that this is only true in times of affluence. When we are all minding our purses, we look more closely at these things and will use what is expedient. Contrast the spread of web native applications like wikis to vertically integrated teamrooms and content management systems. Moreover, the web radically levels the playing field. In the decade or more since the web was adopted as the preferred platform, we have witnessed an inversion of emphasis due to its vastly wider audience and scale.
I'm reminded of the words of a fellow traveller.
I suppose I'd call myself a pragmatist.Waiting 5 years before you adopt the native architecture of the web is almost inexcusable. The web won't (and didn't) wait that long. Others will route around you and their dynamism will be adopted by the marketplace. Now it's a game of catch up on that elusive thing known as mindshare and ultimately on cold cash, rueing all those missed opportunities.
I do whatever works. I strive to fail faster. It's the results that matter, and simplicity (stripping layers) is celebrated because time is precious. We don't have time to waste on complexity and buzzwords; we're already behind on inventing the future.
The perplexing challenge of the web remains: how do we encourage things to fail faster? Perhaps we should all learn to say "Eh?" more often.
Crawl Before You Walk, a Playlist
A soundtrack for this note- The Pharcyde - Passing Me By
The humourous message of this song from The Pharcyde's hugely influential debut album is that obsolescence awaits if opportunities go wanting. The chorus is wist itself: "she keeps on passing me by". - Was (Not Was) - Walk the Dinosaur
Fun soul music that made the pop charts: "everybody walk the dinosaur". - Count Basie - Sleepwalker's Serenade
It appears that the web style is exploding things at Sun and other big companies. It is only fitting that we end with a swinging track from the essence of swing, the big band at its tightest, the horns, the driving bass, not to mention the Count's percussive piano, provide the counterpoint to the ironic serenade of the sleepwalker. The album title: The Complete Atomic Basie. Eh!
File under: rest, technology, adoption, jsf, frameworks, design, architecture, web, http, forms, java, j2ee, platforms, software, rejection, pragmatism, best practices, toli
2 comments:
Hello Koranteng,
Thanks for your comments on the JSF 2.0 draft. While I'm glad to hear you think we're on the right track, I want to point out that JSF's usage of POST for all interactions with the lifecycle is in fact correct with respect to REST.
POST should be used when idempotency cannot be guaranteed. Because the standard JSF lifecycle had no way of guaranteeing idempotency, it made sense to always use POST.
In JSF2, I expect we'll have some mods to the lifecycle that will allow us to make the guarantee.
Finally, I urge you to get in touch with Mr. Stephen Kenna, IBM's rep on the JSF Expert Group. I would greatly appreciate having your JSF feedback flow through him to the JSF expert group.
Ed,
I'll be sure to give feedback, and through the right channels. I'm actually now in a job where this kind of thing is part of what I'm supposed to be doing. Previously, and sadly so, there was no incentive, and a developer's time is too limited.
I won't quibble with JSF's previous use of POST, like you suggest, given the model, it was the right thing to do. I think however that there is a further point to be made and that is about the model.
The process I've suggested is: first, identify all important resources, then figure out the correct verb.
It seems to me that this is part of the analysis that is now being done for JSF 2.0. There are undoubtedly important resources that weren't identified previously. Moreover, for some of these resources, there are likely operations that could deal with an HTTP GET (allowing bookmarking and caching to take place) or perhaps even a PUT. Of course your mileage might vary but a thorough examination of the lifecycle is warranted.
The thing however is that the analysis needs to be done. When folks approach me about REST issues, I always say start with Resource Modeling.
To paraphrase a gospel writer
"Seek ye first the resource model and his righteousness; and all these things shall be added unto you."
Post a Comment