Middleware Matters

I have to say that I was greatly puzzled as to where to begin refuting these two articles that purport to explain why REST is better than SOAP, mainly because they seem to confuse a variety of issues. Thankfully, though, Chris has saved me (and presumably a lot of others) the trouble. Thanks, Chris!

In particular, one thing I really can't figure out is where the whole Decorator/Adapter discussion in those articles is going. My colleagues and I have made extensive use of what I generally call interceptors to implement CORBA middleware, to implement J2EE middleware, and to implement Web services middleware, starting about a decade ago, as a key part of IONA's Adaptive Runtime Technology (ART) that underlies our products. Though the interceptor approach is obviously much older than a decade, it's become quite a popular approach over the past 5 years or so. Interceptors are a form of Chain of Responsibility, and they're useful for message-oriented systems and for RPC-oriented systems alike. Interceptors typically have a general interface because of where they sit in the stack, not because they're REST-oriented. Do interceptors inherently operate by transferring state representations? Not that I know of. Claiming that they have something to do with proving that REST is better than SOAP is therefore quite a stretch, IMO.

I prefer Dave Orchard's line of thinking on this topic -- less divisive, more realistic, and ultimately more useful.