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

[Jan]

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: 
 
<wsdlperation name="search"> 
<wsdl:input name="searchRequest" 
message="tns:searchRequest" /> 
<wsdlutput name="searchResponse" 
message="tns:searchResponse" /> 
</wsdlperation> 
 
I got a message like this: 
 
<wsdl:message name="searchRequest"> 
<wsdlart name="parameters" element="tns:search"></wsdlart> 
</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

 

[Mike Schilling]

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:

<wsdlperation name="search">
<wsdl:input name="searchRequest"
message="tns:searchRequest" />
<wsdlutput name="searchResponse"
message="tns:searchResponse" />
</wsdlperation>

I got a message like this:

<wsdl:message name="searchRequest">
<wsdlart name="parameters" element="tns:search"></wsdlart>
</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.

 

[Jan Thomä]

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

 

[Mike Schilling]

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.

 

[Jan Thomä]

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

 

[Mike Schilling]

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.

 

[Jan Thomä]

Mike,
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

 

[Mike Schilling]

Mike,

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>

 

[Arne Vajhøj]

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

 

[Jan Thomä]

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

 

[Mike Schilling]

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.

What "magic"? Write the schema that way, and generate the Java stub
and skeleton from it.

 

[Jan Thomä]

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.

Mike, again

could it be we are mixing up document/literal and document/literal -
wrapped style here? Because in the wrapped style, the method name is
supposed to appear inside the body of the message. In this case the
the only thing that could cause trouble in dispatching the message
would be an overloaded method. I found a nice article explaining the
differences very well:
http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/

Btw. I have tried another WSDL using the --noWrap switch, where it
seemed not to work . I guess there are some idiosyncracies concerning
the wrapped style with axis.

Best regards,
Jan

 

[Mike Schilling]

Mike, again

could it be we are mixing up document/literal and document/literal -
wrapped style here? Because in the wrapped style, the method name is
supposed to appear inside the body of the message. In this case the
the only thing that could cause trouble in dispatching the message
would be an overloaded method. I found a nice article explaining the
differences very well:
http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/

Btw. I have tried another WSDL using the --noWrap switch, where it
seemed not to work . I guess there are some idiosyncracies
concerning the wrapped style with axis.

OK, I think I'd figured out where the disconnect is. Are you writing
the schemas yourself, of letting Axis generate them from Java classes?

I've been assuming the first of these. Now it looks more like it's
the second, and what you've been asking about is how to get Axis to
generate schemas that are unique for each operation in your service.
"wrapped" is neither a SOAP nor a WSDL concept, so I'm assuming it's
an Axis concept for schema generation. Yes, if you're letting Axis
generate the schemas, it looks like "wrapped" is a better choice
(though RPC/literal is probably better still, as it handles overloaded
operations more naturally.)