You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Milind Gadre <mi...@ecplatforms.com> on 2003/03/10 22:20:05 UTC
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: milind@ecplatforms.com
----- Original Message -----
From: "Bill Pfeiffer" <ws...@tampabay.rr.com>
To: "Axis-User" <ax...@xml.apache.org>
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
>
>
>
Re: Simple little trick for easing (de)serialization issues
Posted by Milind Gadre <mi...@ecplatforms.com>.
Bill, looks like I accidently posted a reply to a different query (that
of simplifying deployment of custom serializers) in response to yours.
I was hoping to present a simple solution to custom serialization
issues (that can probably be wrapped in a generic
'JavaObjectBase64Serializer').
> Umm.... I'm not sure if that would meet my needs. Maybe I'm missing
a
> piece of your explanation/solution (very, very possible!), but your
method
> seems to assume that I will be calling my own service. That will not
be my
> case. Our business partners will be calling the methods. I don't
want to
> burdon them with serialization issues.
>
> I'd really like to present a WSDL doc to potential clients
(developers) of
> my system that their systems can into use to generate java, C# or
whatever
> code to call my service. The WSDL aslo serves as an important
communication
> device in terms of explaining what data these clients can expect to
provide
> when using my service.
>
> Thanks for the response and please feel free to correct any ignorance
> displayed on my part above!
>
> Bill Pfeiffer
Re: Simple little trick for easing (de)serialization issues
Posted by Bill Pfeiffer <ws...@tampabay.rr.com>.
Umm.... I'm not sure if that would meet my needs. Maybe I'm missing a
piece of your explanation/solution (very, very possible!), but your method
seems to assume that I will be calling my own service. That will not be my
case. Our business partners will be calling the methods. I don't want to
burdon them with serialization issues.
I'd really like to present a WSDL doc to potential clients (developers) of
my system that their systems can into use to generate java, C# or whatever
code to call my service. The WSDL aslo serves as an important communication
device in terms of explaining what data these clients can expect to provide
when using my service.
Thanks for the response and please feel free to correct any ignorance
displayed on my part above!
Bill Pfeiffer
----- Original Message -----
From: "Milind Gadre" <mi...@ecplatforms.com>
To: <ax...@ws.apache.org>
Sent: Monday, March 10, 2003 4:20 PM
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: milind@ecplatforms.com
>
> ----- Original Message -----
> From: "Bill Pfeiffer" <ws...@tampabay.rr.com>
> To: "Axis-User" <ax...@xml.apache.org>
> 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
> >
> >
> >
>
>
Re: Simple little trick for easing (de)serialization issues
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Bill Pfeiffer" <ws...@tampabay.rr.com>
To: <ax...@ws.apache.org>
Sent: Monday, March 10, 2003 15:22
Subject: Re: Simple little trick for easing (de)serialization issues
> 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?
>
There ought to be mappings for the sql.date, if not, ask for them or add
them, its faster that way. Similarly, there is support for Vector, so you
could use that to add ArrayLists. Use the source in
org/apache/axis/encoding/ser as your starting point.
sql.Date should map to xsd:datetime ; ArrayList becomes a sequence of
elements in XML . I guess part of the problem there is typing. When you
export/import a simple typed array, its obvious what you send and receive.
Note I find xsd:datetime trouble. Java runtimes add the correct timezone
info from a Calendar object, and expect the timezone to be valid on receipt.
.NET doesnt, it assumes local TZ everywhere. This leads to more confusion,
the further from GMT you are, but confusing it is when things are 8 hours
apart on a local system.
Nowadays I have given up on time and use a long instead, with that mapped to
the classic time_t datatype
Re: Simple little trick for easing (de)serialization issues
Posted by Bill Pfeiffer <ws...@tampabay.rr.com>.
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" <st...@iseran.com>
To: <ax...@ws.apache.org>
Sent: Monday, March 10, 2003 5:58 PM
Subject: Re: Simple little trick for easing (de)serialization issues
>
> ----- Original Message -----
> From: "Milind Gadre" <mi...@ecplatforms.com>
> To: "Paul Andrews" <pa...@cisco.com>
> Cc: <ax...@ws.apache.org>
> 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
>
Re: Simple little trick for easing (de)serialization issues
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Milind Gadre" <mi...@ecplatforms.com>
To: "Paul Andrews" <pa...@cisco.com>
Cc: <ax...@ws.apache.org>
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
Re: Simple little trick for easing (de)serialization issues
Posted by Milind Gadre <mi...@ecplatforms.com>.
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: milind@ecplatforms.com
----- Original Message -----
From: "Paul Andrews" <pa...@cisco.com>
To: <ax...@ws.apache.org>; "'Milind Gadre'"
<mi...@ecplatforms.com>
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:milind@ecplatforms.com]
> > Sent: Monday, March 10, 2003 4:20 PM
> > To: axis-user@ws.apache.org
> > 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: milind@ecplatforms.com
> >
> > ----- Original Message -----
> > From: "Bill Pfeiffer" <ws...@tampabay.rr.com>
> > To: "Axis-User" <ax...@xml.apache.org>
> > 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
> > >
> > >
> > >
> >
> >
>
>
>
RE: Simple little trick for easing (de)serialization issues
Posted by Paul Andrews <pa...@cisco.com>.
Which will only work if both ends are using Java *and* you have access
to the same classes.
> -----Original Message-----
> From: Milind Gadre [mailto:milind@ecplatforms.com]
> Sent: Monday, March 10, 2003 4:20 PM
> To: axis-user@ws.apache.org
> 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: milind@ecplatforms.com
>
> ----- Original Message -----
> From: "Bill Pfeiffer" <ws...@tampabay.rr.com>
> To: "Axis-User" <ax...@xml.apache.org>
> 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
> >
> >
> >
>
>