Hi Nirmal,
Thanks very much for this explanation. Does it also contain the essentials
of the answers to the questions in
http://marc.theaimsgroup.com/?t=104190341000002&r=1&w=2
(subject: (de)serializers for message parts specified by elements, rather
than types)? I neglected to mention in that message that I was using wsif
and consuming web services dynamically (as in the DynamicInvoker example,
extended to permit complex types in input and output).
My interpretation of your explanation is that custom serializers are not
needed in the doc/lit case -- you simply set each input part to an Element
containing all the necessary content, and no xsi:type is needed (e.g. if the
type for the element is anonymous). I still don't see how you would
deserialize a response of this sort, unless you specified that you just
wanted an Element for the return type and let your application code wrap it
appropriately later.
Jeff
----- Original Message -----
From: Nirmal Mukhi
To: [EMAIL PROTECTED]
Sent: Wednesday, January 08, 2003 10:34 AM
Subject: Re: [wsif] zip2geo sample questions
Hello Rhett,
This "unwrapped" style is a convenience that is supported in the Axis
provider. The more general way to write the client code would be to use an
element that wraps everything. You would then have an input message with one
part (an element), that can be populated programatically using the DOM API
or from an XML file, as follows:
// create the input, output and fault messages associated with this
operation
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
DocumentBuilder db = dbf.newDocumentBuilder();
// at this point if you want to read the XML data from a file you
could
// do something like
// Document doc = db.parse (new InputSource (new
FileReader(..)));
Document document = db.newDocument();
// create element according to what is reqd by service, as specified
in WSDL
Element topLevel =
document.createElementNS("http://ws.cdyne.com","GetLatLong";);
document.appendChild(topLevel);
Element zip = document.createElement("zipcode");
zip.setNodeValue(args[1]);
Element license = document.createElement("LicenseKey");
license.setNodeValue("");
topLevel.appendChild(zip);
topLevel.appendChild(license);
WSIFMessage input = operation.createInputMessage();
WSIFMessage output = operation.createOutputMessage();
WSIFMessage fault = operation.createFaultMessage();
// populate the input message
input.setObjectPart("parameters",topLevel);
// do the invocation
if (operation.executeRequestResponseOperation(input, output, fault))
{
// invocation succeeded, extract information from output
// message
Element retValue = (Element) output.getObjectPart("parameters");
System.out.println("Got return value "+retValue);
Replace the appropriate code in the current sample client (under
java/samples/complexsoap/client/dynamic/Run.java) with this and you should
be able to get it to work.
Note that when you use wrapped style as above, the return value will also
have just one part (an element), as specified by the WSDL.
Nirmal.
[EMAIL PROTECTED]
01/08/2003 11:47 AM
Please respond to axis-user
To: [EMAIL PROTECTED]
cc:
Subject: [wsif] zip2geo sample questions
In the WSDL for the Zip2Geo sample, the Message "GetLatLongSoapIn" contains
a single part of "parameters" which references the element "GetLatLong"
The sample code that invokes an operation using this message, the schema is
unwrapped and two input parts are being set vs. the single part that is
specified in the WSDL document. Also, this appears to be the case only
when style="document" and use="literal". Does anyone know the reasoning
behind this, i.e., the unwrapping of the element reference? Also, what
happens is the element references a sufficiently complexType whereby the
complexType is several layers deep and primitive types exist at each level?
Is a input part then required for each of those primitives?
Thanks much.
Rhett DeWall
Sybase Inc.
3665 Discovery Drive
Boulder, CO 80303
303/413-4163
