This post originated from an RSS feed registered with Java Buzz
by Bill de hÓra.
Original Post: It's not called Middleware-Services for a reason
Feed Title: Bill de hÓra
Feed URL: http://www.dehora.net/journal/atom.xml
Feed Description: FD85 1117 1888 1681 7689 B5DF E696 885C 20D8 21F8
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....
Previous Topic
