CORBA versioning (was Re: GNOME & KOM/OP)

[Phil Dawes <philipd parallax co uk>]

I'd like to elaborate on what David Jeske has said, with reference to
CORBA and ORBit if I may:

David Jeske wrote:
> 
> The philosophy of COM (IMO) is quite good, and as you say, the
> implementation on windows is quite bad. They recognized some key
> traits which make COM able to gracefully handle compatibility and
> backward compatibility.
>   1) no inheritence
>       - this makes all access to interfaces fine-grained. To contrast
>         with a class based system, when someone uses a 'Windows' pointer
>         you have to support every method all the way up the inheritence
>         tree in order to make a compatible window, even though he probably
>         dosn't use any of them. In COM, what you have to implement to be
>         compatible is better isolated.

This is sage advice - overuse of inheritence results in programs which
are tightly coupled and difficult to port and change.
Note however that when corba uses the term 'inheritence' it refers to
interface inheritence, which is effectively the same as 'supports an
interface' in com speak.

The way to map COM interfaces to corba interfaces is (IMHO) the
following:

COM: You write com IDL for a set of interfaces, and then at the bottom
of your IDL file you specify how a Class supports these interfaces. You
then implement the class.

CORBA: You write corba IDL for a set of interfaces, and then create a
new interface which multiply inherits the others. You then implement
this interface as a corba object.

Unfortunately CORBA also allows you to create huge monolyithic multiply
inherited hierarchies more easily than COM - something to watch out for.


>   2) aggregation instead of subclassing for code-reuse
>       - this allows lots of run-time object composition to occur. For
>         example, you can write a 'matrix multiply' object which can
>         be added on (sort of like a filter) to any object which exports the
>         Matrix interface. This can be done at runtime, and if you so choose,
>         it can be done automagically. That is, the Matrix coder never knew
>         his object was going to be able to multiply.

You must also do this for multi-language corba. Unfortunately it seems
that the corba example framework we have (opendoc) explicitly required
c++ subclassing to create a component. (Note that the model didn't
require this, but the libraries did AFAIK - I'm going on what I remember
here so it might be crap)

>   3) No fragile base class problems
>       - both because all instance data is truly hidden (i.e. you can't
>         access instance data which is not part of the same implementation
>         as the code), and because object factories are used to create and
>         compose objects, there are no fragile base class problems.

This is also true of CORBA (hurrah!)

>   4) No versioning is good versioning
>       - being able to change the interface of an object after code out there
>         is already linked to it has always been a careful balancing act.
>         COM just admits that this dosn't make any sense. Once you publish
>         an interface to the world, it can never change. This assures that
>         you never break the ability for old programs to bind correctly.
>         An object can support any number of interfaces, so if you want to
>         be backward compatible, you just support the old and the new.
>         More importantly, this allows you to avoid the legacy code problem
>         to a great degree. Because of the robust binding of code to
>         interfaces, you can throw out an old implementation, write the new
>         one the way you want it, and then implement the old interface
>         through the new interface. The COM object model make sure you get
>         the binding right.. (no more hacking shlibs, etc, etc)
> 

Unfortunately this is where I think corba breaks down. Repo IDs do allow
you to specify version information, but AFAIK how to use them isn't
actually specified. SOM provided some version control, but I think this
just let you add operations to interfaces and change their order in the
interface - That would suffer from the same problems you mention.

There is a corba versioning service if I remember rightly and I might
look into this tonight. Unfortunately I don't think it handles
interfaces in the same what that you mention.


As a quick scratch idea on versioning, we could probably model our
component versioning on the COM model by specifying the version info in
the repoid

	IDL:namespace/name:version
		(e.g. IDL:foos/afoo:1.3)

and then try and inforce the 'if you must change an interface then give
it a new version' rule. This could be done through the interface
repository explicitly matching version numbers with interfaces (which I
think the spec probably requires anyway).


Cheers,

Phil.

-- 
_______________________________________________________________________
 Phil Dawes                               |   My opinions are my own
 WWW:    err.. temporarily non-existant   |   and nothing to do with
 Email:  philipd@parallax.co.uk           |      my employer.