Yasser has been battling the RPC vs. Messaging debate with Chris Kinsman. Plenty of interesting comments.
But please bear with this Web Services newbie [1] while I try to present some of my thoughts on the matter, and hopefully clear some things up for myself...
I totally agree with Yasser's assertion that the difference between messaging and RPC starts at design time (I'd even go a bit further and say that the architecture could potentially be pretty influenced by this choice). And this applies to whatever messaging/rpc platform you're on, not just WebServices.
I, too, used to be convinced that WebServices were all about RPC [looks ashamed in the other direction...], but lately, I've come to my senses and seen the light on the beauty that is Doc/Literal SOAP messaging. Thanks to Sam, Keith, Clemens, Yasser and anyone bitching about REST (too many to name) for that.
However, I disagree about some of the comments made about why RPC dominates over the Messaging model. Sure, the tools and SOAP's HTTP binding have something to do with it [2], but I don't think that's the crux of the matter. To me, it's mostly about architectural styles. Most people don't know are only used to the RPC model. It's natural, if you approach things from the same side you approach a common programming language.
I finally decided to talk about these topics and blatantly expose my vast ignorance on the subject for all to see, because it's one topic I've been struggling with lately (even within the context of the application we're currently working on). I've been trying to set up a mental framework for thinking about this and seeing what possible role messaging could play in our application's architecture (I'm not the architect, but that doesn't have to stop me thinking, right?).
And I've actually found some resistance (both in myself, as well as in others) when I bring these topics up, and it's not easy to deal with. I think the largest resistance is about the scenarios where messaging can be effectively applied, and I have yet to find something comprehensive in this area (any pointers?). For example, many people believe that messaging only applies for one-way or async interaction patterns. However, many people try to model all interactions in some sort of Request-Almost-Immediate-Response/Can't-Do-Anything-While-We-Wait-for-it model, which is immediately mapped to RPC-style interactions (which does model it very nicely, I'll admit). What I'm trying to say is: I'd love to know and understand more about the topic and be able to take better advantage of it, so if anyone can share any pointers, I'd really appreciate it!
The Interop argument Yasser brings up for messaging is certainly a good one, but that assumes one cares about interop. Allow me to say that most people don't give a dead ratt's ass about interop. Seriously, they don't. Not because they shouldn't, but because they don't know they should. It's easy to ignore the interop argument if you don't think you'll need it just because there's no white elephant external system in sight. And of course, there's the old argument against intentional schemas [3]: it's all XML anyway so it's ready to interoperate, right?
OK, I guess this did turn into a rant, couldn't help it :)
[1] meaning I haven't read all the specs and don't know them by heart :)
[2] Count my vote on loosening SOAP's grip on HTTP and letting SOAPAction burn in hell for all eternity
[3] by intentional schemas I refer to schemas explicitly defined with an intent or motive, versus unintentional schemas resulting through other methods, such as whatever comes out of a serialized DataSet.
