I'm glad someone else brings this to the table. John Cavnar-Johnson puts it very nicely, and I totally agree with this.

This is a topic I have to battle constantly both within our organization and with our customers on our consulting sessions. I've said it in the past and I'll say it again: many people fail to grasp the difference between RPC and Message Orientation in WebServices and other platforms because the programming models created by the tool are totally RPC oriented in nature! Believe me, most people don't really grasp the subtleties involved in how the programming model completely warps their point of view and understanding of the underlying technology.

I'll also say a few other things on this:

  • I'd like to add one other Guidance to John's excellent list: If you have to use ASMX, use this.
  • BizTalk does have it right. As Aaron has mentioned in the past, the BizTalk model is completely contract and message oriented. However, even BTS does a few things in a quirky manner :) Did you know that when you add a Web Reference to an external WebService from your BTS Project, BTS actually generates a client-side proxy class for the service, which the SOAP Send Adapter calls underneath? This has caused problems for quite a few and it is very un-message-oriented-like...
  • Indigo... well, what can I say. Is the programming model Indigo (WCF, whatever) proposes better than ASMX? Yes. Very much. The way DataContracts are specified is easy, and the way it relates to the underlying schema is very nice. However: do I believe most people will grasp the subtle difference from this to the old ASMX/XmlSerializer way of doing it? No. In that sense, I do fear we might not be making quite that bit of forward movement. I also believe that with all the other protocol support Indigo does, it does muddy things somewhat because it is a far more complex environment, in that sense (even though the programming model is easy).


Tomas Restrepo

Software developer located in Colombia. Sr. PFE at Microsoft.