Changes to WSDL11ToAxisServiceBuilder

[Amila Suriarachchi <am...@gmail.com>]

hi,
There were some problems in processing the wsdl file in
WSDL11ToAxisServiceBuilder specially for rpc style. So I did the following
changes to support the basic profile properly to improve the
interoperability.

1. For RPC operations, new Elements (with the operation names) were
generated by adding all the message parts under any message.
       This is only correct if the user has not specified a 'parts'
attribute in corresponding soap:body element. Actually when generating the
new elements, we have to do it for each binding operation (by considering
the parts attribute) instead of operations in the porttype. So I change it ,
first to check for parts and if not present then check for parameter order
and finally for if both are missing to include all parts (while iterating
through binding operations).
       On the other hand earlier implementation, if a part does not have a
type attribute specified then it checked for an element attribute and
process by adding an element reference. This is wrong according to the basic
profile. since for rpc style there can be only type attributes. if a type
attribute is not present we have to throw an exception.

2. For Document literal again parts attribute was not handled properly.
       For Document literal only one part name can be given in parts
attribute. Otherwise we have to throw an exception (this was not there). And
also if there is an empty parts list (i.e. parts="") then we have to set the
ElementQname as null. since we do not have to send any thing in soap body.
Finally if a user has not specified any parts in soap:body element and the
corresponding element contain more than one part, again we have to throw and
exception instead of getting the first element.

This clearly shows the message formats goes inside the <soap:body> element
(when invoking the web services) totaly depends on the binding. In other
words Element Qname refereces in AxisMessages ( hence AxisOperation and Axis
Service) depends on the binding. Therefore generated skelton ( with
wsdl2java) is also differ from binding to binding. As a result of this I
think it is not possible to provide multiple port support for WSDL
1.1unless all the ports refer to the same Binding with the current
axis
architecture.

Currently when populating the servie, WSDL11ToAxisServicBuilder first picks
up an binding and set message element Qname refereces accordingly. And
populate all the binding details as well.  Therefore I believe the latter
action is not necessary when we consider the  above fact? So shall we remove
that part? any thoughts?

Amila.

-- 
Amila Suriarachchi,
WSO2 Inc.