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