I only managed to take in a few talks here and there, but the ones I did catch sure had some first-rate REST preaching. To the extent that there’s a surprising trend at this year’s J1, I’d say it’s REST-is-in, “Big Web Services” (see below) are out.
Project Zero: Groovy + PHP + Java + REST · I went and caught Rob Nicholson’s The Duke and the Elephant: PHP Meets Java Technology—the Best of Both Worlds. He’s one of the IBM “Project Zero” guys. I’ve been unimpressed by the project’s “We can’t be open-source because we’re commercial” positioning, but it was an interesting talk.
Rob Nicholson.
This part of Zero is called “Project sMash”. You can write logic in Java or Groovy or PHP—their own PHP-on-the-JVM implementation. I couldn’t quite figure out where you’d use Groovy and where PHP, and I was puzzled that, unlike other modern Web frameworks, this thing doesn’t seem to come with a built-in unit-testing framework.
At runtime, each application crams all this PHP and Groovy and Java and Web serving and so on into a single JVM, started via a Portlet. Also, It’s got a multi-level shared scratch data space called “Global Content” that reminded me of Apache memory-management pools. Which was, I thought, the most technically interesting part of the puzzle.
There’s a built-into-the-browser IDE because that’s supposed to reduce time-to-market, but there’s also an Eclipse plug-in, which is what Project Zero developers actually use.
The big deal though, was the focus on RESTful Web Services. You can annotate your PHP code somewhat like the JSR-311 people are doing with Java to get the resources and URIs and code connections set up.
It’s even got a REST-to-SOAP gateway so that you can call out to things like SugarCRM that are SOAPy.
JSR 311 · I went to a presentation by Paul Sandoz and Marc Hadley about the work they’re doing on JSR311 and the Jersey implementation. I’ve been friendly to this project for a while; it looks like a nice clean way to help Java developers do REST properly.
The demo was nice and slick; I predict a bright future for this thing.
SOA @ Overstock · But the most interesting Web-Service-y preso was It’s All About the SOA: RESTful Service-Oriented Architecture at Overstock.com by Sean Landis and Ian Robertson; Overstock.com is a very high-volume online merchant. They weren’t talking theory, they were talking about how they’d actually converted their V1 C implementation to a modern Java version, all running along REST lines.
This and several other presentations opened with a basic introduction to REST concepts; my suspicion is that, given all these well-attended sessions, never before have so many developers received the core REST pitch in such a short time. Several people plugged Leonard Richardson and Sam Ruby’s RESTful Web Services as The Place To Start, but the JavaOne bookstore didn’t have it.
This presentation included this slide discussing their decision to go with REST rather than WS-*, which they called “Big Web Services”; I kind of like that name. I think it speaks for itself, but there was one nice sound-bite about REST that I’d like to pass on: “Full control without much complexity.”
The Overstock system was based on the Restlet API, which, when I looked at it last (quite a while ago) I’d found kind of heavyweight and complicated, but I gather it’s evolved. The code samples looked clean and straightforward, and I was particularly impressed by how they did load sharing by dispatching step-by-step along the URI path to different machines.
Their lessons-learned slide was really excellent, but I didn’t capture it and can’t find it online. The take-away that’s obvious once you think of it is that since you can’t possibly deploy all the components of a distributed system instantly in parallel, version N of each protocol has to interoperate with version N-1; that way you can roll things out without breaking things.
They didn’t claim that REST made building this kind of system easy; just that it was the best alternative for them. And I enjoyed their attempt to snatch the “SOA” acronym out of the WS-* swamp.
Conclusions · Down in the big Java One trade-show, there was a “SOA village”, where all the vendors of SOAP/WSDL/WS-* technology were talking about Governance and Reliability and Integration and so on. “Village” is the word all right; a village left behind by history. It was kind of sad, actually. REST may not have won, but SOA-as-in-WSDL is in the middle of losing.
My second take-away, watching the presentations’ sample code: there was way too much of it. When you’ve been living in Ruby-land for a while, Java’s verbosity starts to hurt your eyes. In particular those constructors spilling across two or three lines, festooned with hideously-nested generics cruft; that’s just wrong.
Having said that, I’m really glad that Java is getting all this REST machinery, and that the community is developing some best practices, because it will make Java a much better citizen in an increasingly-RESTful world.
Comment feed for ongoing:
From: Chris (May 08 2008, at 11:01)
Thanks for posting this info, real interested stuff, esp. us guys who couldn't make it to J1 this year.
Thanks.
[link]
From: razmaspaz (May 08 2008, at 11:28)
Tim,
I'm living on the fringe of REST, and I have been working happily with SOAP services for quite a while now. I see you preaching against SOAP all the time, and don't really have the REST experience to make my own informed decision. Working in an environment where services are taking off at a frightening pace, I'm a little curious about your governance comments. I don't see why REST makes governance, reliability, and integration into non issues. I know WS-* is a mess, but how does a RESTful world handle 500 services in an organization any better than a WS-* one?
[link]
From: Jonathan Eunice (May 08 2008, at 12:25)
The Overstock.com session at J1 had an also-excellent SOAPy counterpart, presented by Discount Tire Corp. The Tao of SOA clearly contains both a Yin and a Yang side.
[link]
From: Sean (May 08 2008, at 20:03)
razmaspaz,
I don't think anyone said REST makes governance, reliability, and integration into non issues. I think - although I can't speak for Tim - the point is that the WS-* people were talking the same old story; a story that isn't very compelling.
-> Using web services for integration? What a concept!
-> Reliability has little to do with web services.
-> Governance is overhyped. There's a kernel of usefulness there but much of what the Marketects are selling is unnecessary in most contexts.
[link]
From: Gunnar (May 09 2008, at 11:52)
I liked how they compared the security models. Oh wait, they didn't.
[link]
From: Sean (May 09 2008, at 21:10)
We didn't compare security models because it was not an important criteria for us - our SOA is a backend system in a tight security domain.
FWIW - security for REST is the same as on the web. And, for that matter, we would use the same approach we use on our web site.
We made a point in the presentation of being able to leverage what we know.
[link]
From: Rob Nicholson (May 19 2008, at 02:17)
To clarify where you'd use Groovy versus PHP in ProjectZero/WebSphere sMash, I think its not so much about _where_ as _who_. What we are seeing is that people who come from a Java background prefer to use Groovy as the type system and syntax are familiar to them. People coming from the large and growing PHP community prefer to use PHP. We are also seeing people re-using existing PHP code. Our general goal is to enable the use of either PHP or Groovy in most places so that folks can choose which language to use based on their background.
One other clarification. We do not use portlets. Each sMash application is a completely stand alone Java application which does not require a container. It requires only J2SE.
[link]