Frederik,
The "at most one child in the SOAP Body" restriction is defined by the
WS-I Basic Profile. This restriction has since been ratified in the
SOAP 1.2 specification.
The SOAP specification does not explain how to process multiple child
elements in a SOAP body, and therefore different implementations
behave differently, causing interoperability issues. As far as I know,
all systems that do support multiple child elements in the SOAP body
treat them as two separate operation requests -- not as multiple
parameters to a single request -- whether it's RPC or document style.
When using RPC style, the SOAP engine automatically generates a
wrapper element for the specified parameters. When using document
style, you must assemble your parameters into a single element.
The restriction pertains to both wrapped style and unwrapped style. In
wrapped style, you create a wrapper element has the same name as the
operation. In unwrapped style, the child element of the SOAP body can
have any name -- but the point is, you are sending a document -- not
parameters.
Regards,
- Anne
On Fri, 18 Feb 2005 00:04:33 +0100, frederik.de.backer_at_belgacom.be
<frederik.de.backer_at_belgacom.be> wrote:
>
> Anne,
>
> I am a colleague from Xavier and would like to thank you for the quick
> response.
>
> I have anyhow some other questions:
> - is this resttriction added by the JWSDP JAX-RPC implementation or is
> it part of the WSDL 1.1 specs?
> - I have seen that there are two styles for document/literal: wrapper
> and non wrapper. For the wrapper you can give only one part per message.
> I have not seen this restriction for the non-wrapper style. Isn't there
> a workaround posible with the non-wrapper style?
>
> Thx for the support,
>
> Frederik.
>
> -----Original Message-----
> From: Anne Thomas Manes [mailto:atmanes_at_gmail.com]
> Sent: 17 February 2005 22:58
> To: users_at_jax-rpc.dev.java.net
> Subject: Re: WSDeploy error in case multipart input message
>
> Xavier,
>
> When using doc/literal, your input message must contain at most one body
> part. If you need to input multiple parameters, then you need to define
> a wrapper element that contains those parameters as a sequence of
> elements. For example, edit your WSDL as follows:
>
> <wsdl:types>
> <xsd:schema
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> xmlns="urn:v1.test.ithomi.be"
> targetNamespace="urn:v1.test.ithomi.be"
> xmlns:serviceMgt="urn:v1.test.ithomi.be"
> elementFormDefault="qualified"
> attributeFormDefault="unqualified"
> version="1.2">
>
> <xsd:element name="createService">
> <xsd:complexType>
> <xsd:sequence>
> <xsd:element name="userId" type="xsd:string"/>
> <xsd:element name="serviceId"
> type="xsd:string"/>
> </xsd:sequence>
> </xsd:complexType>
> </xsd:element>
>
> </xsd:schema>
> </wsdl:types>
> <wsdl:message name="inputCreateService">
> <wsdl:part name="parameters"
> element="serviceMgt:createService"/>
> </wsdl:message>
>
> Regards,
> Anne
>
> On Thu, 17 Feb 2005 07:41:33 -0800, xdenayer_at_ithomi.com
> <xdenayer_at_ithomi.com> wrote:
> > Hello, can anybody help us?
> >
> > We have an operation for which the input message contains 2 parts.
> > As we need documentliteral, those parts are declare with an
> > 'element'-attribute.
> > When doing a wscompile (-features wsi,documentliteral) and wsdeploy
> > (jwsdp1.4 or 1.5), this generates an error:
> > -> [wsdeploy] error: generator error: internal error
> > (should not happen): tie.generator.002 As a result, the generated
> > web.xml is not correct and, as such, when we deploy the war on an
> > application server, the service is not reachable...
> > When we remove one of the 2 message parts, everything is ok!
> >
> > So, the problem we are facing is:
> > How to compile a webservice with jwsdp, in documentliteral style, with
>
> > an operation input message containing more than one part....
> >
> > I added an example wsdl in attach. Note: this wsdl is just an example
> > to show the error (the structure is not optimal at all!!)
> >
> > Thanks for the multiple replies!
> > Xavier
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
> > For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
> For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>
>
> **** DISCLAIMER ****
> http://www.belgacom.be/maildisclaimer
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
> For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>
>