axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anne Thomas Manes" <atma...@gmail.com>
Subject Re: wsdl message with no parts
Date Tue, 03 Apr 2007 13:50:12 GMT
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 <rishikrrish@gmail.com> 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 <atmanes@gmail.com> 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 < rishikrrish@gmail.com> 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 <atmanes@gmail.com> 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 <rishikrrish@gmail.com> 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 <atmanes@gmail.com> 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 < rishikrrish@gmail.com> 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 < amilasuriarachchi@gmail.com>
> wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On 3/29/07, Rishi krish < rishikrrish@gmail.com
> 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:
> > > > > axis-user-unsubscribe@ws.apache.org
> > > > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > thanks
> > > > > Rishi
> > > >
> > > >
> > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> > > axis-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > > thanks
> > > Rishi
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> axis-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-user-help@ws.apache.org
> >
> >
>
>
>
> --
> thanks
>  Rishi
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org


Mime
View raw message