Corba Versioning

Versioning issues for CORBA classes over time:

COM has separate explicit support for concepts of "class, interface, and implementation," while CORBA has only "interface" and "implementation."

In COM, each object/class/instance will normally support multiple interfaces, and it's easy to switch between them. In essence, this is MultipleInheritance of interfaces.

CORBA is the same but with a different model of casting between interfaces. Basically any distributed system forces the separation of interface and implementation. COM's QueryInterface mechanism is a form of multiple interface inheritance. COM forces the programmer the implement this by hand; in CORBA the IDL compiler implements it for you.

We may be talking about two different things here:

InterfaceInheritance, and casting/querying to navigate from one interface to another.
Version Control -- how interfaces change over time, with upward & backward compatibility issues.

<JeffGrigg> It's been my experience that CORBA is weak on the "change over time" issues: If you just go ahead and change an interface, you'll often crash existing clients or servers that are still using the old definition of the interface, when you attempt mix-and-match interoperation between versions (either intentionally or by accident). </JeffGrigg>

Example: Suppose I implement a system, and it has Interface1:

interface Interface1 {
function x(a,b,c)
function y(a,b)
function z(b,c)
}

Then, due to refactoring, breaking classes apart (or combining them) and/or moving responsibilities from client to server or vice-versa, I find that I need a new version of Interface1 (function "x" no longer makes sense, "y" needs a new parameter, and there's a new function, "u"):

interface Interface1.v2 {
function y(a,b,c)
function z(b,c)
function u(a,c)
}

In COM, I would simply implement both Interface1 and Interface.v2 in my server object. Clients can migrate to ".v2" at their leisure, and I can drop "Interface1" from the system later, when I'm sure that all clients have been converted. Also, internally, new versions of client programs can have a mix of Interface1 and Interface.v2 usage, and do QueryInterface at appropriate points to go from one to the other. This makes it easier to convert large complex client programs from one interface to another -- you do the conversion in small steps.

This mechanism is also rather useful in CORBA. When it's needed you can inherit from an interface having a single method, getInterface which lets you navigate from one interface to any other interface. I think the POSA book calls this pattern ExtensibleInterface?.

What do you do in CORBA?

You could have Interface1.v2 inherit from Interface1. This allows old clients to continue using Interface1, and upgrade to Interface.v2 at their leisure. But, Interface.v2, by inheriting all the functions of Interface1, makes it look like function "x" is a valid function of Interface.v2, rather than indicating that it's "depreciated," and will no longer be supported in the future. Also, the changed parameters to function "y" give you a similar problem. Clients, after converting to Interface.v2 could very easily continue using function "x" and the old parameters to function "y", causing them to break when Interface1 is retired, and removed from the system.

Speaking of which, how do you remove Inteface1 from the system, once all client applications have been migrated to Interface.v2?

<JeffGrigg> I think you're stuck, because you can't change Interface.v2 to stop inheriting from Interface1 without breaking all existing clients. And you can't solve this problem with more inheritance, as it will only get you deeper into the problem. </JeffGrigg>