Re: The Object Model and Component Architecture history and abbreviation

[David Jeske <jeske home chat net>]

This is great... I figured I go in and fill in a few blanks.

On Wed, Aug 12, 1998 at 01:48:53AM +0200, Dirk Luetjens wrote:

[.. snip ..]

> 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)

  COM dosn't actually marshall or unmarshall arguments. Nor does it
handle non-local (i.e. out of address space) objects. It's just a
binary standard for connecting together code. It more replaces the C
shlibrary link methods than anything.

  DCOM is the distributed COM wrapper. DCOM generates 'stub objects'
(much like RPC generates stub functions) which marshal and unmarshal
arguments. (more below)

> - PO (Portable Objects)

  This is actually "distributed object" (DO) or "portable distributed objects"
  (PDO). (more below)

> Abstract:

> 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

CORBA had a Component Architecture which was designed at the same time.

> SOM: System Object Model
>  Object Model, IBM, OS/2
>  ????

  Used for the basis of OpenDoc. It had versioning, and
inheritence. It was basically around to solve the C++ fragile base
class problem. Early on it was a pain to program for, then DirectToSOM
compilers emerged and things became much more straighforward. It
required a virtual function call for every method (like COM) and
people complained that would exact too much of a performace
penalty. Ironic, considering that COM is considered fast compared to
other objects models because it only uses virtual function calls for
every method. :) Because they tried to tie it to the language object
model, they left compatibility between different versions of an object
up to the programmer. Often causing much grief.

  OpenDoc used SOM. 

> COM: Component Object Model
>  Object Model, Microsoft (Active Group)
>  + fast concearning the method call
>  - restricted to the same computer
>  - complicated during the programming

 They did away with concepts like versioning, and subclassing. They
decided that to version an object once it was released really didn't
make any sense, because it had been released. They also decided to go
with a code-reuse mentality called 'aggregation' instead of
subclassing. This provided some additional benefits with respect to
run-time object composition, but was one of the most highly criticized
issues. (i.e. go search the net for COM vs SOM and you'll find someone
bashing COM's lack of subclassing and versioning. In my opinion, COM's
choices on these two issues are the two BEST things about it.) 

 COM+ (due out sometime next year in VC++ 6.0) apparently adds
subclassing.

 COM dosn't define type vending or dynamic method dispatch. Instead
these things are layed on top (type-libraries, and IDispatch).

> DCOM: Distributed Object Model
>  Object Model, Microsoft (Active Group)
>  enhancment of the COM standard to different computers on the same network

DCOM is technically the name of the wire-protocol which is
used. Although there are some other things lumped in there like the
DCOM ORB.

> PO: Portable Objects
>  Object Model, Apple, Next?

Distributed Objects from NeXT. I think this predates CORBA, maybe it
was around the same time. They used Objective-C and developed a wire
protocol, ORB, and argument marshaler for Objective-C called
DO. Because Objective-C provides a portable way to marshall and
unmarshall arguments to and from method calls, DO has some unique
properties:
   + no stub generation is necessary, there is only one set of proxy
     code and it handles all objects
   + any object can 'transparently' be made a remote object. For example
     pass any Objective-C object as an argument across a DO link, and 
     DO will automatically turn that into a proxy on the other side
     which talks back across the link to the original object.
   + seamless integration of programming language (Objective-C) with DO
   + GNU implementation of DO available
   - tight coupling between Obj-C and DO make it's use with other languages
     burdneded. None the less, even programming in something else and
     using Obj-C for DO is pretty easy.

PDO (Portable Distributed Objects) is just the NeXT marketing name
which refers to Ports of DO which run on non-NeXT operating
systems. For example, HP-UX and Solaris.

> OLE, OLE2: Object linking and embedding
>  Component Architecture, Microsoft
> ActiveX:
>  Component Architecture, Microsoft
>  renamed OLE

This should be reworded, as I think people will be confused by
it. "OLE was renamed to ActiveX".

> 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.

Keep in mind that not all object models/languages use stube. They are
required because if you are using standard C (or C-like) calling
conventions, there is no portable way to (un)marshal arguments in and
out of function calls. If using OO languages which allow this (Obj-C,
Smalltalk, TOM, etc) stub generation is not necessary. In fact, if
portable marshal/unmarshal code for function arguments was available,
stub generation would not be necessary on the static languages either
(i.e. C, C++, Pascal, etc).

Take a look at 'C (i.e. Tick-C) at: http://pdos.lcs.mit.edu/tickc/
It's a C superset which defines a portable way to marshal/unmarshal
function arguments.



-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net