You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Mark Hansen <ma...@javector.com> on 2005/07/26 10:28:41 UTC
difference between rpc/lit and doc/lit
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
Re: difference between rpc/lit and doc/lit
Posted by James Wilson <wi...@ociweb.com>.
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 <at...@gmail.com>:
> 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 <wi...@ociweb.com> wrote:
> >
> >
> > Quoting Anne Thomas Manes <at...@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 <ma...@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
> > > >
> > > >
> > >
> >
>
Re: difference between rpc/lit and doc/lit
Posted by Anne Thomas Manes <at...@gmail.com>.
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 <wi...@ociweb.com> wrote:
>
>
> Quoting Anne Thomas Manes <at...@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 <ma...@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
> > >
> > >
> >
>
Re: difference between rpc/lit and doc/lit
Posted by James Wilson <wi...@ociweb.com>.
Quoting Anne Thomas Manes <at...@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 <ma...@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
> >
> >
>
Re: difference between rpc/lit and doc/lit
Posted by Anne Thomas Manes <at...@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. 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 <ma...@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
>
>