Hi Anne, Thank you. Much appreciated.
Shahar -----Original Message----- From: Anne Thomas Manes [mailto:[EMAIL PROTECTED] Sent: Thursday, September 21, 2006 8:27 AM To: [email protected] Subject: Re: [Axis2] Using 'type' attribute for the message part Yes -- that is correct. If you are using document style, your message part MUST reference an element. Anne On 9/21/06, Kedar, Shahar <[EMAIL PROTECTED]> wrote: > Hi Anne, > > Does this mean that if I'm using the Doc style, and my operation has an > input of native type (let say integer), then I'm required to have an > element tag in the schema with @type xsd:integer, and in the message tag > have a wsdl:part tag with @element and not @type? > > Regards, > Shahar Kedar > > -----Original Message----- > From: Anne Thomas Manes [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 20, 2006 7:48 PM > To: [email protected] > Subject: Re: [Axis2] Using 'type' attribute for the message part > > Brennan, > > The semantics of type vs element in <wsdl:part> is defined in the WS-I > Basic Profile, Section 4.4.1 [1]. > > You must use @type when using RPC style; you must use @element when > using document style. > > With document style, you specify the literal schema of the element > contained in the SOAP Body; therefore, the message may contain at most > one body part, and that part must reference an element definition. It > must not reference a type definition. > > With RPC style, you specify the types of the parameters that must be > passed in the SOAP Body, but not the literal schema. The message > definition must contain a part for each parameter, and those parts > must reference a type definition. At runtime, the SOAP engine is > responsible for dynamically constructing the element contained in the > SOAP Body as follows: > - It generates a wrapper element that has the same local name as the > operation, and which is qualified by the namespace specified in the > <soap:body> definition in the binding. This wrapper element has no > formally specified type or schema. > - It generates an accessor element for each parameter. The accessor > elements are non-qualified, and they get their local name from the > @name in the <wsdl:part>. The type of each accessor element is the > type specified in the WSDL part definition. > > For example, if you have: > > <wsdl:message name="opRequest"> > <wsdl:part name="param1" type="xsd:string"/> > <wsdl:part name="param2" type="xsd:string"/> > </wsdl:message> > ... > <wsdl:binding ...> > <soap:binding style="rpc" ...> > <wsdl:operation name="op"> > ... > <wsdl:input> > <soap:body use="literal" namespace="urn:example:rpc"/> > </wsdl:input> > ... > </wsdl:operation> > </wsdl:binding> > > The message on the wire would look like: > > <soap:Body> > <ns1:op xmlns:ns1="urn:example:rpc"> > <param1>some string</param1> > <param2>some string</param2> > </ns1:op> > </soap:Body> > > [1] > http://www.ws-i.org/Profiles/BasicProfile-1.1.html#Bindings_and_Parts > > On 9/18/06, Spies, Brennan <[EMAIL PROTECTED]> wrote: > > Yes, I am using the most recent nightly build. The input and output is > > Doc/literal... > > > > > > <wsdl:binding name="ActionSoapHttp" type="tns:ActionInterface"> > > <soap:binding style="document" > > transport="http://schemas.xmlsoap.org/soap/http"; /> > > <wsdl:operation name="Action"> > > <soap:operation > > > > soapAction="urn:ejgallo:workflow:service:action/Action" /> > > <wsdl:input> > > <soap:body use="literal" /> > > </wsdl:input> > > <wsdl:output> > > <soap:body use="literal" /> > > </wsdl:output> > > </wsdl:operation> > > </wsdl:binding> > > > > > > I can file a bug (no problem) since it's clear the lack of a return > doc is a > > bug, but I also wanted to know what is meant when a 'type' is > specified in > > the WSDL, i.e., what SHOULD be the result of such a configuration in > terms of > > what is generated in the SOAP, and more specifically to Axis2, the > generated > > classes? > > > > Brennan > > > > -----Original Message----- > > From: Ajith Ranabahu [mailto:[EMAIL PROTECTED] > > Sent: Monday, September 18, 2006 11:42 AM > > To: [email protected]; [EMAIL PROTECTED] > > Subject: Re: [Axis2] Using 'type' attribute for the message part > > > > Hi, > > What kind of binding do you have ? > > > > Ajith > > > > On 9/18/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote: > > > Are u using the nightly build? If so, please open a issue/bug. > > > > > > thanks, > > > dims > > > > > > On 9/18/06, Spies, Brennan <[EMAIL PROTECTED]> wrote: > > > > Axis devs, > > > > > > > > Got a question regarding the use of types for message parts rather > than > > > > elements...specifically, what are the semantics of it? Reading the > WSDL > > spec > > > > does not clarify this for me. > > > > > > > > For example, suppose you have an output message defined as > > > > > > > > <message name="Response"> > > > > <part name="output" type="ns:responseType"/> > > > > </message> > > > > > > > > Using the Axis code generator with XMLBeans databinding, the > ResponseType > > > > class will be generated, but there is no corresponding *Document > class. > > Also, > > > > the methods in the generated code look more like an IN ONLY MEP > rather > > than > > > > IN-OUT--i.e., the skeleton has no return value, hence no > meaningful SOAP > > > > response is generated. > > > > > > > > Brennan > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > -- > > > Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service > Developers) > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > Ajith Ranabahu > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
