You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by su...@opensource.lk on 2004/02/18 13:57:48 UTC
Generating wrapped doc/lit style code by WSDL2Ws tool
Hi Jean-Yves
I merged the diff. And working on adding ClientStubWriter.java changes.
BTW can we adhere to what
http://www-106.ibm.com/developerworks/webservices/library/ws-whichwsdl/#N101D2
says ?
It says having name="parameters" is a convention.
<message name="myMethodRequest">
<part name="parameters" element="myMethod"/>
</message>
Anyway we have to check whether the input element name is the same as the
operation name which we dont do at the moment.
Also there can be other checks we have to do before generating wrapped
doc/lit style code. if any check fails and if --nowrapped option provided
we have to generate doc/lit style code.
> I have also other questions :-(
>
> When enumerations will be supported ?
We probably have to prepare a priority list of these features and have a plan
Above article says that having attributes in element's complex type is
wrong in wrapped doc/lit style web services. Can anyone confirm this ?.
Ex:
<complexType name="Person">
<sequence>
<element minOccurs="1" maxOccurs="1" name="Age" type="double"/>
<element minOccurs="1" maxOccurs="1" name="ID" type="xsd:float"/>
</sequence>
<attribute name="Name" type="string"/>
<attribute name="Male" type="boolean"/>
</complexType>
<element name="x_Person" type="typens:Person"/>
<message name="echoPerson">
<part name="x" element="typens:x_Person"/>
</message>
Thanks,
Susantha.
RE: Generating wrapped doc/lit style code by WSDL2Ws tool
Posted by Susantha Kumara <su...@opensource.lk>.
Hi Jean-Yves,
I applied patch to BeanParamWriter.java and Type.java but not to
ParameterInfo.java
This is because the problem of name conflicts between types and parameters
will be solved better when we use fully qualified type names.
Ex: For type in
<schema targetNamespace="http://soapinterop.org/xsd"
..............
<complexType name="SOAPStruct">
<sequence>
............
</sequence>
</complexType>
</schema>
The name of the C/C++ type we generate at the moment is "SOAPStruct"
But we have to make the typename to be
http___soapinterop_org_xsd__SOAPStruct.
>
> For ParameterInfo.java the fix concern this kind of declaration in the
> schema declaration part :
> ...
> <xsd:element maxOccurs="1" minOccurs="0" ref="tns:Input"/>
> ...
> The fix avoid to have a type and variable with the same name. I still
> have compilation fail when maxOccurs="unbounded"
Please see the attched WSDL. Does it shows this "unbounded" issue ?.
But I see that there is another issue. That is the return values of the
method are complex type arrays
But the method in the generated code returns only 2 objects not 2 arrays.
>
> For Type.java the quick & durty allow the declaration of inner type (see
> comments in the diff file).
>
I applied this patch as is. But I couldnot come across this situation when
running several wsdls.
Thanks,
Susantha.
Re: Generating wrapped doc/lit style code by WSDL2Ws tool
Posted by Jean-Yves Baudy <jy...@free.fr>.
Hi,
Thanks for the integration. Here some more fixes (always C++ doc/lit)
For BeanParamWriter.java it fix compilation issue when a type is empty.
It may make no sense to define empty type but like this the generated
code compile.
For ParameterInfo.java the fix concern this kind of declaration in the
schema declaration part :
...
<xsd:element maxOccurs="1" minOccurs="0" ref="tns:Input"/>
...
The fix avoid to have a type and variable with the same name. I still
have compilation fail when maxOccurs="unbounded"
For Type.java the quick & durty allow the declaration of inner type (see
comments in the diff file).
Regards,
Jean-Yves
susantha@opensource.lk wrote:
> Hi Jean-Yves
>
> I merged the diff. And working on adding ClientStubWriter.java changes.
> BTW can we adhere to what
> http://www-106.ibm.com/developerworks/webservices/library/ws-whichwsdl/#N101D2
> says ?
> It says having name="parameters" is a convention.
>
> <message name="myMethodRequest">
> <part name="parameters" element="myMethod"/>
> </message>
>
> Anyway we have to check whether the input element name is the same as the
> operation name which we dont do at the moment.
>
> Also there can be other checks we have to do before generating wrapped
> doc/lit style code. if any check fails and if --nowrapped option provided
> we have to generate doc/lit style code.
>
>
>>I have also other questions :-(
>>
>>When enumerations will be supported ?
>
>
> We probably have to prepare a priority list of these features and have a plan
>
> Above article says that having attributes in element's complex type is
> wrong in wrapped doc/lit style web services. Can anyone confirm this ?.
>
> Ex:
>
> <complexType name="Person">
> <sequence>
> <element minOccurs="1" maxOccurs="1" name="Age" type="double"/>
> <element minOccurs="1" maxOccurs="1" name="ID" type="xsd:float"/>
> </sequence>
> <attribute name="Name" type="string"/>
> <attribute name="Male" type="boolean"/>
> </complexType>
> <element name="x_Person" type="typens:Person"/>
>
> <message name="echoPerson">
> <part name="x" element="typens:x_Person"/>
> </message>
>
> Thanks,
>
> Susantha.
>
>
>
Re: Generating wrapped doc/lit style code by WSDL2Ws tool
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Hi Susantha,
> I merged the diff. And working on adding ClientStubWriter.java changes.
> BTW can we adhere to what
>
http://www-106.ibm.com/developerworks/webservices/library/ws-whichwsdl/#N101
D2
> says ?
> It says having name="parameters" is a convention.
NO!!!!
> <message name="myMethodRequest">
> <part name="parameters" element="myMethod"/>
> </message>
>
> Anyway we have to check whether the input element name is the same as the
> operation name which we dont do at the moment.
These are not rules defined by WSDL but random rules defined by
MSFT primarily which Axis adopted. WSDL 2.0 is changing this quite
a bit but it'll be sometime before that becomes widespread.
> Also there can be other checks we have to do before generating wrapped
> doc/lit style code. if any check fails and if --nowrapped option provided
> we have to generate doc/lit style code.
The right solution IMO is to allow the user to select with with --wrapped
or --nowrapped and then codegen accordingly (and select a suitable
default .. wrapped probably). The WSDL description and choice of
programming model are *not* coupled, contrary to what that article
appears to imply and the lousy conventions that certain folks used.
(I'm the co-author of the WSDL spec and co-editor of the upcoming
WSDL 2.0 spec as well.)
> > I have also other questions :-(
> >
> > When enumerations will be supported ?
>
> We probably have to prepare a priority list of these features and have a
plan
Does Axis' XSD parser support enumerations? If not we should wait
until the JaxMe stuff gets integrated.
Also are enumerations part of the basic profile 1.0? If yes. that
certainly raises the priorities!
> Above article says that having attributes in element's complex type is
> wrong in wrapped doc/lit style web services. Can anyone confirm this ?.
There is no such thing as "wrapped doc/lit" style Web services. The
whole doc/lit, doc/encoded, rpc/lit, rpc/encoded concepts were WSDL
inventions for alternative ways to describe a given Web service. The
main rpc vs. doc concept came from SOAP having defined an RPC convention
on top of the base message layer (interpret first child of <Body> as
method call, its children as parameters, no attributes in the
first child element, ..). The WSDL rpc mechanism is a way to describe
how to create such SOAP envelopes at a higher level than with the
XML element indicating the method etc.
It was a nice idea (IMO), but the resulting complexity of WSDL did
confuse a lot of people. So WSDL 2.0 is moving away from all this and
having just *one* way to describe a SOAP payload: *one* XML element
and it can be anything. *If* that element adheres to certain
conventions then it can be considered to as an RPC signature if
the programming model generator wishes to do so.
"Wrapped doc/lit" is an attempt at doing that - defining a set
of conventions over doc/lit to indicate that its a method. Those
conventions are however non-standard and pretty damn ad hoc and
crappy. So, the right solution for now (and for always IMO) is
to allow the programmer to decide whether they want to take a
WSDL of doc/lit style and "unwrap" the outermost element as a
method call or to leave it alone. The heuristics for automatically
doing that are just that - heuristics.
Sanjiva.