The MONDO Approach to: Language Independent Object Serialization
Mark L. Fussell
fussellm at alumni.caltech.edu
Mon Dec 1 14:23:17 GMT 1997
The MONDO Approach to: 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).
Tradeoffs
=========
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
Notes
=====
[1] Actually, we can be even looser than that using a separate
"interpretation" file.
[2] I ran over 3 pages by a couple paragraphs :-( I guess the DSSSL
example pushed me over.
--Mark
mark.fussell at chimu.com
i ChiMu Corporation Architectures for Information
h M info at chimu.com Object-Oriented Information Systems
C u www.chimu.com Architecture, Frameworks, and Mentoring
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev
mailing list