SOCKET

The Bad Easy

On first meeting Web services and WSDLs, the concepts of rpc-style and document-style services are confusing. The problem stems from the fact that there are two completely different considerations that are described using the same terminology, the implementation of the Web service itself and the structure of the soap content in the WSDL document.

The important facet is the programming model that the consumer and producer use to process their soap messages, not the style of the WSDL. This is where the real distinction between rpc-style and document-style services lies. Since the fundamental aim of SOCKET is to create consumer software for Web services from a WSDL it is essential that we know all the variations that services can throw at us so that we can proceed as far as possible in the process of setting up the consumer side of the service. For very simple services, SOCKET will be able to provide a one-step turnkey process for creating a client. For more complex rpc services and document-style services, SOCKET will probably provide a handler interface wrapped around the XML message which can then be implemented for a complete construction of the functionality of the service.

If we are using the Axis (JAX-RPC) programs Java2WSDL and WSDL2Java, or their equivalents in our language of choice, then we're probably doing rpc. And, bad news, rpc is bad. It's bad for interoperability. If Java shall speak only unto Java, and C# shall speak only to C# and Python shall speak only to Python, then we'd be OK, but then what'd be the point of Web services? It's when Java tries to talk to RosieLea, or when Python wrestles with Anaconda, that the rpc difficulties emerge, essentially through the minefield of mismatched datatypes, and also in the so-called XML-OO impedance mismatch.

So what is the document style? In a document-style Web service, you simply send the soap message to the producer and say, Look, we've talked about this, and we bashed out our schema, take the message and do what you want with it. The producer does this and sends a soap document back. There you are, consumer, we talked about this and we bashed out our schema, take the reply and do what you want with it. Using this style, I suspect that SAAJ 1.2 soap elements, which implement DOM, feeding into an XSLT/XPath engine will be the most important protocol, rather than using some tool-generated language-specific API. This will become clearer in the near future. So how is this better than rpc? Well, hopefully the problem spots have been identified and can be catered for. One field might be a date. The producers can say - look, this field is a date, but - hey - we might feed it in as a null value (nillable = true in the schema) - so watch out for this. In the rpc service, the null date might feed straight into an api that hasn't got null date types - it might go in as a zero...with hilarious consequences (I take this particular example from a Ted Neward interview on The Server Side).

So rpc is bad, and document is good. Document is also good from a related angle - message-oriented middleware and the Humptyhump Humpty Bus. I might say more about this at a later date - I usually do.

The bad news is that for simple services rpc is easier - all tool based, and taken directly from the WSDL operations and messages. With a bit of luck, for simple rpc-style services you are saved the problems that necessarily exist if an XML document has to be developed to implement complex service functionality. Having said this, even simple rpc-style services will have semantic problems, albeit of a different kind, in the absence of good annotations or documentation. Please input gas pressure. Surely - in Pascals, bars, torrs, atmospheres, psi...? Missions to Mars have perished on such semantic asteroids, and so will many a badly-drawn Web service.

So, there are rpc-style and document-style Web services. Either style can be employed using rpc-style or document-style WSDL documents. The WSDL styles are normally referred to as rpc-literal and doc(ument)-literal. So, if we can have an RPC-style Web Service (RWS) and a Document-style Web Service (DWS), there are 4 immediate possibilities: rpc-literal and doc-literal RWS; and rpc-literal and doc-literal DWS (I suppose we ought to give document-wrapped literal a namecheck, too, which makes it easier for tools to handle RWS with doc-style WSDLs).

SOCKET has started orff with the bad easy stuff, a natural place to start: rpc-literal RWS.

Posted at 10:16AM Apr 12, 2006 by Brian Peter Clark in General  |