« J2EE and the JVM: Ted Neward calls it | Main | Leave integration to the programmers »

It's not called Middleware-Services for a reason

Mark is upbeat about this entry from Jim Webber. So am I. Yet, I confess it's been frustrating over the last few years listening to middleware/rpc types dictating how to build web-services. I have always had the impression that these folks secretly considered people like myself to be childish web-monkeys incapable of building true enterprise systems (which no-one denies is hard work). Anyway, the increased convergence between web and middleware factions can only be a good thing.

The fact is that regular Web Services have a far more uniform interface than the REST style. I've laid down the challenge before, but you can't get much more uniform than one (imaginary) verb, can you? - Jim Webber

So, having figured out that not constraining an architecture's verb set doesn't work, time to swing to the polar opposite - one verb. A curious approach ;)

We're past the RPC stage of Web Services, and we've been past it for a while now. Message to the REST community - stop telling us that we're playing catch up and see what's really been happening on our side of the fence. - Jim Webber

Glad to hear it, but message to the ex-RPC community - stop telling us how you think you can build build internet scale systems this time around, and go and look at the ones we have. C'mon guys, it's not called middleware-services for a reason!

Mark responds thusly:

That's really good to hear you say that Web services have uniform semantics. But it's impossible for them to be more uniform than REST, because REST prescribes uniform interface semantics by definition. - Mark Baker

I have to admit I don't get this. What does it mean? Mark's thinking in two areas, uniformity by definition and self-description has confused me in the past. My notion of self-description is based mathematical logic (yawn), but is precise in that respect. I don't find HTTP any more self-describing than XML, but I wouldn't find RDF self-describing either because there are real limits to the descriptive power of formal languages. Maybe Mark is talking about the the amount of description/state (inline information) carried by a REST-style message rather than the descriptive power of the message language. Which would make me something of a pedant. Guess we'll have to meet up sometime.

The HTTP verbs are too numerous. - Jim Webber

I would say the HTTP verbs are sufficient :) but if there's an argument that the HTTP verb set is either proliferate or inadequate I'm interested.

Jim made an interesting observation:

In terms of addressing the asynchronous behaviours, the speakers (Bill Donoghoe co-presented with Hao) were pretty honest (with a little prodding from some "pommie" bloke in the audience) that full asynchronous behaviour isn't really an option for most developers today. They discussed a simple polling pattern and agreed that sometimes it just makes sense to do synchronous communication rather than polling. Although the implication that synchronous consumers block while they're waiting for responses from services is being economical with the facts (hint: threads). - Jim Webber

Very true, this is economical with the truth, but even backed by threads, the sync model is never going to scale as well as an event/queue/async based model can. There's scope in making better request-response models atop an asynchronous infrastructure. We've looked at this in Propylon at the application and messaging levels, especially at how to give application developers a good programming model for highly asynchronous systems (put it this way - there are reasons why NIO-backed servlet engines aren't prevelant).

Under the hood, much of it comes right down to how the servers and the wiring between the tiers themselves are architected. In terms of the scalability needs for machine to machine comms, there's only so much you can do on top of a thread per request model before the servers melt down (and "melt down" merely implies more threads than CPUs). An ex-colleague of mine Miles Sabin, did a lot of work in the area of scalable web-servers, and for a taste of what can been done, take a look at Matt Welsh's Seda (I think Matt and Miles designed the first two Java NIO backed web servers). Dan Kegel has a good summary of the technical issues and options in his C10K problem page. I feel this is becoming a much more critical subject today for web services than it was during the dot-com era.

Finally, having ordered it, I'm looking forward to reading Jim's book.


April 11, 2004 05:37 PM

Comments

Mark Baker
(April 12, 2004 12:17 AM #)

Is the interface semantic uniform? If so, then it's RESTful. If not, then it's not RESTful. I don't think there's much more to it than that.

Regarding HTTP POST, it may very well be that there's some non-RESTful part of its definition which doesn't make it uniform (though I don't think there is). So perhaps it isn't RESTful. But if "processMessage" is indeed perfectly uniform, then it would be RESTful. But since I believe that POST is uniform, and I think I understand what Jim means by "processMessage", I'm confident that they mean the same thing, and are both uniform.

Sorry if that's bit long-winded. Perhaps we have different mental models of how architectural constraints work, because my uniform claim/observation seems very motherhood-and-apple-pie to me. *shrug*

Bill de hra
(April 12, 2004 03:36 PM #)

Thanks Mark,

I don't think we think we have so different models on this stuff, but I suspect my terminology isn't a good fit here - it's logical/kr jargon. I'll have to go through the literature again and try to lose some presumptions.

Matt Garland
(April 12, 2004 05:30 PM #)

Dilip
(April 16, 2004 05:48 AM #)

An interesting rebuttal on Jim Webber's article showed up as feedback here:
http://www.sys-con.com/story/?storyid=44354&DE=1

From Michi Henning -- a bit harsh but makes some clear cut points.

Trackback Pings

TrackBack URL for this entry:
http://www.dehora.net/mt/mt-tb.cgi/1216

Listed below are links to weblogs that reference It's not called Middleware-Services for a reason:

» On REST's Uniform Interface from geekaboo.net
Clarifying the meaning of REST's "uniform interface"... [Read More]

Tracked on April 14, 2004 08:28 AM

» Wow! 1090 messages!!! from test
TITLE: Wow! 1090 messages!!! URL: http://savas.parastatidis.name/2004/04/14/750b3c13-4575-4d6e-ae72-8befc137b745.aspx IP: 128.240.229.66 BLOG NAME: test DATE: 04/24/2004 12:19:36 AM [Read More]

Tracked on April 24, 2004 12:19 AM

» Wow! 1090 messages!!! from
TITLE: Wow! 1090 messages!!! URL: http://savas.parastatidis.name/2004/04/14/750b3c13-4575-4d6e-ae72-8befc137b745.aspx IP: 128.240.229.6 BLOG NAME: DATE: 04/24/2004 02:12:43 AM [Read More]

Tracked on April 24, 2004 02:12 AM