axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Buss (JIRA)" <>
Subject [jira] Commented: (AXIS2-2246) Rpc-Literal Client and Server adb codegen create messages that are non WS-I complient
Date Thu, 05 Apr 2007 09:09:32 GMT


Tim Buss commented on AXIS2-2246:

I assume you are referring to this paragraph of the WS-I basic profile.

"Conversely, in a rpc-literal SOAP binding, the serialized child element of the soap:Body
element consists of a wrapper element, whose namespace is the value of the namespace attribute
of the soapbind:body element and whose local name is either the name of the operation or the
name of the operation suffixed with "Response". The namespace attribute is required, as opposed
to being optional, to ensure that the children of the soap:Body element are namespace-qualified."

It would be normal to declare the element in the document literal case since the document
literal message would reference the element as its "document" type.  I see no reason why such
an element would be illegal in the RPC-literal case since no such element actually exists
elsewhere in the same namespace in the schema or WSDL.  The fact that the WSDL implies the
generation of such an element in the SOAP message is independent of the schema even if it
might logically create a conflicting definition. In the rpc literal case the wrapper element
of an rpc-literal soap message is not technically part of a document defined by the schema
and can't be validated by it.  I understand your point but this worked in Axis 1.X and passes
the WS-I check in WTP so I suspect it is legal even if it is logically suspect. 

In any case, whether this is illegal or legal and a restriction of Axis2 it should not generate
code that apparently works but does the wrong thing! At the very least it should generate
a warning or an error.   Possibly  pre-scanning for WS-I compliance such as is done by the
eclipse WTP tool would be the only easy way to do this. However, since it is known from the
WSDL that the service is rpc-literal and the WSDL defines what namespace and name the wrapper
element should have as described above, it seems reasonable to ignore any other definitions
conflicting or otherwise and just generate code that does the right thing.

> Rpc-Literal Client and Server adb codegen create messages that are non WS-I complient

> --------------------------------------------------------------------------------------
>                 Key: AXIS2-2246
>                 URL:
>             Project: Axis 2.0 (Axis2)
>          Issue Type: Bug
>          Components: adb
>    Affects Versions: 1.1.1
>         Environment: Axis 1.5, Tomcat 5.5, Axis2 1.1.1, Axis2 Eclipse codegen plugin
1.1.1, Eclipse 3.2, WTP 1.5.1, Windows 2003 server
>            Reporter: Tim Buss
>            Priority: Critical
>         Attachments: Axis2RPCLiteralTest.wsdl
> There appears to be two problems.  The most obvious is that the RPC-literal message sent
by the generated client and accepted by the generated service is incorrect .  The following
message body  is sent for the various test cases I have tried - string, complex type, nested
complex type. 
> <soapenv:Body> 
>     <ns:OperationName> 
>         <ns:PartName> 
> .............content..... 
>         </ns:PartName> 
>     </ns:OperationName> 
> </soapenv:Body> 
> but it should be: 
> <soapenv:Body> 
>     <ns:OperationName> 
>         <PartName> 
> .............content..... 
>         </PartName> 
>     </ns:OperationName> 
> </soapenv:Body> 
> PartName should be a non qualified name.  Axis 1.3 did it this way, and other sources
support this as being the correct form for rpc-literal.  In particualr WS-I Basic 1.0 states:

> "4.7.20 Part Accessors 
> For rpc-literal envelopes, WSDL 1.1 is not clear what namespace, if any, the accessor
elements for parameters and return value are a part of. Different implementations make different
choices, leading to interoperability problems. 
> R2735 An ENVELOPE described with an rpc-literal binding MUST place the part accessor
elements for parameters and return value in no namespace. 
> R2755 The part accessor elements in a MESSAGE described with an rpc-literal binding MUST
have a local name of the same value as the name attribute of the corresponding wsdl:part element.

> Settling on one alternative is crucial to achieving interoperability. The Profile places
the part accessor elements in no namespace as doing so is simple, covers all cases, and does
not lead to logical inconsistency. " 
> The second problem that I have yet to narrow down is that with a much more complex type,
the generated client sends a message with a body like this where the "part" element is not
> <soapenv:Body> 
>     <ns:OperationName> 
>  .............content..... 
>      </ns:OperationName> 
> </soapenv:Body> 
> One other difference that may be a factor in this case is that my complex service is
one way. 

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message