[omniORB] Extending a union by a member - is a mismatch btw. server and client IDL allowed?

[Martin B.]

Our CORBA API currently has an interface like:

module XYZ {
...
enum DataType {
FloatingPointT,
IntegerT
};

// v 1.1
union Value switch (DataType) {
FloatingPointT : double dv;
IntegerT : long iv;
};

interface ... {
Value GetValue(....);
...

We now would like to extend this interface to allow for string values in
addition to the two existing types:

// v 1.2
enum DataType {
FloatingPointT,
IntegerT,
StringT
};

union Value switch (DataType) {
FloatingPointT : double dv;
IntegerT : long iv;
StringT: string;
};

and keep the interface the same otherwise.

Is a client compiled with v1-1.idl supposed to be able to talk to a
server compiled with v1-2.idl -- where the definition of the union (and
the enum) differ but are a pure addition to the existing interface?

Can a client correctly invoke GetValue() as long as this function
doesn't return a unknown datatype?

Is this covered by the CORBA spec at all?

Note: It *does* indeed work when I test it with omniORB 4.1.4 (both
client and server) but that doesn't tell me whether it'll work with all
possible client ORBs!

Thanks for any pointers!

cheers,
Martin

[Duncan Grisby]

Post by Martin B.
Is a client compiled with v1-1.idl supposed to be able to talk to a
server compiled with v1-2.idl -- where the definition of the union (and
the enum) differ but are a pure addition to the existing interface?
Can a client correctly invoke GetValue() as long as this function
doesn't return a unknown datatype?
Is this covered by the CORBA spec at all?

The CORBA spec says that it is illegal to have differing IDL on client
and server. However, as long as they are communicating with GIOP, you
will get away with it. The on-the-wire format for unions just sends the
discriminator followed by the value associated with that discriminator.
As long as the receiver gets a discriminator and value it knows, it will
never know that the sender had a different definition.

With an enum discriminator, you must extend it by adding items to the
end of the enum. Enums are sent by numerical value, so if you modify the
order of the enum, the values will be misinterpreted.

You will of course be in real trouble if the receiver gets a union value
with a discriminator it didn't expect. Exactly what will happen depends
on the IDL definitions and how the receiving ORB handles the unexpected
marshalled data. You may get various different exceptions or even crash.

Cheers,

Duncan.

[Martin B.]

Duncan, thanks. Great explanation as ever!

I did test the case where the sender sends the union with a
discriminator value that wasn't defined in the receivers IDL.

On omniORB, this causes a marshalling exception of some sort.

I'm fine with *any* System Exception, since from the receivers view,
anything the sender sends that isn't in its IDL is just garbage.

On the other hand, I think a crash for *any* malformed GIOP data would
be a sign of a poor implementation. I'd call it a bug.

I guess there's nothing but trying the ORB combinations I'm interested
in to have proof that it does work withing reasonable limits.

Aside:

I've always taken it for granted that adding a new method to an
interface (just adding at the end of the definition on the server side)
is essentially a compatible change.

From what you said, "it is illegal to have differing IDL" it seems this
is also just an artefact of how GIOP is defined?

cheers,
Martin

Post by Duncan Grisby

Post by Martin B.
Is a client compiled with v1-1.idl supposed to be able to talk to a
server compiled with v1-2.idl -- where the definition of the union (and
the enum) differ but are a pure addition to the existing interface?
Can a client correctly invoke GetValue() as long as this function
doesn't return a unknown datatype?
Is this covered by the CORBA spec at all?

The CORBA spec says that it is illegal to have differing IDL on client
and server. However, as long as they are communicating with GIOP, you
will get away with it. The on-the-wire format for unions just sends the
discriminator followed by the value associated with that discriminator.
As long as the receiver gets a discriminator and value it knows, it will
never know that the sender had a different definition.
With an enum discriminator, you must extend it by adding items to the
end of the enum. Enums are sent by numerical value, so if you modify the
order of the enum, the values will be misinterpreted.
You will of course be in real trouble if the receiver gets a union value
with a discriminator it didn't expect. Exactly what will happen depends
on the IDL definitions and how the receiving ORB handles the unexpected
marshalled data. You may get various different exceptions or even crash.
Cheers,
Duncan.