axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug B" <ummmm...@gmail.com>
Subject Re: No such operation
Date Tue, 27 Jun 2006 23:30:43 GMT
Sure:

  <wsdl:portType name="DOIServicesPortType">
    <wsdl:operation name="SuccessfulRenewalOperation">
    	<wsdl:input message="tns:SuccessfulRenewalRequestMessage"/>
    	<wsdl:output message="tns:SuccessfulRenewalResponseMessage"/>
    </wsdl:operation>
  </wsdl:portType>
  <wsdl:binding name="DOIServicesBinding" type="tns:DOIServicesPortType">
    <soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
    <wsdl:operation name="SuccessfulRenewalOperation">
      <soap:operation
soapAction="http://az.gov/doi-ws/SuccessfulRenewalOperation"/>
    	<wsdl:input>
	        <soap:body use="literal"/>
    	</wsdl:input>
    	<wsdl:output>
	        <soap:body use="literal"/>
    	</wsdl:output>
    </wsdl:operation>
  </wsdl:binding>



On 6/27/06, Anne Thomas Manes <atmanes@gmail.com> wrote:
>
> 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
> > > SOAPAction HTTP 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
> > > > <snip>
> > > >
> > >

Mime
View raw message