You are viewing a plain text version of this content. The canonical link for it is here.

Posted to java-user@axis.apache.org by Doug B <um...@gmail.com> on 2006/06/25 20:58:05 UTC

No such operation

We're doing a "contract-first" implementation with a customer, using
Document-Literal from handwritten WSDL and Schema.  We are the client and
our customer the server.  The Schema has elements (and types) defined for
each request and response message, and the WSDL uses single elements for
each message part, named "request" and "response", with single input and
output elements for the operations.

We've used this same approach with a .NET customer and had no issues.
However, this particular customer is using Axis (1.2 beta 3 because of his
particular version of JBoss) and it reports that it's trying to call an
operation whose name is actually the name of our request element.  Doing a
little digging, it almost looks like Axis has decided to use something like
wrapped style, which we're not using.

Any ideas on the cause of this?  How we can resolve it?

(I realize the customer's Axis is not current, and I'm going to pursue with
him whether he can update to at least the last release level of 1.2, but I'm
not sure that will make any difference.)

Relevant excerpts from the definitions:
...

<xsd:element name="SuccessfulRenewalRequest"
type="doi:SuccessfulRenewalRequestType"/>
<xsd:element name="SuccessfulRenewalResponse"
type="doi:SuccessfulRenewalResponseType"/>

...

<wsdl:message name="SuccessfulRenewalRequestMessage">
  <wsdl:part name="request" element="doi:SuccessfulRenewalRequest"/>
</wsdl:message>
<wsdl:message name="SuccessfulRenewalResponseMessage">
  <wsdl:part name="response" element="doi:SuccessfulRenewalResponse"/>
</wsdl:message>

<wsdl:operation name="SuccessfulRenewalOperation">
  <wsdl:input message="tns:SuccessfulRenewalRequestMessage"/>
  <wsdl:output message="tns:SuccessfulRenewalResponseMessage"/>
</wsdl:operation>
...

And from the messages (captured with TCPMon):

SOAPAction: "**ns removed**/SuccessfulRenewalOperation"
Content-Length: 732

<?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>
         <SuccessfulRenewalRequest
xsi:type="ns1:SuccessfulRenewalRequestType" xmlns="**removed**"
xmlns:ns1="**removed**">
           ...
            ** 6 sequence fields removed **
           ...
         </SuccessfulRenewalRequest>
      </soapenv:Body>
   </soapenv:Envelope>

...

<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:Fault>
         <faultcode xmlns:ns1="http://xml.apache.org/axis/
">ns1:Client</faultcode>
         <faultstring>No such operation
'SuccessfulRenewalRequest'</faultstring>
         <detail>
            <ns2:hostname xmlns:ns2="http://xml.apache.org/axis/">**servername
removed**</ns2:hostname>
         </detail>
      </soapenv:Fault>
   </soapenv:Body></soapenv:Envelope>

i.e. Axis appears to be using the main element in the Body, not the
SOAPAction, as the Operation name.

Doug

Re: No such operation

Posted by Jeff Greif <jg...@alumni.princeton.edu>.

Wrapped style has to do with client and/or server implementation.  The
wsdl definition is of a doc/lit operation with request element given
as described in the wsdl.  The child elements of that request are the
parameters that are "wrapped" by that element, but the wsdl file
contains no information about this.  Rather, the deployment descriptor
on client specifies the "wrapped" style which allows the client to
provide the java objects corresponding to those child elements and
have the Axis machinery convert them to xml and then wrap them.
Similarly, a deployment descriptor on the server specifying wrapped
style tells the Axis machinery to "unwrap" the child elements,
deserialize them into java objects and pass them to the method
implementing the service as arguments.  The soap sent between client
and server is unchanged by using the wrapped convention on either
client or server or both.

Jeff

On 6/25/06, Doug B <um...@gmail.com> wrote:
> Thanks, Anne.  That makes sense and looks like a simple solution.
>
> Best I can tell, the WS-I Basic Profile does not recommend or even mention
> wrapped Document-Literal, does it?  Plus, from reading some older Axis
> discussion threads, it sounds as if wrapped style may not even be concretely
> defined, much less standardized.  Or is that no longer the case?  I guess
> I'm surprised that Axis defaults to what appears the non-standard scenario
> rather than the standard one.
>
>
> On 6/25/06, Anne Thomas Manes <at...@gmail.com> wrote:
> >
> > Axis figures out how to map an incoming request based on the QName of the
> child element of the SOAP Body. If you use RPC style or wrapped document
> style, then the name of that element will be the same as the operation name,
> and Axis can automatically figure out how to map the request. But if you use
> non-wrapped document style (as you are in this case) then you must
> explicitly tell Axis how to map the request using the <operation> tag in the
> WSDD. To map your input message <doi:SuccessfulRenewalRequest> to the
> service method SuccessfulRenewalOperation, you must specify the following:
> >
> > <operation name="SuccessfulRenewalOperation"
> > qname="doi:SuccessfulRenewalRequest"
> > />
> >
> >
> > Anne
> >
> >
> >
> > On 6/25/06, Doug B <um...@gmail.com> wrote:
> > >
> > > We're doing a "contract-first" implementation with a customer, using
> Document-Literal from handwritten WSDL and Schema.  We are the client and
> our customer the server.  The Schema has elements (and types) defined for
> each request and response message, and the WSDL uses single elements for
> each message part, named "request" and "response", with single input and
> output elements for the operations.
> > >
> > > We've used this same approach with a .NET customer and had no issues.
> However, this particular customer is using Axis (1.2 beta 3 because of his
> particular version of JBoss) and it reports that it's trying to call an
> operation whose name is actually the name of our request element.  Doing a
> little digging, it almost looks like Axis has decided to use something like
> wrapped style, which we're not using.
> > >
> > > Any ideas on the cause of this?  How we can resolve it?
> > >
> > > (I realize the customer's Axis is not current, and I'm going to pursue
> with him whether he can update to at least the last release level of 1.2,
> but I'm not sure that will make any difference.)
> > >
> > > Relevant excerpts from the definitions:
> > > ...
> > > <xsd:element name="SuccessfulRenewalRequest"
> type="doi:SuccessfulRenewalRequestType"/>
> > > <xsd:element name="SuccessfulRenewalResponse"
> type="doi:SuccessfulRenewalResponseType"/>
> > >
> > >
> > >
> > >
> > > ...
> > > <wsdl:message name="SuccessfulRenewalRequestMessage">
> > > <wsdl:part name="request"
> element="doi:SuccessfulRenewalRequest"/>
> > > </wsdl:message>
> > >
> > >
> > > <wsdl:message name="SuccessfulRenewalResponseMessage">
> > >
> > > <wsdl:part name="response"
> element="doi:SuccessfulRenewalResponse"/>
> > > </wsdl:message>
> > >
> > > <wsdl:operation name="SuccessfulRenewalOperation">
> > >
> > >
> > > <wsdl:input
> message="tns:SuccessfulRenewalRequestMessage"/>
> > >
> > > <wsdl:output
> message="tns:SuccessfulRenewalResponseMessage"/>
> > > </wsdl:operation>
> > > ...
> > >
> > > And from the messages (captured with TCPMon):
> > >
> > > SOAPAction: "**ns removed**/SuccessfulRenewalOperation"
> > > Content-Length: 732
> > >
> > > <?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>
> > >          <SuccessfulRenewalRequest
> xsi:type="ns1:SuccessfulRenewalRequestType"
> xmlns="**removed**" xmlns:ns1="**removed**">
> > >            ...
> > >             ** 6 sequence fields removed **
> > >            ...
> > >          </SuccessfulRenewalRequest>
> > >       </soapenv:Body>
> > >    </soapenv:Envelope>
> > >
> > > ...
> > >
> > > <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:Fault>
> > >          <faultcode xmlns:ns1="
> http://xml.apache.org/axis/">ns1:Client</faultcode>
> > >          <faultstring>No such operation
> 'SuccessfulRenewalRequest'</faultstring>
> > >          <detail>
> > >             <ns2:hostname xmlns:ns2="
> http://xml.apache.org/axis/">**servername removed**</ns2:hostname>
> > >          </detail>
> > >       </soapenv:Fault>
> > >    </soapenv:Body></soapenv:Envelope>
> > >
> > > i.e. Axis appears to be using the main element in the Body, not the
> SOAPAction, as the Operation name.
> > >
> > >
> > > Doug
> > >
> >
> >
>
>

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

Re: No such operation

Posted by Anne Thomas Manes <at...@gmail.com>.

I don't see anything wrong. Smells like a bug...

On 6/27/06, Doug B <um...@gmail.com> wrote:
>
> Darn.  Sorry for formatting.  Let's try again:
>
>   <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>
>
> >
> > 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 <um...@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>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>

Re: No such operation

Posted by Doug B <um...@gmail.com>.

Darn.  Sorry for formatting.  Let's try again:

  <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>

>
> 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 <um...@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>

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

Re: No such operation

Posted by Doug B <um...@gmail.com>.

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 <at...@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 <um...@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>
> > > >
> > >

Re: No such operation

Posted by Anne Thomas Manes <at...@gmail.com>.

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 <um...@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 <at...@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 <um...@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 <at...@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 <um...@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
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: No such operation

Posted by Doug B <um...@gmail.com>.

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 <at...@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:bindingassociated 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 <um...@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 <um...@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 <at...@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 <um...@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
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: WSDL2Java and one-way binding

Posted by Dies Koper <di...@jp.fujitsu.com>.

Hello Bonjamin,

There is a tag in the WSDD to set the WSDL file, I believe "<wsdl-file>".
If you specify it, that file will be returned by ?wsdl instead.
No need to touch the skeletons.

Regards,
Dies

Benjamin Fan wrote:
> I've given up on service-generated-WSDL - I hand-cut/validate WSDL and use
> WSDL2Java to generate both the server-side skeleton and the client side
> stubs. I haven't done it yet but I'm told its straight forward to modify 
> the
> generated code to return static WSDL files rather than genertaing WSDL on
> the fly. ANy chance of you manually maintaining the generated skeleton? 
> This
> is what I'm going to have to do...
> 
> On 6/29/06, John Mani <jm...@comverge.com> wrote:
>>
>> Hi all
>>
>> Any comments on the below issue ? I'd expect this to be a common scenario
>> .. so am I
>> misunderstanding something ?
>>
>> thanx
>> -john
>>
>> ________________________________
>>
>> From: John Mani [mailto:jmani@comverge.com]
>> Sent: Tue 6/27/2006 6:53 PM
>> To: axis-user@ws.apache.org
>> Subject: WSDL2Java and one-way binding
>>
>>
>> I'm using Axis 1.4 WSDL2Java to generate skeletons for a webservice 
>> from a
>> WSDL doc.
>>
>> The source WSDL (generated by .NET) uses one-way binding - it just
>> specifies a
>> <wsdl:input> element, no <wsdl:output> element.
>>
>> However, the generated skeleton code seems to be including a response to
>> the request.
>> This is proven by checking the deployed skeleton's WSDL (deployed in
>> tomcat, using
>> the axis war) - it contains  <wsdl:input> and <WSDL:output> messages.
>> Also, when
>> I run the .NET client against the deployed skeleton, the client 
>> complaints
>> about the
>> unexpected entity body in the response.
>>
>> Any comments/help ?
>>
>> thanx
>> -jm


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

Re: WSDL2Java and one-way binding

Posted by Benjamin Fan <bt...@gmail.com>.

I've given up on service-generated-WSDL - I hand-cut/validate WSDL and use
WSDL2Java to generate both the server-side skeleton and the client side
stubs. I haven't done it yet but I'm told its straight forward to modify the
generated code to return static WSDL files rather than genertaing WSDL on
the fly. ANy chance of you manually maintaining the generated skeleton? This
is what I'm going to have to do...

On 6/29/06, John Mani <jm...@comverge.com> wrote:
>
> Hi all
>
> Any comments on the below issue ? I'd expect this to be a common scenario
> .. so am I
> misunderstanding something ?
>
> thanx
> -john
>
> ________________________________
>
> From: John Mani [mailto:jmani@comverge.com]
> Sent: Tue 6/27/2006 6:53 PM
> To: axis-user@ws.apache.org
> Subject: WSDL2Java and one-way binding
>
>
> I'm using Axis 1.4 WSDL2Java to generate skeletons for a webservice from a
> WSDL doc.
>
> The source WSDL (generated by .NET) uses one-way binding - it just
> specifies a
> <wsdl:input> element, no <wsdl:output> element.
>
> However, the generated skeleton code seems to be including a response to
> the request.
> This is proven by checking the deployed skeleton's WSDL (deployed in
> tomcat, using
> the axis war) - it contains  <wsdl:input> and <WSDL:output> messages.
> Also, when
> I run the .NET client against the deployed skeleton, the client complaints
> about the
> unexpected entity body in the response.
>
> Any comments/help ?
>
> thanx
> -jm
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>

RE: WSDL2Java and one-way binding

Posted by John Mani <jm...@comverge.com>.

Hi all
 
Any comments on the below issue ? I'd expect this to be a common scenario .. so am I
misunderstanding something ?
 
thanx
-john

________________________________

From: John Mani [mailto:jmani@comverge.com]
Sent: Tue 6/27/2006 6:53 PM
To: axis-user@ws.apache.org
Subject: WSDL2Java and one-way binding


I'm using Axis 1.4 WSDL2Java to generate skeletons for a webservice from a WSDL doc.
 
The source WSDL (generated by .NET) uses one-way binding - it just specifies a 
<wsdl:input> element, no <wsdl:output> element.
 
However, the generated skeleton code seems to be including a response to the request.
This is proven by checking the deployed skeleton's WSDL (deployed in tomcat, using
the axis war) - it contains  <wsdl:input> and <WSDL:output> messages. Also, when
I run the .NET client against the deployed skeleton, the client complaints about the
unexpected entity body in the response.
 
Any comments/help ?
 
thanx
-jm

WSDL2Java and one-way binding

Posted by John Mani <jm...@comverge.com>.

I'm using Axis 1.4 WSDL2Java to generate skeletons for a webservice from a WSDL doc.
 
The source WSDL (generated by .NET) uses one-way binding - it just specifies a 
<wsdl:input> element, no <wsdl:output> element.
 
However, the generated skeleton code seems to be including a response to the request.
This is proven by checking the deployed skeleton's WSDL (deployed in tomcat, using
the axis war) - it contains  <wsdl:input> and <WSDL:output> messages. Also, when
I run the .NET client against the deployed skeleton, the client complaints about the
unexpected entity body in the response.
 
Any comments/help ?
 
thanx
-jm

Re: No such operation

Posted by Anne Thomas Manes <at...@gmail.com>.

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:bindingassociated 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 <um...@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 <at...@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 <um...@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 <at...@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 <um...@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
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: No such operation

Posted by Doug B <um...@gmail.com>.

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 <at...@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 <um...@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 <at...@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 <um...@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
> > > > >
> > > >
> > > >
> > >
> >
>

Re: No such operation

Posted by Anne Thomas Manes <at...@gmail.com>.

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 <um...@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 <at...@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 <um...@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 <at...@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 <um...@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
> > > >
> > >
> > >
> >
>

Re: No such operation

Posted by Doug B <um...@gmail.com>.

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 <at...@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 <um...@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 <um...@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 <at...@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 <um...@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
> > >
> >
> >
>

Re: No such operation

Posted by Anne Thomas Manes <at...@gmail.com>.

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 <um...@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 <um...@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 <at...@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 <um...@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
> >
>
>

Re: No such operation

Posted by Doug B <um...@gmail.com>.

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 <um...@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 <at...@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 <um...@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
>

Re: No such operation

Posted by Doug B <um...@gmail.com>.

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 <at...@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 <um...@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
> >
> >
> > On 6/26/06, Anne Thomas Manes < atmanes@gmail.com> wrote:
> > >
> > > Doug,
> > >
> > > "Wrapped" is a WSDL design convention that helps tools simulate an
> > > RPC-like programming interface. The WS-I BP doesn't address language binding
> > > issues, therefore "wrapped" versus "unwrapped" is out of scope for the WS-I
> > > BP.
> > >
> > > .NET generates "wrapped" interfaces by default. The JAX-RPC spec
> > > defines the "wrapped" convention for Java. I've also provided a summary of
> > > the convention here:
> > >
> > >
> > > http://atmanes.blogspot.com/2005/03/wrapped-documentliteral-convention.html
> > >
> > >
> > > Anne
> > >
> > > <snip>
> > >
> >

Re: No such operation

Posted by Anne Thomas Manes <at...@gmail.com>.

One more note to clarify. The problem is not with the WSDL. It's with the
service's configuration (WSDD). Just ask your customer to add the
information I specified in the first response to their WSDD, and it should
resolve the error. (They will have to add comparable entries for all
operations.)

In the future, I suggest you define your WSDLs using the wrapped convention.
It just makes it easier to interoperate. (The endpoints aren't required to
take advantage of the wrapped convention if they don't want to, but they
can't if you don't follow the convention.)

Anne

On 6/26/06, Anne Thomas Manes <at...@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 <um...@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
> >
> >
> > On 6/26/06, Anne Thomas Manes < atmanes@gmail.com> wrote:
> > >
> > > Doug,
> > >
> > > "Wrapped" is a WSDL design convention that helps tools simulate an
> > > RPC-like programming interface. The WS-I BP doesn't address language binding
> > > issues, therefore "wrapped" versus "unwrapped" is out of scope for the WS-I
> > > BP.
> > >
> > > .NET generates "wrapped" interfaces by default. The JAX-RPC spec
> > > defines the "wrapped" convention for Java. I've also provided a summary of
> > > the convention here:
> > >
> > >
> > > http://atmanes.blogspot.com/2005/03/wrapped-documentliteral-convention.html
> > >
> > >
> > > Anne
> > >
> > > On 6/25/06, Doug B < ummmmm22@gmail.com> wrote:
> > > >
> > > > Thanks, Anne.  That makes sense and looks like a simple solution.
> > > >
> > > > Best I can tell, the WS-I Basic Profile does not recommend or even
> > > > mention wrapped Document-Literal, does it?  Plus, from reading some older
> > > > Axis discussion threads, it sounds as if wrapped style may not even be
> > > > concretely defined, much less standardized.  Or is that no longer the case?
> > > > I guess I'm surprised that Axis defaults to what appears the non-standard
> > > > scenario rather than the standard one.
> > > >
> > > >
> > > > On 6/25/06, Anne Thomas Manes < atmanes@gmail.com> wrote:
> > > > >
> > > > > Axis figures out how to map an incoming request based on the QName
> > > > > of the child element of the SOAP Body. If you use RPC style or wrapped
> > > > > document style, then the name of that element will be the same as the
> > > > > operation name, and Axis can automatically figure out how to map the
> > > > > request. But if you use non-wrapped document style (as you are in this case)
> > > > > then you must explicitly tell Axis how to map the request using the
> > > > > <operation> tag in the WSDD. To map your input message
> > > > > <doi:SuccessfulRenewalRequest> to the service method
> > > > > SuccessfulRenewalOperation, you must specify the following:
> > > > >
> > > > >         <operation name="SuccessfulRenewalOperation"
> > > > >                    qname="doi:SuccessfulRenewalRequest"
> > > > >         />
> > > > >
> > > > >
> > > > > Anne
> > > > >
> > > > >
> > > > > On 6/25/06, Doug B <um...@gmail.com> wrote:
> > > > > >
> > > > > > We're doing a "contract-first" implementation with a customer,
> > > > > > using Document-Literal from handwritten WSDL and Schema.  We are the client
> > > > > > and our customer the server.  The Schema has elements (and types) defined
> > > > > > for each request and response message, and the WSDL uses single elements for
> > > > > > each message part, named "request" and "response", with single input and
> > > > > > output elements for the operations.
> > > > > >
> > > > > > We've used this same approach with a .NET customer and had no
> > > > > > issues.  However, this particular customer is using Axis (1.2beta 3 because of his particular version of JBoss) and it reports that it's
> > > > > > trying to call an operation whose name is actually the name of our request
> > > > > > element.  Doing a little digging, it almost looks like Axis has decided to
> > > > > > use something like wrapped style, which we're not using.
> > > > > >
> > > > > > Any ideas on the cause of this?  How we can resolve it?
> > > > > >
> > > > > > (I realize the customer's Axis is not current, and I'm going to
> > > > > > pursue with him whether he can update to at least the last release level of
> > > > > > 1.2, but I'm not sure that will make any difference.)
> > > > > >
> > > > > > Relevant excerpts from the definitions:
> > > > > > ...
> > > > > >
> > > > > > <xsd:element name="SuccessfulRenewalRequest" type="doi:SuccessfulRenewalRequestType"/>
> > > > > > <xsd:element name="SuccessfulRenewalResponse" type="doi:SuccessfulRenewalResponseType"/>
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > ...
> > > > > >
> > > > > > <wsdl:message name="SuccessfulRenewalRequestMessage">
> > > > > >   <wsdl:part name="request" element="doi:SuccessfulRenewalRequest"/>
> > > > > > </wsdl:message>
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > <wsdl:message name="SuccessfulRenewalResponseMessage">
> > > > > >
> > > > > >   <wsdl:part name="response" element="doi:SuccessfulRenewalResponse"/>
> > > > > > </wsdl:message>
> > > > > >
> > > > > > <wsdl:operation name="SuccessfulRenewalOperation">
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >   <wsdl:input message="tns:SuccessfulRenewalRequestMessage"/>
> > > > > >
> > > > > >   <wsdl:output message="tns:SuccessfulRenewalResponseMessage"/>
> > > > > > </wsdl:operation>
> > > > > > ...
> > > > > >
> > > > > > And from the messages (captured with TCPMon):
> > > > > >
> > > > > > SOAPAction: "**ns removed**/SuccessfulRenewalOperation"
> > > > > > Content-Length: 732
> > > > > >
> > > > > > <?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>
> > > > > >          <SuccessfulRenewalRequest
> > > > > > xsi:type="ns1:SuccessfulRenewalRequestType" xmlns="**removed**"
> > > > > > xmlns:ns1="**removed**">
> > > > > >            ...
> > > > > >             ** 6 sequence fields removed **
> > > > > >            ...
> > > > > >          </SuccessfulRenewalRequest>
> > > > > >       </soapenv:Body>
> > > > > >    </soapenv:Envelope>
> > > > > >
> > > > > > ...
> > > > > >
> > > > > > <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:Fault>
> > > > > >          <faultcode xmlns:ns1=" http://xml.apache.org/axis/
> > > > > > ">ns1:Client</faultcode>
> > > > > >          <faultstring>No such operation
> > > > > > 'SuccessfulRenewalRequest'</faultstring>
> > > > > >          <detail>
> > > > > >             <ns2:hostname xmlns:ns2="
> > > > > > http://xml.apache.org/axis/">**servername
> > > > > > removed**</ns2:hostname>
> > > > > >          </detail>
> > > > > >       </soapenv:Fault>
> > > > > >    </soapenv:Body></soapenv:Envelope>
> > > > > >
> > > > > > i.e. Axis appears to be using the main element in the Body, not
> > > > > > the SOAPAction, as the Operation name.
> > > > > >
> > > > > > Doug
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: No such operation

Posted by Anne Thomas Manes <at...@gmail.com>.

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 <um...@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
>
>
> On 6/26/06, Anne Thomas Manes <at...@gmail.com> wrote:
> >
> > Doug,
> >
> > "Wrapped" is a WSDL design convention that helps tools simulate an
> > RPC-like programming interface. The WS-I BP doesn't address language binding
> > issues, therefore "wrapped" versus "unwrapped" is out of scope for the WS-I
> > BP.
> >
> > .NET generates "wrapped" interfaces by default. The JAX-RPC spec defines
> > the "wrapped" convention for Java. I've also provided a summary of the
> > convention here:
> >
> >
> > http://atmanes.blogspot.com/2005/03/wrapped-documentliteral-convention.html
> >
> >
> > Anne
> >
> > On 6/25/06, Doug B < ummmmm22@gmail.com> wrote:
> > >
> > > Thanks, Anne.  That makes sense and looks like a simple solution.
> > >
> > > Best I can tell, the WS-I Basic Profile does not recommend or even
> > > mention wrapped Document-Literal, does it?  Plus, from reading some older
> > > Axis discussion threads, it sounds as if wrapped style may not even be
> > > concretely defined, much less standardized.  Or is that no longer the case?
> > > I guess I'm surprised that Axis defaults to what appears the non-standard
> > > scenario rather than the standard one.
> > >
> > >
> > > On 6/25/06, Anne Thomas Manes < atmanes@gmail.com> wrote:
> > > >
> > > > Axis figures out how to map an incoming request based on the QName
> > > > of the child element of the SOAP Body. If you use RPC style or wrapped
> > > > document style, then the name of that element will be the same as the
> > > > operation name, and Axis can automatically figure out how to map the
> > > > request. But if you use non-wrapped document style (as you are in this case)
> > > > then you must explicitly tell Axis how to map the request using the
> > > > <operation> tag in the WSDD. To map your input message
> > > > <doi:SuccessfulRenewalRequest> to the service method
> > > > SuccessfulRenewalOperation, you must specify the following:
> > > >
> > > >         <operation name="SuccessfulRenewalOperation"
> > > >                    qname="doi:SuccessfulRenewalRequest"
> > > >         />
> > > >
> > > >
> > > > Anne
> > > >
> > > >
> > > > On 6/25/06, Doug B <um...@gmail.com> wrote:
> > > > >
> > > > > We're doing a "contract-first" implementation with a customer,
> > > > > using Document-Literal from handwritten WSDL and Schema.  We are the client
> > > > > and our customer the server.  The Schema has elements (and types) defined
> > > > > for each request and response message, and the WSDL uses single elements for
> > > > > each message part, named "request" and "response", with single input and
> > > > > output elements for the operations.
> > > > >
> > > > > We've used this same approach with a .NET customer and had no
> > > > > issues.  However, this particular customer is using Axis (1.2 beta
> > > > > 3 because of his particular version of JBoss) and it reports that it's
> > > > > trying to call an operation whose name is actually the name of our request
> > > > > element.  Doing a little digging, it almost looks like Axis has decided to
> > > > > use something like wrapped style, which we're not using.
> > > > >
> > > > > Any ideas on the cause of this?  How we can resolve it?
> > > > >
> > > > > (I realize the customer's Axis is not current, and I'm going to
> > > > > pursue with him whether he can update to at least the last release level of
> > > > > 1.2, but I'm not sure that will make any difference.)
> > > > >
> > > > > Relevant excerpts from the definitions:
> > > > > ...
> > > > >
> > > > > <xsd:element name="SuccessfulRenewalRequest" type="doi:SuccessfulRenewalRequestType"/>
> > > > > <xsd:element name="SuccessfulRenewalResponse" type="doi:SuccessfulRenewalResponseType"/>
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ...
> > > > >
> > > > > <wsdl:message name="SuccessfulRenewalRequestMessage">
> > > > >   <wsdl:part name="request" element="doi:SuccessfulRenewalRequest"/>
> > > > > </wsdl:message>
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > <wsdl:message name="SuccessfulRenewalResponseMessage">
> > > > >
> > > > >   <wsdl:part name="response" element="doi:SuccessfulRenewalResponse"/>
> > > > > </wsdl:message>
> > > > >
> > > > > <wsdl:operation name="SuccessfulRenewalOperation">
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >   <wsdl:input message="tns:SuccessfulRenewalRequestMessage"/>
> > > > >
> > > > >   <wsdl:output message="tns:SuccessfulRenewalResponseMessage"/>
> > > > > </wsdl:operation>
> > > > > ...
> > > > >
> > > > > And from the messages (captured with TCPMon):
> > > > >
> > > > > SOAPAction: "**ns removed**/SuccessfulRenewalOperation"
> > > > > Content-Length: 732
> > > > >
> > > > > <?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>
> > > > >          <SuccessfulRenewalRequest
> > > > > xsi:type="ns1:SuccessfulRenewalRequestType" xmlns="**removed**"
> > > > > xmlns:ns1="**removed**">
> > > > >            ...
> > > > >             ** 6 sequence fields removed **
> > > > >            ...
> > > > >          </SuccessfulRenewalRequest>
> > > > >       </soapenv:Body>
> > > > >    </soapenv:Envelope>
> > > > >
> > > > > ...
> > > > >
> > > > > <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:Fault>
> > > > >          <faultcode xmlns:ns1=" http://xml.apache.org/axis/
> > > > > ">ns1:Client</faultcode>
> > > > >          <faultstring>No such operation
> > > > > 'SuccessfulRenewalRequest'</faultstring>
> > > > >          <detail>
> > > > >             <ns2:hostname xmlns:ns2=" http://xml.apache.org/axis/">**servername
> > > > > removed**</ns2:hostname>
> > > > >          </detail>
> > > > >       </soapenv:Fault>
> > > > >    </soapenv:Body></soapenv:Envelope>
> > > > >
> > > > > i.e. Axis appears to be using the main element in the Body, not
> > > > > the SOAPAction, as the Operation name.
> > > > >
> > > > > Doug
> > > > >
> > > >
> > > >
> > >
> >
>

Re: No such operation

Posted by Doug B <um...@gmail.com>.

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

On 6/26/06, Anne Thomas Manes <at...@gmail.com> wrote:
>
> Doug,
>
> "Wrapped" is a WSDL design convention that helps tools simulate an
> RPC-like programming interface. The WS-I BP doesn't address language binding
> issues, therefore "wrapped" versus "unwrapped" is out of scope for the WS-I
> BP.
>
> .NET generates "wrapped" interfaces by default. The JAX-RPC spec defines
> the "wrapped" convention for Java. I've also provided a summary of the
> convention here:
>
>
> http://atmanes.blogspot.com/2005/03/wrapped-documentliteral-convention.html
>
>
> Anne
>
> On 6/25/06, Doug B < ummmmm22@gmail.com> wrote:
> >
> > Thanks, Anne.  That makes sense and looks like a simple solution.
> >
> > Best I can tell, the WS-I Basic Profile does not recommend or even
> > mention wrapped Document-Literal, does it?  Plus, from reading some older
> > Axis discussion threads, it sounds as if wrapped style may not even be
> > concretely defined, much less standardized.  Or is that no longer the case?
> > I guess I'm surprised that Axis defaults to what appears the non-standard
> > scenario rather than the standard one.
> >
> >
> > On 6/25/06, Anne Thomas Manes < atmanes@gmail.com> wrote:
> > >
> > > Axis figures out how to map an incoming request based on the QName of
> > > the child element of the SOAP Body. If you use RPC style or wrapped document
> > > style, then the name of that element will be the same as the operation name,
> > > and Axis can automatically figure out how to map the request. But if you use
> > > non-wrapped document style (as you are in this case) then you must
> > > explicitly tell Axis how to map the request using the <operation> tag in the
> > > WSDD. To map your input message <doi:SuccessfulRenewalRequest> to the
> > > service method SuccessfulRenewalOperation, you must specify the following:
> > >
> > >         <operation name="SuccessfulRenewalOperation"
> > >                    qname="doi:SuccessfulRenewalRequest"
> > >         />
> > >
> > >
> > > Anne
> > >
> > >
> > > On 6/25/06, Doug B <um...@gmail.com> wrote:
> > > >
> > > > We're doing a "contract-first" implementation with a customer, using
> > > > Document-Literal from handwritten WSDL and Schema.  We are the client and
> > > > our customer the server.  The Schema has elements (and types) defined for
> > > > each request and response message, and the WSDL uses single elements for
> > > > each message part, named "request" and "response", with single input and
> > > > output elements for the operations.
> > > >
> > > > We've used this same approach with a .NET customer and had no
> > > > issues.  However, this particular customer is using Axis (1.2 beta 3
> > > > because of his particular version of JBoss) and it reports that it's trying
> > > > to call an operation whose name is actually the name of our request
> > > > element.  Doing a little digging, it almost looks like Axis has decided to
> > > > use something like wrapped style, which we're not using.
> > > >
> > > > Any ideas on the cause of this?  How we can resolve it?
> > > >
> > > > (I realize the customer's Axis is not current, and I'm going to
> > > > pursue with him whether he can update to at least the last release level of
> > > > 1.2, but I'm not sure that will make any difference.)
> > > >
> > > > Relevant excerpts from the definitions:
> > > > ...
> > > >
> > > > <xsd:element name="SuccessfulRenewalRequest" type="doi:SuccessfulRenewalRequestType"/>
> > > > <xsd:element name="SuccessfulRenewalResponse" type="doi:SuccessfulRenewalResponseType"/>
> > > >
> > > >
> > > >
> > > >
> > > > ...
> > > >
> > > > <wsdl:message name="SuccessfulRenewalRequestMessage">
> > > >   <wsdl:part name="request" element="doi:SuccessfulRenewalRequest"/>
> > > > </wsdl:message>
> > > >
> > > >
> > > >
> > > > <wsdl:message name="SuccessfulRenewalResponseMessage">
> > > >
> > > >   <wsdl:part name="response" element="doi:SuccessfulRenewalResponse"/>
> > > > </wsdl:message>
> > > >
> > > > <wsdl:operation name="SuccessfulRenewalOperation">
> > > >
> > > >
> > > >
> > > >   <wsdl:input message="tns:SuccessfulRenewalRequestMessage"/>
> > > >
> > > >   <wsdl:output message="tns:SuccessfulRenewalResponseMessage"/>
> > > > </wsdl:operation>
> > > > ...
> > > >
> > > > And from the messages (captured with TCPMon):
> > > >
> > > > SOAPAction: "**ns removed**/SuccessfulRenewalOperation"
> > > > Content-Length: 732
> > > >
> > > > <?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>
> > > >          <SuccessfulRenewalRequest
> > > > xsi:type="ns1:SuccessfulRenewalRequestType" xmlns="**removed**"
> > > > xmlns:ns1="**removed**">
> > > >            ...
> > > >             ** 6 sequence fields removed **
> > > >            ...
> > > >          </SuccessfulRenewalRequest>
> > > >       </soapenv:Body>
> > > >    </soapenv:Envelope>
> > > >
> > > > ...
> > > >
> > > > <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:Fault>
> > > >          <faultcode xmlns:ns1=" http://xml.apache.org/axis/
> > > > ">ns1:Client</faultcode>
> > > >          <faultstring>No such operation
> > > > 'SuccessfulRenewalRequest'</faultstring>
> > > >          <detail>
> > > >             <ns2:hostname xmlns:ns2=" http://xml.apache.org/axis/">**servername
> > > > removed**</ns2:hostname>
> > > >          </detail>
> > > >       </soapenv:Fault>
> > > >    </soapenv:Body></soapenv:Envelope>
> > > >
> > > > i.e. Axis appears to be using the main element in the Body, not the
> > > > SOAPAction, as the Operation name.
> > > >
> > > > Doug
> > > >
> > >
> > >
> >
>

Re: No such operation

Posted by Anne Thomas Manes <at...@gmail.com>.

Doug,

"Wrapped" is a WSDL design convention that helps tools simulate an RPC-like
programming interface. The WS-I BP doesn't address language binding issues,
therefore "wrapped" versus "unwrapped" is out of scope for the WS-I BP.

.NET generates "wrapped" interfaces by default. The JAX-RPC spec defines the
"wrapped" convention for Java. I've also provided a summary of the
convention here:

http://atmanes.blogspot.com/2005/03/wrapped-documentliteral-convention.html

Anne

On 6/25/06, Doug B <um...@gmail.com> wrote:
>
> Thanks, Anne.  That makes sense and looks like a simple solution.
>
> Best I can tell, the WS-I Basic Profile does not recommend or even mention
> wrapped Document-Literal, does it?  Plus, from reading some older Axis
> discussion threads, it sounds as if wrapped style may not even be concretely
> defined, much less standardized.  Or is that no longer the case?  I guess
> I'm surprised that Axis defaults to what appears the non-standard scenario
> rather than the standard one.
>
>
> On 6/25/06, Anne Thomas Manes <at...@gmail.com> wrote:
> >
> > Axis figures out how to map an incoming request based on the QName of
> > the child element of the SOAP Body. If you use RPC style or wrapped document
> > style, then the name of that element will be the same as the operation name,
> > and Axis can automatically figure out how to map the request. But if you use
> > non-wrapped document style (as you are in this case) then you must
> > explicitly tell Axis how to map the request using the <operation> tag in the
> > WSDD. To map your input message <doi:SuccessfulRenewalRequest> to the
> > service method SuccessfulRenewalOperation, you must specify the following:
> >
> >         <operation name="SuccessfulRenewalOperation"
> >                    qname="doi:SuccessfulRenewalRequest"
> >         />
> >
> >
> > Anne
> >
> >
> > On 6/25/06, Doug B <um...@gmail.com> wrote:
> > >
> > > We're doing a "contract-first" implementation with a customer, using
> > > Document-Literal from handwritten WSDL and Schema.  We are the client and
> > > our customer the server.  The Schema has elements (and types) defined for
> > > each request and response message, and the WSDL uses single elements for
> > > each message part, named "request" and "response", with single input and
> > > output elements for the operations.
> > >
> > > We've used this same approach with a .NET customer and had no issues.
> > > However, this particular customer is using Axis (1.2 beta 3 because of
> > > his particular version of JBoss) and it reports that it's trying to call an
> > > operation whose name is actually the name of our request element.  Doing a
> > > little digging, it almost looks like Axis has decided to use something like
> > > wrapped style, which we're not using.
> > >
> > > Any ideas on the cause of this?  How we can resolve it?
> > >
> > > (I realize the customer's Axis is not current, and I'm going to pursue
> > > with him whether he can update to at least the last release level of
> > > 1.2, but I'm not sure that will make any difference.)
> > >
> > > Relevant excerpts from the definitions:
> > > ...
> > >
> > > <xsd:element name="SuccessfulRenewalRequest" type="doi:SuccessfulRenewalRequestType"/>
> > > <xsd:element name="SuccessfulRenewalResponse" type="doi:SuccessfulRenewalResponseType"/>
> > >
> > >
> > >
> > > ...
> > >
> > > <wsdl:message name="SuccessfulRenewalRequestMessage">
> > >   <wsdl:part name="request" element="doi:SuccessfulRenewalRequest"/>
> > > </wsdl:message>
> > >
> > >
> > > <wsdl:message name="SuccessfulRenewalResponseMessage">
> > >
> > >   <wsdl:part name="response" element="doi:SuccessfulRenewalResponse"/>
> > > </wsdl:message>
> > >
> > > <wsdl:operation name="SuccessfulRenewalOperation">
> > >
> > >
> > >   <wsdl:input message="tns:SuccessfulRenewalRequestMessage"/>
> > >
> > >   <wsdl:output message="tns:SuccessfulRenewalResponseMessage"/>
> > > </wsdl:operation>
> > > ...
> > >
> > > And from the messages (captured with TCPMon):
> > >
> > > SOAPAction: "**ns removed**/SuccessfulRenewalOperation"
> > > Content-Length: 732
> > >
> > > <?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>
> > >          <SuccessfulRenewalRequest
> > > xsi:type="ns1:SuccessfulRenewalRequestType" xmlns="**removed**"
> > > xmlns:ns1="**removed**">
> > >            ...
> > >             ** 6 sequence fields removed **
> > >            ...
> > >          </SuccessfulRenewalRequest>
> > >       </soapenv:Body>
> > >    </soapenv:Envelope>
> > >
> > > ...
> > >
> > > <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:Fault>
> > >          <faultcode xmlns:ns1=" http://xml.apache.org/axis/
> > > ">ns1:Client</faultcode>
> > >          <faultstring>No such operation
> > > 'SuccessfulRenewalRequest'</faultstring>
> > >          <detail>
> > >             <ns2:hostname xmlns:ns2=" http://xml.apache.org/axis/">**servername
> > > removed**</ns2:hostname>
> > >          </detail>
> > >       </soapenv:Fault>
> > >    </soapenv:Body></soapenv:Envelope>
> > >
> > > i.e. Axis appears to be using the main element in the Body, not the
> > > SOAPAction, as the Operation name.
> > >
> > > Doug
> > >
> >
> >
>

Re: No such operation

Posted by Doug B <um...@gmail.com>.

Thanks, Anne.  That makes sense and looks like a simple solution.

Best I can tell, the WS-I Basic Profile does not recommend or even mention
wrapped Document-Literal, does it?  Plus, from reading some older Axis
discussion threads, it sounds as if wrapped style may not even be concretely
defined, much less standardized.  Or is that no longer the case?  I guess
I'm surprised that Axis defaults to what appears the non-standard scenario
rather than the standard one.

On 6/25/06, Anne Thomas Manes <at...@gmail.com> wrote:
>
> Axis figures out how to map an incoming request based on the QName of the
> child element of the SOAP Body. If you use RPC style or wrapped document
> style, then the name of that element will be the same as the operation name,
> and Axis can automatically figure out how to map the request. But if you use
> non-wrapped document style (as you are in this case) then you must
> explicitly tell Axis how to map the request using the <operation> tag in the
> WSDD. To map your input message <doi:SuccessfulRenewalRequest> to the
> service method SuccessfulRenewalOperation, you must specify the following:
>
>         <operation name="SuccessfulRenewalOperation"
>                    qname="doi:SuccessfulRenewalRequest"
>         />
>
>
> Anne
>
>
> On 6/25/06, Doug B <um...@gmail.com> wrote:
> >
> > We're doing a "contract-first" implementation with a customer, using
> > Document-Literal from handwritten WSDL and Schema.  We are the client and
> > our customer the server.  The Schema has elements (and types) defined for
> > each request and response message, and the WSDL uses single elements for
> > each message part, named "request" and "response", with single input and
> > output elements for the operations.
> >
> > We've used this same approach with a .NET customer and had no issues.
> > However, this particular customer is using Axis (1.2 beta 3 because of
> > his particular version of JBoss) and it reports that it's trying to call an
> > operation whose name is actually the name of our request element.  Doing a
> > little digging, it almost looks like Axis has decided to use something like
> > wrapped style, which we're not using.
> >
> > Any ideas on the cause of this?  How we can resolve it?
> >
> > (I realize the customer's Axis is not current, and I'm going to pursue
> > with him whether he can update to at least the last release level of 1.2,
> > but I'm not sure that will make any difference.)
> >
> > Relevant excerpts from the definitions:
> > ...
> >
> > <xsd:element name="SuccessfulRenewalRequest" type="doi:SuccessfulRenewalRequestType"/>
> > <xsd:element name="SuccessfulRenewalResponse" type="doi:SuccessfulRenewalResponseType"/>
> >
> >
> > ...
> >
> > <wsdl:message name="SuccessfulRenewalRequestMessage">
> >   <wsdl:part name="request" element="doi:SuccessfulRenewalRequest"/>
> > </wsdl:message>
> >
> > <wsdl:message name="SuccessfulRenewalResponseMessage">
> >
> >   <wsdl:part name="response" element="doi:SuccessfulRenewalResponse"/>
> > </wsdl:message>
> >
> > <wsdl:operation name="SuccessfulRenewalOperation">
> >
> >   <wsdl:input message="tns:SuccessfulRenewalRequestMessage"/>
> >
> >   <wsdl:output message="tns:SuccessfulRenewalResponseMessage"/>
> > </wsdl:operation>
> > ...
> >
> > And from the messages (captured with TCPMon):
> >
> > SOAPAction: "**ns removed**/SuccessfulRenewalOperation"
> > Content-Length: 732
> >
> > <?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>
> >          <SuccessfulRenewalRequest
> > xsi:type="ns1:SuccessfulRenewalRequestType" xmlns="**removed**"
> > xmlns:ns1="**removed**">
> >            ...
> >             ** 6 sequence fields removed **
> >            ...
> >          </SuccessfulRenewalRequest>
> >       </soapenv:Body>
> >    </soapenv:Envelope>
> >
> > ...
> >
> > <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:Fault>
> >          <faultcode xmlns:ns1=" http://xml.apache.org/axis/
> > ">ns1:Client</faultcode>
> >          <faultstring>No such operation
> > 'SuccessfulRenewalRequest'</faultstring>
> >          <detail>
> >             <ns2:hostname xmlns:ns2=" http://xml.apache.org/axis/">**servername
> > removed**</ns2:hostname>
> >          </detail>
> >       </soapenv:Fault>
> >    </soapenv:Body></soapenv:Envelope>
> >
> > i.e. Axis appears to be using the main element in the Body, not the
> > SOAPAction, as the Operation name.
> >
> > Doug
> >
>
>

Re: No such operation

Posted by Anne Thomas Manes <at...@gmail.com>.

Axis figures out how to map an incoming request based on the QName of the
child element of the SOAP Body. If you use RPC style or wrapped document
style, then the name of that element will be the same as the operation name,
and Axis can automatically figure out how to map the request. But if you use
non-wrapped document style (as you are in this case) then you must
explicitly tell Axis how to map the request using the <operation> tag in the
WSDD. To map your input message <doi:SuccessfulRenewalRequest> to the
service method SuccessfulRenewalOperation, you must specify the following:

        <operation name="SuccessfulRenewalOperation"
                   qname="doi:SuccessfulRenewalRequest"
        />


Anne

On 6/25/06, Doug B <um...@gmail.com> wrote:
>
> We're doing a "contract-first" implementation with a customer, using
> Document-Literal from handwritten WSDL and Schema.  We are the client and
> our customer the server.  The Schema has elements (and types) defined for
> each request and response message, and the WSDL uses single elements for
> each message part, named "request" and "response", with single input and
> output elements for the operations.
>
> We've used this same approach with a .NET customer and had no issues.
> However, this particular customer is using Axis (1.2 beta 3 because of his
> particular version of JBoss) and it reports that it's trying to call an
> operation whose name is actually the name of our request element.  Doing a
> little digging, it almost looks like Axis has decided to use something like
> wrapped style, which we're not using.
>
> Any ideas on the cause of this?  How we can resolve it?
>
> (I realize the customer's Axis is not current, and I'm going to pursue
> with him whether he can update to at least the last release level of 1.2,
> but I'm not sure that will make any difference.)
>
> Relevant excerpts from the definitions:
> ...
>
> <xsd:element name="SuccessfulRenewalRequest" type="doi:SuccessfulRenewalRequestType"/>
> <xsd:element name="SuccessfulRenewalResponse" type="doi:SuccessfulRenewalResponseType"/>
>
> ...
>
> <wsdl:message name="SuccessfulRenewalRequestMessage">
>   <wsdl:part name="request" element="doi:SuccessfulRenewalRequest"/>
> </wsdl:message>
> <wsdl:message name="SuccessfulRenewalResponseMessage">
>
>   <wsdl:part name="response" element="doi:SuccessfulRenewalResponse"/>
> </wsdl:message>
>
> <wsdl:operation name="SuccessfulRenewalOperation">
>   <wsdl:input message="tns:SuccessfulRenewalRequestMessage"/>
>
>   <wsdl:output message="tns:SuccessfulRenewalResponseMessage"/>
> </wsdl:operation>
> ...
>
> And from the messages (captured with TCPMon):
>
> SOAPAction: "**ns removed**/SuccessfulRenewalOperation"
> Content-Length: 732
>
> <?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>
>          <SuccessfulRenewalRequest
> xsi:type="ns1:SuccessfulRenewalRequestType" xmlns="**removed**"
> xmlns:ns1="**removed**">
>            ...
>             ** 6 sequence fields removed **
>            ...
>          </SuccessfulRenewalRequest>
>       </soapenv:Body>
>    </soapenv:Envelope>
>
> ...
>
> <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:Fault>
>          <faultcode xmlns:ns1=" http://xml.apache.org/axis/
> ">ns1:Client</faultcode>
>          <faultstring>No such operation
> 'SuccessfulRenewalRequest'</faultstring>
>          <detail>
>             <ns2:hostname xmlns:ns2=" http://xml.apache.org/axis/">**servername
> removed**</ns2:hostname>
>          </detail>
>       </soapenv:Fault>
>    </soapenv:Body></soapenv:Envelope>
>
> i.e. Axis appears to be using the main element in the Body, not the
> SOAPAction, as the Operation name.
>
> Doug
>