SOAP Serialization

[Milind Gadre <mi...@idiom.com>]

Hello all, I am new to this slippery world of SOAP, so please enlighten
me if my questions have already been answered some other place. I am
having a hard time figuring out the logic behind SOAP serialization of
arbitrary Java objects. I have not been able to find relevant
documentation on the matter.

My questions are:

[1] How does SOAP serialization handle protected/private fields of
arbitrary objects? Does it override some security settings in order to
get access to the private/protected fields? In an earlier post to this
discussion group I described a stack trace from the XMI classes.

[2] Similar to the readObject/writeObject logic of Java Serialization,
is it possible to intercept the SOAP serialization procedures to insert
custom logic? I see this as being critical to sending java objects down
the pipe.

[3] If the above is not possible, then how can I extend the SOAP
serialization classes so as to perform custom logic *just prior* to
sending an object and *just after* receiving an object.

[4] What about *transient* fields?

It seems to me that if SOAP is to support a general purpose
serialization mechanism, an API that has at least some of the
extensibility and features of existing Java Serialization is a must.

Thanks in advance for any help on this matter.

Best regards...Milind
milind@idiom.com


> -----Original Message-----
> From: Yusuf Goolamabbas [mailto:yusufg@outblaze.com]
> Sent: Friday, August 18, 2000 3:45 AM
> To: soap-user@xml.apache.org
> Cc: soap@discuss.develop.com
> Subject: Shouldn't public properties of beans be named accessor
>
>
> Hi, I modified my Java client code [posted earlier] to use public
> properties for the origin and corner beans and sent it to my SOAP/Perl
> server. This is the SOAP envelope which got sent
>
> [yusufg@yusufg soap]$ java -classpath
> /usr/java/jdk1.3/jre/lib/rt.jar:$HOME/classes/soap.jar:$HOME/c
lasses/xerces.jar:. Geo http://127.0.0.1:8080/perl?class=Geometry
> args[0] = http://127.0.0.1:8080/perl?class=Geometry
> Request envelope:
> <SOAP-ENV:Envelope
> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
> xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
> xmlns:xsd="http://www.w3.org/1999/XMLSchema">
> <SOAP-ENV:Body>
> <ns1:calculateArea xmlns:ns1="urn:com-develop-geometry"
> SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
> <origin xsi:type="ns1:origin">
> </origin>
> <corner xsi:type="ns1:corner">
> </corner>
> </ns1:calculateArea>
> </SOAP-ENV:Body>
> </SOAP-ENV:Envelope>
>
>
> As seen above, the origin and corner types don't have the x/y values
> serialized. Is this not supported by current IBM SOAP. I am using
> 2.0rc5
>
> Using a SOAP/Perl client. This is the envelope which gets generated
>
> POST /perl?class=Geometry HTTP/1.0
> Host: 127.0.0.1:8080
> User-Agent: libwww-perl/5.47
> Content-Length: 498
> Content-Type: text/xml
> SOAPAction: urn:com-develop-geometry#calculateArea
>
> <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
> xmlns:xsd="http://www.w3.org/1999/XMLSchema"
> xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
> xmlns:n1="urn:com-develop-geometry"
> s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
> <s:Body><n1:calculateArea s:id="ref-1" s:rootWithId="1">
> <origin s:href="#ref-2" />
> <corner s:href="#ref-3" />
> </n1:calculateArea>
> <item s:id="ref-3"><x>100</x><y>200</y>
> </item>
> <item s:id="ref-2"><x>10</x><y>20</y>
>

Re: SOAP Serialization

[Cory Isaacson <ci...@capita2.com>]

I also see that I can use the literal xml encoding provided with soap to do
this, which does the translation to an XML string and parses again into a
dom automatically. This will work fine, but I wonder if its the most
efficient. Any comments?

For example, I noticed that with Java 1.2 you can use XMI, which I assume
does a binary rendition of an object. Would this be a smaller representation
of a DOM than converting it to a string and then back to a DOM? Maybe
converting to binary violates the concept of SOAP, but it seems like if you
are responsible for both sides the efficiencies gained would be worth it.

I noticed that the performance study done which was recently published on
this list was mostly complaining about the need to convert from binary to a
tag-delimited xml format, and could be 10 - 100 times slower (or something
like that). Is converting to binary using Base64 (like an email attachment)
a better way to go for situations like this?

I also noticed that you can write your own encoder, so I assume I could do
this and use Java serialization. Has anyone written a custom encoder? Is
there any sample code available?

Thanks,

Cory
----- Original Message -----
From: "Cory Isaacson" <ci...@capita2.com>
To: <so...@xml.apache.org>
Cc: <ed...@ics.uci.edu>
Sent: Sunday, August 20, 2000 9:01 AM
Subject: Re: SOAP Serialization


> Eric,
>
> This sounds very interesting. Does your serialization work similar to the
> current Apache SOAP implementation, in that each field must be declared in
> the bean and is then translated into an XML element?
>
> The reason I ask is that I have a need to transmit an entire XML document
> from a server to a client and back. The XML document is in a DOM before
its
> transmitted, and I need it in a DOM to use it. It seems I have the
following
> options:
>
> 1) I can convert to a a CDATA string and pass as a single parameter), and
> then re-parse the XML string into a DOM;
> 2) Try your serializer on the DOM itself.
>
> Can your serializer handle this last case? If not, is there a way to
simply
> serialize a DOM (as a binary Java class) and use Base64 to transmit it
> through SOAP? It seems like that would be more efficient as I wouldn't
have
> to re-parse the XML on the receiving side, but I have noticed that in some
> cases Java serialization is very slow and big.in the translation.
>
> Any other ideas as to how to do this efficiently?
>
> Thanks in advance,
>
> Cory
> ----- Original Message -----
> From: "Eric M. Dashofy" <ed...@ics.uci.edu>
> To: <so...@xml.apache.org>
> Sent: Friday, August 18, 2000 5:49 PM
> Subject: RE: SOAP Serialization
>
>
> >
> > Hello all!
> >
> > With the Apache SOAP for Java API, serializers are provided for the Java
> > basic types, some other types, and one-dimensional arrays of these
types.
> > Arbitrary objects can be serialized with a custom serializer if you
write
> > one.
> >
> > I have recently finished writing a serializer that can serialize and
> > deserialize (marshall and unmarshall, if you prefer) arbitrary Java
> objects
> > (they don't have to be Beans) to and from XML with a few minor caveats:
> >
> > 1.  You have to implement an interface, XmlSerializable, that my package
> > provides.
> > 2.  You have to insert three boilerplate lines of code in your class,
> which
> > I provide.
> > 3.  If you do not provide a default (no-arg) constructor for your
> > XML-serializable class, you have to change one boilerplate line of code.
> > 4.  Private fields in a superclass that you do NOT have the code for
must
> be
> > serialized somewhat manually by implementing two small additional
methods.
> > This doesn't come up much in practice.  This is the only kind of field
> that
> > requires custom code, which is mostly boilerplate anyway.
> > 5.  Transient/final fields are not serialized, because they're, well,
> > transient/final :).
> > 6.  Additionally, my serializer can serialize multidimensional Java
> arrays,
> > but admittedly not in the SOAP style (yet).
> >
> > This is done through a tiny bit of deep magic with Java's reflection
API.
> > I've been spending the last couple of days inserting my Java<->XML
> > serializer into the IBM (now Apache) SOAP for Java package, and I have
> been
> > successful.  I'm now in the process of retrofitting my code, which
> contains
> > some of the same fixes as have been included in the new 2.0 release,
into
> > the 2.0 release (It still works under 2.0, but I don't want to reinvent
> the
> > wheel).  I may post a patch or two to the Apache 2.0 release in the next
> > couple of days for the community's review.
> >
> > In any case, this gives you characteristics VERY similar to Java object
> > serialization, in a very programmer-friendly manner.  Additionally, I
have
> > implemented an AutoSOAPMappingRegistry that, if you try to serialize an
> > object that does not already have a registered serializer, will generate
> one
> > using my serializer if possible.  This eliminates the need for you to
> hassle
> > registering a serializer for each type of object you want to send in a
> SOAP
> > message.
> >
> > Furthermore, on top of all this I have built a stubber that can take an
> > arbitrary Java interface and generate a
CORBA/RMI/Distributed-Objects-like
> > stub for it, meaning that you don't have to write 30 lines of code per
> SOAP
> > call.  For this to work, I had to munge serialized exceptions into the
> > SOAPFault detail element, but it works dandily.
> >
> > Sadly, I only got this working yesterday and it's not quite ready for
> public
> > posting.  If any of you folks are interested in taking a look at it,
send
> me
> > an email or post to the discussion list, and I will consider sending it
to
> > you or posting an alpha copy for evaluation.
> >
> > Best Regards,
> > -----
> >   Eric M. Dashofy <ed...@ics.uci.edu>
> >   Graduate Student Researcher, Information & Computer Science
> >   University of California, Irvine
> >   http://www.ics.uci.edu/~edashofy
> >
> > -----Original Message-----
> > From: Milind Gadre [mailto:milind@idiom.com]
> > Sent: Friday, August 18, 2000 12:29 PM
> > To: soap-user@xml.apache.org
> > Cc: soap@discuss.develop.com
> > Subject: SOAP Serialization
> >
> > Hello all, I am new to this slippery world of SOAP, so please enlighten
> > me if my questions have already been answered some other place. I am
> > having a hard time figuring out the logic behind SOAP serialization of
> > arbitrary Java objects. I have not been able to find relevant
> > documentation on the matter.
> >
> > My questions are:
> >
> > [1] How does SOAP serialization handle protected/private fields of
> > arbitrary objects? Does it override some security settings in order to
> > get access to the private/protected fields? In an earlier post to this
> > discussion group I described a stack trace from the XMI classes.
> >
> > [2] Similar to the readObject/writeObject logic of Java Serialization,
> > is it possible to intercept the SOAP serialization procedures to insert
> > custom logic? I see this as being critical to sending java objects down
> > the pipe.
> >
> > [3] If the above is not possible, then how can I extend the SOAP
> > serialization classes so as to perform custom logic *just prior* to
> > sending an object and *just after* receiving an object.
> >
> > [4] What about *transient* fields?
> >
> > It seems to me that if SOAP is to support a general purpose
> > serialization mechanism, an API that has at least some of the
> > extensibility and features of existing Java Serialization is a must.
> >
> > Thanks in advance for any help on this matter.
> >
> > Best regards...Milind
> > milind@idiom.com
> >
> >
>

Re: SOAP Serialization

[Cory Isaacson <ci...@capita2.com>]

I also see that I can use the literal xml encoding provided with soap to do
this, which does the translation to an XML string and parses again into a
dom automatically. This will work fine, but I wonder if its the most
efficient. Any comments?

For example, I noticed that with Java 1.2 you can use XMI, which I assume
does a binary rendition of an object. Would this be a smaller representation
of a DOM than converting it to a string and then back to a DOM? Maybe
converting to binary violates the concept of SOAP, but it seems like if you
are responsible for both sides the efficiencies gained would be worth it.

I noticed that the performance study done which was recently published on
this list was mostly complaining about the need to convert from binary to a
tag-delimited xml format, and could be 10 - 100 times slower (or something
like that). Is converting to binary using Base64 (like an email attachment)
a better way to go for situations like this?

I also noticed that you can write your own encoder, so I assume I could do
this and use Java serialization. Has anyone written a custom encoder? Is
there any sample code available?

Thanks,

Cory
----- Original Message -----
From: "Cory Isaacson" <ci...@capita2.com>
To: <so...@xml.apache.org>
Cc: <ed...@ics.uci.edu>
Sent: Sunday, August 20, 2000 9:01 AM
Subject: Re: SOAP Serialization


> Eric,
>
> This sounds very interesting. Does your serialization work similar to the
> current Apache SOAP implementation, in that each field must be declared in
> the bean and is then translated into an XML element?
>
> The reason I ask is that I have a need to transmit an entire XML document
> from a server to a client and back. The XML document is in a DOM before
its
> transmitted, and I need it in a DOM to use it. It seems I have the
following
> options:
>
> 1) I can convert to a a CDATA string and pass as a single parameter), and
> then re-parse the XML string into a DOM;
> 2) Try your serializer on the DOM itself.
>
> Can your serializer handle this last case? If not, is there a way to
simply
> serialize a DOM (as a binary Java class) and use Base64 to transmit it
> through SOAP? It seems like that would be more efficient as I wouldn't
have
> to re-parse the XML on the receiving side, but I have noticed that in some
> cases Java serialization is very slow and big.in the translation.
>
> Any other ideas as to how to do this efficiently?
>
> Thanks in advance,
>
> Cory
> ----- Original Message -----
> From: "Eric M. Dashofy" <ed...@ics.uci.edu>
> To: <so...@xml.apache.org>
> Sent: Friday, August 18, 2000 5:49 PM
> Subject: RE: SOAP Serialization
>
>
> >
> > Hello all!
> >
> > With the Apache SOAP for Java API, serializers are provided for the Java
> > basic types, some other types, and one-dimensional arrays of these
types.
> > Arbitrary objects can be serialized with a custom serializer if you
write
> > one.
> >
> > I have recently finished writing a serializer that can serialize and
> > deserialize (marshall and unmarshall, if you prefer) arbitrary Java
> objects
> > (they don't have to be Beans) to and from XML with a few minor caveats:
> >
> > 1.  You have to implement an interface, XmlSerializable, that my package
> > provides.
> > 2.  You have to insert three boilerplate lines of code in your class,
> which
> > I provide.
> > 3.  If you do not provide a default (no-arg) constructor for your
> > XML-serializable class, you have to change one boilerplate line of code.
> > 4.  Private fields in a superclass that you do NOT have the code for
must
> be
> > serialized somewhat manually by implementing two small additional
methods.
> > This doesn't come up much in practice.  This is the only kind of field
> that
> > requires custom code, which is mostly boilerplate anyway.
> > 5.  Transient/final fields are not serialized, because they're, well,
> > transient/final :).
> > 6.  Additionally, my serializer can serialize multidimensional Java
> arrays,
> > but admittedly not in the SOAP style (yet).
> >
> > This is done through a tiny bit of deep magic with Java's reflection
API.
> > I've been spending the last couple of days inserting my Java<->XML
> > serializer into the IBM (now Apache) SOAP for Java package, and I have
> been
> > successful.  I'm now in the process of retrofitting my code, which
> contains
> > some of the same fixes as have been included in the new 2.0 release,
into
> > the 2.0 release (It still works under 2.0, but I don't want to reinvent
> the
> > wheel).  I may post a patch or two to the Apache 2.0 release in the next
> > couple of days for the community's review.
> >
> > In any case, this gives you characteristics VERY similar to Java object
> > serialization, in a very programmer-friendly manner.  Additionally, I
have
> > implemented an AutoSOAPMappingRegistry that, if you try to serialize an
> > object that does not already have a registered serializer, will generate
> one
> > using my serializer if possible.  This eliminates the need for you to
> hassle
> > registering a serializer for each type of object you want to send in a
> SOAP
> > message.
> >
> > Furthermore, on top of all this I have built a stubber that can take an
> > arbitrary Java interface and generate a
CORBA/RMI/Distributed-Objects-like
> > stub for it, meaning that you don't have to write 30 lines of code per
> SOAP
> > call.  For this to work, I had to munge serialized exceptions into the
> > SOAPFault detail element, but it works dandily.
> >
> > Sadly, I only got this working yesterday and it's not quite ready for
> public
> > posting.  If any of you folks are interested in taking a look at it,
send
> me
> > an email or post to the discussion list, and I will consider sending it
to
> > you or posting an alpha copy for evaluation.
> >
> > Best Regards,
> > -----
> >   Eric M. Dashofy <ed...@ics.uci.edu>
> >   Graduate Student Researcher, Information & Computer Science
> >   University of California, Irvine
> >   http://www.ics.uci.edu/~edashofy
> >
> > -----Original Message-----
> > From: Milind Gadre [mailto:milind@idiom.com]
> > Sent: Friday, August 18, 2000 12:29 PM
> > To: soap-user@xml.apache.org
> > Cc: soap@discuss.develop.com
> > Subject: SOAP Serialization
> >
> > Hello all, I am new to this slippery world of SOAP, so please enlighten
> > me if my questions have already been answered some other place. I am
> > having a hard time figuring out the logic behind SOAP serialization of
> > arbitrary Java objects. I have not been able to find relevant
> > documentation on the matter.
> >
> > My questions are:
> >
> > [1] How does SOAP serialization handle protected/private fields of
> > arbitrary objects? Does it override some security settings in order to
> > get access to the private/protected fields? In an earlier post to this
> > discussion group I described a stack trace from the XMI classes.
> >
> > [2] Similar to the readObject/writeObject logic of Java Serialization,
> > is it possible to intercept the SOAP serialization procedures to insert
> > custom logic? I see this as being critical to sending java objects down
> > the pipe.
> >
> > [3] If the above is not possible, then how can I extend the SOAP
> > serialization classes so as to perform custom logic *just prior* to
> > sending an object and *just after* receiving an object.
> >
> > [4] What about *transient* fields?
> >
> > It seems to me that if SOAP is to support a general purpose
> > serialization mechanism, an API that has at least some of the
> > extensibility and features of existing Java Serialization is a must.
> >
> > Thanks in advance for any help on this matter.
> >
> > Best regards...Milind
> > milind@idiom.com
> >
> >
>

Re: SOAP Serialization

[Cory Isaacson <ci...@capita2.com>]

Eric,

This is very helpful. I think you're right, eventually there should be a
binary XML format which can solve the performance transmission problem, and
even in my tests now that is 90% of the time required, so I think you're
right -- the double-DOM on either end is small in perspective.

And yes, my intent is to have an identical DOM on both ends, and the SOAP
XML encoding does that just fine. Let me know when you complete work on the
binary XML format (again, just kidding).

Thanks,

Cory
----- Original Message -----
From: "Eric M. Dashofy" <ed...@ics.uci.edu>
To: <so...@xml.apache.org>
Sent: Monday, August 21, 2000 1:37 PM
Subject: RE: SOAP Serialization


> Cory:
>
> That's interesting.  Okay, now I'm delving into the realm of speculation,
> and be warned that this is just brainstorming, I don't know if what I'm
> saying is actually true:
>
> Now that I think about it, the double-DOMming that's going on is really
only
> slightly more expensive than just shoving the elements in the document
> unencoded, since the translation from XML-to-DOM (and vice-versa) only
> happens once.  The string encoding/decoding is an extra step, but it's not
> very expensive, since it's just a pass through the XML string.
>
> I see your point about performance and all.  If the question is, "Is there
a
> way I can serialize an XML document that I have in memory as a DOM tree to
a
> format that can be quickly deserialized into the identical DOM tree and is
> highly compact?  Java serialization tends to suck, so that's not an
option."
> I think the answer might be "not yet."  Of course, the canonical
serialized
> format for a DOM tree _is_ an XML document, so that's where the work has
> been done to date.  As XML was developed as a document markup language,
our
> uses of it (to serialize parameters over a network) are really a sort of
> misuse of the original intention of XML.  Of course, I'm not saying AT ALL
> that this isn't a great use of XML, it's just that the kind of efficiency
> problems you're talking about are not really addressed by the original
goals
> of XML.
>
> I've heard talk for a long time about a mythical, and as yet nonexistent,
> beast known as "the Wire-Markup-Language" that would provide a
> highly-efficient data markup language analogous to XML (and probably
> translatable to and from XML) but that used binary encoding and
> data-compression techniques instead of string-based encoding.  This sort
of
> thing would be an ideal enhancement for SOAP--you translate to XML, then
> compress/binary-encode to Wire-Markup-Language to save bits on the wire,
> then decompress to XML on the other end...giving you the best of all
worlds.
> As yet, this hasn't happened to my knowledge (wanna have a BOF? j/k).
>
> The Internet Gurus that I've had a chance to collaborate with argue that,
> when dealing with small documents like SOAP requests, the real
communication
> (time) cost is not in the number of bits sent over the wire, but in the
cost
> of setting up and tearing down the TCP connection, i.e. time to establish
> another TCP connection >> time to send one extra packet.  So, the real
> efficiency win will happen when all of this supports HTTP/1.1 properly and
> you can piggyback multiple requests on a single TCP connection.
>
> Again, this is purely brainstorming, but maybe it will clarify (or muddy)
> some issues for you.
>
> Best Regards,
> -----
>   Eric M. Dashofy <ed...@ics.uci.edu>
>   Graduate Student Researcher, Information & Computer Science
>   University of California, Irvine
>   http://www.ics.uci.edu/~edashofy
>
> -----Original Message-----
> From: Cory Isaacson [mailto:cisaacson@capita2.com]
> Sent: Monday, August 21, 2000 10:11 AM
> To: soap-user@xml.apache.org
> Subject: Re: SOAP Serialization
>
>
> Eric,
>
> Thanks for the info. I did check out the XML encoding, and it will work
for
> what I need, but it looks like SOAP is doing the "double DOMing" instead
of
> my code. This is easier, but probably will perform similarly. Any ideas on
> doing a true serialization of a DOM? Would it perform better? I know it
may
> not, as the normal Java serialization often makes the serialized object
much
> bigger than the original, and the communications cost is the mostly time
> intensive in my testing to date.
>
> Cory
> ----- Original Message -----
> From: "Eric M. Dashofy" <ed...@ics.uci.edu>
> To: <so...@xml.apache.org>
> Cc: <ci...@capita2.com>
> Sent: Monday, August 21, 2000 1:00 PM
> Subject: RE: SOAP Serialization
>
>
> >
> > No, my serializer does not require you to implement your Java objects
with
> > beans or declare each field to translate into an element.  Rather, to
make
> > an object XML-serializable with my serializer you only need to change
four
> > lines of code in your object.  Of course, you need to mark any
> > non-serializable fields as transient, but this would apply in any case.
> It
> > can serialize any field in an XML-serializable class, and any public or
> > protected field in a superclass.  If the XML-serializable class extends
a
> > non-XML-serializable class, you must write a small custom routine to
> > serialize private fields of the non-XML-serializalbe superclass, but
this
> > rarely occurs in practice.
> >
> > For your particular problem, I would NOT suggest using my serializer, as
> > Apache SOAP provides this capability for you.  You can use the Literal
XML
> > encoding type, which should be pretty efficient as you're not
> double-DOMming
> > your XML document.  I'm not sure exactly how this works (I haven't had
the
> > opportunity to test it out yet), but it looks pretty straightforward.
> >
> > Again, for your problem, try investigating the literal XML encoding
style.
> > My serializer is more for use when you have implemented an arbitrary
Java
> > data structure you want to easily XMLify and unXMLify.
> >
> > All My Best,
> > -----
> >   Eric M. Dashofy <ed...@ics.uci.edu>
> >   Graduate Student Researcher, Information & Computer Science
> >   University of California, Irvine
> >   http://www.ics.uci.edu/~edashofy
> >
> >
> > -----Original Message-----
> > From: Cory Isaacson [mailto:cisaacson@capita2.com]
> > Sent: Sunday, August 20, 2000 6:02 AM
> > To: soap-user@xml.apache.org
> > Cc: edashofy@ics.uci.edu
> > Subject: Re: SOAP Serialization
> >
> >
> > Eric,
> >
> > This sounds very interesting. Does your serialization work similar to
the
> > current Apache SOAP implementation, in that each field must be declared
in
> > the bean and is then translated into an XML element?
> >
> > The reason I ask is that I have a need to transmit an entire XML
document
> > from a server to a client and back. The XML document is in a DOM before
> its
> > transmitted, and I need it in a DOM to use it. It seems I have the
> following
> > options:
> >
> > 1) I can convert to a a CDATA string and pass as a single parameter),
and
> > then re-parse the XML string into a DOM;
> > 2) Try your serializer on the DOM itself.
> >
> > Can your serializer handle this last case? If not, is there a way to
> simply
> > serialize a DOM (as a binary Java class) and use Base64 to transmit it
> > through SOAP? It seems like that would be more efficient as I wouldn't
> have
> > to re-parse the XML on the receiving side, but I have noticed that in
some
> > cases Java serialization is very slow and big.in the translation.
> >
> > Any other ideas as to how to do this efficiently?
> >
> > Thanks in advance,
> >
> > Cory
> > ----- Original Message -----
> > From: "Eric M. Dashofy" <ed...@ics.uci.edu>
> > To: <so...@xml.apache.org>
> > Sent: Friday, August 18, 2000 5:49 PM
> > Subject: RE: SOAP Serialization
> >
> >
> > >
> > > Hello all!
> > >
> > > With the Apache SOAP for Java API, serializers are provided for the
Java
> > > basic types, some other types, and one-dimensional arrays of these
> types.
> > > Arbitrary objects can be serialized with a custom serializer if you
> write
> > > one.
> > >
> > > I have recently finished writing a serializer that can serialize and
> > > deserialize (marshall and unmarshall, if you prefer) arbitrary Java
> > objects
> > > (they don't have to be Beans) to and from XML with a few minor
caveats:
> > >
> > > 1.  You have to implement an interface, XmlSerializable, that my
package
> > > provides.
> > > 2.  You have to insert three boilerplate lines of code in your class,
> > which
> > > I provide.
> > > 3.  If you do not provide a default (no-arg) constructor for your
> > > XML-serializable class, you have to change one boilerplate line of
code.
> > > 4.  Private fields in a superclass that you do NOT have the code for
> must
> > be
> > > serialized somewhat manually by implementing two small additional
> methods.
> > > This doesn't come up much in practice.  This is the only kind of field
> > that
> > > requires custom code, which is mostly boilerplate anyway.
> > > 5.  Transient/final fields are not serialized, because they're, well,
> > > transient/final :).
> > > 6.  Additionally, my serializer can serialize multidimensional Java
> > arrays,
> > > but admittedly not in the SOAP style (yet).
> > >
> > > This is done through a tiny bit of deep magic with Java's reflection
> API.
> > > I've been spending the last couple of days inserting my Java<->XML
> > > serializer into the IBM (now Apache) SOAP for Java package, and I have
> > been
> > > successful.  I'm now in the process of retrofitting my code, which
> > contains
> > > some of the same fixes as have been included in the new 2.0 release,
> into
> > > the 2.0 release (It still works under 2.0, but I don't want to
reinvent
> > the
> > > wheel).  I may post a patch or two to the Apache 2.0 release in the
next
> > > couple of days for the community's review.
> > >
> > > In any case, this gives you characteristics VERY similar to Java
object
> > > serialization, in a very programmer-friendly manner.  Additionally, I
> have
> > > implemented an AutoSOAPMappingRegistry that, if you try to serialize
an
> > > object that does not already have a registered serializer, will
generate
> > one
> > > using my serializer if possible.  This eliminates the need for you to
> > hassle
> > > registering a serializer for each type of object you want to send in a
> > SOAP
> > > message.
> > >
> > > Furthermore, on top of all this I have built a stubber that can take
an
> > > arbitrary Java interface and generate a
> CORBA/RMI/Distributed-Objects-like
> > > stub for it, meaning that you don't have to write 30 lines of code per
> > SOAP
> > > call.  For this to work, I had to munge serialized exceptions into the
> > > SOAPFault detail element, but it works dandily.
> > >
> > > Sadly, I only got this working yesterday and it's not quite ready for
> > public
> > > posting.  If any of you folks are interested in taking a look at it,
> send
> > me
> > > an email or post to the discussion list, and I will consider sending
it
> to
> > > you or posting an alpha copy for evaluation.
> > >
> > > Best Regards,
> > > -----
> > >   Eric M. Dashofy <ed...@ics.uci.edu>
> > >   Graduate Student Researcher, Information & Computer Science
> > >   University of California, Irvine
> > >   http://www.ics.uci.edu/~edashofy
> > >
> > > -----Original Message-----
> > > From: Milind Gadre [mailto:milind@idiom.com]
> > > Sent: Friday, August 18, 2000 12:29 PM
> > > To: soap-user@xml.apache.org
> > > Cc: soap@discuss.develop.com
> > > Subject: SOAP Serialization
> > >
> > > Hello all, I am new to this slippery world of SOAP, so please
enlighten
> > > me if my questions have already been answered some other place. I am
> > > having a hard time figuring out the logic behind SOAP serialization of
> > > arbitrary Java objects. I have not been able to find relevant
> > > documentation on the matter.
> > >
> > > My questions are:
> > >
> > > [1] How does SOAP serialization handle protected/private fields of
> > > arbitrary objects? Does it override some security settings in order to
> > > get access to the private/protected fields? In an earlier post to this
> > > discussion group I described a stack trace from the XMI classes.
> > >
> > > [2] Similar to the readObject/writeObject logic of Java Serialization,
> > > is it possible to intercept the SOAP serialization procedures to
insert
> > > custom logic? I see this as being critical to sending java objects
down
> > > the pipe.
> > >
> > > [3] If the above is not possible, then how can I extend the SOAP
> > > serialization classes so as to perform custom logic *just prior* to
> > > sending an object and *just after* receiving an object.
> > >
> > > [4] What about *transient* fields?
> > >
> > > It seems to me that if SOAP is to support a general purpose
> > > serialization mechanism, an API that has at least some of the
> > > extensibility and features of existing Java Serialization is a must.
> > >
> > > Thanks in advance for any help on this matter.
> > >
> > > Best regards...Milind
> > > milind@idiom.com
> > >
> > >
> >
>

Re: SOAP Serialization

[George I Matkovits <ma...@uswest.net>]

IMHO you are correct on the overhead problem. I am currently testing  'SSL over
a URL Connection' version of XML-SOAP and see that with HTTP1.1's keep-alive
successive connections are not renegotiated  (this is what I expected) Samples
like the Calculator run over SSL very effectively. The calculator sample makes
multiple server calls from within one session. Standalone Tomcat does not
support 'keepalive' directly but the Apache/Tomcat combination does. We will
have more and more  bandwidth in the future (Iternet2) but the connection
'access time' will remain almost the same. IMHO support for HTTP1.1 and and
better SOAP functionality is more important then a slightly  reduced payload
size.
Regards - George

"Eric M. Dashofy" wrote:

> Cory:
>
> That's interesting.  Okay, now I'm delving into the realm of speculation,
> and be warned that this is just brainstorming, I don't know if what I'm
> saying is actually true:
>
> Now that I think about it, the double-DOMming that's going on is really only
> slightly more expensive than just shoving the elements in the document
> unencoded, since the translation from XML-to-DOM (and vice-versa) only
> happens once.  The string encoding/decoding is an extra step, but it's not
> very expensive, since it's just a pass through the XML string.
>
> I see your point about performance and all.  If the question is, "Is there a
> way I can serialize an XML document that I have in memory as a DOM tree to a
> format that can be quickly deserialized into the identical DOM tree and is
> highly compact?  Java serialization tends to suck, so that's not an option."
> I think the answer might be "not yet."  Of course, the canonical serialized
> format for a DOM tree _is_ an XML document, so that's where the work has
> been done to date.  As XML was developed as a document markup language, our
> uses of it (to serialize parameters over a network) are really a sort of
> misuse of the original intention of XML.  Of course, I'm not saying AT ALL
> that this isn't a great use of XML, it's just that the kind of efficiency
> problems you're talking about are not really addressed by the original goals
> of XML.
>
> I've heard talk for a long time about a mythical, and as yet nonexistent,
> beast known as "the Wire-Markup-Language" that would provide a
> highly-efficient data markup language analogous to XML (and probably
> translatable to and from XML) but that used binary encoding and
> data-compression techniques instead of string-based encoding.  This sort of
> thing would be an ideal enhancement for SOAP--you translate to XML, then
> compress/binary-encode to Wire-Markup-Language to save bits on the wire,
> then decompress to XML on the other end...giving you the best of all worlds.
> As yet, this hasn't happened to my knowledge (wanna have a BOF? j/k).
>
> The Internet Gurus that I've had a chance to collaborate with argue that,
> when dealing with small documents like SOAP requests, the real communication
> (time) cost is not in the number of bits sent over the wire, but in the cost
> of setting up and tearing down the TCP connection, i.e. time to establish
> another TCP connection >> time to send one extra packet.  So, the real
> efficiency win will happen when all of this supports HTTP/1.1 properly and
> you can piggyback multiple requests on a single TCP connection.
>
> Again, this is purely brainstorming, but maybe it will clarify (or muddy)
> some issues for you.
>
> Best Regards,
> -----
>   Eric M. Dashofy <ed...@ics.uci.edu>
>   Graduate Student Researcher, Information & Computer Science
>   University of California, Irvine
>   http://www.ics.uci.edu/~edashofy
>
> -----Original Message-----
> From: Cory Isaacson [mailto:cisaacson@capita2.com]
> Sent: Monday, August 21, 2000 10:11 AM
> To: soap-user@xml.apache.org
> Subject: Re: SOAP Serialization
>
> Eric,
>
> Thanks for the info. I did check out the XML encoding, and it will work for
> what I need, but it looks like SOAP is doing the "double DOMing" instead of
> my code. This is easier, but probably will perform similarly. Any ideas on
> doing a true serialization of a DOM? Would it perform better? I know it may
> not, as the normal Java serialization often makes the serialized object much
> bigger than the original, and the communications cost is the mostly time
> intensive in my testing to date.
>
> Cory
> ----- Original Message -----
> From: "Eric M. Dashofy" <ed...@ics.uci.edu>
> To: <so...@xml.apache.org>
> Cc: <ci...@capita2.com>
> Sent: Monday, August 21, 2000 1:00 PM
> Subject: RE: SOAP Serialization
>
> >
> > No, my serializer does not require you to implement your Java objects with
> > beans or declare each field to translate into an element.  Rather, to make
> > an object XML-serializable with my serializer you only need to change four
> > lines of code in your object.  Of course, you need to mark any
> > non-serializable fields as transient, but this would apply in any case.
> It
> > can serialize any field in an XML-serializable class, and any public or
> > protected field in a superclass.  If the XML-serializable class extends a
> > non-XML-serializable class, you must write a small custom routine to
> > serialize private fields of the non-XML-serializalbe superclass, but this
> > rarely occurs in practice.
> >
> > For your particular problem, I would NOT suggest using my serializer, as
> > Apache SOAP provides this capability for you.  You can use the Literal XML
> > encoding type, which should be pretty efficient as you're not
> double-DOMming
> > your XML document.  I'm not sure exactly how this works (I haven't had the
> > opportunity to test it out yet), but it looks pretty straightforward.
> >
> > Again, for your problem, try investigating the literal XML encoding style.
> > My serializer is more for use when you have implemented an arbitrary Java
> > data structure you want to easily XMLify and unXMLify.
> >
> > All My Best,
> > -----
> >   Eric M. Dashofy <ed...@ics.uci.edu>
> >   Graduate Student Researcher, Information & Computer Science
> >   University of California, Irvine
> >   http://www.ics.uci.edu/~edashofy
> >
> >
> > -----Original Message-----
> > From: Cory Isaacson [mailto:cisaacson@capita2.com]
> > Sent: Sunday, August 20, 2000 6:02 AM
> > To: soap-user@xml.apache.org
> > Cc: edashofy@ics.uci.edu
> > Subject: Re: SOAP Serialization
> >
> >
> > Eric,
> >
> > This sounds very interesting. Does your serialization work similar to the
> > current Apache SOAP implementation, in that each field must be declared in
> > the bean and is then translated into an XML element?
> >
> > The reason I ask is that I have a need to transmit an entire XML document
> > from a server to a client and back. The XML document is in a DOM before
> its
> > transmitted, and I need it in a DOM to use it. It seems I have the
> following
> > options:
> >
> > 1) I can convert to a a CDATA string and pass as a single parameter), and
> > then re-parse the XML string into a DOM;
> > 2) Try your serializer on the DOM itself.
> >
> > Can your serializer handle this last case? If not, is there a way to
> simply
> > serialize a DOM (as a binary Java class) and use Base64 to transmit it
> > through SOAP? It seems like that would be more efficient as I wouldn't
> have
> > to re-parse the XML on the receiving side, but I have noticed that in some
> > cases Java serialization is very slow and big.in the translation.
> >
> > Any other ideas as to how to do this efficiently?
> >
> > Thanks in advance,
> >
> > Cory
> > ----- Original Message -----
> > From: "Eric M. Dashofy" <ed...@ics.uci.edu>
> > To: <so...@xml.apache.org>
> > Sent: Friday, August 18, 2000 5:49 PM
> > Subject: RE: SOAP Serialization
> >
> >
> > >
> > > Hello all!
> > >
> > > With the Apache SOAP for Java API, serializers are provided for the Java
> > > basic types, some other types, and one-dimensional arrays of these
> types.
> > > Arbitrary objects can be serialized with a custom serializer if you
> write
> > > one.
> > >
> > > I have recently finished writing a serializer that can serialize and
> > > deserialize (marshall and unmarshall, if you prefer) arbitrary Java
> > objects
> > > (they don't have to be Beans) to and from XML with a few minor caveats:
> > >
> > > 1.  You have to implement an interface, XmlSerializable, that my package
> > > provides.
> > > 2.  You have to insert three boilerplate lines of code in your class,
> > which
> > > I provide.
> > > 3.  If you do not provide a default (no-arg) constructor for your
> > > XML-serializable class, you have to change one boilerplate line of code.
> > > 4.  Private fields in a superclass that you do NOT have the code for
> must
> > be
> > > serialized somewhat manually by implementing two small additional
> methods.
> > > This doesn't come up much in practice.  This is the only kind of field
> > that
> > > requires custom code, which is mostly boilerplate anyway.
> > > 5.  Transient/final fields are not serialized, because they're, well,
> > > transient/final :).
> > > 6.  Additionally, my serializer can serialize multidimensional Java
> > arrays,
> > > but admittedly not in the SOAP style (yet).
> > >
> > > This is done through a tiny bit of deep magic with Java's reflection
> API.
> > > I've been spending the last couple of days inserting my Java<->XML
> > > serializer into the IBM (now Apache) SOAP for Java package, and I have
> > been
> > > successful.  I'm now in the process of retrofitting my code, which
> > contains
> > > some of the same fixes as have been included in the new 2.0 release,
> into
> > > the 2.0 release (It still works under 2.0, but I don't want to reinvent
> > the
> > > wheel).  I may post a patch or two to the Apache 2.0 release in the next
> > > couple of days for the community's review.
> > >
> > > In any case, this gives you characteristics VERY similar to Java object
> > > serialization, in a very programmer-friendly manner.  Additionally, I
> have
> > > implemented an AutoSOAPMappingRegistry that, if you try to serialize an
> > > object that does not already have a registered serializer, will generate
> > one
> > > using my serializer if possible.  This eliminates the need for you to
> > hassle
> > > registering a serializer for each type of object you want to send in a
> > SOAP
> > > message.
> > >
> > > Furthermore, on top of all this I have built a stubber that can take an
> > > arbitrary Java interface and generate a
> CORBA/RMI/Distributed-Objects-like
> > > stub for it, meaning that you don't have to write 30 lines of code per
> > SOAP
> > > call.  For this to work, I had to munge serialized exceptions into the
> > > SOAPFault detail element, but it works dandily.
> > >
> > > Sadly, I only got this working yesterday and it's not quite ready for
> > public
> > > posting.  If any of you folks are interested in taking a look at it,
> send
> > me
> > > an email or post to the discussion list, and I will consider sending it
> to
> > > you or posting an alpha copy for evaluation.
> > >
> > > Best Regards,
> > > -----
> > >   Eric M. Dashofy <ed...@ics.uci.edu>
> > >   Graduate Student Researcher, Information & Computer Science
> > >   University of California, Irvine
> > >   http://www.ics.uci.edu/~edashofy
> > >
> > > -----Original Message-----
> > > From: Milind Gadre [mailto:milind@idiom.com]
> > > Sent: Friday, August 18, 2000 12:29 PM
> > > To: soap-user@xml.apache.org
> > > Cc: soap@discuss.develop.com
> > > Subject: SOAP Serialization
> > >
> > > Hello all, I am new to this slippery world of SOAP, so please enlighten
> > > me if my questions have already been answered some other place. I am
> > > having a hard time figuring out the logic behind SOAP serialization of
> > > arbitrary Java objects. I have not been able to find relevant
> > > documentation on the matter.
> > >
> > > My questions are:
> > >
> > > [1] How does SOAP serialization handle protected/private fields of
> > > arbitrary objects? Does it override some security settings in order to
> > > get access to the private/protected fields? In an earlier post to this
> > > discussion group I described a stack trace from the XMI classes.
> > >
> > > [2] Similar to the readObject/writeObject logic of Java Serialization,
> > > is it possible to intercept the SOAP serialization procedures to insert
> > > custom logic? I see this as being critical to sending java objects down
> > > the pipe.
> > >
> > > [3] If the above is not possible, then how can I extend the SOAP
> > > serialization classes so as to perform custom logic *just prior* to
> > > sending an object and *just after* receiving an object.
> > >
> > > [4] What about *transient* fields?
> > >
> > > It seems to me that if SOAP is to support a general purpose
> > > serialization mechanism, an API that has at least some of the
> > > extensibility and features of existing Java Serialization is a must.
> > >
> > > Thanks in advance for any help on this matter.
> > >
> > > Best regards...Milind
> > > milind@idiom.com
> > >
> > >
> >

Re: SOAP Serialization

[George I Matkovits <ma...@uswest.net>]

IMHO you are correct on the overhead problem. I am currently testing  'SSL over
a URL Connection' version of XML-SOAP and see that with HTTP1.1's keep-alive
successive connections are not renegotiated  (this is what I expected) Samples
like the Calculator run over SSL very effectively. The calculator sample makes
multiple server calls from within one session. Standalone Tomcat does not
support 'keepalive' directly but the Apache/Tomcat combination does. We will
have more and more  bandwidth in the future (Iternet2) but the connection
'access time' will remain almost the same. IMHO support for HTTP1.1 and and
better SOAP functionality is more important then a slightly  reduced payload
size.
Regards - George

"Eric M. Dashofy" wrote:

> Cory:
>
> That's interesting.  Okay, now I'm delving into the realm of speculation,
> and be warned that this is just brainstorming, I don't know if what I'm
> saying is actually true:
>
> Now that I think about it, the double-DOMming that's going on is really only
> slightly more expensive than just shoving the elements in the document
> unencoded, since the translation from XML-to-DOM (and vice-versa) only
> happens once.  The string encoding/decoding is an extra step, but it's not
> very expensive, since it's just a pass through the XML string.
>
> I see your point about performance and all.  If the question is, "Is there a
> way I can serialize an XML document that I have in memory as a DOM tree to a
> format that can be quickly deserialized into the identical DOM tree and is
> highly compact?  Java serialization tends to suck, so that's not an option."
> I think the answer might be "not yet."  Of course, the canonical serialized
> format for a DOM tree _is_ an XML document, so that's where the work has
> been done to date.  As XML was developed as a document markup language, our
> uses of it (to serialize parameters over a network) are really a sort of
> misuse of the original intention of XML.  Of course, I'm not saying AT ALL
> that this isn't a great use of XML, it's just that the kind of efficiency
> problems you're talking about are not really addressed by the original goals
> of XML.
>
> I've heard talk for a long time about a mythical, and as yet nonexistent,
> beast known as "the Wire-Markup-Language" that would provide a
> highly-efficient data markup language analogous to XML (and probably
> translatable to and from XML) but that used binary encoding and
> data-compression techniques instead of string-based encoding.  This sort of
> thing would be an ideal enhancement for SOAP--you translate to XML, then
> compress/binary-encode to Wire-Markup-Language to save bits on the wire,
> then decompress to XML on the other end...giving you the best of all worlds.
> As yet, this hasn't happened to my knowledge (wanna have a BOF? j/k).
>
> The Internet Gurus that I've had a chance to collaborate with argue that,
> when dealing with small documents like SOAP requests, the real communication
> (time) cost is not in the number of bits sent over the wire, but in the cost
> of setting up and tearing down the TCP connection, i.e. time to establish
> another TCP connection >> time to send one extra packet.  So, the real
> efficiency win will happen when all of this supports HTTP/1.1 properly and
> you can piggyback multiple requests on a single TCP connection.
>
> Again, this is purely brainstorming, but maybe it will clarify (or muddy)
> some issues for you.
>
> Best Regards,
> -----
>   Eric M. Dashofy <ed...@ics.uci.edu>
>   Graduate Student Researcher, Information & Computer Science
>   University of California, Irvine
>   http://www.ics.uci.edu/~edashofy
>
> -----Original Message-----
> From: Cory Isaacson [mailto:cisaacson@capita2.com]
> Sent: Monday, August 21, 2000 10:11 AM
> To: soap-user@xml.apache.org
> Subject: Re: SOAP Serialization
>
> Eric,
>
> Thanks for the info. I did check out the XML encoding, and it will work for
> what I need, but it looks like SOAP is doing the "double DOMing" instead of
> my code. This is easier, but probably will perform similarly. Any ideas on
> doing a true serialization of a DOM? Would it perform better? I know it may
> not, as the normal Java serialization often makes the serialized object much
> bigger than the original, and the communications cost is the mostly time
> intensive in my testing to date.
>
> Cory
> ----- Original Message -----
> From: "Eric M. Dashofy" <ed...@ics.uci.edu>
> To: <so...@xml.apache.org>
> Cc: <ci...@capita2.com>
> Sent: Monday, August 21, 2000 1:00 PM
> Subject: RE: SOAP Serialization
>
> >
> > No, my serializer does not require you to implement your Java objects with
> > beans or declare each field to translate into an element.  Rather, to make
> > an object XML-serializable with my serializer you only need to change four
> > lines of code in your object.  Of course, you need to mark any
> > non-serializable fields as transient, but this would apply in any case.
> It
> > can serialize any field in an XML-serializable class, and any public or
> > protected field in a superclass.  If the XML-serializable class extends a
> > non-XML-serializable class, you must write a small custom routine to
> > serialize private fields of the non-XML-serializalbe superclass, but this
> > rarely occurs in practice.
> >
> > For your particular problem, I would NOT suggest using my serializer, as
> > Apache SOAP provides this capability for you.  You can use the Literal XML
> > encoding type, which should be pretty efficient as you're not
> double-DOMming
> > your XML document.  I'm not sure exactly how this works (I haven't had the
> > opportunity to test it out yet), but it looks pretty straightforward.
> >
> > Again, for your problem, try investigating the literal XML encoding style.
> > My serializer is more for use when you have implemented an arbitrary Java
> > data structure you want to easily XMLify and unXMLify.
> >
> > All My Best,
> > -----
> >   Eric M. Dashofy <ed...@ics.uci.edu>
> >   Graduate Student Researcher, Information & Computer Science
> >   University of California, Irvine
> >   http://www.ics.uci.edu/~edashofy
> >
> >
> > -----Original Message-----
> > From: Cory Isaacson [mailto:cisaacson@capita2.com]
> > Sent: Sunday, August 20, 2000 6:02 AM
> > To: soap-user@xml.apache.org
> > Cc: edashofy@ics.uci.edu
> > Subject: Re: SOAP Serialization
> >
> >
> > Eric,
> >
> > This sounds very interesting. Does your serialization work similar to the
> > current Apache SOAP implementation, in that each field must be declared in
> > the bean and is then translated into an XML element?
> >
> > The reason I ask is that I have a need to transmit an entire XML document
> > from a server to a client and back. The XML document is in a DOM before
> its
> > transmitted, and I need it in a DOM to use it. It seems I have the
> following
> > options:
> >
> > 1) I can convert to a a CDATA string and pass as a single parameter), and
> > then re-parse the XML string into a DOM;
> > 2) Try your serializer on the DOM itself.
> >
> > Can your serializer handle this last case? If not, is there a way to
> simply
> > serialize a DOM (as a binary Java class) and use Base64 to transmit it
> > through SOAP? It seems like that would be more efficient as I wouldn't
> have
> > to re-parse the XML on the receiving side, but I have noticed that in some
> > cases Java serialization is very slow and big.in the translation.
> >
> > Any other ideas as to how to do this efficiently?
> >
> > Thanks in advance,
> >
> > Cory
> > ----- Original Message -----
> > From: "Eric M. Dashofy" <ed...@ics.uci.edu>
> > To: <so...@xml.apache.org>
> > Sent: Friday, August 18, 2000 5:49 PM
> > Subject: RE: SOAP Serialization
> >
> >
> > >
> > > Hello all!
> > >
> > > With the Apache SOAP for Java API, serializers are provided for the Java
> > > basic types, some other types, and one-dimensional arrays of these
> types.
> > > Arbitrary objects can be serialized with a custom serializer if you
> write
> > > one.
> > >
> > > I have recently finished writing a serializer that can serialize and
> > > deserialize (marshall and unmarshall, if you prefer) arbitrary Java
> > objects
> > > (they don't have to be Beans) to and from XML with a few minor caveats:
> > >
> > > 1.  You have to implement an interface, XmlSerializable, that my package
> > > provides.
> > > 2.  You have to insert three boilerplate lines of code in your class,
> > which
> > > I provide.
> > > 3.  If you do not provide a default (no-arg) constructor for your
> > > XML-serializable class, you have to change one boilerplate line of code.
> > > 4.  Private fields in a superclass that you do NOT have the code for
> must
> > be
> > > serialized somewhat manually by implementing two small additional
> methods.
> > > This doesn't come up much in practice.  This is the only kind of field
> > that
> > > requires custom code, which is mostly boilerplate anyway.
> > > 5.  Transient/final fields are not serialized, because they're, well,
> > > transient/final :).
> > > 6.  Additionally, my serializer can serialize multidimensional Java
> > arrays,
> > > but admittedly not in the SOAP style (yet).
> > >
> > > This is done through a tiny bit of deep magic with Java's reflection
> API.
> > > I've been spending the last couple of days inserting my Java<->XML
> > > serializer into the IBM (now Apache) SOAP for Java package, and I have
> > been
> > > successful.  I'm now in the process of retrofitting my code, which
> > contains
> > > some of the same fixes as have been included in the new 2.0 release,
> into
> > > the 2.0 release (It still works under 2.0, but I don't want to reinvent
> > the
> > > wheel).  I may post a patch or two to the Apache 2.0 release in the next
> > > couple of days for the community's review.
> > >
> > > In any case, this gives you characteristics VERY similar to Java object
> > > serialization, in a very programmer-friendly manner.  Additionally, I
> have
> > > implemented an AutoSOAPMappingRegistry that, if you try to serialize an
> > > object that does not already have a registered serializer, will generate
> > one
> > > using my serializer if possible.  This eliminates the need for you to
> > hassle
> > > registering a serializer for each type of object you want to send in a
> > SOAP
> > > message.
> > >
> > > Furthermore, on top of all this I have built a stubber that can take an
> > > arbitrary Java interface and generate a
> CORBA/RMI/Distributed-Objects-like
> > > stub for it, meaning that you don't have to write 30 lines of code per
> > SOAP
> > > call.  For this to work, I had to munge serialized exceptions into the
> > > SOAPFault detail element, but it works dandily.
> > >
> > > Sadly, I only got this working yesterday and it's not quite ready for
> > public
> > > posting.  If any of you folks are interested in taking a look at it,
> send
> > me
> > > an email or post to the discussion list, and I will consider sending it
> to
> > > you or posting an alpha copy for evaluation.
> > >
> > > Best Regards,
> > > -----
> > >   Eric M. Dashofy <ed...@ics.uci.edu>
> > >   Graduate Student Researcher, Information & Computer Science
> > >   University of California, Irvine
> > >   http://www.ics.uci.edu/~edashofy
> > >
> > > -----Original Message-----
> > > From: Milind Gadre [mailto:milind@idiom.com]
> > > Sent: Friday, August 18, 2000 12:29 PM
> > > To: soap-user@xml.apache.org
> > > Cc: soap@discuss.develop.com
> > > Subject: SOAP Serialization
> > >
> > > Hello all, I am new to this slippery world of SOAP, so please enlighten
> > > me if my questions have already been answered some other place. I am
> > > having a hard time figuring out the logic behind SOAP serialization of
> > > arbitrary Java objects. I have not been able to find relevant
> > > documentation on the matter.
> > >
> > > My questions are:
> > >
> > > [1] How does SOAP serialization handle protected/private fields of
> > > arbitrary objects? Does it override some security settings in order to
> > > get access to the private/protected fields? In an earlier post to this
> > > discussion group I described a stack trace from the XMI classes.
> > >
> > > [2] Similar to the readObject/writeObject logic of Java Serialization,
> > > is it possible to intercept the SOAP serialization procedures to insert
> > > custom logic? I see this as being critical to sending java objects down
> > > the pipe.
> > >
> > > [3] If the above is not possible, then how can I extend the SOAP
> > > serialization classes so as to perform custom logic *just prior* to
> > > sending an object and *just after* receiving an object.
> > >
> > > [4] What about *transient* fields?
> > >
> > > It seems to me that if SOAP is to support a general purpose
> > > serialization mechanism, an API that has at least some of the
> > > extensibility and features of existing Java Serialization is a must.
> > >
> > > Thanks in advance for any help on this matter.
> > >
> > > Best regards...Milind
> > > milind@idiom.com
> > >
> > >
> >

Re: SOAP Serialization

[Cory Isaacson <ci...@capita2.com>]

Eric,

This is very helpful. I think you're right, eventually there should be a
binary XML format which can solve the performance transmission problem, and
even in my tests now that is 90% of the time required, so I think you're
right -- the double-DOM on either end is small in perspective.

And yes, my intent is to have an identical DOM on both ends, and the SOAP
XML encoding does that just fine. Let me know when you complete work on the
binary XML format (again, just kidding).

Thanks,

Cory
----- Original Message -----
From: "Eric M. Dashofy" <ed...@ics.uci.edu>
To: <so...@xml.apache.org>
Sent: Monday, August 21, 2000 1:37 PM
Subject: RE: SOAP Serialization


> Cory:
>
> That's interesting.  Okay, now I'm delving into the realm of speculation,
> and be warned that this is just brainstorming, I don't know if what I'm
> saying is actually true:
>
> Now that I think about it, the double-DOMming that's going on is really
only
> slightly more expensive than just shoving the elements in the document
> unencoded, since the translation from XML-to-DOM (and vice-versa) only
> happens once.  The string encoding/decoding is an extra step, but it's not
> very expensive, since it's just a pass through the XML string.
>
> I see your point about performance and all.  If the question is, "Is there
a
> way I can serialize an XML document that I have in memory as a DOM tree to
a
> format that can be quickly deserialized into the identical DOM tree and is
> highly compact?  Java serialization tends to suck, so that's not an
option."
> I think the answer might be "not yet."  Of course, the canonical
serialized
> format for a DOM tree _is_ an XML document, so that's where the work has
> been done to date.  As XML was developed as a document markup language,
our
> uses of it (to serialize parameters over a network) are really a sort of
> misuse of the original intention of XML.  Of course, I'm not saying AT ALL
> that this isn't a great use of XML, it's just that the kind of efficiency
> problems you're talking about are not really addressed by the original
goals
> of XML.
>
> I've heard talk for a long time about a mythical, and as yet nonexistent,
> beast known as "the Wire-Markup-Language" that would provide a
> highly-efficient data markup language analogous to XML (and probably
> translatable to and from XML) but that used binary encoding and
> data-compression techniques instead of string-based encoding.  This sort
of
> thing would be an ideal enhancement for SOAP--you translate to XML, then
> compress/binary-encode to Wire-Markup-Language to save bits on the wire,
> then decompress to XML on the other end...giving you the best of all
worlds.
> As yet, this hasn't happened to my knowledge (wanna have a BOF? j/k).
>
> The Internet Gurus that I've had a chance to collaborate with argue that,
> when dealing with small documents like SOAP requests, the real
communication
> (time) cost is not in the number of bits sent over the wire, but in the
cost
> of setting up and tearing down the TCP connection, i.e. time to establish
> another TCP connection >> time to send one extra packet.  So, the real
> efficiency win will happen when all of this supports HTTP/1.1 properly and
> you can piggyback multiple requests on a single TCP connection.
>
> Again, this is purely brainstorming, but maybe it will clarify (or muddy)
> some issues for you.
>
> Best Regards,
> -----
>   Eric M. Dashofy <ed...@ics.uci.edu>
>   Graduate Student Researcher, Information & Computer Science
>   University of California, Irvine
>   http://www.ics.uci.edu/~edashofy
>
> -----Original Message-----
> From: Cory Isaacson [mailto:cisaacson@capita2.com]
> Sent: Monday, August 21, 2000 10:11 AM
> To: soap-user@xml.apache.org
> Subject: Re: SOAP Serialization
>
>
> Eric,
>
> Thanks for the info. I did check out the XML encoding, and it will work
for
> what I need, but it looks like SOAP is doing the "double DOMing" instead
of
> my code. This is easier, but probably will perform similarly. Any ideas on
> doing a true serialization of a DOM? Would it perform better? I know it
may
> not, as the normal Java serialization often makes the serialized object
much
> bigger than the original, and the communications cost is the mostly time
> intensive in my testing to date.
>
> Cory
> ----- Original Message -----
> From: "Eric M. Dashofy" <ed...@ics.uci.edu>
> To: <so...@xml.apache.org>
> Cc: <ci...@capita2.com>
> Sent: Monday, August 21, 2000 1:00 PM
> Subject: RE: SOAP Serialization
>
>
> >
> > No, my serializer does not require you to implement your Java objects
with
> > beans or declare each field to translate into an element.  Rather, to
make
> > an object XML-serializable with my serializer you only need to change
four
> > lines of code in your object.  Of course, you need to mark any
> > non-serializable fields as transient, but this would apply in any case.
> It
> > can serialize any field in an XML-serializable class, and any public or
> > protected field in a superclass.  If the XML-serializable class extends
a
> > non-XML-serializable class, you must write a small custom routine to
> > serialize private fields of the non-XML-serializalbe superclass, but
this
> > rarely occurs in practice.
> >
> > For your particular problem, I would NOT suggest using my serializer, as
> > Apache SOAP provides this capability for you.  You can use the Literal
XML
> > encoding type, which should be pretty efficient as you're not
> double-DOMming
> > your XML document.  I'm not sure exactly how this works (I haven't had
the
> > opportunity to test it out yet), but it looks pretty straightforward.
> >
> > Again, for your problem, try investigating the literal XML encoding
style.
> > My serializer is more for use when you have implemented an arbitrary
Java
> > data structure you want to easily XMLify and unXMLify.
> >
> > All My Best,
> > -----
> >   Eric M. Dashofy <ed...@ics.uci.edu>
> >   Graduate Student Researcher, Information & Computer Science
> >   University of California, Irvine
> >   http://www.ics.uci.edu/~edashofy
> >
> >
> > -----Original Message-----
> > From: Cory Isaacson [mailto:cisaacson@capita2.com]
> > Sent: Sunday, August 20, 2000 6:02 AM
> > To: soap-user@xml.apache.org
> > Cc: edashofy@ics.uci.edu
> > Subject: Re: SOAP Serialization
> >
> >
> > Eric,
> >
> > This sounds very interesting. Does your serialization work similar to
the
> > current Apache SOAP implementation, in that each field must be declared
in
> > the bean and is then translated into an XML element?
> >
> > The reason I ask is that I have a need to transmit an entire XML
document
> > from a server to a client and back. The XML document is in a DOM before
> its
> > transmitted, and I need it in a DOM to use it. It seems I have the
> following
> > options:
> >
> > 1) I can convert to a a CDATA string and pass as a single parameter),
and
> > then re-parse the XML string into a DOM;
> > 2) Try your serializer on the DOM itself.
> >
> > Can your serializer handle this last case? If not, is there a way to
> simply
> > serialize a DOM (as a binary Java class) and use Base64 to transmit it
> > through SOAP? It seems like that would be more efficient as I wouldn't
> have
> > to re-parse the XML on the receiving side, but I have noticed that in
some
> > cases Java serialization is very slow and big.in the translation.
> >
> > Any other ideas as to how to do this efficiently?
> >
> > Thanks in advance,
> >
> > Cory
> > ----- Original Message -----
> > From: "Eric M. Dashofy" <ed...@ics.uci.edu>
> > To: <so...@xml.apache.org>
> > Sent: Friday, August 18, 2000 5:49 PM
> > Subject: RE: SOAP Serialization
> >
> >
> > >
> > > Hello all!
> > >
> > > With the Apache SOAP for Java API, serializers are provided for the
Java
> > > basic types, some other types, and one-dimensional arrays of these
> types.
> > > Arbitrary objects can be serialized with a custom serializer if you
> write
> > > one.
> > >
> > > I have recently finished writing a serializer that can serialize and
> > > deserialize (marshall and unmarshall, if you prefer) arbitrary Java
> > objects
> > > (they don't have to be Beans) to and from XML with a few minor
caveats:
> > >
> > > 1.  You have to implement an interface, XmlSerializable, that my
package
> > > provides.
> > > 2.  You have to insert three boilerplate lines of code in your class,
> > which
> > > I provide.
> > > 3.  If you do not provide a default (no-arg) constructor for your
> > > XML-serializable class, you have to change one boilerplate line of
code.
> > > 4.  Private fields in a superclass that you do NOT have the code for
> must
> > be
> > > serialized somewhat manually by implementing two small additional
> methods.
> > > This doesn't come up much in practice.  This is the only kind of field
> > that
> > > requires custom code, which is mostly boilerplate anyway.
> > > 5.  Transient/final fields are not serialized, because they're, well,
> > > transient/final :).
> > > 6.  Additionally, my serializer can serialize multidimensional Java
> > arrays,
> > > but admittedly not in the SOAP style (yet).
> > >
> > > This is done through a tiny bit of deep magic with Java's reflection
> API.
> > > I've been spending the last couple of days inserting my Java<->XML
> > > serializer into the IBM (now Apache) SOAP for Java package, and I have
> > been
> > > successful.  I'm now in the process of retrofitting my code, which
> > contains
> > > some of the same fixes as have been included in the new 2.0 release,
> into
> > > the 2.0 release (It still works under 2.0, but I don't want to
reinvent
> > the
> > > wheel).  I may post a patch or two to the Apache 2.0 release in the
next
> > > couple of days for the community's review.
> > >
> > > In any case, this gives you characteristics VERY similar to Java
object
> > > serialization, in a very programmer-friendly manner.  Additionally, I
> have
> > > implemented an AutoSOAPMappingRegistry that, if you try to serialize
an
> > > object that does not already have a registered serializer, will
generate
> > one
> > > using my serializer if possible.  This eliminates the need for you to
> > hassle
> > > registering a serializer for each type of object you want to send in a
> > SOAP
> > > message.
> > >
> > > Furthermore, on top of all this I have built a stubber that can take
an
> > > arbitrary Java interface and generate a
> CORBA/RMI/Distributed-Objects-like
> > > stub for it, meaning that you don't have to write 30 lines of code per
> > SOAP
> > > call.  For this to work, I had to munge serialized exceptions into the
> > > SOAPFault detail element, but it works dandily.
> > >
> > > Sadly, I only got this working yesterday and it's not quite ready for
> > public
> > > posting.  If any of you folks are interested in taking a look at it,
> send
> > me
> > > an email or post to the discussion list, and I will consider sending
it
> to
> > > you or posting an alpha copy for evaluation.
> > >
> > > Best Regards,
> > > -----
> > >   Eric M. Dashofy <ed...@ics.uci.edu>
> > >   Graduate Student Researcher, Information & Computer Science
> > >   University of California, Irvine
> > >   http://www.ics.uci.edu/~edashofy
> > >
> > > -----Original Message-----
> > > From: Milind Gadre [mailto:milind@idiom.com]
> > > Sent: Friday, August 18, 2000 12:29 PM
> > > To: soap-user@xml.apache.org
> > > Cc: soap@discuss.develop.com
> > > Subject: SOAP Serialization
> > >
> > > Hello all, I am new to this slippery world of SOAP, so please
enlighten
> > > me if my questions have already been answered some other place. I am
> > > having a hard time figuring out the logic behind SOAP serialization of
> > > arbitrary Java objects. I have not been able to find relevant
> > > documentation on the matter.
> > >
> > > My questions are:
> > >
> > > [1] How does SOAP serialization handle protected/private fields of
> > > arbitrary objects? Does it override some security settings in order to
> > > get access to the private/protected fields? In an earlier post to this
> > > discussion group I described a stack trace from the XMI classes.
> > >
> > > [2] Similar to the readObject/writeObject logic of Java Serialization,
> > > is it possible to intercept the SOAP serialization procedures to
insert
> > > custom logic? I see this as being critical to sending java objects
down
> > > the pipe.
> > >
> > > [3] If the above is not possible, then how can I extend the SOAP
> > > serialization classes so as to perform custom logic *just prior* to
> > > sending an object and *just after* receiving an object.
> > >
> > > [4] What about *transient* fields?
> > >
> > > It seems to me that if SOAP is to support a general purpose
> > > serialization mechanism, an API that has at least some of the
> > > extensibility and features of existing Java Serialization is a must.
> > >
> > > Thanks in advance for any help on this matter.
> > >
> > > Best regards...Milind
> > > milind@idiom.com
> > >
> > >
> >
>

RE: SOAP Serialization

["Eric M. Dashofy" <ed...@ics.uci.edu>]

Cory:

That's interesting.  Okay, now I'm delving into the realm of speculation,
and be warned that this is just brainstorming, I don't know if what I'm
saying is actually true:

Now that I think about it, the double-DOMming that's going on is really only
slightly more expensive than just shoving the elements in the document
unencoded, since the translation from XML-to-DOM (and vice-versa) only
happens once.  The string encoding/decoding is an extra step, but it's not
very expensive, since it's just a pass through the XML string.

I see your point about performance and all.  If the question is, "Is there a
way I can serialize an XML document that I have in memory as a DOM tree to a
format that can be quickly deserialized into the identical DOM tree and is
highly compact?  Java serialization tends to suck, so that's not an option."
I think the answer might be "not yet."  Of course, the canonical serialized
format for a DOM tree _is_ an XML document, so that's where the work has
been done to date.  As XML was developed as a document markup language, our
uses of it (to serialize parameters over a network) are really a sort of
misuse of the original intention of XML.  Of course, I'm not saying AT ALL
that this isn't a great use of XML, it's just that the kind of efficiency
problems you're talking about are not really addressed by the original goals
of XML.

I've heard talk for a long time about a mythical, and as yet nonexistent,
beast known as "the Wire-Markup-Language" that would provide a
highly-efficient data markup language analogous to XML (and probably
translatable to and from XML) but that used binary encoding and
data-compression techniques instead of string-based encoding.  This sort of
thing would be an ideal enhancement for SOAP--you translate to XML, then
compress/binary-encode to Wire-Markup-Language to save bits on the wire,
then decompress to XML on the other end...giving you the best of all worlds.
As yet, this hasn't happened to my knowledge (wanna have a BOF? j/k).

The Internet Gurus that I've had a chance to collaborate with argue that,
when dealing with small documents like SOAP requests, the real communication
(time) cost is not in the number of bits sent over the wire, but in the cost
of setting up and tearing down the TCP connection, i.e. time to establish
another TCP connection >> time to send one extra packet.  So, the real
efficiency win will happen when all of this supports HTTP/1.1 properly and
you can piggyback multiple requests on a single TCP connection.

Again, this is purely brainstorming, but maybe it will clarify (or muddy)
some issues for you.

Best Regards,
-----
  Eric M. Dashofy <ed...@ics.uci.edu>
  Graduate Student Researcher, Information & Computer Science
  University of California, Irvine
  http://www.ics.uci.edu/~edashofy

-----Original Message-----
From: Cory Isaacson [mailto:cisaacson@capita2.com]
Sent: Monday, August 21, 2000 10:11 AM
To: soap-user@xml.apache.org
Subject: Re: SOAP Serialization


Eric,

Thanks for the info. I did check out the XML encoding, and it will work for
what I need, but it looks like SOAP is doing the "double DOMing" instead of
my code. This is easier, but probably will perform similarly. Any ideas on
doing a true serialization of a DOM? Would it perform better? I know it may
not, as the normal Java serialization often makes the serialized object much
bigger than the original, and the communications cost is the mostly time
intensive in my testing to date.

Cory
----- Original Message -----
From: "Eric M. Dashofy" <ed...@ics.uci.edu>
To: <so...@xml.apache.org>
Cc: <ci...@capita2.com>
Sent: Monday, August 21, 2000 1:00 PM
Subject: RE: SOAP Serialization


>
> No, my serializer does not require you to implement your Java objects with
> beans or declare each field to translate into an element.  Rather, to make
> an object XML-serializable with my serializer you only need to change four
> lines of code in your object.  Of course, you need to mark any
> non-serializable fields as transient, but this would apply in any case.
It
> can serialize any field in an XML-serializable class, and any public or
> protected field in a superclass.  If the XML-serializable class extends a
> non-XML-serializable class, you must write a small custom routine to
> serialize private fields of the non-XML-serializalbe superclass, but this
> rarely occurs in practice.
>
> For your particular problem, I would NOT suggest using my serializer, as
> Apache SOAP provides this capability for you.  You can use the Literal XML
> encoding type, which should be pretty efficient as you're not
double-DOMming
> your XML document.  I'm not sure exactly how this works (I haven't had the
> opportunity to test it out yet), but it looks pretty straightforward.
>
> Again, for your problem, try investigating the literal XML encoding style.
> My serializer is more for use when you have implemented an arbitrary Java
> data structure you want to easily XMLify and unXMLify.
>
> All My Best,
> -----
>   Eric M. Dashofy <ed...@ics.uci.edu>
>   Graduate Student Researcher, Information & Computer Science
>   University of California, Irvine
>   http://www.ics.uci.edu/~edashofy
>
>
> -----Original Message-----
> From: Cory Isaacson [mailto:cisaacson@capita2.com]
> Sent: Sunday, August 20, 2000 6:02 AM
> To: soap-user@xml.apache.org
> Cc: edashofy@ics.uci.edu
> Subject: Re: SOAP Serialization
>
>
> Eric,
>
> This sounds very interesting. Does your serialization work similar to the
> current Apache SOAP implementation, in that each field must be declared in
> the bean and is then translated into an XML element?
>
> The reason I ask is that I have a need to transmit an entire XML document
> from a server to a client and back. The XML document is in a DOM before
its
> transmitted, and I need it in a DOM to use it. It seems I have the
following
> options:
>
> 1) I can convert to a a CDATA string and pass as a single parameter), and
> then re-parse the XML string into a DOM;
> 2) Try your serializer on the DOM itself.
>
> Can your serializer handle this last case? If not, is there a way to
simply
> serialize a DOM (as a binary Java class) and use Base64 to transmit it
> through SOAP? It seems like that would be more efficient as I wouldn't
have
> to re-parse the XML on the receiving side, but I have noticed that in some
> cases Java serialization is very slow and big.in the translation.
>
> Any other ideas as to how to do this efficiently?
>
> Thanks in advance,
>
> Cory
> ----- Original Message -----
> From: "Eric M. Dashofy" <ed...@ics.uci.edu>
> To: <so...@xml.apache.org>
> Sent: Friday, August 18, 2000 5:49 PM
> Subject: RE: SOAP Serialization
>
>
> >
> > Hello all!
> >
> > With the Apache SOAP for Java API, serializers are provided for the Java
> > basic types, some other types, and one-dimensional arrays of these
types.
> > Arbitrary objects can be serialized with a custom serializer if you
write
> > one.
> >
> > I have recently finished writing a serializer that can serialize and
> > deserialize (marshall and unmarshall, if you prefer) arbitrary Java
> objects
> > (they don't have to be Beans) to and from XML with a few minor caveats:
> >
> > 1.  You have to implement an interface, XmlSerializable, that my package
> > provides.
> > 2.  You have to insert three boilerplate lines of code in your class,
> which
> > I provide.
> > 3.  If you do not provide a default (no-arg) constructor for your
> > XML-serializable class, you have to change one boilerplate line of code.
> > 4.  Private fields in a superclass that you do NOT have the code for
must
> be
> > serialized somewhat manually by implementing two small additional
methods.
> > This doesn't come up much in practice.  This is the only kind of field
> that
> > requires custom code, which is mostly boilerplate anyway.
> > 5.  Transient/final fields are not serialized, because they're, well,
> > transient/final :).
> > 6.  Additionally, my serializer can serialize multidimensional Java
> arrays,
> > but admittedly not in the SOAP style (yet).
> >
> > This is done through a tiny bit of deep magic with Java's reflection
API.
> > I've been spending the last couple of days inserting my Java<->XML
> > serializer into the IBM (now Apache) SOAP for Java package, and I have
> been
> > successful.  I'm now in the process of retrofitting my code, which
> contains
> > some of the same fixes as have been included in the new 2.0 release,
into
> > the 2.0 release (It still works under 2.0, but I don't want to reinvent
> the
> > wheel).  I may post a patch or two to the Apache 2.0 release in the next
> > couple of days for the community's review.
> >
> > In any case, this gives you characteristics VERY similar to Java object
> > serialization, in a very programmer-friendly manner.  Additionally, I
have
> > implemented an AutoSOAPMappingRegistry that, if you try to serialize an
> > object that does not already have a registered serializer, will generate
> one
> > using my serializer if possible.  This eliminates the need for you to
> hassle
> > registering a serializer for each type of object you want to send in a
> SOAP
> > message.
> >
> > Furthermore, on top of all this I have built a stubber that can take an
> > arbitrary Java interface and generate a
CORBA/RMI/Distributed-Objects-like
> > stub for it, meaning that you don't have to write 30 lines of code per
> SOAP
> > call.  For this to work, I had to munge serialized exceptions into the
> > SOAPFault detail element, but it works dandily.
> >
> > Sadly, I only got this working yesterday and it's not quite ready for
> public
> > posting.  If any of you folks are interested in taking a look at it,
send
> me
> > an email or post to the discussion list, and I will consider sending it
to
> > you or posting an alpha copy for evaluation.
> >
> > Best Regards,
> > -----
> >   Eric M. Dashofy <ed...@ics.uci.edu>
> >   Graduate Student Researcher, Information & Computer Science
> >   University of California, Irvine
> >   http://www.ics.uci.edu/~edashofy
> >
> > -----Original Message-----
> > From: Milind Gadre [mailto:milind@idiom.com]
> > Sent: Friday, August 18, 2000 12:29 PM
> > To: soap-user@xml.apache.org
> > Cc: soap@discuss.develop.com
> > Subject: SOAP Serialization
> >
> > Hello all, I am new to this slippery world of SOAP, so please enlighten
> > me if my questions have already been answered some other place. I am
> > having a hard time figuring out the logic behind SOAP serialization of
> > arbitrary Java objects. I have not been able to find relevant
> > documentation on the matter.
> >
> > My questions are:
> >
> > [1] How does SOAP serialization handle protected/private fields of
> > arbitrary objects? Does it override some security settings in order to
> > get access to the private/protected fields? In an earlier post to this
> > discussion group I described a stack trace from the XMI classes.
> >
> > [2] Similar to the readObject/writeObject logic of Java Serialization,
> > is it possible to intercept the SOAP serialization procedures to insert
> > custom logic? I see this as being critical to sending java objects down
> > the pipe.
> >
> > [3] If the above is not possible, then how can I extend the SOAP
> > serialization classes so as to perform custom logic *just prior* to
> > sending an object and *just after* receiving an object.
> >
> > [4] What about *transient* fields?
> >
> > It seems to me that if SOAP is to support a general purpose
> > serialization mechanism, an API that has at least some of the
> > extensibility and features of existing Java Serialization is a must.
> >
> > Thanks in advance for any help on this matter.
> >
> > Best regards...Milind
> > milind@idiom.com
> >
> >
>

RE: SOAP Serialization

["Eric M. Dashofy" <ed...@ics.uci.edu>]

Cory:

That's interesting.  Okay, now I'm delving into the realm of speculation,
and be warned that this is just brainstorming, I don't know if what I'm
saying is actually true:

Now that I think about it, the double-DOMming that's going on is really only
slightly more expensive than just shoving the elements in the document
unencoded, since the translation from XML-to-DOM (and vice-versa) only
happens once.  The string encoding/decoding is an extra step, but it's not
very expensive, since it's just a pass through the XML string.

I see your point about performance and all.  If the question is, "Is there a
way I can serialize an XML document that I have in memory as a DOM tree to a
format that can be quickly deserialized into the identical DOM tree and is
highly compact?  Java serialization tends to suck, so that's not an option."
I think the answer might be "not yet."  Of course, the canonical serialized
format for a DOM tree _is_ an XML document, so that's where the work has
been done to date.  As XML was developed as a document markup language, our
uses of it (to serialize parameters over a network) are really a sort of
misuse of the original intention of XML.  Of course, I'm not saying AT ALL
that this isn't a great use of XML, it's just that the kind of efficiency
problems you're talking about are not really addressed by the original goals
of XML.

I've heard talk for a long time about a mythical, and as yet nonexistent,
beast known as "the Wire-Markup-Language" that would provide a
highly-efficient data markup language analogous to XML (and probably
translatable to and from XML) but that used binary encoding and
data-compression techniques instead of string-based encoding.  This sort of
thing would be an ideal enhancement for SOAP--you translate to XML, then
compress/binary-encode to Wire-Markup-Language to save bits on the wire,
then decompress to XML on the other end...giving you the best of all worlds.
As yet, this hasn't happened to my knowledge (wanna have a BOF? j/k).

The Internet Gurus that I've had a chance to collaborate with argue that,
when dealing with small documents like SOAP requests, the real communication
(time) cost is not in the number of bits sent over the wire, but in the cost
of setting up and tearing down the TCP connection, i.e. time to establish
another TCP connection >> time to send one extra packet.  So, the real
efficiency win will happen when all of this supports HTTP/1.1 properly and
you can piggyback multiple requests on a single TCP connection.

Again, this is purely brainstorming, but maybe it will clarify (or muddy)
some issues for you.

Best Regards,
-----
  Eric M. Dashofy <ed...@ics.uci.edu>
  Graduate Student Researcher, Information & Computer Science
  University of California, Irvine
  http://www.ics.uci.edu/~edashofy

-----Original Message-----
From: Cory Isaacson [mailto:cisaacson@capita2.com]
Sent: Monday, August 21, 2000 10:11 AM
To: soap-user@xml.apache.org
Subject: Re: SOAP Serialization


Eric,

Thanks for the info. I did check out the XML encoding, and it will work for
what I need, but it looks like SOAP is doing the "double DOMing" instead of
my code. This is easier, but probably will perform similarly. Any ideas on
doing a true serialization of a DOM? Would it perform better? I know it may
not, as the normal Java serialization often makes the serialized object much
bigger than the original, and the communications cost is the mostly time
intensive in my testing to date.

Cory
----- Original Message -----
From: "Eric M. Dashofy" <ed...@ics.uci.edu>
To: <so...@xml.apache.org>
Cc: <ci...@capita2.com>
Sent: Monday, August 21, 2000 1:00 PM
Subject: RE: SOAP Serialization


>
> No, my serializer does not require you to implement your Java objects with
> beans or declare each field to translate into an element.  Rather, to make
> an object XML-serializable with my serializer you only need to change four
> lines of code in your object.  Of course, you need to mark any
> non-serializable fields as transient, but this would apply in any case.
It
> can serialize any field in an XML-serializable class, and any public or
> protected field in a superclass.  If the XML-serializable class extends a
> non-XML-serializable class, you must write a small custom routine to
> serialize private fields of the non-XML-serializalbe superclass, but this
> rarely occurs in practice.
>
> For your particular problem, I would NOT suggest using my serializer, as
> Apache SOAP provides this capability for you.  You can use the Literal XML
> encoding type, which should be pretty efficient as you're not
double-DOMming
> your XML document.  I'm not sure exactly how this works (I haven't had the
> opportunity to test it out yet), but it looks pretty straightforward.
>
> Again, for your problem, try investigating the literal XML encoding style.
> My serializer is more for use when you have implemented an arbitrary Java
> data structure you want to easily XMLify and unXMLify.
>
> All My Best,
> -----
>   Eric M. Dashofy <ed...@ics.uci.edu>
>   Graduate Student Researcher, Information & Computer Science
>   University of California, Irvine
>   http://www.ics.uci.edu/~edashofy
>
>
> -----Original Message-----
> From: Cory Isaacson [mailto:cisaacson@capita2.com]
> Sent: Sunday, August 20, 2000 6:02 AM
> To: soap-user@xml.apache.org
> Cc: edashofy@ics.uci.edu
> Subject: Re: SOAP Serialization
>
>
> Eric,
>
> This sounds very interesting. Does your serialization work similar to the
> current Apache SOAP implementation, in that each field must be declared in
> the bean and is then translated into an XML element?
>
> The reason I ask is that I have a need to transmit an entire XML document
> from a server to a client and back. The XML document is in a DOM before
its
> transmitted, and I need it in a DOM to use it. It seems I have the
following
> options:
>
> 1) I can convert to a a CDATA string and pass as a single parameter), and
> then re-parse the XML string into a DOM;
> 2) Try your serializer on the DOM itself.
>
> Can your serializer handle this last case? If not, is there a way to
simply
> serialize a DOM (as a binary Java class) and use Base64 to transmit it
> through SOAP? It seems like that would be more efficient as I wouldn't
have
> to re-parse the XML on the receiving side, but I have noticed that in some
> cases Java serialization is very slow and big.in the translation.
>
> Any other ideas as to how to do this efficiently?
>
> Thanks in advance,
>
> Cory
> ----- Original Message -----
> From: "Eric M. Dashofy" <ed...@ics.uci.edu>
> To: <so...@xml.apache.org>
> Sent: Friday, August 18, 2000 5:49 PM
> Subject: RE: SOAP Serialization
>
>
> >
> > Hello all!
> >
> > With the Apache SOAP for Java API, serializers are provided for the Java
> > basic types, some other types, and one-dimensional arrays of these
types.
> > Arbitrary objects can be serialized with a custom serializer if you
write
> > one.
> >
> > I have recently finished writing a serializer that can serialize and
> > deserialize (marshall and unmarshall, if you prefer) arbitrary Java
> objects
> > (they don't have to be Beans) to and from XML with a few minor caveats:
> >
> > 1.  You have to implement an interface, XmlSerializable, that my package
> > provides.
> > 2.  You have to insert three boilerplate lines of code in your class,
> which
> > I provide.
> > 3.  If you do not provide a default (no-arg) constructor for your
> > XML-serializable class, you have to change one boilerplate line of code.
> > 4.  Private fields in a superclass that you do NOT have the code for
must
> be
> > serialized somewhat manually by implementing two small additional
methods.
> > This doesn't come up much in practice.  This is the only kind of field
> that
> > requires custom code, which is mostly boilerplate anyway.
> > 5.  Transient/final fields are not serialized, because they're, well,
> > transient/final :).
> > 6.  Additionally, my serializer can serialize multidimensional Java
> arrays,
> > but admittedly not in the SOAP style (yet).
> >
> > This is done through a tiny bit of deep magic with Java's reflection
API.
> > I've been spending the last couple of days inserting my Java<->XML
> > serializer into the IBM (now Apache) SOAP for Java package, and I have
> been
> > successful.  I'm now in the process of retrofitting my code, which
> contains
> > some of the same fixes as have been included in the new 2.0 release,
into
> > the 2.0 release (It still works under 2.0, but I don't want to reinvent
> the
> > wheel).  I may post a patch or two to the Apache 2.0 release in the next
> > couple of days for the community's review.
> >
> > In any case, this gives you characteristics VERY similar to Java object
> > serialization, in a very programmer-friendly manner.  Additionally, I
have
> > implemented an AutoSOAPMappingRegistry that, if you try to serialize an
> > object that does not already have a registered serializer, will generate
> one
> > using my serializer if possible.  This eliminates the need for you to
> hassle
> > registering a serializer for each type of object you want to send in a
> SOAP
> > message.
> >
> > Furthermore, on top of all this I have built a stubber that can take an
> > arbitrary Java interface and generate a
CORBA/RMI/Distributed-Objects-like
> > stub for it, meaning that you don't have to write 30 lines of code per
> SOAP
> > call.  For this to work, I had to munge serialized exceptions into the
> > SOAPFault detail element, but it works dandily.
> >
> > Sadly, I only got this working yesterday and it's not quite ready for
> public
> > posting.  If any of you folks are interested in taking a look at it,
send
> me
> > an email or post to the discussion list, and I will consider sending it
to
> > you or posting an alpha copy for evaluation.
> >
> > Best Regards,
> > -----
> >   Eric M. Dashofy <ed...@ics.uci.edu>
> >   Graduate Student Researcher, Information & Computer Science
> >   University of California, Irvine
> >   http://www.ics.uci.edu/~edashofy
> >
> > -----Original Message-----
> > From: Milind Gadre [mailto:milind@idiom.com]
> > Sent: Friday, August 18, 2000 12:29 PM
> > To: soap-user@xml.apache.org
> > Cc: soap@discuss.develop.com
> > Subject: SOAP Serialization
> >
> > Hello all, I am new to this slippery world of SOAP, so please enlighten
> > me if my questions have already been answered some other place. I am
> > having a hard time figuring out the logic behind SOAP serialization of
> > arbitrary Java objects. I have not been able to find relevant
> > documentation on the matter.
> >
> > My questions are:
> >
> > [1] How does SOAP serialization handle protected/private fields of
> > arbitrary objects? Does it override some security settings in order to
> > get access to the private/protected fields? In an earlier post to this
> > discussion group I described a stack trace from the XMI classes.
> >
> > [2] Similar to the readObject/writeObject logic of Java Serialization,
> > is it possible to intercept the SOAP serialization procedures to insert
> > custom logic? I see this as being critical to sending java objects down
> > the pipe.
> >
> > [3] If the above is not possible, then how can I extend the SOAP
> > serialization classes so as to perform custom logic *just prior* to
> > sending an object and *just after* receiving an object.
> >
> > [4] What about *transient* fields?
> >
> > It seems to me that if SOAP is to support a general purpose
> > serialization mechanism, an API that has at least some of the
> > extensibility and features of existing Java Serialization is a must.
> >
> > Thanks in advance for any help on this matter.
> >
> > Best regards...Milind
> > milind@idiom.com
> >
> >
>

Re: SOAP Serialization

[Cory Isaacson <ci...@capita2.com>]

Eric,

Thanks for the info. I did check out the XML encoding, and it will work for
what I need, but it looks like SOAP is doing the "double DOMing" instead of
my code. This is easier, but probably will perform similarly. Any ideas on
doing a true serialization of a DOM? Would it perform better? I know it may
not, as the normal Java serialization often makes the serialized object much
bigger than the original, and the communications cost is the mostly time
intensive in my testing to date.

Cory
----- Original Message -----
From: "Eric M. Dashofy" <ed...@ics.uci.edu>
To: <so...@xml.apache.org>
Cc: <ci...@capita2.com>
Sent: Monday, August 21, 2000 1:00 PM
Subject: RE: SOAP Serialization


>
> No, my serializer does not require you to implement your Java objects with
> beans or declare each field to translate into an element.  Rather, to make
> an object XML-serializable with my serializer you only need to change four
> lines of code in your object.  Of course, you need to mark any
> non-serializable fields as transient, but this would apply in any case.
It
> can serialize any field in an XML-serializable class, and any public or
> protected field in a superclass.  If the XML-serializable class extends a
> non-XML-serializable class, you must write a small custom routine to
> serialize private fields of the non-XML-serializalbe superclass, but this
> rarely occurs in practice.
>
> For your particular problem, I would NOT suggest using my serializer, as
> Apache SOAP provides this capability for you.  You can use the Literal XML
> encoding type, which should be pretty efficient as you're not
double-DOMming
> your XML document.  I'm not sure exactly how this works (I haven't had the
> opportunity to test it out yet), but it looks pretty straightforward.
>
> Again, for your problem, try investigating the literal XML encoding style.
> My serializer is more for use when you have implemented an arbitrary Java
> data structure you want to easily XMLify and unXMLify.
>
> All My Best,
> -----
>   Eric M. Dashofy <ed...@ics.uci.edu>
>   Graduate Student Researcher, Information & Computer Science
>   University of California, Irvine
>   http://www.ics.uci.edu/~edashofy
>
>
> -----Original Message-----
> From: Cory Isaacson [mailto:cisaacson@capita2.com]
> Sent: Sunday, August 20, 2000 6:02 AM
> To: soap-user@xml.apache.org
> Cc: edashofy@ics.uci.edu
> Subject: Re: SOAP Serialization
>
>
> Eric,
>
> This sounds very interesting. Does your serialization work similar to the
> current Apache SOAP implementation, in that each field must be declared in
> the bean and is then translated into an XML element?
>
> The reason I ask is that I have a need to transmit an entire XML document
> from a server to a client and back. The XML document is in a DOM before
its
> transmitted, and I need it in a DOM to use it. It seems I have the
following
> options:
>
> 1) I can convert to a a CDATA string and pass as a single parameter), and
> then re-parse the XML string into a DOM;
> 2) Try your serializer on the DOM itself.
>
> Can your serializer handle this last case? If not, is there a way to
simply
> serialize a DOM (as a binary Java class) and use Base64 to transmit it
> through SOAP? It seems like that would be more efficient as I wouldn't
have
> to re-parse the XML on the receiving side, but I have noticed that in some
> cases Java serialization is very slow and big.in the translation.
>
> Any other ideas as to how to do this efficiently?
>
> Thanks in advance,
>
> Cory
> ----- Original Message -----
> From: "Eric M. Dashofy" <ed...@ics.uci.edu>
> To: <so...@xml.apache.org>
> Sent: Friday, August 18, 2000 5:49 PM
> Subject: RE: SOAP Serialization
>
>
> >
> > Hello all!
> >
> > With the Apache SOAP for Java API, serializers are provided for the Java
> > basic types, some other types, and one-dimensional arrays of these
types.
> > Arbitrary objects can be serialized with a custom serializer if you
write
> > one.
> >
> > I have recently finished writing a serializer that can serialize and
> > deserialize (marshall and unmarshall, if you prefer) arbitrary Java
> objects
> > (they don't have to be Beans) to and from XML with a few minor caveats:
> >
> > 1.  You have to implement an interface, XmlSerializable, that my package
> > provides.
> > 2.  You have to insert three boilerplate lines of code in your class,
> which
> > I provide.
> > 3.  If you do not provide a default (no-arg) constructor for your
> > XML-serializable class, you have to change one boilerplate line of code.
> > 4.  Private fields in a superclass that you do NOT have the code for
must
> be
> > serialized somewhat manually by implementing two small additional
methods.
> > This doesn't come up much in practice.  This is the only kind of field
> that
> > requires custom code, which is mostly boilerplate anyway.
> > 5.  Transient/final fields are not serialized, because they're, well,
> > transient/final :).
> > 6.  Additionally, my serializer can serialize multidimensional Java
> arrays,
> > but admittedly not in the SOAP style (yet).
> >
> > This is done through a tiny bit of deep magic with Java's reflection
API.
> > I've been spending the last couple of days inserting my Java<->XML
> > serializer into the IBM (now Apache) SOAP for Java package, and I have
> been
> > successful.  I'm now in the process of retrofitting my code, which
> contains
> > some of the same fixes as have been included in the new 2.0 release,
into
> > the 2.0 release (It still works under 2.0, but I don't want to reinvent
> the
> > wheel).  I may post a patch or two to the Apache 2.0 release in the next
> > couple of days for the community's review.
> >
> > In any case, this gives you characteristics VERY similar to Java object
> > serialization, in a very programmer-friendly manner.  Additionally, I
have
> > implemented an AutoSOAPMappingRegistry that, if you try to serialize an
> > object that does not already have a registered serializer, will generate
> one
> > using my serializer if possible.  This eliminates the need for you to
> hassle
> > registering a serializer for each type of object you want to send in a
> SOAP
> > message.
> >
> > Furthermore, on top of all this I have built a stubber that can take an
> > arbitrary Java interface and generate a
CORBA/RMI/Distributed-Objects-like
> > stub for it, meaning that you don't have to write 30 lines of code per
> SOAP
> > call.  For this to work, I had to munge serialized exceptions into the
> > SOAPFault detail element, but it works dandily.
> >
> > Sadly, I only got this working yesterday and it's not quite ready for
> public
> > posting.  If any of you folks are interested in taking a look at it,
send
> me
> > an email or post to the discussion list, and I will consider sending it
to
> > you or posting an alpha copy for evaluation.
> >
> > Best Regards,
> > -----
> >   Eric M. Dashofy <ed...@ics.uci.edu>
> >   Graduate Student Researcher, Information & Computer Science
> >   University of California, Irvine
> >   http://www.ics.uci.edu/~edashofy
> >
> > -----Original Message-----
> > From: Milind Gadre [mailto:milind@idiom.com]
> > Sent: Friday, August 18, 2000 12:29 PM
> > To: soap-user@xml.apache.org
> > Cc: soap@discuss.develop.com
> > Subject: SOAP Serialization
> >
> > Hello all, I am new to this slippery world of SOAP, so please enlighten
> > me if my questions have already been answered some other place. I am
> > having a hard time figuring out the logic behind SOAP serialization of
> > arbitrary Java objects. I have not been able to find relevant
> > documentation on the matter.
> >
> > My questions are:
> >
> > [1] How does SOAP serialization handle protected/private fields of
> > arbitrary objects? Does it override some security settings in order to
> > get access to the private/protected fields? In an earlier post to this
> > discussion group I described a stack trace from the XMI classes.
> >
> > [2] Similar to the readObject/writeObject logic of Java Serialization,
> > is it possible to intercept the SOAP serialization procedures to insert
> > custom logic? I see this as being critical to sending java objects down
> > the pipe.
> >
> > [3] If the above is not possible, then how can I extend the SOAP
> > serialization classes so as to perform custom logic *just prior* to
> > sending an object and *just after* receiving an object.
> >
> > [4] What about *transient* fields?
> >
> > It seems to me that if SOAP is to support a general purpose
> > serialization mechanism, an API that has at least some of the
> > extensibility and features of existing Java Serialization is a must.
> >
> > Thanks in advance for any help on this matter.
> >
> > Best regards...Milind
> > milind@idiom.com
> >
> >
>

Re: SOAP Serialization

[Cory Isaacson <ci...@capita2.com>]

Eric,

Thanks for the info. I did check out the XML encoding, and it will work for
what I need, but it looks like SOAP is doing the "double DOMing" instead of
my code. This is easier, but probably will perform similarly. Any ideas on
doing a true serialization of a DOM? Would it perform better? I know it may
not, as the normal Java serialization often makes the serialized object much
bigger than the original, and the communications cost is the mostly time
intensive in my testing to date.

Cory
----- Original Message -----
From: "Eric M. Dashofy" <ed...@ics.uci.edu>
To: <so...@xml.apache.org>
Cc: <ci...@capita2.com>
Sent: Monday, August 21, 2000 1:00 PM
Subject: RE: SOAP Serialization


>
> No, my serializer does not require you to implement your Java objects with
> beans or declare each field to translate into an element.  Rather, to make
> an object XML-serializable with my serializer you only need to change four
> lines of code in your object.  Of course, you need to mark any
> non-serializable fields as transient, but this would apply in any case.
It
> can serialize any field in an XML-serializable class, and any public or
> protected field in a superclass.  If the XML-serializable class extends a
> non-XML-serializable class, you must write a small custom routine to
> serialize private fields of the non-XML-serializalbe superclass, but this
> rarely occurs in practice.
>
> For your particular problem, I would NOT suggest using my serializer, as
> Apache SOAP provides this capability for you.  You can use the Literal XML
> encoding type, which should be pretty efficient as you're not
double-DOMming
> your XML document.  I'm not sure exactly how this works (I haven't had the
> opportunity to test it out yet), but it looks pretty straightforward.
>
> Again, for your problem, try investigating the literal XML encoding style.
> My serializer is more for use when you have implemented an arbitrary Java
> data structure you want to easily XMLify and unXMLify.
>
> All My Best,
> -----
>   Eric M. Dashofy <ed...@ics.uci.edu>
>   Graduate Student Researcher, Information & Computer Science
>   University of California, Irvine
>   http://www.ics.uci.edu/~edashofy
>
>
> -----Original Message-----
> From: Cory Isaacson [mailto:cisaacson@capita2.com]
> Sent: Sunday, August 20, 2000 6:02 AM
> To: soap-user@xml.apache.org
> Cc: edashofy@ics.uci.edu
> Subject: Re: SOAP Serialization
>
>
> Eric,
>
> This sounds very interesting. Does your serialization work similar to the
> current Apache SOAP implementation, in that each field must be declared in
> the bean and is then translated into an XML element?
>
> The reason I ask is that I have a need to transmit an entire XML document
> from a server to a client and back. The XML document is in a DOM before
its
> transmitted, and I need it in a DOM to use it. It seems I have the
following
> options:
>
> 1) I can convert to a a CDATA string and pass as a single parameter), and
> then re-parse the XML string into a DOM;
> 2) Try your serializer on the DOM itself.
>
> Can your serializer handle this last case? If not, is there a way to
simply
> serialize a DOM (as a binary Java class) and use Base64 to transmit it
> through SOAP? It seems like that would be more efficient as I wouldn't
have
> to re-parse the XML on the receiving side, but I have noticed that in some
> cases Java serialization is very slow and big.in the translation.
>
> Any other ideas as to how to do this efficiently?
>
> Thanks in advance,
>
> Cory
> ----- Original Message -----
> From: "Eric M. Dashofy" <ed...@ics.uci.edu>
> To: <so...@xml.apache.org>
> Sent: Friday, August 18, 2000 5:49 PM
> Subject: RE: SOAP Serialization
>
>
> >
> > Hello all!
> >
> > With the Apache SOAP for Java API, serializers are provided for the Java
> > basic types, some other types, and one-dimensional arrays of these
types.
> > Arbitrary objects can be serialized with a custom serializer if you
write
> > one.
> >
> > I have recently finished writing a serializer that can serialize and
> > deserialize (marshall and unmarshall, if you prefer) arbitrary Java
> objects
> > (they don't have to be Beans) to and from XML with a few minor caveats:
> >
> > 1.  You have to implement an interface, XmlSerializable, that my package
> > provides.
> > 2.  You have to insert three boilerplate lines of code in your class,
> which
> > I provide.
> > 3.  If you do not provide a default (no-arg) constructor for your
> > XML-serializable class, you have to change one boilerplate line of code.
> > 4.  Private fields in a superclass that you do NOT have the code for
must
> be
> > serialized somewhat manually by implementing two small additional
methods.
> > This doesn't come up much in practice.  This is the only kind of field
> that
> > requires custom code, which is mostly boilerplate anyway.
> > 5.  Transient/final fields are not serialized, because they're, well,
> > transient/final :).
> > 6.  Additionally, my serializer can serialize multidimensional Java
> arrays,
> > but admittedly not in the SOAP style (yet).
> >
> > This is done through a tiny bit of deep magic with Java's reflection
API.
> > I've been spending the last couple of days inserting my Java<->XML
> > serializer into the IBM (now Apache) SOAP for Java package, and I have
> been
> > successful.  I'm now in the process of retrofitting my code, which
> contains
> > some of the same fixes as have been included in the new 2.0 release,
into
> > the 2.0 release (It still works under 2.0, but I don't want to reinvent
> the
> > wheel).  I may post a patch or two to the Apache 2.0 release in the next
> > couple of days for the community's review.
> >
> > In any case, this gives you characteristics VERY similar to Java object
> > serialization, in a very programmer-friendly manner.  Additionally, I
have
> > implemented an AutoSOAPMappingRegistry that, if you try to serialize an
> > object that does not already have a registered serializer, will generate
> one
> > using my serializer if possible.  This eliminates the need for you to
> hassle
> > registering a serializer for each type of object you want to send in a
> SOAP
> > message.
> >
> > Furthermore, on top of all this I have built a stubber that can take an
> > arbitrary Java interface and generate a
CORBA/RMI/Distributed-Objects-like
> > stub for it, meaning that you don't have to write 30 lines of code per
> SOAP
> > call.  For this to work, I had to munge serialized exceptions into the
> > SOAPFault detail element, but it works dandily.
> >
> > Sadly, I only got this working yesterday and it's not quite ready for
> public
> > posting.  If any of you folks are interested in taking a look at it,
send
> me
> > an email or post to the discussion list, and I will consider sending it
to
> > you or posting an alpha copy for evaluation.
> >
> > Best Regards,
> > -----
> >   Eric M. Dashofy <ed...@ics.uci.edu>
> >   Graduate Student Researcher, Information & Computer Science
> >   University of California, Irvine
> >   http://www.ics.uci.edu/~edashofy
> >
> > -----Original Message-----
> > From: Milind Gadre [mailto:milind@idiom.com]
> > Sent: Friday, August 18, 2000 12:29 PM
> > To: soap-user@xml.apache.org
> > Cc: soap@discuss.develop.com
> > Subject: SOAP Serialization
> >
> > Hello all, I am new to this slippery world of SOAP, so please enlighten
> > me if my questions have already been answered some other place. I am
> > having a hard time figuring out the logic behind SOAP serialization of
> > arbitrary Java objects. I have not been able to find relevant
> > documentation on the matter.
> >
> > My questions are:
> >
> > [1] How does SOAP serialization handle protected/private fields of
> > arbitrary objects? Does it override some security settings in order to
> > get access to the private/protected fields? In an earlier post to this
> > discussion group I described a stack trace from the XMI classes.
> >
> > [2] Similar to the readObject/writeObject logic of Java Serialization,
> > is it possible to intercept the SOAP serialization procedures to insert
> > custom logic? I see this as being critical to sending java objects down
> > the pipe.
> >
> > [3] If the above is not possible, then how can I extend the SOAP
> > serialization classes so as to perform custom logic *just prior* to
> > sending an object and *just after* receiving an object.
> >
> > [4] What about *transient* fields?
> >
> > It seems to me that if SOAP is to support a general purpose
> > serialization mechanism, an API that has at least some of the
> > extensibility and features of existing Java Serialization is a must.
> >
> > Thanks in advance for any help on this matter.
> >
> > Best regards...Milind
> > milind@idiom.com
> >
> >
>

RE: SOAP Serialization

["Eric M. Dashofy" <ed...@ics.uci.edu>]

No, my serializer does not require you to implement your Java objects with
beans or declare each field to translate into an element.  Rather, to make
an object XML-serializable with my serializer you only need to change four
lines of code in your object.  Of course, you need to mark any
non-serializable fields as transient, but this would apply in any case.  It
can serialize any field in an XML-serializable class, and any public or
protected field in a superclass.  If the XML-serializable class extends a
non-XML-serializable class, you must write a small custom routine to
serialize private fields of the non-XML-serializalbe superclass, but this
rarely occurs in practice.

For your particular problem, I would NOT suggest using my serializer, as
Apache SOAP provides this capability for you.  You can use the Literal XML
encoding type, which should be pretty efficient as you're not double-DOMming
your XML document.  I'm not sure exactly how this works (I haven't had the
opportunity to test it out yet), but it looks pretty straightforward.

Again, for your problem, try investigating the literal XML encoding style.
My serializer is more for use when you have implemented an arbitrary Java
data structure you want to easily XMLify and unXMLify.

All My Best,
-----
  Eric M. Dashofy <ed...@ics.uci.edu>
  Graduate Student Researcher, Information & Computer Science
  University of California, Irvine
  http://www.ics.uci.edu/~edashofy


-----Original Message-----
From: Cory Isaacson [mailto:cisaacson@capita2.com]
Sent: Sunday, August 20, 2000 6:02 AM
To: soap-user@xml.apache.org
Cc: edashofy@ics.uci.edu
Subject: Re: SOAP Serialization


Eric,

This sounds very interesting. Does your serialization work similar to the
current Apache SOAP implementation, in that each field must be declared in
the bean and is then translated into an XML element?

The reason I ask is that I have a need to transmit an entire XML document
from a server to a client and back. The XML document is in a DOM before its
transmitted, and I need it in a DOM to use it. It seems I have the following
options:

1) I can convert to a a CDATA string and pass as a single parameter), and
then re-parse the XML string into a DOM;
2) Try your serializer on the DOM itself.

Can your serializer handle this last case? If not, is there a way to simply
serialize a DOM (as a binary Java class) and use Base64 to transmit it
through SOAP? It seems like that would be more efficient as I wouldn't have
to re-parse the XML on the receiving side, but I have noticed that in some
cases Java serialization is very slow and big.in the translation.

Any other ideas as to how to do this efficiently?

Thanks in advance,

Cory
----- Original Message -----
From: "Eric M. Dashofy" <ed...@ics.uci.edu>
To: <so...@xml.apache.org>
Sent: Friday, August 18, 2000 5:49 PM
Subject: RE: SOAP Serialization


>
> Hello all!
>
> With the Apache SOAP for Java API, serializers are provided for the Java
> basic types, some other types, and one-dimensional arrays of these types.
> Arbitrary objects can be serialized with a custom serializer if you write
> one.
>
> I have recently finished writing a serializer that can serialize and
> deserialize (marshall and unmarshall, if you prefer) arbitrary Java
objects
> (they don't have to be Beans) to and from XML with a few minor caveats:
>
> 1.  You have to implement an interface, XmlSerializable, that my package
> provides.
> 2.  You have to insert three boilerplate lines of code in your class,
which
> I provide.
> 3.  If you do not provide a default (no-arg) constructor for your
> XML-serializable class, you have to change one boilerplate line of code.
> 4.  Private fields in a superclass that you do NOT have the code for must
be
> serialized somewhat manually by implementing two small additional methods.
> This doesn't come up much in practice.  This is the only kind of field
that
> requires custom code, which is mostly boilerplate anyway.
> 5.  Transient/final fields are not serialized, because they're, well,
> transient/final :).
> 6.  Additionally, my serializer can serialize multidimensional Java
arrays,
> but admittedly not in the SOAP style (yet).
>
> This is done through a tiny bit of deep magic with Java's reflection API.
> I've been spending the last couple of days inserting my Java<->XML
> serializer into the IBM (now Apache) SOAP for Java package, and I have
been
> successful.  I'm now in the process of retrofitting my code, which
contains
> some of the same fixes as have been included in the new 2.0 release, into
> the 2.0 release (It still works under 2.0, but I don't want to reinvent
the
> wheel).  I may post a patch or two to the Apache 2.0 release in the next
> couple of days for the community's review.
>
> In any case, this gives you characteristics VERY similar to Java object
> serialization, in a very programmer-friendly manner.  Additionally, I have
> implemented an AutoSOAPMappingRegistry that, if you try to serialize an
> object that does not already have a registered serializer, will generate
one
> using my serializer if possible.  This eliminates the need for you to
hassle
> registering a serializer for each type of object you want to send in a
SOAP
> message.
>
> Furthermore, on top of all this I have built a stubber that can take an
> arbitrary Java interface and generate a CORBA/RMI/Distributed-Objects-like
> stub for it, meaning that you don't have to write 30 lines of code per
SOAP
> call.  For this to work, I had to munge serialized exceptions into the
> SOAPFault detail element, but it works dandily.
>
> Sadly, I only got this working yesterday and it's not quite ready for
public
> posting.  If any of you folks are interested in taking a look at it, send
me
> an email or post to the discussion list, and I will consider sending it to
> you or posting an alpha copy for evaluation.
>
> Best Regards,
> -----
>   Eric M. Dashofy <ed...@ics.uci.edu>
>   Graduate Student Researcher, Information & Computer Science
>   University of California, Irvine
>   http://www.ics.uci.edu/~edashofy
>
> -----Original Message-----
> From: Milind Gadre [mailto:milind@idiom.com]
> Sent: Friday, August 18, 2000 12:29 PM
> To: soap-user@xml.apache.org
> Cc: soap@discuss.develop.com
> Subject: SOAP Serialization
>
> Hello all, I am new to this slippery world of SOAP, so please enlighten
> me if my questions have already been answered some other place. I am
> having a hard time figuring out the logic behind SOAP serialization of
> arbitrary Java objects. I have not been able to find relevant
> documentation on the matter.
>
> My questions are:
>
> [1] How does SOAP serialization handle protected/private fields of
> arbitrary objects? Does it override some security settings in order to
> get access to the private/protected fields? In an earlier post to this
> discussion group I described a stack trace from the XMI classes.
>
> [2] Similar to the readObject/writeObject logic of Java Serialization,
> is it possible to intercept the SOAP serialization procedures to insert
> custom logic? I see this as being critical to sending java objects down
> the pipe.
>
> [3] If the above is not possible, then how can I extend the SOAP
> serialization classes so as to perform custom logic *just prior* to
> sending an object and *just after* receiving an object.
>
> [4] What about *transient* fields?
>
> It seems to me that if SOAP is to support a general purpose
> serialization mechanism, an API that has at least some of the
> extensibility and features of existing Java Serialization is a must.
>
> Thanks in advance for any help on this matter.
>
> Best regards...Milind
> milind@idiom.com
>
>

RE: SOAP Serialization

["Eric M. Dashofy" <ed...@ics.uci.edu>]

No, my serializer does not require you to implement your Java objects with
beans or declare each field to translate into an element.  Rather, to make
an object XML-serializable with my serializer you only need to change four
lines of code in your object.  Of course, you need to mark any
non-serializable fields as transient, but this would apply in any case.  It
can serialize any field in an XML-serializable class, and any public or
protected field in a superclass.  If the XML-serializable class extends a
non-XML-serializable class, you must write a small custom routine to
serialize private fields of the non-XML-serializalbe superclass, but this
rarely occurs in practice.

For your particular problem, I would NOT suggest using my serializer, as
Apache SOAP provides this capability for you.  You can use the Literal XML
encoding type, which should be pretty efficient as you're not double-DOMming
your XML document.  I'm not sure exactly how this works (I haven't had the
opportunity to test it out yet), but it looks pretty straightforward.

Again, for your problem, try investigating the literal XML encoding style.
My serializer is more for use when you have implemented an arbitrary Java
data structure you want to easily XMLify and unXMLify.

All My Best,
-----
  Eric M. Dashofy <ed...@ics.uci.edu>
  Graduate Student Researcher, Information & Computer Science
  University of California, Irvine
  http://www.ics.uci.edu/~edashofy


-----Original Message-----
From: Cory Isaacson [mailto:cisaacson@capita2.com]
Sent: Sunday, August 20, 2000 6:02 AM
To: soap-user@xml.apache.org
Cc: edashofy@ics.uci.edu
Subject: Re: SOAP Serialization


Eric,

This sounds very interesting. Does your serialization work similar to the
current Apache SOAP implementation, in that each field must be declared in
the bean and is then translated into an XML element?

The reason I ask is that I have a need to transmit an entire XML document
from a server to a client and back. The XML document is in a DOM before its
transmitted, and I need it in a DOM to use it. It seems I have the following
options:

1) I can convert to a a CDATA string and pass as a single parameter), and
then re-parse the XML string into a DOM;
2) Try your serializer on the DOM itself.

Can your serializer handle this last case? If not, is there a way to simply
serialize a DOM (as a binary Java class) and use Base64 to transmit it
through SOAP? It seems like that would be more efficient as I wouldn't have
to re-parse the XML on the receiving side, but I have noticed that in some
cases Java serialization is very slow and big.in the translation.

Any other ideas as to how to do this efficiently?

Thanks in advance,

Cory
----- Original Message -----
From: "Eric M. Dashofy" <ed...@ics.uci.edu>
To: <so...@xml.apache.org>
Sent: Friday, August 18, 2000 5:49 PM
Subject: RE: SOAP Serialization


>
> Hello all!
>
> With the Apache SOAP for Java API, serializers are provided for the Java
> basic types, some other types, and one-dimensional arrays of these types.
> Arbitrary objects can be serialized with a custom serializer if you write
> one.
>
> I have recently finished writing a serializer that can serialize and
> deserialize (marshall and unmarshall, if you prefer) arbitrary Java
objects
> (they don't have to be Beans) to and from XML with a few minor caveats:
>
> 1.  You have to implement an interface, XmlSerializable, that my package
> provides.
> 2.  You have to insert three boilerplate lines of code in your class,
which
> I provide.
> 3.  If you do not provide a default (no-arg) constructor for your
> XML-serializable class, you have to change one boilerplate line of code.
> 4.  Private fields in a superclass that you do NOT have the code for must
be
> serialized somewhat manually by implementing two small additional methods.
> This doesn't come up much in practice.  This is the only kind of field
that
> requires custom code, which is mostly boilerplate anyway.
> 5.  Transient/final fields are not serialized, because they're, well,
> transient/final :).
> 6.  Additionally, my serializer can serialize multidimensional Java
arrays,
> but admittedly not in the SOAP style (yet).
>
> This is done through a tiny bit of deep magic with Java's reflection API.
> I've been spending the last couple of days inserting my Java<->XML
> serializer into the IBM (now Apache) SOAP for Java package, and I have
been
> successful.  I'm now in the process of retrofitting my code, which
contains
> some of the same fixes as have been included in the new 2.0 release, into
> the 2.0 release (It still works under 2.0, but I don't want to reinvent
the
> wheel).  I may post a patch or two to the Apache 2.0 release in the next
> couple of days for the community's review.
>
> In any case, this gives you characteristics VERY similar to Java object
> serialization, in a very programmer-friendly manner.  Additionally, I have
> implemented an AutoSOAPMappingRegistry that, if you try to serialize an
> object that does not already have a registered serializer, will generate
one
> using my serializer if possible.  This eliminates the need for you to
hassle
> registering a serializer for each type of object you want to send in a
SOAP
> message.
>
> Furthermore, on top of all this I have built a stubber that can take an
> arbitrary Java interface and generate a CORBA/RMI/Distributed-Objects-like
> stub for it, meaning that you don't have to write 30 lines of code per
SOAP
> call.  For this to work, I had to munge serialized exceptions into the
> SOAPFault detail element, but it works dandily.
>
> Sadly, I only got this working yesterday and it's not quite ready for
public
> posting.  If any of you folks are interested in taking a look at it, send
me
> an email or post to the discussion list, and I will consider sending it to
> you or posting an alpha copy for evaluation.
>
> Best Regards,
> -----
>   Eric M. Dashofy <ed...@ics.uci.edu>
>   Graduate Student Researcher, Information & Computer Science
>   University of California, Irvine
>   http://www.ics.uci.edu/~edashofy
>
> -----Original Message-----
> From: Milind Gadre [mailto:milind@idiom.com]
> Sent: Friday, August 18, 2000 12:29 PM
> To: soap-user@xml.apache.org
> Cc: soap@discuss.develop.com
> Subject: SOAP Serialization
>
> Hello all, I am new to this slippery world of SOAP, so please enlighten
> me if my questions have already been answered some other place. I am
> having a hard time figuring out the logic behind SOAP serialization of
> arbitrary Java objects. I have not been able to find relevant
> documentation on the matter.
>
> My questions are:
>
> [1] How does SOAP serialization handle protected/private fields of
> arbitrary objects? Does it override some security settings in order to
> get access to the private/protected fields? In an earlier post to this
> discussion group I described a stack trace from the XMI classes.
>
> [2] Similar to the readObject/writeObject logic of Java Serialization,
> is it possible to intercept the SOAP serialization procedures to insert
> custom logic? I see this as being critical to sending java objects down
> the pipe.
>
> [3] If the above is not possible, then how can I extend the SOAP
> serialization classes so as to perform custom logic *just prior* to
> sending an object and *just after* receiving an object.
>
> [4] What about *transient* fields?
>
> It seems to me that if SOAP is to support a general purpose
> serialization mechanism, an API that has at least some of the
> extensibility and features of existing Java Serialization is a must.
>
> Thanks in advance for any help on this matter.
>
> Best regards...Milind
> milind@idiom.com
>
>

Re: SOAP Serialization

[Cory Isaacson <ci...@capita2.com>]

Eric,

This sounds very interesting. Does your serialization work similar to the
current Apache SOAP implementation, in that each field must be declared in
the bean and is then translated into an XML element?

The reason I ask is that I have a need to transmit an entire XML document
from a server to a client and back. The XML document is in a DOM before its
transmitted, and I need it in a DOM to use it. It seems I have the following
options:

1) I can convert to a a CDATA string and pass as a single parameter), and
then re-parse the XML string into a DOM;
2) Try your serializer on the DOM itself.

Can your serializer handle this last case? If not, is there a way to simply
serialize a DOM (as a binary Java class) and use Base64 to transmit it
through SOAP? It seems like that would be more efficient as I wouldn't have
to re-parse the XML on the receiving side, but I have noticed that in some
cases Java serialization is very slow and big.in the translation.

Any other ideas as to how to do this efficiently?

Thanks in advance,

Cory
----- Original Message -----
From: "Eric M. Dashofy" <ed...@ics.uci.edu>
To: <so...@xml.apache.org>
Sent: Friday, August 18, 2000 5:49 PM
Subject: RE: SOAP Serialization


>
> Hello all!
>
> With the Apache SOAP for Java API, serializers are provided for the Java
> basic types, some other types, and one-dimensional arrays of these types.
> Arbitrary objects can be serialized with a custom serializer if you write
> one.
>
> I have recently finished writing a serializer that can serialize and
> deserialize (marshall and unmarshall, if you prefer) arbitrary Java
objects
> (they don't have to be Beans) to and from XML with a few minor caveats:
>
> 1.  You have to implement an interface, XmlSerializable, that my package
> provides.
> 2.  You have to insert three boilerplate lines of code in your class,
which
> I provide.
> 3.  If you do not provide a default (no-arg) constructor for your
> XML-serializable class, you have to change one boilerplate line of code.
> 4.  Private fields in a superclass that you do NOT have the code for must
be
> serialized somewhat manually by implementing two small additional methods.
> This doesn't come up much in practice.  This is the only kind of field
that
> requires custom code, which is mostly boilerplate anyway.
> 5.  Transient/final fields are not serialized, because they're, well,
> transient/final :).
> 6.  Additionally, my serializer can serialize multidimensional Java
arrays,
> but admittedly not in the SOAP style (yet).
>
> This is done through a tiny bit of deep magic with Java's reflection API.
> I've been spending the last couple of days inserting my Java<->XML
> serializer into the IBM (now Apache) SOAP for Java package, and I have
been
> successful.  I'm now in the process of retrofitting my code, which
contains
> some of the same fixes as have been included in the new 2.0 release, into
> the 2.0 release (It still works under 2.0, but I don't want to reinvent
the
> wheel).  I may post a patch or two to the Apache 2.0 release in the next
> couple of days for the community's review.
>
> In any case, this gives you characteristics VERY similar to Java object
> serialization, in a very programmer-friendly manner.  Additionally, I have
> implemented an AutoSOAPMappingRegistry that, if you try to serialize an
> object that does not already have a registered serializer, will generate
one
> using my serializer if possible.  This eliminates the need for you to
hassle
> registering a serializer for each type of object you want to send in a
SOAP
> message.
>
> Furthermore, on top of all this I have built a stubber that can take an
> arbitrary Java interface and generate a CORBA/RMI/Distributed-Objects-like
> stub for it, meaning that you don't have to write 30 lines of code per
SOAP
> call.  For this to work, I had to munge serialized exceptions into the
> SOAPFault detail element, but it works dandily.
>
> Sadly, I only got this working yesterday and it's not quite ready for
public
> posting.  If any of you folks are interested in taking a look at it, send
me
> an email or post to the discussion list, and I will consider sending it to
> you or posting an alpha copy for evaluation.
>
> Best Regards,
> -----
>   Eric M. Dashofy <ed...@ics.uci.edu>
>   Graduate Student Researcher, Information & Computer Science
>   University of California, Irvine
>   http://www.ics.uci.edu/~edashofy
>
> -----Original Message-----
> From: Milind Gadre [mailto:milind@idiom.com]
> Sent: Friday, August 18, 2000 12:29 PM
> To: soap-user@xml.apache.org
> Cc: soap@discuss.develop.com
> Subject: SOAP Serialization
>
> Hello all, I am new to this slippery world of SOAP, so please enlighten
> me if my questions have already been answered some other place. I am
> having a hard time figuring out the logic behind SOAP serialization of
> arbitrary Java objects. I have not been able to find relevant
> documentation on the matter.
>
> My questions are:
>
> [1] How does SOAP serialization handle protected/private fields of
> arbitrary objects? Does it override some security settings in order to
> get access to the private/protected fields? In an earlier post to this
> discussion group I described a stack trace from the XMI classes.
>
> [2] Similar to the readObject/writeObject logic of Java Serialization,
> is it possible to intercept the SOAP serialization procedures to insert
> custom logic? I see this as being critical to sending java objects down
> the pipe.
>
> [3] If the above is not possible, then how can I extend the SOAP
> serialization classes so as to perform custom logic *just prior* to
> sending an object and *just after* receiving an object.
>
> [4] What about *transient* fields?
>
> It seems to me that if SOAP is to support a general purpose
> serialization mechanism, an API that has at least some of the
> extensibility and features of existing Java Serialization is a must.
>
> Thanks in advance for any help on this matter.
>
> Best regards...Milind
> milind@idiom.com
>
>

Re: SOAP Serialization

[Cory Isaacson <ci...@capita2.com>]

Eric,

This sounds very interesting. Does your serialization work similar to the
current Apache SOAP implementation, in that each field must be declared in
the bean and is then translated into an XML element?

The reason I ask is that I have a need to transmit an entire XML document
from a server to a client and back. The XML document is in a DOM before its
transmitted, and I need it in a DOM to use it. It seems I have the following
options:

1) I can convert to a a CDATA string and pass as a single parameter), and
then re-parse the XML string into a DOM;
2) Try your serializer on the DOM itself.

Can your serializer handle this last case? If not, is there a way to simply
serialize a DOM (as a binary Java class) and use Base64 to transmit it
through SOAP? It seems like that would be more efficient as I wouldn't have
to re-parse the XML on the receiving side, but I have noticed that in some
cases Java serialization is very slow and big.in the translation.

Any other ideas as to how to do this efficiently?

Thanks in advance,

Cory
----- Original Message -----
From: "Eric M. Dashofy" <ed...@ics.uci.edu>
To: <so...@xml.apache.org>
Sent: Friday, August 18, 2000 5:49 PM
Subject: RE: SOAP Serialization


>
> Hello all!
>
> With the Apache SOAP for Java API, serializers are provided for the Java
> basic types, some other types, and one-dimensional arrays of these types.
> Arbitrary objects can be serialized with a custom serializer if you write
> one.
>
> I have recently finished writing a serializer that can serialize and
> deserialize (marshall and unmarshall, if you prefer) arbitrary Java
objects
> (they don't have to be Beans) to and from XML with a few minor caveats:
>
> 1.  You have to implement an interface, XmlSerializable, that my package
> provides.
> 2.  You have to insert three boilerplate lines of code in your class,
which
> I provide.
> 3.  If you do not provide a default (no-arg) constructor for your
> XML-serializable class, you have to change one boilerplate line of code.
> 4.  Private fields in a superclass that you do NOT have the code for must
be
> serialized somewhat manually by implementing two small additional methods.
> This doesn't come up much in practice.  This is the only kind of field
that
> requires custom code, which is mostly boilerplate anyway.
> 5.  Transient/final fields are not serialized, because they're, well,
> transient/final :).
> 6.  Additionally, my serializer can serialize multidimensional Java
arrays,
> but admittedly not in the SOAP style (yet).
>
> This is done through a tiny bit of deep magic with Java's reflection API.
> I've been spending the last couple of days inserting my Java<->XML
> serializer into the IBM (now Apache) SOAP for Java package, and I have
been
> successful.  I'm now in the process of retrofitting my code, which
contains
> some of the same fixes as have been included in the new 2.0 release, into
> the 2.0 release (It still works under 2.0, but I don't want to reinvent
the
> wheel).  I may post a patch or two to the Apache 2.0 release in the next
> couple of days for the community's review.
>
> In any case, this gives you characteristics VERY similar to Java object
> serialization, in a very programmer-friendly manner.  Additionally, I have
> implemented an AutoSOAPMappingRegistry that, if you try to serialize an
> object that does not already have a registered serializer, will generate
one
> using my serializer if possible.  This eliminates the need for you to
hassle
> registering a serializer for each type of object you want to send in a
SOAP
> message.
>
> Furthermore, on top of all this I have built a stubber that can take an
> arbitrary Java interface and generate a CORBA/RMI/Distributed-Objects-like
> stub for it, meaning that you don't have to write 30 lines of code per
SOAP
> call.  For this to work, I had to munge serialized exceptions into the
> SOAPFault detail element, but it works dandily.
>
> Sadly, I only got this working yesterday and it's not quite ready for
public
> posting.  If any of you folks are interested in taking a look at it, send
me
> an email or post to the discussion list, and I will consider sending it to
> you or posting an alpha copy for evaluation.
>
> Best Regards,
> -----
>   Eric M. Dashofy <ed...@ics.uci.edu>
>   Graduate Student Researcher, Information & Computer Science
>   University of California, Irvine
>   http://www.ics.uci.edu/~edashofy
>
> -----Original Message-----
> From: Milind Gadre [mailto:milind@idiom.com]
> Sent: Friday, August 18, 2000 12:29 PM
> To: soap-user@xml.apache.org
> Cc: soap@discuss.develop.com
> Subject: SOAP Serialization
>
> Hello all, I am new to this slippery world of SOAP, so please enlighten
> me if my questions have already been answered some other place. I am
> having a hard time figuring out the logic behind SOAP serialization of
> arbitrary Java objects. I have not been able to find relevant
> documentation on the matter.
>
> My questions are:
>
> [1] How does SOAP serialization handle protected/private fields of
> arbitrary objects? Does it override some security settings in order to
> get access to the private/protected fields? In an earlier post to this
> discussion group I described a stack trace from the XMI classes.
>
> [2] Similar to the readObject/writeObject logic of Java Serialization,
> is it possible to intercept the SOAP serialization procedures to insert
> custom logic? I see this as being critical to sending java objects down
> the pipe.
>
> [3] If the above is not possible, then how can I extend the SOAP
> serialization classes so as to perform custom logic *just prior* to
> sending an object and *just after* receiving an object.
>
> [4] What about *transient* fields?
>
> It seems to me that if SOAP is to support a general purpose
> serialization mechanism, an API that has at least some of the
> extensibility and features of existing Java Serialization is a must.
>
> Thanks in advance for any help on this matter.
>
> Best regards...Milind
> milind@idiom.com
>
>

RE: SOAP Serialization

[Milind Gadre <mi...@idiom.com>]

Eric, thanks for your efforts !! I am interested in seeing what you have
done, and will provide feedback in as timely a manner as possible. You
can send me email directly if you like.

BTW: do you know of any documentation/code samples on writing a custom
serializer using the existing SOAP apis?

Best regards...Milind
milind@idiom.com


> -----Original Message-----
> From: Eric M. Dashofy [mailto:edashofy@ics.uci.edu]
> Sent: Friday, August 18, 2000 2:49 PM
> To: soap-user@xml.apache.org
> Subject: RE: SOAP Serialization
>
>
>
> Hello all!
>
> With the Apache SOAP for Java API, serializers are provided
> for the Java
> basic types, some other types, and one-dimensional arrays of
> these types.
> Arbitrary objects can be serialized with a custom serializer
> if you write
> one.
>
> I have recently finished writing a serializer that can serialize and
> deserialize (marshall and unmarshall, if you prefer)
> arbitrary Java objects
> (they don't have to be Beans) to and from XML with a few
> minor caveats:
>
> 1.  You have to implement an interface, XmlSerializable, that
> my package
> provides.
> 2.  You have to insert three boilerplate lines of code in
> your class, which
> I provide.
> 3.  If you do not provide a default (no-arg) constructor for your
> XML-serializable class, you have to change one boilerplate
> line of code.
> 4.  Private fields in a superclass that you do NOT have the
> code for must be
> serialized somewhat manually by implementing two small
> additional methods.
> This doesn't come up much in practice.  This is the only kind
> of field that
> requires custom code, which is mostly boilerplate anyway.
> 5.  Transient/final fields are not serialized, because they're, well,
> transient/final :).
> 6.  Additionally, my serializer can serialize
> multidimensional Java arrays,
> but admittedly not in the SOAP style (yet).
>
> This is done through a tiny bit of deep magic with Java's
> reflection API.
> I've been spending the last couple of days inserting my Java<->XML
> serializer into the IBM (now Apache) SOAP for Java package,
> and I have been
> successful.  I'm now in the process of retrofitting my code,
> which contains
> some of the same fixes as have been included in the new 2.0
> release, into
> the 2.0 release (It still works under 2.0, but I don't want
> to reinvent the
> wheel).  I may post a patch or two to the Apache 2.0 release
> in the next
> couple of days for the community's review.
>
> In any case, this gives you characteristics VERY similar to
> Java object
> serialization, in a very programmer-friendly manner.
> Additionally, I have
> implemented an AutoSOAPMappingRegistry that, if you try to
> serialize an
> object that does not already have a registered serializer,
> will generate one
> using my serializer if possible.  This eliminates the need
> for you to hassle
> registering a serializer for each type of object you want to
> send in a SOAP
> message.
>
> Furthermore, on top of all this I have built a stubber that
> can take an
> arbitrary Java interface and generate a
> CORBA/RMI/Distributed-Objects-like
> stub for it, meaning that you don't have to write 30 lines of
> code per SOAP
> call.  For this to work, I had to munge serialized exceptions into the
> SOAPFault detail element, but it works dandily.
>
> Sadly, I only got this working yesterday and it's not quite
> ready for public
> posting.  If any of you folks are interested in taking a look
> at it, send me
> an email or post to the discussion list, and I will consider
> sending it to
> you or posting an alpha copy for evaluation.
>
> Best Regards,
> -----
>   Eric M. Dashofy <ed...@ics.uci.edu>
>   Graduate Student Researcher, Information & Computer Science
>   University of California, Irvine
>   http://www.ics.uci.edu/~edashofy
>
> -----Original Message-----
> From: Milind Gadre [mailto:milind@idiom.com]
> Sent: Friday, August 18, 2000 12:29 PM
> To: soap-user@xml.apache.org
> Cc: soap@discuss.develop.com
> Subject: SOAP Serialization
>
> Hello all, I am new to this slippery world of SOAP, so please
> enlighten
> me if my questions have already been answered some other place. I am
> having a hard time figuring out the logic behind SOAP serialization of
> arbitrary Java objects. I have not been able to find relevant
> documentation on the matter.
>
> My questions are:
>
> [1] How does SOAP serialization handle protected/private fields of
> arbitrary objects? Does it override some security settings in order to
> get access to the private/protected fields? In an earlier post to this
> discussion group I described a stack trace from the XMI classes.
>
> [2] Similar to the readObject/writeObject logic of Java Serialization,
> is it possible to intercept the SOAP serialization procedures
> to insert
> custom logic? I see this as being critical to sending java
> objects down
> the pipe.
>
> [3] If the above is not possible, then how can I extend the SOAP
> serialization classes so as to perform custom logic *just prior* to
> sending an object and *just after* receiving an object.
>
> [4] What about *transient* fields?
>
> It seems to me that if SOAP is to support a general purpose
> serialization mechanism, an API that has at least some of the
> extensibility and features of existing Java Serialization is a must.
>
> Thanks in advance for any help on this matter.
>
> Best regards...Milind
> milind@idiom.com
>
>
>

RE: SOAP Serialization

[Milind Gadre <mi...@idiom.com>]

Eric, thanks for your efforts !! I am interested in seeing what you have
done, and will provide feedback in as timely a manner as possible. You
can send me email directly if you like.

BTW: do you know of any documentation/code samples on writing a custom
serializer using the existing SOAP apis?

Best regards...Milind
milind@idiom.com


> -----Original Message-----
> From: Eric M. Dashofy [mailto:edashofy@ics.uci.edu]
> Sent: Friday, August 18, 2000 2:49 PM
> To: soap-user@xml.apache.org
> Subject: RE: SOAP Serialization
>
>
>
> Hello all!
>
> With the Apache SOAP for Java API, serializers are provided
> for the Java
> basic types, some other types, and one-dimensional arrays of
> these types.
> Arbitrary objects can be serialized with a custom serializer
> if you write
> one.
>
> I have recently finished writing a serializer that can serialize and
> deserialize (marshall and unmarshall, if you prefer)
> arbitrary Java objects
> (they don't have to be Beans) to and from XML with a few
> minor caveats:
>
> 1.  You have to implement an interface, XmlSerializable, that
> my package
> provides.
> 2.  You have to insert three boilerplate lines of code in
> your class, which
> I provide.
> 3.  If you do not provide a default (no-arg) constructor for your
> XML-serializable class, you have to change one boilerplate
> line of code.
> 4.  Private fields in a superclass that you do NOT have the
> code for must be
> serialized somewhat manually by implementing two small
> additional methods.
> This doesn't come up much in practice.  This is the only kind
> of field that
> requires custom code, which is mostly boilerplate anyway.
> 5.  Transient/final fields are not serialized, because they're, well,
> transient/final :).
> 6.  Additionally, my serializer can serialize
> multidimensional Java arrays,
> but admittedly not in the SOAP style (yet).
>
> This is done through a tiny bit of deep magic with Java's
> reflection API.
> I've been spending the last couple of days inserting my Java<->XML
> serializer into the IBM (now Apache) SOAP for Java package,
> and I have been
> successful.  I'm now in the process of retrofitting my code,
> which contains
> some of the same fixes as have been included in the new 2.0
> release, into
> the 2.0 release (It still works under 2.0, but I don't want
> to reinvent the
> wheel).  I may post a patch or two to the Apache 2.0 release
> in the next
> couple of days for the community's review.
>
> In any case, this gives you characteristics VERY similar to
> Java object
> serialization, in a very programmer-friendly manner.
> Additionally, I have
> implemented an AutoSOAPMappingRegistry that, if you try to
> serialize an
> object that does not already have a registered serializer,
> will generate one
> using my serializer if possible.  This eliminates the need
> for you to hassle
> registering a serializer for each type of object you want to
> send in a SOAP
> message.
>
> Furthermore, on top of all this I have built a stubber that
> can take an
> arbitrary Java interface and generate a
> CORBA/RMI/Distributed-Objects-like
> stub for it, meaning that you don't have to write 30 lines of
> code per SOAP
> call.  For this to work, I had to munge serialized exceptions into the
> SOAPFault detail element, but it works dandily.
>
> Sadly, I only got this working yesterday and it's not quite
> ready for public
> posting.  If any of you folks are interested in taking a look
> at it, send me
> an email or post to the discussion list, and I will consider
> sending it to
> you or posting an alpha copy for evaluation.
>
> Best Regards,
> -----
>   Eric M. Dashofy <ed...@ics.uci.edu>
>   Graduate Student Researcher, Information & Computer Science
>   University of California, Irvine
>   http://www.ics.uci.edu/~edashofy
>
> -----Original Message-----
> From: Milind Gadre [mailto:milind@idiom.com]
> Sent: Friday, August 18, 2000 12:29 PM
> To: soap-user@xml.apache.org
> Cc: soap@discuss.develop.com
> Subject: SOAP Serialization
>
> Hello all, I am new to this slippery world of SOAP, so please
> enlighten
> me if my questions have already been answered some other place. I am
> having a hard time figuring out the logic behind SOAP serialization of
> arbitrary Java objects. I have not been able to find relevant
> documentation on the matter.
>
> My questions are:
>
> [1] How does SOAP serialization handle protected/private fields of
> arbitrary objects? Does it override some security settings in order to
> get access to the private/protected fields? In an earlier post to this
> discussion group I described a stack trace from the XMI classes.
>
> [2] Similar to the readObject/writeObject logic of Java Serialization,
> is it possible to intercept the SOAP serialization procedures
> to insert
> custom logic? I see this as being critical to sending java
> objects down
> the pipe.
>
> [3] If the above is not possible, then how can I extend the SOAP
> serialization classes so as to perform custom logic *just prior* to
> sending an object and *just after* receiving an object.
>
> [4] What about *transient* fields?
>
> It seems to me that if SOAP is to support a general purpose
> serialization mechanism, an API that has at least some of the
> extensibility and features of existing Java Serialization is a must.
>
> Thanks in advance for any help on this matter.
>
> Best regards...Milind
> milind@idiom.com
>
>
>

RE: SOAP Serialization

["Eric M. Dashofy" <ed...@ics.uci.edu>]

Hello all!

With the Apache SOAP for Java API, serializers are provided for the Java
basic types, some other types, and one-dimensional arrays of these types.
Arbitrary objects can be serialized with a custom serializer if you write
one.

I have recently finished writing a serializer that can serialize and
deserialize (marshall and unmarshall, if you prefer) arbitrary Java objects
(they don't have to be Beans) to and from XML with a few minor caveats:

1.  You have to implement an interface, XmlSerializable, that my package
provides.
2.  You have to insert three boilerplate lines of code in your class, which
I provide.
3.  If you do not provide a default (no-arg) constructor for your
XML-serializable class, you have to change one boilerplate line of code.
4.  Private fields in a superclass that you do NOT have the code for must be
serialized somewhat manually by implementing two small additional methods.
This doesn't come up much in practice.  This is the only kind of field that
requires custom code, which is mostly boilerplate anyway.
5.  Transient/final fields are not serialized, because they're, well,
transient/final :).
6.  Additionally, my serializer can serialize multidimensional Java arrays,
but admittedly not in the SOAP style (yet).

This is done through a tiny bit of deep magic with Java's reflection API.
I've been spending the last couple of days inserting my Java<->XML
serializer into the IBM (now Apache) SOAP for Java package, and I have been
successful.  I'm now in the process of retrofitting my code, which contains
some of the same fixes as have been included in the new 2.0 release, into
the 2.0 release (It still works under 2.0, but I don't want to reinvent the
wheel).  I may post a patch or two to the Apache 2.0 release in the next
couple of days for the community's review.

In any case, this gives you characteristics VERY similar to Java object
serialization, in a very programmer-friendly manner.  Additionally, I have
implemented an AutoSOAPMappingRegistry that, if you try to serialize an
object that does not already have a registered serializer, will generate one
using my serializer if possible.  This eliminates the need for you to hassle
registering a serializer for each type of object you want to send in a SOAP
message.

Furthermore, on top of all this I have built a stubber that can take an
arbitrary Java interface and generate a CORBA/RMI/Distributed-Objects-like
stub for it, meaning that you don't have to write 30 lines of code per SOAP
call.  For this to work, I had to munge serialized exceptions into the
SOAPFault detail element, but it works dandily.

Sadly, I only got this working yesterday and it's not quite ready for public
posting.  If any of you folks are interested in taking a look at it, send me
an email or post to the discussion list, and I will consider sending it to
you or posting an alpha copy for evaluation.

Best Regards,
-----
  Eric M. Dashofy <ed...@ics.uci.edu>
  Graduate Student Researcher, Information & Computer Science
  University of California, Irvine
  http://www.ics.uci.edu/~edashofy

-----Original Message-----
From: Milind Gadre [mailto:milind@idiom.com]
Sent: Friday, August 18, 2000 12:29 PM
To: soap-user@xml.apache.org
Cc: soap@discuss.develop.com
Subject: SOAP Serialization

Hello all, I am new to this slippery world of SOAP, so please enlighten
me if my questions have already been answered some other place. I am
having a hard time figuring out the logic behind SOAP serialization of
arbitrary Java objects. I have not been able to find relevant
documentation on the matter.

My questions are:

[1] How does SOAP serialization handle protected/private fields of
arbitrary objects? Does it override some security settings in order to
get access to the private/protected fields? In an earlier post to this
discussion group I described a stack trace from the XMI classes.

[2] Similar to the readObject/writeObject logic of Java Serialization,
is it possible to intercept the SOAP serialization procedures to insert
custom logic? I see this as being critical to sending java objects down
the pipe.

[3] If the above is not possible, then how can I extend the SOAP
serialization classes so as to perform custom logic *just prior* to
sending an object and *just after* receiving an object.

[4] What about *transient* fields?

It seems to me that if SOAP is to support a general purpose
serialization mechanism, an API that has at least some of the
extensibility and features of existing Java Serialization is a must.

Thanks in advance for any help on this matter.

Best regards...Milind
milind@idiom.com

RE: SOAP Serialization

["Eric M. Dashofy" <ed...@ics.uci.edu>]

Hello all!

With the Apache SOAP for Java API, serializers are provided for the Java
basic types, some other types, and one-dimensional arrays of these types.
Arbitrary objects can be serialized with a custom serializer if you write
one.

I have recently finished writing a serializer that can serialize and
deserialize (marshall and unmarshall, if you prefer) arbitrary Java objects
(they don't have to be Beans) to and from XML with a few minor caveats:

1.  You have to implement an interface, XmlSerializable, that my package
provides.
2.  You have to insert three boilerplate lines of code in your class, which
I provide.
3.  If you do not provide a default (no-arg) constructor for your
XML-serializable class, you have to change one boilerplate line of code.
4.  Private fields in a superclass that you do NOT have the code for must be
serialized somewhat manually by implementing two small additional methods.
This doesn't come up much in practice.  This is the only kind of field that
requires custom code, which is mostly boilerplate anyway.
5.  Transient/final fields are not serialized, because they're, well,
transient/final :).
6.  Additionally, my serializer can serialize multidimensional Java arrays,
but admittedly not in the SOAP style (yet).

This is done through a tiny bit of deep magic with Java's reflection API.
I've been spending the last couple of days inserting my Java<->XML
serializer into the IBM (now Apache) SOAP for Java package, and I have been
successful.  I'm now in the process of retrofitting my code, which contains
some of the same fixes as have been included in the new 2.0 release, into
the 2.0 release (It still works under 2.0, but I don't want to reinvent the
wheel).  I may post a patch or two to the Apache 2.0 release in the next
couple of days for the community's review.

In any case, this gives you characteristics VERY similar to Java object
serialization, in a very programmer-friendly manner.  Additionally, I have
implemented an AutoSOAPMappingRegistry that, if you try to serialize an
object that does not already have a registered serializer, will generate one
using my serializer if possible.  This eliminates the need for you to hassle
registering a serializer for each type of object you want to send in a SOAP
message.

Furthermore, on top of all this I have built a stubber that can take an
arbitrary Java interface and generate a CORBA/RMI/Distributed-Objects-like
stub for it, meaning that you don't have to write 30 lines of code per SOAP
call.  For this to work, I had to munge serialized exceptions into the
SOAPFault detail element, but it works dandily.

Sadly, I only got this working yesterday and it's not quite ready for public
posting.  If any of you folks are interested in taking a look at it, send me
an email or post to the discussion list, and I will consider sending it to
you or posting an alpha copy for evaluation.

Best Regards,
-----
  Eric M. Dashofy <ed...@ics.uci.edu>
  Graduate Student Researcher, Information & Computer Science
  University of California, Irvine
  http://www.ics.uci.edu/~edashofy

-----Original Message-----
From: Milind Gadre [mailto:milind@idiom.com]
Sent: Friday, August 18, 2000 12:29 PM
To: soap-user@xml.apache.org
Cc: soap@discuss.develop.com
Subject: SOAP Serialization

Hello all, I am new to this slippery world of SOAP, so please enlighten
me if my questions have already been answered some other place. I am
having a hard time figuring out the logic behind SOAP serialization of
arbitrary Java objects. I have not been able to find relevant
documentation on the matter.

My questions are:

[1] How does SOAP serialization handle protected/private fields of
arbitrary objects? Does it override some security settings in order to
get access to the private/protected fields? In an earlier post to this
discussion group I described a stack trace from the XMI classes.

[2] Similar to the readObject/writeObject logic of Java Serialization,
is it possible to intercept the SOAP serialization procedures to insert
custom logic? I see this as being critical to sending java objects down
the pipe.

[3] If the above is not possible, then how can I extend the SOAP
serialization classes so as to perform custom logic *just prior* to
sending an object and *just after* receiving an object.

[4] What about *transient* fields?

It seems to me that if SOAP is to support a general purpose
serialization mechanism, an API that has at least some of the
extensibility and features of existing Java Serialization is a must.

Thanks in advance for any help on this matter.

Best regards...Milind
milind@idiom.com