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.
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.
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.
DougOn 6/27/06, Anne Thomas Manes < [EMAIL PROTECTED]> 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.
AnneOn 6/27/06, Doug B < [EMAIL PROTECTED]> 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 :-)
DougOn 6/27/06, Anne Thomas Manes < [EMAIL PROTECTED]> 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.
AnneOn 6/26/06, Doug B < [EMAIL PROTECTED]> 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.
DougOn 6/26/06, Doug B <[EMAIL PROTECTED]> 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.)
DougOn 6/26/06, Anne Thomas Manes <[EMAIL PROTECTED]> 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.
AnneOn 6/26/06, Doug B <[EMAIL PROTECTED]> 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
