Just want to say thanks for a nice write up. I had been wondering myself since DAIS-WG's OGSA implementation of a data mounting web service is document based, though a competing group named Spitfire is RPC based.
If this could make its way into a FAQ that would be nice (if it isn't already in one). On Fri, 2002-11-22 at 16:43, Anne Thomas Manes wrote: > SOAP supports two different ways to structure messages. A SOAP message can > be structured as an RPC or a document. > > The RPC style simulates an RPC invocation and response. An RPC input message > specifies the name of the procedure to be invoked, and it contains a set of > input parameters. An RPC output message contains the return value and any > output parameters of the procedure. The format of the RPC input and output > messages can be defined by literal XML schema definitions, or they can be > structured using a data model called SOAP encoding. This SOAP encoding data > model allows you to easily map complex object-oriented data structures > (graphs) to XML. So for example, an RPC message looks something like this: > > <env:Body> > <m:methodName xmlns:m="someURI"> > <m:param1>...</m:param1> > <m:param2>...</m:param2> > ... > </m:methodName> > </env:Body> > > Document style does not impose any particular structure to the message. > There's no automatic convention for how to specify a method name or a list > of parameters. The format of the document input and output messages are > defined by XML schema definitions, which may be defined within the Web > services WSDL document or within a separate schema. Formatting a SOAP > message according to a specified schema is called literal encoding. Document > style can be used for request/response messages or for one-way messages. > It's up to the SOAP listener to figure out where to direct the message. In > many cases the method name is specified in the SOAPAction HTTP header rather > than in the SOAP message. > > >From a practical point of view, there's very little difference from RPC and > document style. Your parameters in RPC style can be as complex as you like. > For example, you can pass a purchase order as a document or as a parameter > in a method called placeOrder. It's your choice: > > Document style: > <env:Body> > <m:purchaseOrder xmlns:m="someURI"> > ... > </m:purchaseOrder> > </env:Body> > > RPC style: > <env:Body> > <m:placeOrder xmlns:m="someURI"> > <m:purchaseOrder> > ... > </m:purchaseOrder> > </m:placeOrder> > </env:Body> > > The bigger difference is how you encode the message. In most circumstances, > you use literal encoding with Document style and SOAP encoding with RPC > style. Literal encoding means that the Body contents conform to a specific > XML Schema. SOAP encoding uses a set of rules based on the XML Schema > datatypes to encode the data, but the message doesn't conform to a > particular schema. SOAP encoding is particularly useful is you're passing > cyclic object graphs. For example, if you have an element which is > referenced repeatedly within the object graph, when using SOAP encoding, you > would specify the element once and then reference the element as needed. > When using literal encoding, you would have to repeat this element each time > it's referenced. > > The advantage of using document or RPC messages structured using a literal > XML schema definition is that the messages can be validated using the schema > and transformed using an XSLT stylesheet. RPC messages structured using SOAP > encoding cannot be validated and transformed using standard XML tools. The > advantage of using SOAP encoding is that it provides a simpler and more > efficient method to represent and transfer object-oriented data in XML, but > it limits flexibility. > > Anne
