Claude, good point. I am new to using Web Services and wanted to get some feedback. I will keep your comments in mind moving forward.
Counterpoint - General purpose interoperability is a myth. Both sides have to know what is being requested and delivered, and in what format. One need not always use the notion of interoperability to impose un-necessary hardship. I can easily see the effect of mismatched Java versions causing headaches. While I would not use my approach to pass any and all Java Objects around, it may be reasonable to use it to simplify the passing of general Java Objects that come with the JDK - or complex types that are known to both sides of the fence. Ultimately, both sides of the fence *have* to know what is going around - unless we are restricting ourselves to making simple 'search' or 'stock price' queries against Google. Regards... Milind Gadre VP Product Development ecPlatforms, Inc 901 Mariner's Island Blvd, Suite 565 San Mateo, CA 94404 C: 510.919.0596 E: [EMAIL PROTECTED] ----- Original Message ----- From: "Vervoort, Claude" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; "Milind Gadre" <[EMAIL PROTECTED]>; "Paul Andrews" <[EMAIL PROTECTED]> Sent: Monday, March 10, 2003 2:30 PM Subject: RE: Simple little trick for easing (de)serialization issues > Well I think it goes quite against a very basic principle of Web Service: interoperability. If you're to rely on java serialization framework, you imply client and server are sharing the same code base, so could you not use RMI over Http? > > Claude > > -----Original Message----- > From: Milind Gadre [mailto:[EMAIL PROTECTED] > Sent: Monday, March 10, 2003 2:25 PM > To: Paul Andrews > Cc: [EMAIL PROTECTED] > 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... > > Milind Gadre > VP Product Development > ecPlatforms, Inc > 901 Mariner's Island Blvd, Suite 565 > San Mateo, CA 94404 > C: 510.919.0596 > E: [EMAIL PROTECTED] > > ----- Original Message ----- > From: "Paul Andrews" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]>; "'Milind Gadre'" > <[EMAIL PROTECTED]> > Sent: Monday, March 10, 2003 2:11 PM > Subject: RE: Simple little trick for easing (de)serialization issues > > > > Which will only work if both ends are using Java *and* you have > access > > to the same classes. > > > > > -----Original Message----- > > > From: Milind Gadre [mailto:[EMAIL PROTECTED] > > > Sent: Monday, March 10, 2003 4:20 PM > > > To: [EMAIL PROTECTED] > > > Subject: Simple little trick for easing (de)serialization issues > > > > > > > > > > > > Bill, here is a quick fix to your problem. > > > > > > 1. Perform a JAVA Object Serialization of your Object(s) into a > > > ByteArrayOutputStream wrapped in a ObjectOutputStream. > > > Remember to have > > > your objects implement java.io.Serializable. > > > 2. Base64.encode the resulting byte[] > > > 3. Send that String to the end-point. > > > 4. At the end-point, Base64.decode the String into a byte[], and > > > perform a JAVA Object Deserialization. > > > 5. Do the same for the returned JAVA object. > > > > > > The biggest advantages of this little trick are > > > > > > 1. No need to define and configure custom (de)serializers > > > 2. Simplified API. > > > > > > Potential downside - handling large objects and attachments. > > > > > > Hope this helps - comments/flames from Axis experts welcome. > > > > > > Regards... > > > > > > Milind Gadre > > > VP Product Development > > > ecPlatforms, Inc > > > 901 Mariner's Island Blvd, Suite 565 > > > San Mateo, CA 94404 > > > C: 510.919.0596 > > > E: [EMAIL PROTECTED] > > > > > > ----- Original Message ----- > > > From: "Bill Pfeiffer" <[EMAIL PROTECTED]> > > > To: "Axis-User" <[EMAIL PROTECTED]> > > > Sent: Monday, March 10, 2003 1:12 PM > > > Subject: Help on ArrayList, java.sql.Date classes > > > > > > > > > > I've posted previously on this just a short while ago, but was > > > wondering if > > > > someone could help me a bit further. > > > > > > > > I need serializers/des for ArrayList, and java.sql.Date. I'm > fine > > > with them > > > > going to normal SOAP array and SOAP date. > > > > > > > > If someone has already written and successfully tested, could you > > > post code? > > > > > > > > If not, is there a getting started on writing these things? The > > > example > > > > referenced in the docs seems pretty inadequate for what I > > > want to do. > > > > > > > > Background: > > > > > > > > What I am trying to do is expose some large grained > > > SessionBean calls > > > that > > > > pass a data object model around. The model is composed of java > beans > > > > containing other java beans as well as collections of > > > javabeans. The > > > java > > > > beans work fine, the collections and the java.sql.Dates choke on > the > > > WSDL > > > > generation. > > > > > > > > I have successfully deployed the service and called with my > custom > > > coded > > > > client that has access to my data model. I now want to use the > WSDL > > > to > > > > generate the java to make the call. This is where the > > > collections/sql Dates > > > > are tripping me up. > > > > > > > > Thanks for any pointers here. > > > > > > > > Bill Pfeiffer > > > > > > > > > > > > > > > > > > > > > > > > > > > >
