Using Doc Literal for all Services

With all the discussion about the best encoding style to use for WSDL/SOAP, such as this excellent IBM DeveloperWorks article from October, 2003, I have to wonder whether the best answer is really just to use doc/literal for everything…?
The doc/literal style would seem to be the most abstract or the most “loosely coupled,” since it does not include data typing (although data typing is provided by an associated XML Schema) and does not include a method name in the message.
True, the burden of interpreting the XML document falls on the Web service implementation, but isn’t that how it should be? In developing services, as Don Box and others have been recently saying, shouldn’t we be thinking about the content of the message independently of the underlying implementation of the service? Whether it’s object-oriented, procedure-oriented, a message queue, an ERP package, Java, C#, COBOL, or Python? Then the implementation of the service, whether a direct or indirect mapping (that is, whether the execution stage involves transformation or multiple steps), can take responsiblity for extracting the relevant information from the XML document and formatting it for the execution environment.
Won’t this level of abstraction really make life easy? Maybe not for the folks who have to develop the services and the mapping of the documents, but for the next level developers who have to stitch everything together. I mean, once enterprises are all service-oriented, and have adopted and implemented SOA using Web Services and XML, won’t integrators just have to worry about the data being passed in the messages, and not about the objects, queues, methods, or programs underneath the services?
Once executable, compiled software systems are over-layed with XML based Web services, and they start exchanging messages based on the data in them, and stop worrying about the object signature, productivity will go way up, won’t it?
Today when integrating various bits and types of software, combining programs written using different languages and/or middleware systems, you have to know what it is you’re invoking and figure out how to structure your data into the arguments associated with the particular method or program name. I don’t think that’s very productive, at least not for those integrating services into appliations and flows.


3 responses to “Using Doc Literal for all Services

  1. Very good point, Eric! As editor of Cutter’s “Web Services Strategies” newsletter, I have spent a lot of time researching what people say about Web services and SOA, and “loose coupling” is probably where the greatest confusion arises. It seems to me there is a lot of doubletalk going on, with people claiming all the theoretical benefits of Web services (e.g. loose coupling through the use of Doc Literal) – then going straight on to cite code that follows the RPC model, and enthusing about how easily it can be generated!
    Moreover, I think the use of Doc Literal fits in well with the “WSDL first” development style (or better still, perhaps, for those using MDA, “PIM first, then WSDL”). Start by figuring out the data schemas at the CIM level, then work downward. Code comes last!
    Convenience dictates otherwise, though – and convenience (with its good buddies, speed and cheapness) scores high in sales meetings. The convenient way is to point one of the scores of tools out there at some existing code, and let it generate WSDL from that.

  2. Hi Eric!
    I definitely agree with your comments. However, I would like to point out that Doc/Literal helps if one wants to build loosely-coupled systems but it does not guarantee loose-coupling. This is true with all technologies when they are not used properly.
    Isn’t WS-RF an example of a suite of specifications where doc/literal is used to implement a resource-oriented or object-based approach to building distributed applications? I suspect that the WS-RF approach will lead to tight-coupling and will not scale. But it may be just me.
    Related entry (since my trackback doesn’t work)…

  3. Eric, I think you’re mostly on the money: transitioning to a more message-centric model would be a great leap forward. I think, however, you overstate the ease at which integration will move forward when everyone is focusing on data exchange and agnostic about implementation choices: integrators will still be very much constrained by capabilities (especially delivery guarantees), business policies and bi-lateral agreements, etc. But come to think of it, those are the aspects they should be focusing on anyway…