Object serialization in ICE

shantanu_k06

Hello,

Is there any support for object-serialization in ICE? Or in case there's isn't, can anybody please suggest me a 3rd-party library that can work across C++ and Java (subject to constraints, admittedly)? I tried finding it in the manual, but to no avail. And I am yet to print the manual for a thorough reading, so I may not have the right information as of now.

Consider this scenario:

1. S is a server having ICE server-side stubs.
2. C1, C2, C3....Cn are clients.
3. Clients have a trivial server-side stub that is activated in response to subscribe/notify mechanism.
4. The top level object-type that is understood by all clients is "Message".
5. Now, assuming that C2 and C5 want to exchange a message that is derived from "Message". For example -- "VoiceMessage".

Now, is it possible to send a "VoiceMessage" from C2 to S, and yet have it delivered correctly to C5 by S given that C5 can understand "VoiceMessage" correctly? The point is, S should not have to be aware of the derived type of "Message".

That's the reason why I want object serialization, because messages would be pretty dynamic in nature and it won't be possible to update the server-stubs on S for each message-type. I don't know, am I sounding like asking for "DynAny"?

Regards,
Shantanu

mes

Hi,

The situation you're describing would normally result in the VoiceMessage object being "sliced" to the Message type if the server does not have a factory installed for VoiceMessage. However, it's also possible to forward requests without unmarshaling them. This has several advantages for an event system: it avoids the overhead of unmarshaling and remarshaling the request, it eliminates the need for the server to have static type knowledge, and therefore it avoids the slicing issues for object parameters.

Although it's not documented yet, it is an "official" API used by both IceStorm and Glacier. In short, you derive a servant class from the Ice::Blobject class and implement the ice_invoke function. The servant can forward the request by calling ice_invoke on the recipient's proxy.

Take care,
- Mark

shantanu_k06

Neat. Thanks for the tip, Mark. However, I am still not sure how to deal a "store-and-forward" situation with this method. For an example, a scenario where a client logs in to download his messages later (something like Yahoo Messenger Offlines). Any pointers would be appreciated.

Regards,
Shantanu

mes

Assuming you have some kind of persistent storage available, then the server would need to store the input parameters as well as request information such as identity, operation name, etc. The input parameters are provided to ice_invoke as a sequence of bytes, and the request information is contained in the Ice::Current argument.

Continuing this line of thought, the recipient could request that the server forward all requests for a particular identity, at which point the server would scan its persistent state for the recipient's identity and call ice_invoke on the recipient's proxy for each stored request.

If you really prefer to do your own serialization, then you would have no choice at this point but to use the IceInternal::BasicStream class to obtain the marshaled representation of your state.

Take care,
- Mark

amrufon

I was able to implement something like this with ICE last year (although due to budget reasons ... it got shelved)

Basically, the system deals with multi-dimensional data. The data can be a simple vector to a 6 dimension matrix. Although each of the data is named, the client won't be able to know its dimension until it got down the wire from the server.

In retrospect, the server does not even know what its storing. All it knows is that the ice server is getting a sequence and its storing it as a dictionary data (name-value pairs).

Fortunately for me, the main programming language I used (J Programming Language) supports data serialization internally to it so any data being sent to the server are automatically serialized and data coming from the server are converted back into its original shape and datatypes.

I basically did the conversions with the main application and used ICE as the transport protocol.

Alex