axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anne Thomas Manes <atma...@gmail.com>
Subject Re: difference between rpc/lit and doc/lit
Date Tue, 26 Jul 2005 17:53:32 GMT
James, 

You are correct -- neither the WSDL 1.1 spec nor the SOAP 1.1 spec
specifies that the <soap:Body> may contain at most one top-level
element, but neither do they specify how a SOAP engine should
interpret a <soap:Body> that contains more than one top-level element.

Should the extra elements be treated as multiple elements for input to
a single operation, or should each element be processed as a separate
operation request?

Most SOAP engines, including Axis, ignore all extra elements. I'm
surprised to hear you say that you have produced a doc/lit service
with mutliple body parts that worked the way you expected it to. I've
answered quite a few questions on this list from people who say that
they're missing all by the first parameter when using doc/lit.

The "one top-level element per <soap:Body>" rule comes from the WS-I BP. 

(Also note that WSDL 1.1 is not a W3C Recommendation. It's just a "W3C
Note". That status does not imply any kind of endorsement or
ratification by W3C. It just means that W3C has published a submitted
specification for the purpose of public discussion.)

Anne

On 7/26/05, James Wilson <wilsonj@ociweb.com> wrote:
> 
> 
> Quoting Anne Thomas Manes <atmanes@gmail.com>:
> 
> > WSDL style (rpc vs document) has no impact on whether or not you can
> > map multiple binding ports to a single URL. That's more likely to be a
> > function of your SOAP engine rather than the design of your service.
> >
> > There are a number of differences between the way you define an
> > rpc/lit WSDL versus a doc/lit WSDL, but "wrapped" doc/lit and rpc/lit
> > look almost identical on the wire. You may see differences in
> > namespaces and in the response element name. In doc/lit, the schema
> > explicitly specifies the name of the response element and what
> > namespaces must be used for the top-level element and all local
> > elements. In rpc/lit, the top-level element within the <soap:Body> is
> > in the namespace specified by the namespace attribute in the
> > <wsdlsoap:body> definition in the <wsdl:binding>, and the parameter
> > elements are never namespace qualified. Also, in rpc/lit the SOAP
> > engine autogenerates the name of the response element, and its name is
> > not significant.
> >
> > When using doc/lit, you define the full schema of the message payload
> > by defining the <xsd:element> structure of the contents of the
> > <soap:Body>. There can be at most one top-level element within the
> > <soap:Body>, therefore this element must contain all message
> > parameters.
> 
> I'm confused by this last sentence.  I don't see in the WSDL1.1 spec from w3c
> that a doc/lit body can have only one child element, "If the operation style is
> document there are no additional wrappers, and the message parts appear directly
> under the SOAP Body element."  In practice, my services that had more than one
> part, produced messages that had more than one child element in the
> soapenv:body.
> 
> I did encounter that the WS-I Basic Profile adds the restriction that doc/lit
> messages can have only one part.
> 
> > The <wsdl:message> definition must specify at most one
> > body part (although it may contain additional header or fault parts),
> > and that body part must reference the <xsd:element> definition. For
> > example, for an operation "foobar" with two input parameters "foo" and
> > "bar", the <wsdl:message> definition would look like this:
> >
> >   <wsdl:message name="foobarRequest">
> >      <wsdl:part name="body" element="ns1:foobar"/>
> >   </wsdl:message>
> >
> > And the ns1:foobar element definition would look something like this:
> >
> >   <xsd:element name="foobar">
> >     <xsd:complexType>
> >       <xsd:sequence>
> >          <xsd:element name="foo" type="xsd:string"/>
> >          <xsd:element name="bar" type="xsd:string"/>
> >       </xsd:sequence>
> >     </xsd:complexType>
> >   </xsd:element>
> >
> > When using wrapped doc/lit, the top-level element name must be the
> > same as the operation name (in this case, "foobar"). When using
> > unwrapped doc/lit, the top-level element may have any name -- but you
> > still must define all input information as local elements within the
> > top-level element.
> >
> > When using rpc/lit, you do not define the full schema of the message
> > payload. Instead you only define the types of your input parameters.
> > At runtime, the SOAP engine autogenerates the message element
> > structure. As with doc/lit, the <soap:Body> may contain at most one
> > top-level element, but in this case, the SOAP engine generates this
> > element. It uses the operation name for the element's local name, and
> > it gets the namespace from the namespace attribute in the
> > <wsdlsoap:body> definition. The SOAP engine also generates elements
> > for each parameter type. These elements as unqualified, and the local
> > name comes from the name attribute in the <wsdl:part> definition.
> >
> > In rpc/lit, the <wsdl:message> definition specifies one body part for
> > each operation parameter. Each <wsd:part> definition must specify the
> > name of the parameter and the parameter type. If the parameter type is
> > a complexType, then the type must be defined as a <xsd:complexType> in
> > the <wsdl:types> section. For the "foobar" example, the <wsdl:message>
> > definition would look like this:
> >
> >   <wsdl:message name="foobarRequest">
> >      <wsdl:part name="foo" type="xsd:string"/>
> >      <wsdl:part name="bar" type="xsd:string"/>
> >   </wsdl:message>
> >
> > Anne
> >
> > On 7/26/05, Mark Hansen <mark@javector.com> wrote:
> > > Is the only difference between rpc/lit and doc/lit that the rpc/lit
> > > style wraps the parameters (parts) in the method (operation) name?  Is
> > > the purpose of the rpc/lit style to use the method wrapper as a way to
> > > implement the WSDL allowed mapping of multiple binding ports to a single
> > > URL?
> > >
> > > Thanks for any clarification,
> > >
> > > Mark
> > >
> > >
> >
>

Mime
View raw message