Rosa Parks Rides the Enterprise Service Bus

We're talking about REST these days and left off musing about enterprise protocols more exotic than HTTP. What does it even mean to be RESTful without HTTP? To the great striving middle class of programmers, it seems like the programming universe is being rent asunder by incredibly boring arguments about HTTP verbs, tortured analogies with SQL, and general ennui.

In the midst of this mayhem, the marketing drones interject their RESTful sales pitches for "Enterprise Service Buses" blissfully unaware that they are only getting paid because the world accidentally invented the World's Biggest Enterprise Service Bus (hint: it's called The Internet). They are able to walk the path from "the Internet is good", to "the Internet is mostly REST", to "we should make money off REST by convincing people they need expensive message passing software" without getting dizzy -- probably thanks to fancy SkyMall devices not available to the REST of us.

And honestly, if REST is an architectural state of mind — the journey, not the destination — why do I have to read endlessly about whether browsers support PUT and DELETE? So lets ignore HTTP for a while and talk about REST. The rest of us should be allowed to ride this bus after all. This wil take some time, so this article merely lays out the rules of the ride: and we are not giving up our seat.

According to Roy Fielding according to Wikipedia (and when has that ever been wrong?)

REST enables intermediate processing by constraining messages to be self-descriptive: interaction is stateless between requests, standard methods and media types are used to indicate semantics and exchange information, and responses explicitly indicate cacheability.

• Self-Descriptive. I covered this last time. The GIS world is in decent shape here with broad adoption of standards from vectors to rasters to projections. (I'll have to save my ""so why does ESRI think they need to invent another raster and vector format?" rant for another time.)
• Stateless. The cool kids like the word idempotent because it almost sounds naughty. Statelessness is tough. In the projects I work on, most of our GIS data comes from Oracle via SDE. Now there's a connection which is far from stateless -- the whole thing is predicated on transactionality, limited concurrency. To add insult to injury, the entire ESRI software stack is spectactularly un-resilient to connection failure with a geodatabase. I work in oil and gas, so OpenSpirit is everywhere. This is a shared-memory and RPC protocol fresh off the design shelves of the 1980s, complete with leg warmers and stubble.
• Cacheability. This matters a lot for GIS with such staggering volumes of data. Google Maps didn't take off because the map was slidey -- it took off because it was fast, and that happened because of caching. But the public internet relies on HTTP caching proxies for the magic of tiled maps and blog feeds. What do we do in the enterprise? You're going to cache an Oracle response? Caching also matters for editing if we're talking about seriously complex data like is found in oil and gas, where even main memory never seems fast enough.

And we haven't even started talking about giving every blessed polygon a name -- a URI. Since URIs start with protocol specifiers, I guess we have more to do. We'll start with stateless next time.