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: No such operation
Date Tue, 27 Jun 2006 17:24:55 GMT
After you run java2wsdl, you then have to run wsdl2java. It should have
produced an appropriate WSDD for you.

The WSDL is the artifact that clients use to consume the service. It is
designed to hide implementation information, therefore it isn't much use to
Axis in terms of telling it how to dispatch a request. The WSDD is the
artifact that contains the information that maps the abstract WSDL
information to the concrete implementation. Axis uses the WSDD to dispatch
requests.

SOAPAction isn't particularly useful, and it actually goes away in SOAP 1.2.

Anne

On 6/27/06, Doug B <ummmmm22@gmail.com> wrote:
>
> Interesting.  So does the java2wsdl -A option do anything at all?  Sorry
> if I'm just being thick here, but something just doesn't seem right when the
> only artifact required for defining an interface, the WSDL, is ignored.  If
> the interface says the operation is named Operation, why is Axis expecting
> it to be named Request?
>
> Again, I'm not disputing what you're saying, I just don't understand
> something about why it is so.  Is Axis not actually able to define the
> service from the WSDL but only from the Java code generated from the WSDL?
> Even if Axis uses only the WSDD at deployment time, why is not not
> reflecting what was in the WSDL? I must be missing something obvious here,
> so feel free to give up on me whenever you want :-)
>
> Doug
>
>
> On 6/27/06, Anne Thomas Manes <atmanes@gmail.com> wrote:
> >
> > SOAPAction is just a "hint". You may notice that the WSDD doesn't
> > reference the SOAPAction parameter. Axis uses the WSDD (not the WSDL) to
> > figure out how to dispatch the request. If the information isn't in there,
> > Axis can't figure it out.
> >
> >
> > Anne
> >
> > On 6/26/06, Doug B < ummmmm22@gmail.com> wrote:
> > >
> > > Hmmm... so it turns out the options he can specify in his JBoss
> > > environment correspond to those on the java2wsdl tool.  -T, -A, -y, -u.  To
> > > me, that should mean they're relevant only to the server side.  Yet
> > > specifying SOAPAction: OPERATION (-A), doesn't seem to resolve the problem.
> > > Furthermore, such options aren't even available on wsdl2java, which is all
> > > it seems he should need to be using in this case.  (That's another issue,
> > > why he can't get an actual service deployed just from wsdl2java artifacts
> > > and why he's having to go down this java2wsdl path at all (using the code
> > > originally generated from wsdl2java)).
> > >
> > > Don't get me wrong, I believe that the wsdd option is the solution (or
> > > altering the WSDL to use the operation name as the request element name), I
> > > just want to understand why some of Axis seems to understand that the
> > > SOAPAction field might need to contain the operation name, but some of it
> > > doesn't.
> > >
> > > Thanks again for your patient instruction.
> > >
> > > Doug
> > >
> > > On 6/26/06, Doug B <ummmmm22@gmail.com> wrote:
> > > >
> > > > I'm also discovering that my Axis customer is having to do some
> > > > intermediate step where he generates code from our WSDL but can't find
any
> > > > deployable artifacts until he takes some "other steps", at which point
he
> > > > has to re-specify several options, including... style, encoding, SOAP
> > > > Action.  So far,  none of those were set correctly and his ?wsdl didn't
even
> > > > match the "contract" WSDL in those crucial parameters.  Will be testing
soon
> > > > with hopefully the correct values specified there.
> > > >
> > > > (I have no details at all on my .NET customer's environment, so it's
> > > > also possible he had to do some tweaking himself.)
> > > >
> > > > Doug
> > > >
> > > > On 6/26/06, Anne Thomas Manes <atmanes@gmail.com> wrote:
> > > >
> > > > > Not quite. Axis does not assume that you are using wrapped. Axis
> > > > is reading the Qname of the incoming SOAP body and trying to map it to
a
> > > > known operation. Because you have not explicitly specified that the incoming
> > > > "doi:SuccessfulCompletionRequest" QName maps to the method
> > > > "SuccessfulCompletionOperation", Axis doesn't know how to handle the request
> > > > and returns an error of "No such operation".
> > > >
> > > > You haven't supplied any information about the .NET environment, so
> > > > I can't tell you why it miraculously worked.
> > > >
> > > > Anne
> > > >
> > > >
> > > > On 6/26/06, Doug B <ummmmm22@gmail.com> wrote:
> > > >
> > > > >  Thanks again (you too, Jeff).  I'm starting to understand, but
> > > > bear with me.  Your article was helpful, but I'm still left wondering
about
> > > > a few things.
> > > >
> > > > Namely, I'd have to change my WSDL to support "wrapped", whether or
> > > > not I'm going to actually use it on either side, right?  I have to use
> > > > particular naming conventions.  And Axis seems to be assuming that I've
done
> > > > so.  Again, strangely enough, my .NET customer's environment did not make
> > > > this assumption.
> > > >
> > > > Or is Axis' operation name expectation completely unrelated to the
> > > > "wrapped" convention?  Maybe that's the real issue, and *that* seems like
> > > > something the WS-I would need to address.  i.e. whether a request
> > > > element name should match its operation name to be able to be easily looked
> > > > up.
> > > >
> > > > Doug
> > > >
> > >
> > >
> >
>

Mime
View raw message