On Jon on Eric on RPC and XML

I just read Jon's post on Eric's appearance on a recent Sys-Con panel. Eric raised made an interesting point about the challenge in thinking about distributed systems from an XML document perspective instead of an RPC perspective. Jon agreed that RPC vs. doc/lit was an interesting issue, but I don't think it's the right one. You have to be careful with the term doc/literal. It's really a WSDL detail meaning simply that the message payload is accurately described by the referenced XSD (as opposed to encoded, where that is not the case). Doc/literal is orthogonal to the issue of whether the architecture or programming model is focused on RPC, async messaging or document transfer. In the MS space, ASP.NET Web Services are doc/literal (by default), but the programming model is RPC. Indigo is doc/literal (by default) and the most talked about programming model is RPC, but other programming models are possible. Biztalk is primarily about document transfer, but you can use it to do RPC and async messaging as well (at least that's how I think of it).

Depending on your background, one of these models is likely to feel the most natural. RPC is the easiest for most folks to understand. Many people who've worked on big enterprise integration systems believe async message queuing is the only thing that works. Many people who've worked on cross-enterprise integration systems have relied on document transfer based models. You can do all of them with SOAP and WSDL, though different kits are more naturally aligned with one or another. I think all of them are valid service-oriented architectures, though I try to recast RPC as synchronous messaging instead of replicating a call-stack (the latter approach is the de facto thinking for most developers, and it leads to lots of complexity and inefficiency).

So all that said, the interesting issue is how to leverage the flexibility and extensiblity of XML to maximum advantage? For instance, how do you create a unified definition of "customer" for your company so that instead of defining a single stringent format, you allow multiple alternate formats. The goal is to get to one for efficiency, but allow others for flexibility in when a branch of the business needs it. XML is excellent for this, but most people coming from a DCOM/CORBA/RMI background don't look at systems that way.