XML and binary data:
- Isn't there a problem with none-XML-savvy characters?
- We used to do MIME-decoding/encoding of byte-data/objects for XML-RPC.
Serialization/Performance:
- In our messurements, the performance of Java serialization makes up a
problem.
- We implement custom serialization as XML, which proven to two times faster
than standard marshalling, although we use a DOM parser (XERCES) to decode
the objects state.
I'm not sure it is "better", but this is how we have implemented XML-RPC,
with regards to object serialization and binary data:
- Binary data as MIME-encoded ascii
- All objects that is accepted as arguments / return values for XML-RPC
implement a custom interface: XMLSerialization, with two public methods:
String toXmlString() and void fromXmlString(String xml). We then implement
custom marhsalling on the classes (readObject, writeObject) using the
methods of the XMLSerialization interface. When the XML-RPC framework
performs marshalling, it uses XMLSerialization. For RMI, the same methods
are invoked indirectly through custom marshalling.
But as Rickard points out, all this is done for you by a SOAP
implementation, like Appache SOAP :-) We have not yet tested the Appache
SOAP implementation for production. So far (lab environemnt) I'm happy with
it. But I would need a wsdl->VB proxy generator. Why has IBM missed this
simple trick to break into MTS/client/server camps?
/Johan
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Engstr�m Anders
Sent: 02 January 2001 12:11
To: [EMAIL PROTECTED]
Subject: OT: Serializing java-objects.
Hi.
This is a somewhat off-topic question, but I'll go ahead and ask it anyway -
I guess some of you must have run into the problem before.
We have an application that uses a servlet as a front-end for a couple of
EJB's. The client is an Applet that uses XML-messaging/RPC over HTTP to
invoke methods on the EJB's through the servlet.The XML-RPC is defined by
us, and is really a light-weight XML-RPC version (http:((www.xmlrpc.org).
We use the XML to specify which EJB to run, and which method to run on the
EJB. Also, the parameters are sent as either plain text, (text nodes) or
XML-documents (inside CDATA-sections within the XML-payload). Return values
are also sent from the servlet to the applet using plaint text och XML.
Now - we want to extend this functionality a bit, and allow parameters and
return values being sent as serialized java objects. The idea is to
serialize the object into a byte-array and somehow send this array as a
string within the XML-payload. The string is then put into a byte-array and
deserialized. This works fine - but I'm not sure we've solved it in the most
elegant way :/
Again - the idea is to represent the serialized object as a String. Below is
the utility-code we're using to read/write the object/string:
// Write an object to a String
public static String getString( Object object )
throws IOException
{
ByteArrayOutputStream baos = new ByteArrayOutputStream();
ObjectOutputStream os = new ObjectOutputStream(baos);
os.writeObject(object);
os.flush();
byte[] b = baos.toByteArray();
StringBuffer buff = new StringBuffer();
for( int i = 0; i < b.length; i++ ){
buff.append( b[i] );
if( i < (b.length-1) )
buff.append(",");
}
os.close();
baos.close();
return buff.toString();
}
//Read an object from a String
public static Object getObject( String data )
throws IOException, ClassNotFoundException
{
StringTokenizer tok = new StringTokenizer(data, ",");
byte[] b = new byte[tok.countTokens()];
int i = 0;
while( tok.hasMoreTokens() )
b[i++] = Byte.valueOf(tok.nextToken()).byteValue();
ByteArrayInputStream bin = new ByteArrayInputStream(b);
ObjectInputStream oin = new ObjectInputStream(bin);
Object o = oin.readObject();
oin.close();
bin.close();
return o;
}
<<eof>>
This is a bit akward as the format of the string is defined entirely by us..
Do you guys have any other ideas on how to represent the object as a string,
and then read the string deserializing the object again?
Best Regards /Anders
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
