axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anne Thomas Manes" <>
Subject RE: Advanced serialization of Collections and Maps
Date Thu, 29 Jul 2004 23:06:27 GMT

Your concerns are right on target. That's the reason why we keep
recommending to people that they flatten all collections into simple types,
structures of simple types, and arrays.

If you want to pass these complex object graphs, then you should use
RPC/encoded and you should assume that only Java clients will be able to
interoperate with your service. But I really don't see the point. For
Java-to-Java communication using an RPC-style distributed object scenario,
you should use Java's native method invocation system: RMI.


-----Original Message-----
From: Anand Natrajan [] 
Sent: Wednesday, July 28, 2004 1:00 PM
Subject: RE: Advanced serialization of Collections and Maps

Marc and Brian,

Forgive me if this is a naive question, but won't your actions below make it
hard to write non-Java clients targetting your web services? It may be hard
for Perl and VB clients to duplicate the complex data structures you're
planning, even if you manage to make Java clients work. Moreover, if you
write custom deserialisers, won't all your clients have to have them as
well? That means you can't just hand a client a WSDL - you have to give them
a deserialiser as well. On the other hand, if you can flatten your complex
types into arrays or simple types, you're guaranteed that non-Java clients
can deal with them.

I may be wrong about my concerns above, in which case I'd like to know how
you go about resolving them. I am interested in the solution because I may
face a similar decision in the near future. Thanks!


On Wed, 28 Jul 2004, Brian Drake wrote:

: Hi Marc --
: If I understand the first part of your question correctly, you want to
: have your service method return the data in a Collection object back to
: the client as a typed array.
: There is an array serializer/deserializer that will work fine for this
: purpose.  They're in the "ser" package along with the Bean serializers
: and such.
: I've been interested in doing the same sort of stuff.  Sending back
: typed arrays is about as close to returning a Collections object as
: I've been able to get.  For the most part this works for my (current)
: needs.  It doesn't require custom serialization (unless the array
: type does).
: -BWD.
: -----Original Message-----
: From: Marc Wilson [mailto:
: Sent: Tuesday, July 27, 2004 8:46 PM
: To:
: Subject: Advanced serialization of Collections and Maps
: Hi,
: I have a few questions about serialization and deserialization of
: Collections and Maps with Axis.
: Basically our app has a Business Object Model of DTOs (Data Transfer
: Objects) that it relatively complex from a Soap p.o.v., ie: it contains
: lists, sets and maps within it. All the lists, sets and maps in the BOM
: contain elements of one type only.
: We are evaluating the practicallity of exposing the API of our application
: (currently accessed through Stateless Session EJBs) also as a WebService
: through AXIS.
: I have got it working for "simple" return values, but for complex return
: values as I expected it doesn't work as easily.
: What I want to be able to do is use the serialization and deserialization
: abilities of Axis to serialise any and all Collections in the return
: as typed arrays (I'll get to maps in a minute).
: I think that the BeanSerializer can currently serialize a List as
: xsd:anyType[] or soapenc:Array, but I need it to be typed when it is
: serialized so that any client can generate everything it needs from the
: and not have to worry about any complex mappings etc..
: I plan to markup the DTOs and use xDoclet and to generate custom
: serialization and deserialization classes:
: ie:
: ----------------------------------------
: class MouseDTO
: {
:     /**
:      * @mymarkuptag.list type=Cat
:      */
:     public List getCats() ...
:     /**
:      * @mymarkuptag.set type=Dog
:      */
:     public Set getDogs() ...
: }
: class CatDTO
: {
:     ..
: }
: class DogDTO
: {
:     ..
: }
: ----------------------------------------
: would generate
: ----------------------------------------
: class FooDTOSerialiser extends MyCollectionSerializer
: {
:     FooDTOSerialiser()
:     {
:         super(new String[]{"cats","dogs"}, new Class[]{CatDTO.class,
: DogDTO.class});
:     }
: }
: ----------------------------------------
: Then I plan to write a MyCollectionSerializer base class which will act
: the current BeanSerializer (probably will extend it) but for the
: that were specified in the constructor (ie: cats) it will do the
: serialisation as if it were an array of that type (ie: CatDTO[]).
: Maps would work the same way except that there would be two classes marked
: up for the key and value types and they would be serialised as an array of
: type that contains the key and value types (ie: TypeATypeBPair[], where
: TypeATypeBPair is { TypeA key, TypeB value}).
: Now, the questions:
: Does what I want to do make sense?
: Is there anything out in Axis land that does this already?
: Does anyone have any ideas/input into how I would/should write the base
: serializer classes?
: Any other ideas of feedback would be appreciated
: Cheers
: -Marc
: _________________________________________________________________
: SEEK: Now with over 50,000 dream jobs! Click here:

View raw message