It's a convention used by .NET to add the extra layer of wrapping on the response.
On Thu, 13 Jan 2005 10:55:13 +0900, Bill Keese <[EMAIL PROTECTED]> wrote: > Thanks for the correction! It makes sense. (It also partially addresses > the other question I recently sent out.) Until the Axis bug gets fixed I > guess I should modify the WSDL file to match Axis' output? > > Also, could you tell me why, for example, the webservice > http://ws2.serviceobjects.net/nw/namewizard.asmx?WSDL embeds a > <getNameInfoResult> inside of a <getNameInfoResponse>? It seems like only > one of the two tags is necessary. Is it unnecessary overhead, or is it > something to make certain client tools happy? > > > Bill > > Anne Thomas Manes wrote: > Clarification: > Bug: In document/literal mode, Axis generate a <methodNameReturn> tag > when writing out the return value; it shouldn't. That tag only makes sense > in wrapped/literal mode. (This is what Ann was saying.) Axis should > generate a <methodNameReturn> tag only when using RPC style. It should not > generate the tag when using either wrapped or document style. In both cases, > the child element of the SOAP Body should be the element specified in the > response message part. For example, if the response message is defined > as: <wsdl:message name="methodResponse"> <wsdl:part name="parameters" > element="tns:foo"/> </wsdl:message> then the response message for either > wrapped or document style should be: <s:Body> <tns:foo.../> </s:Body> - > Anne On Wed, 12 Jan 2005 09:38:49 +0900, Bill > Keese <[EMAIL PROTECTED]> wrote: > OK, I think I understand what's going on now. There is both a bug and > a "missing feature". Bug: In document/literal mode, Axis generate a > <methodNameReturn> tag when writing out the return value; it shouldn't. That > tag only makes sense in wrapped/literal mode. (This is what Ann was > saying.) Missing feature: Axis obeys the specifications in the WSDL file, > but you have to manually call wsdl2java to generate the deploy.wsdd. (This > is what Michael was saying.) However, I would like a feature where > Axis automatically parses and obeys the WSDL file, without manually > calling wsdl2java. Bill -----Message d'origine----- De : Michael > Schuerig > [mailto:[EMAIL PROTECTED] Envoyé : mardi 11 janvier 2005 11:51 À : > [EMAIL PROTECTED] Objet : Re: Document/Literal : bad part name in > axis > server response On Tuesday 11 January 2005 07:26, Ephemeris Lappis wrote: > I don't use wsdl2java. I had it the wrong way around and confused the > java2wsdl from your original message with wsdl2java. > In Jonas, using the new (not so new) ejb 2.1 service endpoint features, i > just provide the wsdl (that is generated from the java endpoint > interface), > and the ejb and webservices descriptors (for the ejb deployment). At > assembly time, Jonas produces the java stubs, the whole web application as > a > war with a limited wsdd descriptor. At deployment time, Jonas merges the > war's wsdd file with the full platform's one to expose the web service > endpoint. This is the wsdd file : Presumably the following is happening: > At > assembly time Jonas uses wsdl2java to generate, among other things, a > deploy.wsdd. At deployment time, Jonas uses the Axis AdminClient to merge > this deploy.wsdd into Axis' server-config.wsdd. Do you know if this is > correct? > <?xml version="1.0" encoding="UTF-8"?> <deployment > xmlns="http://xml.apache.org/axis/wsdd/"; [snip] > </deployment> There are no operation elements in that WSDD. Without them, > Axis won't use the names and types you intended in the input and output > messages. > From my point of view, Axis was expected to use the given wsdl file to > handle client requests according to the descriptor it generated itself... > Well, Axis (at least as of 1.2RC) does that. Not directly, though. You > need > to process your WSDL with wsdl2java and among other things, you get a > deploy.wsdd with names, types and namespaces specified for operations. > Also, > the deployScope can be specified. I may be mistaken and I can't claim that > Axis is doing everything right, but the problem in your case appears to be > one of integration where the Jonas installation doesn't make full use of > what Axis offers. I don't know Jonas, thus I can't say whether this is a > genuine limitation of the respective Jonas version or a shortcoming of the > deployment. Michael -- Michael Schuerig Contests between male toads over > females are mailto:[EMAIL PROTECTED] often settled by the depth of the > croak. http://www.schuerig.de/michael/ --John Maynard Smith
