Re: WSDL - empty request

From: Anne Thomas Manes <atmanes_at_gmail.com>
Date: Wed, 16 Feb 2005 09:30:18 -0500

When using RPC style, the SOAP engine automatically constructs a
wrapper element for the input message that has the same name as the
operation -- therefore you always have a unique wire signature.

When using Document style, the SOAP engine sends only what you've
specified in the <wsdl:message> definition. If you have no part
defined, then the SOAP engine will send an empty <soap:Body/> element.

As I said before, you need to create an empty element (e.g.,
<retrieveError/>) and use it as your input message for that operation.

  <message name="retireveErrorRequest">
     <part name=parameters" element="tns:retrieveError"/>
  </message>

When using doc/literal, I suggest you use the "wrapped" programming
convention. It's described in the JAX-RPC specification, and it's also
the default convention used by .NET.

The rules for the wrapped style are fairly simple:

1. You must have one (and only one) body part in your input message
definition and one body part in your output message definition. (You
may have other message parts representing header blocks or attachments
-- but one and only one body part.) The name of the body part should
be "parameters".

2. The body part definitions in the input and output message
definitions must reference element definitions in the <types> section.
These element definitions are "wrapper" elements (hence the name of
this convention). You define your input and output parameters as
element structures within these wrapper elements.

3. A wrapper element must be defined as a complex type that is a
sequence of elements. Each child element in that sequence will be
generated as a parameter in the service interface.

4. The name of the input wrapper element must be the same as the operation name.

- Anne

On Fri, 11 Feb 2005 08:57:09 -0800, Doug Kohlert <Doug.Kohlert_at_sun.com> wrote:
>
>
> Honorez Dylan wrote:
>
> >Ok, I see.
> >
> >Any suggestions to avoid the SOAPElements that are generated in my signatures? Or is this something I can't avoid with document/literal.
> >
> >
> You get SOAPElements when you use schema constructs not supported by JAXRPC.
>
> >
> >PS:In RPC/Encoded empty messages are no problem.
> >
> >
> >
> They are also not a problem in rpc/literal.
>
> >Dylan Honorez,
> >dylan.honorez_at_xt-i.com
> >http://www.xt-i.com/ <http://www.xt-i.com/>
> >
> >
> >________________________________
> >
> >Van: Doug Kohlert [mailto:Doug.Kohlert_at_Sun.COM]
> >Verzonden: do 10/02/2005 18:02
> >Aan: users_at_jax-rpc.dev.java.net
> >Onderwerp: Re: WSDL - empty request
> >
> >
> >
> >Anne did not mean the message signature in terms of the Java method
> >signature. She was referring to the wire representation of it.
> >Since both of these operations will look identical on the wire, there is
> >no-way to know which one is being invoked.
> >
> >Honorez Dylan wrote:
> >
> >
> >
> >>Method signatures include operation name, so if two different operations
> >>both have an empty request, they are still unique. So that can't be the
> >>reason. Otherwise two operations that have a string as input wouldn't be
> >>unique either.
> >>
> >>About the empty element, that's what I'm using now. It works,
> >>butwscompile generates SOAPElements in signatures, instead of an empty
> >>signatures.
> >>
> >>Kind regards,
> >>Dylan Honorez,
> >>dylan.honorez_at_xt-i.com
> >>http://www.xt-i.com/
> >>
> >>
> >>-----Original Message-----
> >>From: Anne Thomas Manes [mailto:atmanes_at_gmail.com]
> >>Sent: donderdag 10 februari 2005 16:04
> >>To: users_at_jax-rpc.dev.java.net
> >>Subject: Re: WSDL - empty request
> >>
> >>WS-I compliance requires that each operation have a unique signature.
> >>Because you have two operations with an empty input message, you break
> >>this rule. I suggest you create an empty element (e.g.,
> >><retrieveError/>) and use it as your input message for that operation.
> >>
> >>Anne
> >>
> >>On Wed, 9 Feb 2005 12:59:00 +0100, Honorez Dylan
> >><Dylan.Honorez_at_cronos.be> wrote:
> >>
> >>
> >>
> >>
> >>>Hi,
> >>>
> >>>While developing a jax-rpc document/literal webservice, I came across
> >>>the following issue:
> >>>WSCompile is ok with one empty request, but not with more. The WSDL is
> >>>fine and validates within XML Spy.
> >>>
> >>>WSCompile output:
> >>>D:\projects\GFISFileHandling v2>call wscompile -gen:server
> >>>-f:searchschema -keep -verbose -d build/WEB-INF/classes -model build/
> >>>WEB-INF/model.xml.gz config.xml
> >>>users_at_jax-rpc.dev.java.net[CustomClassGenerator: generating JavaClass
> >>>for: fileInfo]
> >>>[CustomClassGenerator: generating JavaClass for: objectInfo]
> >>>[LiteralObjectSerializerGenerator: writing serializer/deserializer
> >>>
> >>>
> >>>
> >>>
> >>for:
> >>
> >>
> >>
> >>
> >>>fileInfo]
> >>>[LiteralObjectSerializerGenerator: writing serializer/deserializer
> >>>
> >>>
> >>>
> >>>
> >>for:
> >>
> >>
> >>
> >>
> >>>objectInfo]
> >>>error: generator error: cannot dispatch operation: retrieveError
> >>>
> >>>This is my WSDL:
> >>>
> >>><?xml version="1.0" encoding="UTF-8"?>
> >>><definitions xmlns="http://schemas.xmlsoap.org/wsdl/"
> >>>xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
> >>>xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
> >>>xmlns:xs="http://www.w3.org/2001/XMLSchema"
> >>>xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
> >>>xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
> >>>xmlns:tns="http://www.xt-i.com/gfis/"
> >>>targetNamespace="http://www.xt-i.com/gfis/">
> >>> <types>
> >>> <xs:schema
> >>>
> >>>
> >>>
> >>>
> >>targetNamespace="http://www.xt-i.com/gfis/">
> >>
> >>
> >>
> >>
> >>> <xs:complexType name="fileInfo">
> >>> <xs:sequence>
> >>> <xs:element name="fileName"
> >>>type="xs:string"/>
> >>> <xs:element name="fileSizeKb"
> >>>type="xs:long"/>
> >>> <xs:element name="objectType"
> >>>type="xs:string"/>
> >>> </xs:sequence>
> >>> </xs:complexType>
> >>> <xs:complexType name="objectInfo">
> >>> <xs:sequence>
> >>> <xs:element name="fileName"
> >>>type="xs:string"/>
> >>> <xs:element name="objectType"
> >>>type="xs:string"/>
> >>> </xs:sequence>
> >>> </xs:complexType>
> >>> <xs:element name="fhstartRequest"
> >>>type="xs:string"/>
> >>> <xs:element name="fhstartResponse"
> >>>type="xs:boolean"/>
> >>> <xs:element name="retrieveResponse"
> >>>type="tns:fileInfo"/>
> >>> <xs:element name="copyRequest"
> >>>type="tns:objectInfo"/>
> >>> <xs:element name="copyResponse"
> >>>type="xs:boolean"/>
> >>> <xs:element name="removeRequest"
> >>>type="tns:objectInfo"/>
> >>> <xs:element name="removeResponse"
> >>>type="xs:boolean"/>
> >>> <xs:element name="retrieveErrorResponse"
> >>>type="tns:fileInfo"/>
> >>> </xs:schema>
> >>> </types>
> >>> <message name="fhstartRequest">
> >>> <part name="fhstartRequest"
> >>>element="tns:fhstartRequest"/>
> >>> </message>
> >>> <message name="fhstartResponse">
> >>> <part name="fhstartResponse"
> >>>element="tns:fhstartResponse"/>
> >>> </message>
> >>> <message name="retrieveRequest"/>
> >>> <message name="retrieveResponse">
> >>> <part name="fileInfo" element="tns:retrieveResponse"/>
> >>> </message>
> >>> <message name="copyRequest">
> >>> <part name="objectInfo" element="tns:copyRequest"/>
> >>> </message>
> >>> <message name="copyResponse">
> >>> <part name="success" element="tns:copyResponse"/>
> >>> </message>
> >>> <message name="removeRequest">
> >>> <part name="objectInfo" element="tns:removeRequest"/>
> >>> </message>
> >>> <message name="removeResponse">
> >>> <part name="success" element="tns:removeResponse"/>
> >>> </message>
> >>> <message name="retrieveErrorRequest"/>
> >>> <message name="retrieveErrorResponse">
> >>> <part name="fileInfo"
> >>>element="tns:retrieveErrorResponse"/>
> >>> </message>
> >>> <portType name="FHPort">
> >>> <operation name="fhstart">
> >>> <input message="tns:fhstartRequest"/>
> >>> <output message="tns:fhstartResponse"/>
> >>> </operation>
> >>> <operation name="retrieve">
> >>> <input message="tns:retrieveRequest"/>
> >>> <output message="tns:retrieveResponse"/>
> >>> </operation>
> >>> <operation name="copy">
> >>> <input message="tns:copyRequest"/>
> >>> <output message="tns:copyResponse"/>
> >>> </operation>
> >>> <operation name="remove">
> >>> <input message="tns:removeRequest"/>
> >>> <output message="tns:removeResponse"/>
> >>> </operation>
> >>> <operation name="retrieveError">
> >>> <input message="tns:retrieveErrorRequest"/>
> >>> <output message="tns:retrieveErrorResponse"/>
> >>> </operation>
> >>> </portType>
> >>> <binding name="FHBinding" type="tns:FHPort">
> >>> <soap:binding style="document"
> >>>transport="http://schemas.xmlsoap.org/soap/http"/>
> >>> <operation name="fhstart">
> >>> 
> >>> <input>
> >>> <soap:body use="literal"/>
> >>> </input>
> >>> <output>
> >>> <soap:body use="literal"/>
> >>> </output>
> >>> </operation>
> >>> <operation name="retrieve">
> >>> 
> >>> <input>
> >>> <soap:body use="literal"/>
> >>> </input>
> >>> <output>
> >>> <soap:body use="literal"/>
> >>> </output>
> >>> </operation>
> >>> <operation name="copy">
> >>> 
> >>> <input>
> >>> <soap:body use="literal"/>
> >>> </input>
> >>> <output>
> >>> <soap:body use="literal"/>
> >>> </output>
> >>> </operation>
> >>> <operation name="remove">
> >>> 
> >>> <input>
> >>> <soap:body use="literal"/>
> >>> </input>
> >>> <output>
> >>> <soap:body use="literal"/>
> >>> </output>
> >>> </operation>
> >>> <operation name="retrieveError">
> >>> 
> >>> <input>
> >>> <soap:body use="literal"/>
> >>> </input>
> >>> <output>
> >>> <soap:body use="literal"/>
> >>> </output>
> >>> </operation>
> >>> </binding>
> >>> <service name="FileHandler">
> >>> <port name="FileHandlerPort" binding="tns:FHBinding">
> >>> <soap:address
> >>>
> >>>
> >>>
> >>>
> >>location="REPLACE_WITH_ACTUAL_URL"
> >>
> >>
> >>
> >>
> >>>xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"/>
> >>> </port>
> >>> </service>
> >>></definitions>
> >>>
> >>>When I remove the "retrieveError" operation WSCompile works ok.
> >>>Any suggestions to my problem or another way to send empty requests?
> >>>
> >>>Kind regards,
> >>>Dylan Honorez,
> >>>dylan.honorez_at_xt-i.com
> >>>http://www.xt-i.com/
> >>>
> >>>---------------------------------------------------------------------
> >>>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
> >>
> >>
> >>---------------------------------------------------------------------
> >>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
> >
> >
> >
> >
> >
> >------------------------------------------------------------------------
> >
> >---------------------------------------------------------------------
> >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
>
>