 | Start a set with this search |
 | Include this search in one of my sets |
 | Exclude this search from one of my sets |
 | Permalink to these results Paste this link in email or IM: |
 | Atom feed for tracking future search results Paste this URL into your reader: |
5 messages in org.apache.ws.axis-userRe: difference between rpc/lit and do...| From | Sent On | Attachments |
|---|---|---|
| Mark Hansen | Jul 26, 2005 1:28 am | |
| Anne Thomas Manes | Jul 26, 2005 9:59 am | |
| James Wilson | Jul 26, 2005 10:16 am | |
| Anne Thomas Manes | Jul 26, 2005 10:53 am | |
| James Wilson | Jul 26, 2005 1:30 pm |
| Permalink for this message Paste this link in email or IM: |
| Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Re: difference between rpc/lit and doc/lit | Actions... |
|---|---|---|
| From: | James Wilson (wils...@ociweb.com) | |
| Date: | Jul 26, 2005 1:30:25 pm | |
| List: | org.apache.ws.axis-user | |
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 <atma...@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 <wils...@ociweb.com> wrote:
Quoting Anne Thomas Manes <atma...@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