Object Models
Table of Contents
Introduction
Comparing the Many Object Models
Standard Domain Models
Object Model Interoperation
Introduction
A major challenge for command and control and both real and virtual enterprises
is sharing information, which comes in many formats each with more or less
declarative semantics. HTML and WWW provide a partial answer for sharing
that works well for unstructured and semi-structured information.
Object technology is quickly becoming the representation vehicle for representing
structured sharable information.
But there are many object models and an object during its lifecycle
may start in an Analysis and Design Tool, be instantiated in the product
data representation language EXPRESS, be translated to OMG IDL for distribution
and language neutrality, be mapped to C++ for processing and perhaps to
Smalltalk as well, and then be stored in an SQL3 relational database system,
an OODB, or even a file system, all of which provide persistent storage.
Thus, there is a need to represent data in different data representations
because not all services are available for all representations, and often
there is a need to be able to interoperate among different data models.
This section is included in the survey to provide pointers to the many
object models and to identify some of the main strategies for object model
interoperation.
Comparing the Many Object Models
ANSI X3H7 Object
Information Management was commissioned in 1992 with an overall goal
of developing a "coherent approach to information management standards
fostering consistent use of the object paradigm in various business and
technology domains (programming languages, database, user interfaces, operating
systems, distributed systems, object analysis and design, enterprise modeling
and information modeling, ...)"
In 1996, X3H7 completed its Object
Model Features Matrix Final Report which compares the features of the
following object models:
Analysis and Design Methods, C++, Cecil, Component Object Model
(COM and OLE 2), OO COBOL, Eiffel, Emerald, EXPRESS, Management Information
Model, Matisse, ODMG, OMG CORBA IDL, OMG Core Object Model, OODB Task Group
Reference Model, Open Distributed Processing, SELF, Smalltalk, SQL3, and
System Object Model (SOM).
The document makes it clear that, while there are many similarities in
the different object models, there are also many sometimes subtle semantic
differences that can make complete interoperability among them difficult.
X3H7 does not address the hard problem of interlanguage sharing.
Standard Domain Models
It is worth noting that interlanguage sharing is not the only barrier to
sharing information. For instance, it is often the case that systems written
in the same language but that decompose a problem differently will
some have trouble interoperating.
A number of communities address this problem by defining common libraries
of objects in some object modeling language. Examples are:
-
the STEP
community for manufacturing product data
-
the OMG Domain Technical Committee
with its subcommittees on financial, manufacturing, healthcare, telecom,
business objects, and GIS.
-
the Object Modeling Working Group (OMWG) (password protected) for command
and control.
Object Model Interoperation
Common situations requiring object model interoperation include the following:
-
a greenfield (brand new) application is being developed and decisions on
sharing are taken into account during its design.
-
legacy representations A and B both represent the same real-world object
differently and it is desirable for a new application to access the object
in A and B representations. This can sometimes be accomplished by data
sharing (or conversion, either manual or automated).
-
a common class library is written in language A and it is desirable to
subclass it (customize it) in language B. An important subcase is when
OMG object services or common facilities (see OMG
section of this survey) are written in language A and need to be used
in other languages.
Following is a list of some of the major approaches we have so far identified
to interlanguage sharing.
-
avoidance - implement a system in a single language. Some very large
single-language only systems exist. Some of these have faced hard problems
of providing for distribution, persistence and other services via implementations
specific to the language. That is, a distributed Smalltalk can use the
standard Smalltalk BOSS external representation to move Smalltalk data
from one site to another. There is no comparable standard external representation
for C++, COBOL, Ada, etc. See HP
Distributed Smalltalk. The ARPA/TI Open OODB project provided its own
external representation for C++.
-
ad hoc - if interoperability is defined as "unplanned reuse"
then it will always be the case that useful legacy subsystems are available,
written in different programming languages, that can be glued together
to form systems. Remote Procedure Call mechanisms like XDR and foreign
function call interfaces provide means of calling out to other languages.
-
intermediate language - rather than mapping data from one representation
to another in an ad hoc way (with N**2 possibilities), another approach
is to select a common intermediate language useful for sharing. Then define
mappings from that representation into C++, Smalltalk, Ada, Java, etc.
OMG Interface Description Language (as well as supersets like ILU ISL and
non-OO variants like DCE IDL) provide ways of doing this. Many groups define
their sharable data in IDL, which in some cases can be whole class libraries
and in other cases more simply IDL interfaces to legacy system APIs. Other
groups are defining standard mappings from other representations to OMG
IDL (e.g., the STEP community's Express to IDL mapping). Some of the more
interesting systems following this approach include:
-
database centered - This approach has traditionally been used when
tools and applications share information via a central database representation.
Choices of DBMS include relational (a low level record-based common representation)
or object-oriented DBMS (higher level but usually supporting one native
object representation well, e.g., C++, Smalltalk). Note that this is actually
a variation on the intermediate language approach in which the intermediate
language is supported by a DBMS. If all applications as well as the DBMS
use a single object model (e.g., all C++ or Smalltalk) then this is also
the avoidance strategy. ANSI X3H2 is defining SQL3 to include yet
another language neutral object model based on ADTs (abstract data types.
Thus, it is too bad that OMG IDL and SQL3 ADTs are not converging since
they (somewhat unnecessarily) provide two industry distinct ways of modeling
sharable information.
-
binary compatibility - Microsoft Component Object Model (COM) defines
a binary standard compatible with any language that supports implementing
and calling functions with C linkage though a pointer. See comparisons
of SOM versus COM at here
(pro-SOM) and here
(pro-COM).
-
data interchange formats - for many purposes, it is useful to define
external representations of data in some file or streaming format. These
formats may be binary or less efficient but human readable ASCII. These
on-the-wire or file storage formats typically are information preserving
and may or may not encode meta data as well as data. As mentioned above,
some object models have standard external representations defined (e.g.,
Smalltalk, EXPRESS) and others do not (unfortunately). In general, data
interchange formats are batch but they could also be incremental and fine-grained
for use in marshalling arguments or by OODBs. In addition to data interchange
formats, there are commonly conversion routines to map one format to another
for many interesting conversions (these may lose information) and compression
mappings used when shipping representations across networks. See OMG Common
Facilities Data Interchange
Format RFP #3 (postscript). The IETF community tends to deal mainly
in wire formats since that does not require a particular object model at
either end but it may instead require application-developed non-standard
conversions at both ends. With today's data interchange formats, there
is no real guarantee that encoded objects or the files they are in are
strongly typed. On OODB or Object File system would improve this, making
it less an issue whether data interchange formats were or were not object
formats.
-
web-centered - The Web is a special case of the data interchange
strategy in which much information is converted from some native form
to HTML or is shipped in native form to any destination. The web makes
it easy to access information in its native representation and to locate
and install conversion filters if they are available. Alternatively, it
makes it easy to install native browsers to view various formats. In these
ways, it does not so much enable fine-grained sharing as it does make co-existence
of many formats very manageable.
This research is sponsored by the Defense Advanced Research
Projects Agency and managed by the U.S. Army Research Laboratory under
contract DAAL01-95-C-0112. The views and conclusions contained in this
document are those of the authors and should not be interpreted as necessarily
representing the official policies, either expressed or implied of the
Defense Advanced Research Projects Agency, U.S. Army Research Laboratory,
or the United States Government.
© Copyright 1996 Object Services and Consulting,
Inc. Permission is granted to copy this document provided this copyright
statement is retained in all copies. Disclaimer: OBJS does not warrant
the accuracy or completeness of the information on this page.
This page was written by Craig Thompson. Send questions
and comments about it to thompson@objs.com.
Last updated: 04/22/96 7:55 PM
Back to Internet Tool
Survey -- Back to OBJS