Home Help Center

Serialization without Transport

I have a requirement for serializing an object and sending it over Tibco or sockets, i.e. we want transport independence. Can Ice serialization be used without transport? Is there a clean way to do it?

Looking at an Ice generated proxy, it looks like one could create MemoryInputStream and MemoryOutputStream classes that implement IceInternal.BasicStream. The generated code would then be hacked to use these classes instead of:
IceInternal.Outgoing og__ = getOutgoing("sayHello",
Ice.OperationMode.Nonmutating, context__);
IceInternal.BasicStream os__ = og__.ostr();

Is this approach sound? Does anyone have code or ideas for creating the MemoryStream classes? How could MemoryStream be injected cleanly in the Ice generated proxy?

Is there a different approach that would be cleaner?

Comments

  • marcmarc FloridaAdministrators, ZeroC Staff Marc LaukienOrganization: ZeroC, Inc.Project: The Internet Communications Engine ZeroC Staff
    Welcome to our forums. Please see this post regarding our support policy.
  • AndewAndew Member
    Just added signature

    Just added signature
  • marcmarc FloridaAdministrators, ZeroC Staff Marc LaukienOrganization: ZeroC, Inc.Project: The Internet Communications Engine ZeroC Staff
    You shouldn't use any IceInternal methods. Instead, use the "Dynamic Ice" interfaces. Please see Chapter 35 "Dynamic Ice" in our user manual, as well as issue 11 and 12 of our newsletter Connections.
  • AndewAndew Member
    Sample Serialization Code

    The following seems to work:

    // Ice autogenerated classes created with the "-- stream" flag contain the ice_write and ice_read methods.

    public byte[] serialize(Order1 order)
    {
    byte[] bytes = null;

    Ice.OutputStream outStream = Ice.Util.createOutputStream(communicator());

    order.ice_write(outStream);
    bytes = outStream.finished();

    return bytes;
    }

    public void deserialize(Order1 order, byte[] bytes)
    {
    Ice.InputStream inStream = Ice.Util.createInputStream(communicator(), bytes);
    order.ice_read(inStream);
    }

    Does this look right? Are there any negative side effects? Is there a better way?
  • mesmes CaliforniaAdministrators, ZeroC Staff Mark SpruiellOrganization: ZeroC, Inc.Project: Ice Developer ZeroC Staff
    You didn't show the Slice definition of Order1. Most Slice types can be handled as you've shown, but instances of Slice classes require more effort.

    Take care,
    - Mark
  • AndewAndew Member
    Slice Definition

    The slice definition follows:

    module Demo
    {
    struct BookingInfo1
    {
    string book;
    };

    struct Order1
    {
    string quoteID;
    double price;
    string expiryDate;
    int quantity;

    BookingInfo1 bookingInfo;
    };

    interface Hello
    {
    nonmutating void sayHello(Order1 o);
    idempotent void shutdown();
    };

    };

    What does "instances of Slice classes" mean?
  • mesmes CaliforniaAdministrators, ZeroC Staff Mark SpruiellOrganization: ZeroC, Inc.Project: Ice Developer ZeroC Staff
    Andew wrote:
    What does "instances of Slice classes" mean?
    It means a Slice object transmitted by value, as shown by the sendList operation below:
    // Slice
    class PointList
    {
        int x;
        int y;
        PointList next;
    };
    
    interface I
    {
        void sendList(PointList l);
    };
    
    If you haven't already discovered it, take a look at the example in demo/Ice/invoke for a demonstration of serializing all of the Slice types.

    Take care,
    - Mark
Sign In or Register to comment.