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 23:19:30 GMT
Doug,

Can you post the portType and binding definitions for this operation? There
might be something there that's not quite right.

Anne

On 6/27/06, Doug B <ummmmm22@gmail.com> wrote:
>
> Thanks again, Anne.  I had read that first BP section, but not really
> understanding the implications until some of this discussion.  It makes more
> sense now.
>
> I did try with Axis 1.3, and it does the same thing, so it must be
> something I'm just not quite grasping.  But I'm content for now that I
> understand what it's doing and somewhat why, so thanks for your time and
> effort.  It's been a couple years since I spent much time in the Axis
> newsgroup, but I remember noting back then that your answers were thorough
> and knowledgable (even bought a copy of your book), so I appreciate having
> your input on this.
>
>
> Doug
>
> On 6/27/06, Anne Thomas Manes <atmanes@gmail.com> wrote:
> >
> > Sorry -- there's no reason to run java2wsdl, but it really helps to run
> > wsdl2java. I'm not sure why it's producing the erroneous qname attribute in
> > the <operation> element. This could be a bug in Axis 1.2 (which had
> > pretty sketchy support for document/literal -- Axis 1.3 or 1.4 is much
> > better).
> >
> > Tell your customer to make the following change to the WSDD:
> >
> > Change this:
> >
> > <operation name="successfulRenewalOperation"
> >                 qname="SuccessfulRenewalOperation"
> >
> >
> > to this:
> > <operation name="successfulRenewalOperation"
> >                 qname="retNS:SuccessfulRenewalRequest"
> >
> > In any case, to answer your questions...
> >
> > The hosting server determines how to dispatch a request by looking at
> > the QName of the child element of the <soap:Body>. The configuration must
> > provide the hosting service with the necessary information to map the QName
> > to an appropriate method in the service agent.
> >
> > See Section 4.7.6 in the WS-I Basic Profile:
> > 4.7.6 Operation Signatures
> >
> > Definition: operation signature
> >
> > The profile defines the "operation signature" to be the fully qualified
> > name of the child element of SOAP body of the SOAP input message described
> > by an operation in a WSDL binding.
> >
> > In the case of rpc-literal binding, the operation name is used as a
> > wrapper for the part accessors. In the document-literal case, since a
> > wrapper with the operation name is not present, the message signatures must
> > be correctly designed so that they meet this requirement.
> >
> > An endpoint that supports multiple operations must unambiguously
> > identify the operation being invoked based on the input message that it
> > receives. This is only possible if all the operations specified in the
> > wsdl:binding associated with an endpoint have a unique operation
> > signature.
> >
> >  R2710 The operations in a wsdl:binding in a DESCRIPTION MUST result in
> > operation signatures that are different from one another.
> > And section 4.7.25 (second paragraph):
> > 4.7.25 Describing SOAPAction
> >
> > Interoperability testing has demonstrated that requiring the SOAPActionHTTP header
field-value to be quoted increases interoperability of
> > implementations. Even though HTTP allows for header field-values to be
> > unquoted, some implementations require that the value be quoted.
> >
> > The SOAPAction header is purely a hint to processors. All vital
> > information regarding the intent of a message is carried in the envelope.
> > Regards,
> >
> > Anne
> >
> > On 6/27/06, Doug B < ummmmm22@gmail.com> wrote:
> > >
> > > But I'm trying to go the other direction.  I don't want to have to run
> > > java2wsdl at all.  I want to handwrite the WSDL and use that as the contract
> > > for both the client and the server.  I want the "wsdl2java --server-side" to
> > > generate a deployable service which matches and honors the original WSDL,
> > > including recognizing the specified operation names.
> > >
> > > I went ahead and generated server-side artifacts myself just to
> > > compare what I think my customer might be seeing.  It seems interesting to
> > > me that, in fact, the deploy.wsdd that is generated from the
> > > "--server-side" option does contain the <operation> mappings - they're
just
> > > looking for what I'd consider the "wrong" qname:
> > >
> > > <operation name="successfulRenewalOperation"
> > >                 qname="SuccessfulRenewalOperation"
> > >                 returnQName="retNS:SuccessfulRenewalResponse"
> > >                 xmlns:retNS=" http://az.gov/doi"
> > >                 returnType="rtns:SuccessfulRenewalResponseType"
> > >                 xmlns:rtns=" http://az.gov/doi"
> > >                 soapAction="
> > > http://az.gov/doi-ws/SuccessfulRenewalOperation" >
> > >     <parameter qname="pns:SuccessfulRenewalRequest"
> > >                       xmlns:pns="http://az.gov/doi"
> > >                       type="tns:SuccessfulRenewalRequestType"
> > >                       xmlns:tns=" http://az.gov/doi"/>
> > > </operation>
> > >
> > > (This is either with or without the --noWrapped option.)
> > >
> > > It gets the correct returnQName from the WSDL-defined response
> > > element, including for another operation where that response name is not at
> > > all related to the operation or request names, so why wouldn't it use the
> > > WSDL-defined request element for the qname by default?
> > >
> > > Regarding SOAPAction, so what is supposed to be *the standard* way the
> > > service endpoint knows what operation is being requested?  Is the "engine"
> > > supposed to have to make a best guess at mapping operation "signatures"
> > > based on "parameters" (with manual override mapping allowed)?  I guess I was
> > > expecting something less ambiguous to be part of the specs or at least ws-i.
> > >
> > >
> > >
> > > Doug
> > >
> > > On 6/27/06, Anne Thomas Manes < atmanes@gmail.com> wrote:
> > > >
> > > > 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