I assume that MXPERSONTinterface is defined in the imported schema.
From what I see, the WSDL is WS-I BP 1.1 compliant. My assumption is
that the .NET validator has a bug.
Anne On 4/3/07, Rishi krish <[EMAIL PROTECTED]> wrote:
Hi Anne I am attaching the wsdl and the conformance report as well as the monitor log which is all based on the c# tool. My request message has a part element MXPERSONInterface which appears as child to the soap message and I have a void response message [no parts defined] which shows up in the response soap message as a soap body having no child elements [just as you had said the beahvious should be]. The BP [BP1212]failure note says :: The content of the soap:Body element is inconsistent with its description. The envelope does not contain exactly one part accessor element for each of the wsdl:part elements bound to the envelope's corresponding soapbind:body element. Which does not appear from the soap on wire as its first and only child [as you would see in the conformance as well as the monitor log] is the element [MXPERSONInterface] as pointed by the wsdl:message in the wsdl. FYI - the java version of the tool for this test says "notApplicable". This is happening with the service deployed in Axis 1.0 [not axis2]. thanks Rishi On 4/2/07, Anne Thomas Manes <[EMAIL PROTECTED]> wrote: > .NET can consume an unwrapped doc/literal service, but it's less > convenient for the .NET developer. As a general rule, I recommend that > you always follow the wrapped convention. > > I'm having trouble understanding where the BP 1.1 validator is > failing. Could you show us the WSDL (or a similar representation) > that's failing? > > When using doc/literal, your messages may contain at most one body > part (which becomes a child of the <soap:body> in the SOAP message). A > "part accessor element" refers to the child of the <soap:body>. (In > RPC style, the "part accessor elements" refer to children of the > auto-generated wrapper element that has the same local name as the > operation.) I believe the error is referring to the SOAP message, not > to the WSDL. > > Anne > > On 4/1/07, Rishi krish < [EMAIL PROTECTED]> wrote: > > Hi Anne > > Thanks again for your clarification on .Net requirements. You said doc-Lit > > wrapped is the default format generated by .Net. Do you imply that if my > > axis service is not conforming to doc-lit wrapped format .Net cannot > > communicate to it? OR .Net can be configured to communicate with a service > > which is just doc-lit and not wrapped? > > I had downloaded the c# based BP 1.1 validator from WS-I site [I am hoping > > that this is representative of .Net platform] and have been trying tests > > with it. It fails me on BP1212 which implements R2212 which requires: > > > > An ENVELOPE MUST contain exactly one part accessor element for each of the > > wsdl:part elements bound to the envelope's corresponding soapbind:body > > element. > > > > My wsdl soapbind:body does not have any part attribute defined - and thats > > perfectly valid [as per R2210] as I have only one part defined in the > > wsdl:message definition. The java BP 1.1 tool says "notApplicable". Is this > > a bug with the c# BP 1.1 tool or this is a .Net requirement that the wsdl > > soapbind:body element has to have the part attribute defined. > > > > thanks > > Rishi > > > > > > > > On 4/1/07, Anne Thomas Manes <[EMAIL PROTECTED]> wrote: > > > 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] > > > > > > > > > > > > > > -- > > 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
