Passing Objects as part of SOAP Request and Getting Objects back as Response....using webservices

Question

Hi! I have a webservice, which takes java.lang.object objects as parameters (because at runtime only know hte type of object)...after doing process, reply response setting java.lang.Object to it.

I am able to send the reuest objects to webservice from calling program, but getting NotSerializable exception while building the response from webservice.

I came to know that 'if we implement, java.io.serializable, the mebmers also should be serializable objects'... here Object isnot a serializable object..it doesn't impllement Serializable....

If anyone could guide mw with right solution..I wouold be thankful.

Thanks Bhaskar

Answer 1

If the members of the class don't implement Serializable then you can't use native Java serialisation for it. That's basically what your error message is telling you.

If you cannot cause the underlying objects to implement Serializable, then you are probably going to have to find a different method of serialisation for passing in and out of your web service. Popular varieties from Java are XML, JSON, AMF, although you can always roll your own.

If you have Java objects on either end of your request then make sure you factor your code so that your serialisation and de-serialisation code is in a library that can be used at both ends. That will greatly ease the burden of testing in your implementation.

I would recommend keeping all the serialisation code out of the domain objects themselves. Think about using a factory pattern for creation of your objects.

HTH

Answer 2

Serialize the object to a Byte Array, and return that in your SOAP call, then marshall the object back from the Byte Array in the client. SOAP can readily and efficiently handle Byte Arrays, and the Serialization will be an implementation detail outside the scope of the SOAP transaction.

Answer 3

To solve your immediate problem, you should accept a "Serializable" in stead of "Object". Then you need to make your class serializable. If you can't do that, you will never be able to transfer the object over a webservice.

This is the core you must understand: If it can be transferred over a webservice, that means it is possible to serialize it. If it is possible to serialize it, it is possible to make it a Serializable.

If you can't modify the class itself, you can work around the problem. For example you can create a new Serializable class, which can read all relevant info from your object.

To say that all members of a Serializable class needs to Serializable too is not the complete truth. All needed data needs to be serializable, but the classes themselves does not need to implement the Serializable interface.

The alternative is to implement these two methods:

private void writeObject(java.io.ObjectOutputStream out) throws IOException;
private void readObject(java.io.ObjectInputStream in) throws IOException, classNotFoundException;

There is an article about serialization here: Discover the secrets of the Java Serialization API

It describes how to use these two methods under "Customize the Default Protocol".

If that isn't advanced enough, keep in reading under "Create Your Own Protocol: the Externalizable Interface" to see how to implement the Externalizable interface (a subinterface to Serializable), which gives you complete control over the serialization process.

(I am ignoring the "transient" feature for simply ignoring non-serializable data, since I assume that you need them. If my assumption is wrong, read the part "Nonserializable Objects".)

Answer 4

I have a webservice, which takes java.lang.object objects as parameters (because at runtime only know hte type of object)

This part worries me. Not knowing the type while programming is a code smell. If you have no idea what it is, how can you make code to handle it?

There could be a legitimate reason to do what you are trying to accomplish, but usually there is a better way. The real question here may be: "How should I design my webservice and code, to handle my requirements?"

When a method accepts "Object" or other extremely general types, they often contain a switch-like structure which checks for certain types and handles them differently, and "unknown" types either throws an exception, or (worse) may simply be ignored. The solution here is probably to create a new method for each type. And it doesn't really matter if it is just a usual Java method, or if it is a webservice.