About Products Services Projects Publications

Language Independent Object Serialization

Problem

How do we serialize Objects so we can later read them back into a program of either the same language or a different language? Also, how do we allow humans to easily create, read, and modify these objects (i.e. include human languages)?

It is common to need a simple way to save a web of objects and later read them back in to the same program or a different one. Sometimes the programs will be of the same language (e.g. both Java) and sometimes they will be different. The later is much more complicated, especially in its most general form (any object to any language). A variation on the inter-language movement is from human writable language (through text) to a computer language. Usually this is restricted to very simple information (e.g. String properties) or document-oriented information (e.g. HTML/SGML).

Forces

If we do not have a single interchange format we will have multiple ones and the complexity will be higher. If we can not describe objects in a cross-language format than languages will be unable to interoperate with this mechanism. If we can not describe object information in human-readable formats than humans will be less likely to understand the process and will be unable to participate in the general capabilities (e.g. they can only work with simple property files).

A single, general, object interchange approach would allow all movements of objects to be easier to both computers and people. On the other hand, if we try to design a general approach that becomes too cumbersome it will not be useful to the many common needs of applications (i.e. same language serialization and simple property files).

MONDO Approach

Encode information as "recipes" to build objects. Describe the most general information first: what to build and what "ingredients" (recipes for other objects) it needs. Next describe the language independent model of that information. Finally describe the possible implementations for that model in different languages. Any of these steps (other than the first) can be left off but it results in less ability to move between languages.

Also, enable "recipes" to be easily convertible to a human readable and writeable form: usually as marked-up text files in any one of XML/SGML/OML (the last being oriented to objects and MONDO, an Object Markup Language similar to XML).

Some simple examples of recipes (in OML and no models yet) are:

=====================

    <Period
        start = <Date iso="1997-10-01">
        end   = <Date>
    >

----------------------

    <Map pairs = (
        <Pair key='speed0' value = ('speed0.gif' '(Speed0)' 4 11)>
        <Pair key='speed1' value = ('speed1.gif' '(Speed1)' 4 11)>

        <Pair key='remote'   value = ('remote.gif' '(Link to Remote Location)' 11 11)>
        <Pair key='local'    value = ('local.gif' '(Link to Local Page)' 6 6)>
    )>

----------------------

    <JavaClass
        name        = "COM.chimu.kernel.basicTypes.Period"
        version     = "v0.1"
        vmRequired  = "1.1"
        description = "This is a simple Period which uses
                       java.util.Dates as its start and end values"
        bytecodes   = <Binary encoding=hex [[cafebabe...2000a]]>
    >

----------------------

    <mode name = "section-reference"
        bindings = (
        <When element = "note"
              build   = <!Recipe (
            <Paragraph
                font-size = "12pt"
                content   = <Sequence
                    font-weight = "bold"
                    content     = "Warning:">
            >
            <process-children>
            ) !Recipe>
        >
        <When element = "title"
              build   = <!Recipe <process-children>>
        >
        //...
    >

----------------------

  <P {VTL's company philosophy and strategic direction
    are set by <A href="lmanley.html" {Luke Manley}>,
    the company's President.  The following is a summary
    written by Luke on what he views as the key elements
    to VTL's success. } P>

=======================

All of the above, when by themselves, rely on the reading and "building" application to interpret and implement the information model. This might be suitable for language specific encoding of information or when the model is very standard.

But we can also explicitly add model information, for example:

   <!-- ExampleModel.oml -->
   <Model types=(
        //...
        <Type
            name = "Period"
            description = "A range of dates"
            properties = (
                <Property name="start" type=<TypeReference name="Date">>
                <Property name="end"   type=<TypeReference name="Date">>
            )
            constructors = (
                <Constructor ("start" "end")>
            )
        >
        //...
    )>

And loosely[1] link it to the actual information:

   <UseModel fileName="exampleModel.oml">
   <Period
        start = <Date iso="1997-10-01">
        end   = <Date>
    >

Alternatively we can use well-known models, which allow wider interchange without moving recipes:

    <UseModel
       model=<FindReference
            <DTDReference sysid="-//HaL and O'Reilly//DTD DocBook//EN">
       >
    >

    <UseModel
       model=<FindReference
            <Reference id="com.sun.java.jdk1_1.standardClasses">
       >
    >

The next step is to be able to connect specific implementations to the models, but this is covered in a different MONDO approach statement: "Extending Model Functionality"

Benefits

We have a very general way to encode information so multiple applications, programming environments, and people can understand it. It is simple to parse and process for a computer and for a person. We have also cleanly separated the information from the specifics required to instantiate that information in any given programming environment. But we can encode general models for the information in the same format (complete reflectivity and closure) and take advantage of them if the application desires.

We can take advantage of sharing models and information through public references to objects/recipes or by "shipping" recipes along with the information. This supports both a push and a pull model of moving information, models, and implementation between applications.

Inter-language movement is inherently supported, as well as inter-version (e.g. JDK version) movement. The choice is up to the application how well the information is described vs. how much the receiving application will be responsible for interpretation.

General document markup, objects, and information modeling are aligned and we can take advantage of the concepts, patterns, designs, and abilities of all of them.

Penalties

MONDO is a newer approach that is different from industry specific and language-specific approaches. More overhead than language specific binary approaches [this could be lessened or removed by using binary recipe encoding format]. Possibly slightly more overhead than simple text property files, but is much more general.

See

The MONDO Design document, an especially Chapters 1-5.

http://www.chimu.com/projects/mondo/design/index.html

For related technology see the Smalltalk file-in format, LISP, Java serialization, CORBA and the ODMG OIF specification. Some resources for these can be found at:

http://www.chimu.com/projects/mondo/links.html

Projects > MONDO