Anand, 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. Anne -----Original Message----- From: Anand Natrajan [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 28, 2004 1:00 PM To: [EMAIL PROTECTED] 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! Anand 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: [EMAIL PROTECTED] : 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 values : 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 wsdl : 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 like : the current BeanSerializer (probably will extend it) but for the properties : 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 a : 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: : http://ninemsn.seek.com.au?hotmail : : :
