During the conversion of my WSDL and it's services from rpc/enc to doc/lit I at
one time had multi-part input messages.  The Axis client was happy to create
the soap envelopes with more than one soapenv:body child element.  However,
it's just as you say that Axis would resolve the method signature based on only
the first child.  This was an intermediate step as I converted the service(s) to
pass the WS-I Basic Profile tests.

Thank you for the clarification.

Regarding the differences between rpc and document encoding styles, I recommend
the W3C website: http://www.w3.org/TR/wsdl.  This was a great source of
information during my doc/lit conversion.

-James


Quoting Anne Thomas Manes <[EMAIL PROTECTED]>:

> 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 <[EMAIL PROTECTED]> wrote:
> >
> >
> > Quoting Anne Thomas Manes <[EMAIL PROTECTED]>:
> >
> > > 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 <[EMAIL PROTECTED]> 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
> > > >
> > > >
> > >
> >
>

Reply via email to