The Object Model and Component Architecture history and abbreviation
- From: Dirk Luetjens <dirk luedi oche de>
- To: gnome-list gnome org
- Subject: The Object Model and Component Architecture history and abbreviation
- Date: 12 Aug 1998 01:48:53 +0200
Hello,
I have followed the latest discussion about the Gnome Object Model,
and I have to say, that Iīm more confused than before. Therefor I
have tried to put together what I know what is behind the different
keywords like COM, OLE, CORBA, OpenDoc, ...
The following is structured in the way of a small history, of how we
got here, the task that must be performed by the different layers and
finally an abstract about the mentioned models.
Perhaps someone else could fill in the missing gaps, correct wrong
statements and spelling :-)
----------
History:
In the beginning, there was a programming language and everybody was
happy, that he/she was able to write smaller or bigger applications in
this language. To not recode tasks over and over again, libraries where
invented and programming methods like data encapsulation. As time went
by, one recognized that the APIs they created for their libraries
were to tight coupled to the libraries implementation and that they
didnīt reflect most programmers problem. They wanted to be able to
redefine some implementation details, enhancing the API without
loosing the work that was done. Although a lot of problems where
related, so they invented the Object Oriented Programming (OOP). With
this programming technique they were able to enhance their APIs,
overload functions, group similar problems together, inherit methods
and encapsulate the data in so called Objects. But still they were
tight to one object oriented programming language, to the same adress
space, to the same computer. A lot of hairy programming was done to
implement one applications function into another one.
What was needed at that time was a _Object Model_ which was capable of
putting the implemented Objects at someoneīs else disposal. The goal
was to allow an application to access objects (or library functions),
which were not instanciated by the application. For this it is
necessary to marshall the parameters, that are transfered in the function or
method call to the Objects point of view and vice versa. Compare it to
a telephone central. Only that you are capable to phone all over the
world does not garantee you, that your opposite can understand you.
There are only 2 possibilities, first you know the language, or
someone else translates for you.
One of the first representative of such a technique were the Remote
Procedure Calls, RPCs (they do not extend to objects, only for
APIs). Other implementations are
- DCE (Distributed Computing Environtment),
- CORBA (Common Object Request Broker Architecture),
- SOM (System Object Model)
- COM (Component Object Model)
- PO (Portable Objects)
Now, that we are capable of calling remote objects makes further steps
necessary. First we must know where to find an remote obejct, we must
provide security when the call is done over insecure networks and so
on. So all of the above mentioned Object Models define so called
horizontal services.
But one problem still isnīt solved. Only that Iīm able to talk to
another person all over the world, and that I could understand what he
is saying, does not imply that we talk about the same subject. If I
want to compose a multimedial document and want to embed as many
different ojects as possible, all those objects must at least respond
to a common set of functions. Otherwice my document editor has to
speak a lot of different dialects or must implement all those
different APIs humans can think off. Again different companies
different goals came up with so called _Component Architecures_ and they
implemented different standards.The Linux community, especially the
Gnome, KDE and GNUstep groups are about of doing the same.
Common names are:
- OLE, OLE2: Object linking and embedding
- ActiveX
- OpenDoc
- OpenParts
- KOM
- GOM
- ??? (some more?)
Tasks:
What are the requirements for the Object Model and the Component
Architecture?
The Object Model must provide the access to the (distributed)
objects. It must do all necessary tasks to hide the different
hardware near implementation details from the user, e.g big and little
endian, different stack architecures as in C and Pascal, ... Therefor
it must marshall the function or method call at the callers location
and unmarshall it at the objects location.
It must define some common services to find, instanciate, refcount,
... the distributed objects. These are so called horizontal or common
services.
Fast marshalling between the caller and the callee.
Furthermore it must provide the IDL syntax (Interface Description Language)
which is the authorative description of the methods provided by this
object.
The Component Architecture on the other hand must define a set of
standard methods applied to equivalent objects.
What is needed from a Document Component Architecture?
- An object must be embeddable in another object
- different recursion depth must be supported
(an Image, that is embedded in a spread sheet, that is embedded in
an Text)
- "in place" and direct editing. One click on the deepest element
should allow the editing of this object in that place
- different outline shapes: suggest a circular image which is embedded
in a text document where the text flows around the circle
- ...
Abstract:
API: Application Programming Interface
defined set of functions to a library
RPC: Remote Procedure Call
a way to call a remote function. The interface is described through a
rpc specific IDL and there exists specific datatypes, that can be
marshalled. RPC only extents to functions, not to objects.
DCE: Distributed Computing Environment
Object Model, Open group
Basis of this object model is the RPC. it defines a naming service,
security service, distributed time service, distributed files
service.
CORBA: Common Object Request Broker Architecture
Object Model, Object Management Group (OMG)
Thought as a generic, computer and OS independant Object Model.
slow? due to marshalling overhead even on the local computer
SOM: System Object Model
Object Model, IBM, OS/2
????
COM: Component Object Model
Object Model, Microsoft (Active Group)
+ fast concearning the method call
- restricted to the same computer
- complicated during the programming
DCOM: Distributed Object Model
Object Model, Microsoft (Active Group)
enhancment of the COM standard to different computers on the same network
PO: Portable Objects
Object Model, Apple, Next?
????
OLE, OLE2: Object linking and embedding
Component Architecture, Microsoft
ActiveX:
Component Architecture, Microsoft
renamed OLE
OpenDoc:
Component Architecture, Apple, IBM WordPerfect
created as a counterpart to OLE
features about OLE in the sence, which features OLE lacks (this is
copied from a german magazin ct' 3, 1997 pp238)
- OLE is only capable of editing objects of the upperst layer in
place.
- to edit an object on a deeper layer, you must first open all
objects on the higher layers
- OLE lacks a standard of a Macroeditor
- only receteangle objects possible in OLE
- no real support for embedded objects that are bigger than a page
- bloated
(please note, that these are features missing against OLE, not
OLE2. I have never done any windows programming, so I do not know
about OLE2)
OpenParts:
Component Architecture, ???
KOM:
Component Architecture, KDE
GOM:
Component Architecture, GNOME
IDL: Interface Description Language
The authorative description of an objects interface. From this
description an idl-compiler generates language appropriate client and
server bindings(stubs) which are filled by the application
programmer. The stubs hide all the dirty detail of marshalling the
parameters from the programmer.
------------
This document is far from beeing finished, correct and
detailed. Consider it as a work in progress. If you have corrections,
additions please feel free to mail me. Iīm thinking of a better
structure and more information.
Now Iīm tired :-)
Dirk
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]