Hi Carl,
I have answered inline to your questions below.
On 4/18/08, Lefrancois, Carl <[EMAIL PROTECTED]> wrote:
> Hi Dimuthu, list,
>
> I have some questions about adding support for abstract base types with
> complexContent extension and restriction.
>
> For the application I am working on, it would be really useful to add this
> functionality to the WSDL2C tool but before looking at the code to see how to
> go about doing this, I want to find out if anyone has already worked on the
> problem and what they may have already discovered.
>
> Has there been any work done to try and get complex content extension /
> restriction supported in WSDL2C?
As I mention in the early mail, WSDL2C fails only when xsi:type based
serialization and deserialization with complex content
extension/restriction. I have noted some of my ideas on how to
implement xsi:type based serialization/deserialization in the end of
this mail.
> If so, what aspects of the problem are difficult to design and/or lead to
> bugs in generated code?
I think we don't have much problem with the current designs, WSDL2Java
tool with the same design as WSDL2C has been successfully implemented
most of the schema constructs. But WSDL2C has some unimplemented
features which I believed to be very uncommon in practice. But
whenever user is interested in something, the developers tend to
implement it most of the time with the users support.
> Who are the main developers of the WSDL2C tool and is there a possibility of
> asking questions about existing functionality / design decisions if I get the
> go-ahead to add this?
WSDL2C and WSDL2Java engines are based on the Axis2/Java codegen tool
which is maintained by the axis2/Java community
([EMAIL PROTECTED]/[EMAIL PROTECTED]). There we have
several xslt (eXtensible Style sheet Transformation language) files
which are 'WSDL2C' specific, and they are mostly maintained by the
axis2/c community. Since most probably java tool is quit stable, we
only need to worry about the xslt is which generate the actual c code.
You can have an idea about these xsl files at here.[1][2] So you are
talking to the right list :)
Here is a little tip on how to implement xsi:type based serialization
and deserialization (just my idea).
currently each wsdl type/ element is mapped to an adb object. This adb
object contains
* structure keeping the object data
* getters/setters
* serialization( adb object to xml) and deserialization (xml to adb
object) functions. These function currently expect the exact
element/type as the name of the adb object.
Say type animal is extended by cat and dog types.
so there will be adb objects with the names: adb_animal, adb_cat and adb_dog.
With the current implementation
adb_animal_serialize only serialize whatever to xml say <animal>animal
specific parameters</animal>
if you go int to this function it logic will be something like (in pseudo code),
1. stream_write ("<animal>")
2. for each animal specific users_parameters as parameter
stream_write(parameter)
3. stream_write (" </animal>")
same way adb_animal_deserialize only identify the <animal> animal
specific parameters</animal> xml
So in a case we implement xsi:type based serialization/deserialization
the serialization would be changed to
1. stream_write ("<animal>")
2. call adb_animal_serialize_parameters (adb_object, user_parameters)
3. stream_write ("</animal>")
adb_animal_serialize_parameters function would be like following,
void adb_animal_serialize_parameters (adb_object, user_parameters ) {
1. if( type_of(adb_object) == "cat") {
2. set attribute ("xsi:type" , "cat");
3 . adb_cat_serialize_parameters(adb_object, user_parameters);
}
4. if( type_of(adb_object) == "dog") {
5. set attribute ("xsi:type" , "dog");
6. adb_dog_serialize_parameters(adb_object, user_parameters);
}
7. if( type_of(adb_object) == "animal) {
8. set attribute ("xsi:type" , "animal");
9. //execute the old algorithm
for each animal specific users_parameters as parameter
stream_write(parameter)
}
}
Similarly adb_animal_deserialize_parameters should be introduced.
void adb_animal_deserialize_parameters (xml ) {
1. if (xml.get_attribute("xsi:type") == "cat") {
2. var = adb_cat_create();
3. adb_cat_deserialize_parameters(xml);
}
4. if (xml.get_attribute("xsi:type") == "dog") {
5. var = adb_dog_create();
6. adb_dog_deserialize_parameters(xml);
}
7 if (xml.get_attribute("xsi:type") == "animal") {
8 //the current algorithm in deserializing animal
}
}
Anyway implementing this in C is not much simple. The first thing it
doesn't support RTTI and it doesn't support type extension. you can't
put adb_cat object to where adb_animal is expected unless the
signature is changed to void*.
RTTI can be solved by generating the adb structures with their type
information like
struct adb_animal {
.... ..
axis2_char_t *whoami;
};
whenever adb_animal is created (adb_animal_create is called) it set
the whoami to "animal" which can be used to identify which type the
object is (in fact we can use a macro to returun the type). And all
the places of serialization and deserialization functions signature
where adb objects expects, should be changed to void* pointers.
Hope this tip is useful.
Thanks
Dimuthu
[1]
https://svn.apache.org/repos/asf/webservices/axis2/trunk/java/modules/adb-codegen/src/org/apache/axis2/schema/template
[2]
https://svn.apache.org/repos/asf/webservices/axis2/trunk/java/modules/codegen/src/org/apache/axis2/wsdl/template/c
>
> Carl
>
>
> -----Message d'origine-----
> De : Dimuthu Gamage [mailto:[EMAIL PROTECTED]
> Envoyé : mardi, avril 15, 2008 13:49
> À : Apache AXIS C User List
> Objet : Re: abstract base type support
>
>
> Hi Carl,
>
> Currently WSDL2C doesn't' support abstract base types with complexContent
> extension and restriction which requires xsi:type attribute. But WSDL2C is
> tested with complexContent other than abstract base types.
>
> In order to have this functionality, we may need to edit the serializing and
> deserializing logic inside the adb object corresponding to the base type. And
> we may need to provide an API to inform the types of the element type
> explicitly.
>
> In a case you want to hack the generated code to have this functionality, my
> idea is you better go through the adb_**_serialize and adb_**_deserialize
> functions for the abstract type.
>
> Thanks
> Dimuthu
>
>
> On Tue, Apr 15, 2008 at 8:13 PM, Lefrancois, Carl <[EMAIL PROTECTED]> wrote:
> > Hello,
> >
> > Can someone confirm that WSDL2C does not support WSDLs with abstract
> > base types? The XML documents generated by my WSDL2C stubs have
> > validation errors referring to missing xsi:type attributes. I think
> > the passage below from the Databinding framework reference [1] says
> > that there is no support for generation of xsi:type attributes yet:
> >
> > Known Limitations
> > ADB is meant to be a 'Simple' databinding framework and was not meant
> > to compile all types of schemas. The following limitations are the
> > most highlighted. 1. Complex Type Extensions and Restrictions.
> >
> > If there is some way to enable generation of xsi:type attributes, can
> > someone kindly point it out? If this is not a supported feature, are
> > there any plans for it to be added later, or some effort already
> > underway?
> >
> > Carl
> > [1] http://ws.apache.org/axis2/1_3/adb/adb-howto.html
> > _____
> >
> > "Ce message est confidentiel, a l'usage exclusif du destinataire
> > ci-dessus et son contenu ne represente en aucun cas un engagement de
> > la part de AXA, sauf en cas de stipulation expresse et par ecrit de
> > la part de AXA. Toute publication, utilisation ou diffusion, meme
> > partielle, doit etre autorisee prealablement. Si vous n'etes pas
> > destinataire de ce message, merci d'en avertir immediatement
> > l'expediteur."
> >
> > "This e-mail message is confidential, for the exclusive use of the
> > addressee and its contents shall not constitute a commitment by AXA,
> > except as otherwise specifically provided in writing by AXA. Any
> > unauthorized disclosure, use or dissemination, either whole or
> > partial, is prohibited. If you are not the intended recipient of the
> > message, please notify the sender immediately."
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
