Steve, I have bought into the interop thing because there's an extremely good chance that my future clients (Insurance inducstry) will be using .NET and Java. So I have one choice and that is to make interop work. Now reality sets in. My data model contains java.sql.Date and ArrayList. I have no problem with (the idea of) marshelling these to the least common denominator of the SOAP types. Why not? SOAP supports arrays and datetimes. That's what these things are when it comes down to it.
My original question stands. How do I write the serializers for these for the server side. Yes I will have to make assumptions, but I own the data model and can do that (Soap array is an ArrayList, Soap Datetime is java.sql.date). Is this possible? Has anyone done? Have examples? Bill ----- Original Message ----- From: "Steve Loughran" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, March 10, 2003 5:58 PM Subject: Re: Simple little trick for easing (de)serialization issues > > ----- Original Message ----- > From: "Milind Gadre" <[EMAIL PROTECTED]> > To: "Paul Andrews" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Monday, March 10, 2003 14:24 > Subject: Re: Simple little trick for easing (de)serialization issues > > > > > > Agreed ... but consider situations (posted by several users on this > > list - and encountered by me) where you want to pass Java Object around > > but are limited by the Java<>XML serialization support. I find the > > existing serialization support to go only as far as the simple types. > > > > I think my approach can lead to a more general purpose > > (de)serialization mechanism - based on the existing Java Serializable > > framework. I am curious if it has been thought of before and rejected > > for some reason. > > > > JavaObjectBase64Serializer > > JavaObjectBase64SerializerFactory > > JavaObjectBase64Deserializer > > JavaObjectBase64DeserializerFactory > > > > Regards... > > If you look at the continual problem, yes people on this list are constantly > trying to send Objects over, File objects, HashMaps and complaining that > Axis bails out. And no doubt the .NET support groups get calls saying 'we > cant send System.Util.HashTable over the wire", or "Why cant I send > System.Object" instances out. > > Both these problems stem from the same underlying cause: you cannot achieve > interop without sacrificing seamless marshalling of all data you can have in > a complex language. Or as I put in in my presentation: > > http://www.iseran.com/Steve/papers/interop/ > > Naiive and unrealistic expectations are a recurring interop issue. User > education -that's you finding out you cant send stuff out. is the first step > to addressing interop. > > At the same time, Web Services built on SOAP+XSD can improve interop. Axis > needs better DataSet handling, everyone needs to agree on standards for > hashtable, list, and other core collection types that can be mapped to java, > .NET, C++ STL and Perl. > > Until then: stop trying to send stuff over SOAP that doesnt work in language > s other than Java. Any quick hacks to support Java only (or indeed .NET, C++ > or Perl) throw away a key benefit of the technology: you dont need to care > what language the caller is using. Once you throw that away, what are you > left with? A distributed messaging protocol that is slow, inefficient and > incomplete -something not worth using > > -steve >
