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
service’s 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
> -----Original Message-----
> From: Paul Faulkner [mailto:[EMAIL PROTECTED]]
> Sent: Friday, November 22, 2002 2:02 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Document style web services
>
>
> would you mind explaining what RPC-Style and Document-Style messages are.
> Sorry I'm very new to this technology.
>
> thanks,
>
> Paul Faulkner
>
>
> -----Original Message-----
> From: Anne Thomas Manes [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, November 21, 2002 12:41 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Document style web services
>
>
> Dennis,
>
> This is a pretty antiquated view of document style. Document style is no
> longer used just for XML messaging. Most SOAP implementations support
> automatic marshalling of both RPC-style and document-style
> messages. As long
> as you have a WSDL description of the message structure, there's
> no problem
> building automatic serializers.
>
> The predominant consensus in the industry at this point is to use
> document-style by default. Document style is much easier to validate,
> transform, and manipulate. The primary reason to consider using
> rpc/encoded
> is if you need to send multi-referencing object structures. SOAP encoding
> does a really nice job marshalling these structures. It's much harded to
> represent them using literal XML Schema. But if you're not using
> multi-refs,
> it's a better practice to use document-style.
>
> Regards,
> Anne
>
> > -----Original Message-----
> > From: Dennis Sosnoski [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, November 21, 2002 1:25 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Document style web services
> >
> >
> > Hi Matt,
> >
> > The whole point of document style is that your application gets passed
> > the XML message payload as XML document fragments. See the "message"
> > sample for an example of this. With a document style interface your
> > class would look like:
> >
> > public class SomeXMLService {
> > public Element[] someXMLMethod(Element[] elems) {
> > ...
> > }
> > }
> >
> > If you want to convert the XML into objects you need to do it yourself,
> > perhaps using a framework such as Castor (http://www.castor.org). I know
> > there's been some integration of Castor with Axis, though I think this
> > was for custom serialization with RPC style.
> >
> > This brings up an interesting point, though. Why not have a Java
> > DataBindingProvider as a replacement for the MsgProvider? This should
> > allow easy use of document style while converting seamlessly between XML
> > and objects without the application needing any special code. I'm
> > looking into some data binding code currently, perhaps I'll see if I can
> > work in this direction.
> >
> > - Dennis
> >
> > Dennis M. Sosnoski
> > Enterprise Java, XML, and Web Services Support
> > http://www.sosnoski.com
> >
> > Crawford, Matt wrote:
> >
> > >Hello,
> > >
> > >Has anyone had experience with document style web services
> similar to the
> > >one shown below? The users guide indicates that "Document
> services do not
> > >use any encoding (so in particular, you won't see multiref object
> > >serialization or SOAP-style arrays on the wire) but DO still do
> > XML<->Java
> > >databinding."
> > >
> > >I'm looking to leverage this databinding to serialize and
> deserialize xml
> > >documents in the body, but the samples/encoding (from what I can
> > tell) deals
> > >with rpc style, not document style.
> > >
> > >Thanks,
> > >Matt Crawford
> > >Enterprise Rent-A-Car
> > >
> > >
> > ><SOAP-ENV:Envelope
> > >xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";
> > >xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"; >
> > ><SOAP-ENV:Body>
> > > <SomeXmlElement xmlns="http://www.somUri.org/someClassName";
> > >anAttribute="foo">
> > > <AnotherXmlElement value="X"/>
> > > <AThirdXmlElement value="three"/>
> > > </SomeXmlElement>
> > ></SOAP-ENV:Body>
> > ></SOAP-ENV:Envelope>
> > >
> > >Would somehow map to (with appropriate typeMapping entries)
> > >
> > >public class SomeXmlService() {
> > > public SomeXmlResponse method(SomeXmlElement arg0) {
> > > return new SomeXmlReponse();
> > > }
> > >}
> > >
> > >
> > >
> >
>
