Wednesday, April 28, 2010

Green escalators...

I'm at a conference watching empty escalators roll constantly and I'm thinking what an incredible energy waste. Ironically, the first speaker of the morning touted the "green-ness" of the Raleigh Convention Center.

My first inclination was that escalators should come with sensors that would detect an approaching person and start it rolling and continue rolling until they are detected to have left the disembarking area.

After further consideration, given that we have an obesity epidemic accompanying our energy challenges, the best thing for our energy and our health would be to just turn them off entirely...

Monday, April 26, 2010

WWW2010 WS-REST Workshop

Day 1 of WWW2010 is complete. I spent the day in the WS-REST Workshop. The day, for me, started out a bit sketchy. Sam's talk was ridiculously interesting, but only tangentially related to REST. Most of the others were solid, predictable and safe. The couple presentations that did approach the edge of our current understanding of REST were, well, bizarre and, arguably, an impedance mismatch for the style itself.

Federico's talk (no slides) was pretty interesting. He suggested the need to describe and communicate new styles that were based on REST but not exactly REST. More generally, a practical model for visualizing and understanding architecture design rationale. He had a modeling tool (i forget the name) that manages a graph of constraint, rationale, and properties (or somesuch). This is somewhat analogous to the styles->properties mapping in the dissertation itself but instead of talking about styles, talking about the constraints directly. For other reasons, I've come to talk directly about constraints instead of REST too lately. It turns out that frameworks facilitate getting REST wrong just as much as they do getting it right, so instead of talking about a squishy style, I've found it more useful to enumerate the constraints explicitly. Having a modeling approach to reason about all this would be pretty useful.

Being hosted at a conference dominated by academia, potential "research areas" seemed a key focus. Some thoughts that I had during the day...

1) It seems that we need more research on getting from style to architecture. Practically, we end up with an unreasonable delta between where the style leaves off and additional constraints of the architecture. We need a framework for defining, sharing, and reasoning about those extended constraints. This doesn't get highlighted very often primarily because the folks that talk about REST do so from the perspective of a single service rather than an
architecture group constraining a set of services across an enterprise? For example, suppose a particular architectural style gives us 6 constraints and a specific architecture has 3 additional constraints. Those 3 constraints are, typically, hidden as implementation details but they should be highlighted and reasoned about in the same way that the style itself was.

2) Someone mentioned the need for the sales pitch for REST style. In other words, if a simple RPC-style solution could be hacked together in half the time, why spend time designing media types, changing the paradigm, etc. ? Intuitively, it seems that the answer is the system properties evoked by the REST style, but maybe that doesn't resonate with managers, etc.?

3) Media type design. Someone mentioned this too, but it's clearly a theme in the RESTful world. It seems that we have collectively grokked what Roy has given us in his dissertation so far and are all collectively struggling with the variety of media type issues. When to pick one over another; when to create your own; how to create your own; json:link types missing; when to use specific vs. generic representation control data (e.g. /xml or /myformat+xml); etc.

4) Link qualifications. Link relations are clearly the way to assert the semantics of the relationship between the "current" resource and some "target" resource. I think we need some clear way to qualify the "target" resource independent of it's relation to the current. Perhaps there isn't a particularly important link relation but you want to assert some link selection criteria anyway.

5) Transactions, of course, got token mention. Mike(i think) mentioned them as the "third rail" of REST:) I dunno, I don't do services on the wild internet so maybe it's a concern, but I got a gut feeling that we've got some problem-solution force-fit going on here. I see the same thing with messaging too - I haven't seen a lot of valid needs for a composite REST/Publish-Subscribe Style. I like REST. A lot. But there are plenty of other valid architectural styles appropriate to other problem domains.

6) Similar to #1 above where there needs to be a macro discussion of REST for the enterprise, I wonder if there's a place for REST style in the micro. It seems like the same REST principles could be applied to micro application architecture. Something like the Actor model of immutable message passing.

Anyway, my rough notes of Day 1 as I understood it...

Wednesday, April 21, 2010

Hypermedia constraint check

The Hypermedia Constraint seems to be the toughest one for developers to "get" in a RESTful system.  Most of my architecture documentation/communication effort has been focused on those things that one needs to get it right.  Things like: links in representations, link relations, etc.  Still, all too often, folks get it wrong.  Terribly wrong even.  So, I've thought about a simple check that I could provide as the hint that you're "doing it wrong":


Imagine the URLs to all resources except the static bookmark had a variable number of random numbers somewhere in the path and changed on each request.  Would your client still work?  Would your service's documentation still be correct?

Is it possible to answer yes to both questions and still break the hypermedia constraint?

Wednesday, April 07, 2010

RFC 5785: Defining Well-Known URIs

This feels like a terrible idea. "Fixed URIs"... it just sounds wrong in a hypertext driven ecosystem. Must be a better way. Why couldn't this be addressed by defining good site-* link relations?



RFC 5785: Defining Well-Known URIs: "

This first piece of the discovery stack was published today as an RFC. RFC 5785 defines a registry for new well-known URIs which will provide a standard location for the host-meta document. This work started a year and a half ago as a well-known document called /site-meta, and slowly evolved into a simple registry. While this isn’t a breakthrough idea, it does codify existing behavior and hopefully encourages people to share ideas, discuss proposals, and reusing existing well-known URIs.

Thursday, April 01, 2010

ASF Membership += Me

I've been proud to participate in the Apache community in a variety of roles over the past five years.  I'm surprised and honored to learn that I've been voted in as an ASF member.  Thanks for nominating and voting for me...