Doc Or Die

At InfoWorld’s SOA Executive Forum in San Francisco this past week Jon Udell moderated a panel about different communication methods used by services. The panelists discussed the range of options from coarse-grained transfer of complete business documents – orders, invoices, and the like – to remote procedure calls with small sets of data. You can make arguments against big document exchanges on the basis of communication efficiency, but you can also make arguments against lots of small information exchanges because of the extra overhead needed to maintain state while all the little exchanges are carried out.

But the best argument for coarse document exchanges is that if you go that way you’ll be making a conscious design choice and almost certainly have invested some effort into designing the document models or evaluating standard document ones. The documents you exchange will more likely be ones that are easy to process because they’ll have unambiguous semantics and use robust code sets and identifiers. They’ll be easier to reuse across a range of related partners and services.

This isn’t to say that fine-grained information exchanges can’t also be well-designed with interoperable semantics. But many proprietary APIs are getting turned into web services by tools that do little more than slap angle brackets around "get" and "set" methods, and you often get what you pay for when you adopt these low-cost “automatic” design techniques.

Of course I’m biased. My book is called Document Engineering, not RPC Engineering.

-Bob Glushko

# posted by Bob Glushko @ 12:58 PM