Axis 1.4: document/literal wrapped style is missing operation name
 

Hi,*
*
i*have*a*WSDL*which*is*built*up*in*document*literal/wrapped*style.*Axis**
successfully*builds*a*client*from*this*(using*wsdl2java).*However,*when**
performing*a*call*from*that*client,*the*operation*name*is*not*set*anywhere,*so**
the*server*does*not*know*which*operation*to*call.**
*
I*have*this*operation:*
*
<wsdl:operation*name="search">*
<wsdl:input*name="searchRequest"*
message="tns:searchRequest"*/>*
<wsdl:output*name="searchResponse"*
message="tns:searchResponse"*/>*
</wsdl:operation>*
*
I*got*a*message*like*this:*
*
<wsdl:message*name="searchRequest">*
<wsdl:part*name="parameters"*element="tns:search"></wsdl:part>*
</wsdl:message>*
*
the*element*inside*that*message*has*the*same*name*as*the*operation*("search")**
and*the*part*is*named*"parameters".*So*this*qualifies*as*document/literal**
unwrapped*style.*
*
Referrring*to*the*search*element:*
*
<xsd:element*name="search"*type="tns:search"*/>*
*
Referring*to*the*search*complex*type:*
*
<xsd:complexType*name="search">*
<xsd:sequence>*
<xsd:element*name="territoryCode"*
type="domain:Territory"*/>*
<xsd:element*minOccurs="0"*name="text"*
nillable="true"*type="xsd:string"*/>*
<xsd:element*minOccurs="0"*name="artistId"*
nillable="true"*type="xsd:string"*/>*
<xsd:element*minOccurs="0"*name="navigatorFilter"*
nillable="true"*type="domain:NavigatorFilter"*/>*
<xsd:element*minOccurs="0"*name="maxResults"*
type="xsd:int"*/>*
</xsd:sequence>*
</xsd:complexType>*
*
So*far*so*good.*Now*axis*has*a*special*treatment*for*this*kind*of*style*as*it**
unwraps*the*parameters*in*the*generated*java*code.*the*generated*signature*looks**
like*this:*
*
*
***public*SearchAnswer*search(String*territoryCode,*String*text,*String**
artistId,*NavigatorFilter*navigatorFilter,*Integer*maxResults)*throws**
java.rmi.RemoteException;*
*
Now*when*i*call*this,*axis*issues*the*following*XML*to*the*server:*
*
*
<?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>*
**<territoryCode*xmlns="http://webservice.musicshop.mycompany.de">DE
territoryCode>*
**<text*xmlns="http://webservice.musicshop.p3gw.mycompany.de">All*this*Time
text>*
**<artistId*xsi:nil="true"*xmlns="http://*
webservice.musicshop.p3gw.mycompany.de"/>*
**<navigatorFilter*xmlns="http://webservice.musicshop.p3gw.mycompany.de">*
***<ns1:navigatorId*xmlns:ns1="http://webservice.anothercompany.de/partner/*
domain">1</ns1:navigatorId>*
***<ns2:navigatorItemId*xmlns:ns2="http://webservice.anothercompany.de/partner/*
domain">1</ns2:navigatorItemId>*
**</navigatorFilter>*
**<maxResults*xmlns="http://webservice.musicshop.p3gw.mycompany.de">10
maxResults>*
*</soapenv:Body>*
</soapenv:Envelope>*
*
*
So*the*parameters*are*still*unwrapped,*there*is*no*enclosing*body*root*element**
named*"search"*as*i*would*have*expected.*Also*the*SoapAction*header*is*set*to**
"".*Therefore*the*server*has*no*way*of*finding*out*which*operation*I*want*to**
call.*
*
Is*this*some*bug*in*Axis*or*am*I*doign*something*wrong*here?

Any*help*is*greatly*appreciated.

Best*regards,
Jan

Re: Axis 1.4: document/literal wrapped style is missing operation name
 

Jan wrote:
> Hi,
>
> i have a WSDL which is built up in document literal/wrapped style.
> Axis successfully builds a client from this (using wsdl2java).
> However, when performing a call from that client, the operation name
> is not set anywhere, so the server does not know which operation to
> call.
> I have this operation:
>
> <wsdl:operation name="search">
> <wsdl:input name="searchRequest"
> message="tns:searchRequest" />
> <wsdl:output name="searchResponse"
> message="tns:searchResponse" />
> </wsdl:operation>
>
> I got a message like this:
>
> <wsdl:message name="searchRequest">
> <wsdl:part name="parameters" element="tns:search"></wsdl:part>
> </wsdl:message>
>
> the element inside that message has the same name as the operation
> ("search") and the part is named "parameters". So this qualifies as
> document/literal unwrapped style.
>
> Referrring to the search element:
>
> <xsd:element name="search" type="tns:search" />
>
> Referring to the search complex type:
>
> <xsd:complexType name="search">
> <xsd:sequence>
> <xsd:element name="territoryCode"
> type="domain:Territory" />
> <xsd:element minOccurs="0" name="text"
> nillable="true" type="xsd:string" />
> <xsd:element minOccurs="0" name="artistId"
> nillable="true" type="xsd:string" />
> <xsd:element minOccurs="0" name="navigatorFilter"
> nillable="true" type="domain:NavigatorFilter" />
> <xsd:element minOccurs="0" name="maxResults"
> type="xsd:int" />
> </xsd:sequence>
> </xsd:complexType>
>
> So far so good. Now axis has a special treatment for this kind of
> style as it unwraps the parameters in the generated java code. the
> generated signature looks like this:
>
>
> public SearchAnswer search(String territoryCode, String text, String
> artistId, NavigatorFilter navigatorFilter, Integer maxResults)
> throws
> java.rmi.RemoteException;
>
> Now when i call this, axis issues the following XML to the server:
>
>
> <?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>
> <territoryCode xmlns="http://webservice.musicshop.mycompany.de">DE
> territoryCode>
> <text xmlns="http://webservice.musicshop.p3gw.mycompany.de">All this
> Time text>
> <artistId xsi:nil="true" xmlns="http://
> webservice.musicshop.p3gw.mycompany.de"/>
> <navigatorFilter
> xmlns="http://webservice.musicshop.p3gw.mycompany.de">
> <ns1:navigatorId
> xmlns:ns1="http://webservice.anothercompany.de/partner/
> domain">1</ns1:navigatorId> <ns2:navigatorItemId
> xmlns:ns2="http://webservice.anothercompany.de/partner/
> domain">1</ns2:navigatorItemId> </navigatorFilter> <maxResults
> xmlns="http://webservice.musicshop.p3gw.mycompany.de">10 maxResults>
> </soapenv:Body>
> </soapenv:Envelope>
>
>
> So the parameters are still unwrapped, there is no enclosing body
> root element named "search" as i would have expected. Also the
> SoapAction header is set to "". Therefore the server has no way of
> finding out which operation I want to call.
>
> Is this some bug in Axis or am I doign something wrong here?

In document literal style, the body of the request is described
precisely by its schema. The operatiion name is added and the
parameters wrapped in rpc literal style.

Re: Axis 1.4: document/literal wrapped style is missing operation name
 

On 2008-08-26 18:53:35 +0200, "Mike Schilling"
<mscottschilling@hotmail.com> said:
> In document literal style, the body of the request is described
> precisely by its schema. The operatiion name is added and the
> parameters wrapped in rpc literal style.


Mike,

I'm not completely sure on how to interpret your post. Are you saying I
did something wrong or are you saying that there is a bug in Axis?

Jan

Re: Axis 1.4: document/literal wrapped style is missing operation name
 

Jan Thomä wrote:
> On 2008-08-26 18:53:35 +0200, "Mike Schilling"
> <mscottschilling@hotmail.com> said:
>> In document literal style, the body of the request is described
>> precisely by its schema. The operatiion name is added and the
>> parameters wrapped in rpc literal style.
>
>
> Mike,
>
> I'm not completely sure on how to interpret your post. Are you saying
> I did something wrong or are you saying that there is a bug in Axis?

I'm saying that Axis is correctly interpreting the WSDL you've given it. If
you want to see the method name appear in the message, use rpc/literal
instead of document/literal.

Re: Axis 1.4: document/literal wrapped style is missing operation name
 

On 2008-08-26 21:56:21 +0200, "Mike Schilling"
<mscottschilling@hotmail.com> said:

> Jan Thomä wrote:
>> On 2008-08-26 18:53:35 +0200, "Mike Schilling"
>> <mscottschilling@hotmail.com> said:
>>> In document literal style, the body of the request is described
>>> precisely by its schema. The operatiion name is added and the
>>> parameters wrapped in rpc literal style.
>>
>>
>> Mike,
>>
>> I'm not completely sure on how to interpret your post. Are you saying
>> I did something wrong or are you saying that there is a bug in Axis?
>
> I'm saying that Axis is correctly interpreting the WSDL you've given it. If
> you want to see the method name appear in the message, use rpc/literal
> instead of document/literal.

Well,

how should the server then know which method is invoked, when axis is
not doing one of these three things:

Wrap the body in a tag named like the method
OR Set the SoapAction header to something meaningful (preferably not "")
OR Add the method's name to the POST url to which the request is posted

Axis does none of these, so the server cannot possibly find out which
method is to be invoked. If you say this is correct behaviour, then
what good is document/literal at all, when you cannot use it to invoke
service methods? How should one use document/literal style then?

I think there might be two reasons why this is not working:

Something is missing in the WSDL
OR Axis has some kind of buggy behaviour.

Any insights?

Best regards,
Jan

Re: Axis 1.4: document/literal wrapped style is missing operation name
 

Jan Thomä wrote:
> On 2008-08-26 21:56:21 +0200, "Mike Schilling"
> <mscottschilling@hotmail.com> said:
>
>> Jan Thomä wrote:
>>> On 2008-08-26 18:53:35 +0200, "Mike Schilling"
>>> <mscottschilling@hotmail.com> said:
>>>> In document literal style, the body of the request is described
>>>> precisely by its schema. The operatiion name is added and the
>>>> parameters wrapped in rpc literal style.
>>>
>>>
>>> Mike,
>>>
>>> I'm not completely sure on how to interpret your post. Are you
>>> saying I did something wrong or are you saying that there is a bug
>>> in Axis?
>>
>> I'm saying that Axis is correctly interpreting the WSDL you've
>> given
>> it. If you want to see the method name appear in the message, use
>> rpc/literal instead of document/literal.
>
> Well,
>
> how should the server then know which method is invoked, when axis
> is
> not doing one of these three things:
>
> Wrap the body in a tag named like the method
> OR Set the SoapAction header to something meaningful (preferably
> not
> "") OR Add the method's name to the POST url to which the request
> is
> posted

If the various request messages received by that service are unique,
it can distinguish them. If not, you're in trouble. :-)

>
> Axis does none of these, so the server cannot possibly find out
> which
> method is to be invoked. If you say this is correct behaviour, then
> what good is document/literal at all, when you cannot use it to
> invoke
> service methods? How should one use document/literal style then?
>
> I think there might be two reasons why this is not working:
>
> Something is missing in the WSDL
> OR Axis has some kind of buggy behaviour.
>
> Any insights?

Yes. I've explained it to you. Feel free to read the WSDL and SOAP
specs if you want more details.

Re: Axis 1.4: document/literal wrapped style is missing operation name
 

Mike,
>>>> On 2008-08-26 18:53:35 +0200, "Mike Schilling"
>>>> <mscottschilling@hotmail.com> said:
>>>>> In document literal style, the body of the request is described
>>>>> precisely by its schema. The operatiion name is added and the
>>>>> parameters wrapped in rpc literal style.

This would mean, that there must not be two operations having the same
parameters because otherwise the service would be ambigous. This would
be a very major limitation in my opinion. Just think of something like:

getFolderByName(String)
getFileByName(String)

If you are correct, then you cannot realize this functionality using a
document/literal style, as since the method name gets lost, you cannot
determine which method to be called. I am not sure if it really works
and should work that way as i think it would break most of the services
out there today.

> Yes. I've explained it to you. Feel free to read the WSDL and SOAP
> specs if you want more details.

I will do this once i find the time, so i can find out how things are
intended to be.

Regarding the problem at hand, i found out that adding the --noWrap
option to wsd2ljava actually does the trick and lets axis create a
working soap client. So for now I assume this is some kind of Axis
idiosyncracy, maybe i find the time to try another framework later on
and see if this works out better.

Thanks for your help and best regards,
Jan

Re: Axis 1.4: document/literal wrapped style is missing operation name
 

Jan Thomä wrote:
> Mike,
>>>>> On 2008-08-26 18:53:35 +0200, "Mike Schilling"
>>>>> <mscottschilling@hotmail.com> said:
>>>>>> In document literal style, the body of the request is described
>>>>>> precisely by its schema. The operatiion name is added and the
>>>>>> parameters wrapped in rpc literal style.
>
> This would mean, that there must not be two operations having the
> same
> parameters because otherwise the service would be ambigous. This
> would
> be a very major limitation in my opinion. Just think of something
> like:
> getFolderByName(String)
> getFileByName(String)

Not ambiguous if the schemas use different element names, say

<folderName>

vs.

<fileName>

Re: Axis 1.4: document/literal wrapped style is missing operationname
 

Jan Thomä wrote:
>> Yes. I've explained it to you. Feel free to read the WSDL and SOAP
>> specs if you want more details.
>
> I will do this once i find the time, so i can find out how things are
> intended to be.

Those specs do not have a reputation for being easy to read ...

:-)

Arne

Re: Axis 1.4: document/literal wrapped style is missing operation name
 

On 2008-08-28 17:08:55 +0200, "Mike Schilling"
<mscottschilling@hotmail.com> said:

>> This would mean, that there must not be two operations having the
>> same
>> parameters because otherwise the service would be ambigous.

>> getFolderByName(String)
>> getFileByName(String)
>
> Not ambiguous if the schemas use different element names, say
>
> <folderName>
>
> vs.
>
> <fileName>

I see, yet our server running axis 1.3 seems not to be able to provide
this kind of magic and complains that there is no known operation
called. So i stick to the --noWrap as this seems to work.

Best regards,
Jan