If you have an empty message, then you aren't following the wrapped convention. The wrapped convention requires that the input message contain an element whose local name is the same as the operation, and the output message contain an element whose local name is the operation appended with "Response". (Essentially it literally follows the RPC convention so that programming frameworks can support an RPC-style programming model, yet still implement a doc/literal message.)
For your example, to use wrapped doc/literal, you should define the response message as: <message name="wsns:testResponseMessage"> <part name="parameters" element="myns:testResponse/> </message> (.NET further requires that the part name = "parameters") The wrapped convention was established by .NET. It is the default format generated by .NET. The Java community responded in order to interoperate more effectively with .NET. The JAX-RPC spec is the only formal specification that defines the wrapped convention. You are under no obligation to support the wrapped convention, but if you want to enable interoperability with .NET, you'll find things go much more easily if you follow it. Note that WS-I BP does require that all input messages have a unique signature. If you have more than one operations that accept no input, you must disambiguate the request messages some way. I always recommend following the wrapped convention just because it makes things easier. Anne On 4/1/07, Rishi krish <[EMAIL PROTECTED]> wrote:
Hi Anne thanks for the clarification. I am wondering if what you said for RPC type is also valid for the wrapped doc-lit type too [which kind of similar to rpc literal type and which is followed by .Net]. I mean if a pojo service method signature reads -- public void test(String s) The response wsdl message will have a part element like --- <message name="wsns:testResponseMessage"> <part name="output" element="myns:testResponse/> </message> -right? as opposed to having no part defined like ---- <message name="wsns:testTesponseMessage"> </message> I am generating the service wsdl on my own and am integrating to .Net paltform [.Net is the client]. Since .Net seems to be following the wrapped doc-lit style do you think I should generate the wsdl response message with a non-empty part as shown above [even though the pojo method has void return type] This will imply that for a request response kind of web service we allways need to have a response message with one part element to be compliant with .Net? That seems little to harsh for me as I didnt find any such requirement in BP 1.1 OR this is something that is introduced just because of .Net? thanks Rishi On 3/31/07, Anne Thomas Manes <[EMAIL PROTECTED]> wrote: > > It depends on the style. > > If you are using document style, an empty message declaration with no > parts (either input or output) will generate an empty SOAP body. > > If you are using rpc style, an empty input message declaration will > generate a SOAP body containing an element that has a local name equal > to the operation name in the namespace specified in the <soap:body> > declaration in the binding. An empty output message declaration will > generate a SOAP body containing an element representing the response > value (in this case, void). The name of the response element is not > significant, but by convention it has a local name constructed from > the operation name appended with "Response" and it is in the namespace > specified in the <soap:body> declaration. > > Anne > > On 3/30/07, Rishi krish < [EMAIL PROTECTED]> wrote: > > Also just wanted to show what the TCP monitor is howing for the response > > > > <?xml version="1.0" encoding="UTF-8"?> > > <soapenv:Envelope > > xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; > > xmlns:xsd=" http://www.w3.org/2001/XMLSchema " > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> > > <soapenv:Body/> > > </soapenv:Envelope> > > > > > > So the body elemet is empty and the wsdl snippet is below: > > > > > > <message name="AddrMessage"> > > <part name="input" element="inx:Address" /> > > </message> > > <message name="AddrMessageResponse" /> > > <portType name="AddrPortType"> > > <operation name="processAddr"> > > <input message="inws:AddrMessage" /> > > <output message="inws:AddrMessageResponse" /> > > </operation> > > </portType> > > > > Note the AddrMessageResponse definition - thats empty too. So can I conclude > > that an empty wsdl"message definition would imply a empty soap body element > > in wire? > > > > thanks > > Rishi > > > > On 3/30/07, Amila Suriarachchi < [EMAIL PROTECTED]> wrote: > > > > > > > > > > > > On 3/29/07, Rishi krish <[EMAIL PROTECTED] > wrote: > > > > > > > > Hi All > > > > This is probably a generic wsdl question - I will be using a the Axis2 > > serviceclient api to call a web service which has a wsdl operation [with > > http binding] the outpout of which refers to a wsdl:message which has no > > parts defined. I am wondering what that means for the service response? > > > > > > > > > http binding has not clearly defined in wsdl 1.1. so if you deal with http > > bindings better to use WSDL 2.0 > > > > > > > > > > > > > > A>the response would be an empty soap body > > > > > > > > > if you use http binding you would not get any soap messages. So we can > > throw this option. > > > Actually this is the case if you have above serario with a > > document/literal binding. > > > > > > > > > > > > > > B>The response would be just an http response with no trace of soap. [no > > soap envelope] > > > > > > > > > I think this should be the case. the problem here is that wsdl 1.1 spec > > does not clearly specify whether we have to use the rpc type message > > construction or document type message construction with http binding. > > > > > > > > > > > > > > Can anyone pls confirm what should be the response if the service/soap > > engine is behaving correctly? > > > > > > > > -- > > > > thanks > > > > Rishi > > > > > > > > > > > > -- > > > Amila Suriarachchi, > > > WSO2 Inc. > > > > > > > > -- > > thanks > > Rishi > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- thanks Rishi
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
