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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
