xml-soap-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Dovlecel <do...@kbs.twi.tudelft.nl>
Subject Re: passing interfaces instead of classes
Date Wed, 04 Dec 2002 18:01:47 GMT
> Right now, it will fail because [de-]serializers are found by exact type
> match only (or a default if one is defined, but this is typically
> useless).  I did not take the time to change the [de-]serializer lookup,
> because I am not sure what the right way is to implement polymorphic
> return values.

yeah, it quite sucks. I would have done the patch myself some month ago (when 
hit the wall myself) but had not too much experience with apache soap. I 
don't have it not even now so... :o( 

> One issue is, how will a client know what different types it can receive
> if the return value is polymorphic?  In your example, a client who
> thinks the contract is A getA() may always expect to deserialize an A.
> Receiving a B would be an error: the client does not even know what a B
> is!  This is a place where WSDL would be a big help.
But I don't know how should be of a big help? Just by noticing the user that 
there are alot of classes to be mapped (like B class that extends A)? (not 
too much experience on this too). 

And then you should generate the classes by using a WSDL2Java tool or 
something similar? 

> You have raised the other major issue: should the service have to map
> all of the concrete types that may be returned?
This is usually the way I do... Is it wrong? 

For example, I map all my class that could be serialized by soap. And usually 
I have total control over the client, so I do the same thing there... adding 
most of the mappings... (maibe even all of them) .

> I am thinking that to address the first issue, I should make return
> value polymorphism an option in the deployment descriptor, so that the
> service implementor will have to explicitly enable it for the service.
> It would then be up to the implementor to document the possible return
> types for client implementors.

> For the second issue, I would walk the inheritance chain looking for a
> serializer, then check implemented interfaces for one.  This really is
> not too big of a deal.
I suppose this is the way axis handles inheritance... could you tell me if I 
am wrong with this one? BEcause right now I use axis (started one month ago) 
and I don't want to find this issues right when I don't have the time to 
solve them :o( 

> Scott Nichol
Tx for clarifying some buggy things walking through my mind

View raw message