3

What I think I know so far is that the CORBA specification as such doesn't allow any differences between the IDL the server program uses and the IDL the client program uses.

However, in practice, certain differences are bound to work (pretty) universally, because the underlying communication mechanism is very probably GIOP (at least IIOP) and some differences are bound to not be detectable via IIOP.

What I like to establish is which differences are allowed between the server and client IDL universally between arbitrary ORBs as long as GIOP/IIOP is used.

For example: So far I assume it works to:

  • Add any type/interface to the server IDL as long as the types the client IDL knows about aren't touched or any unknown new types sent back to the client.
  • Add a method to an existing interface on the server side -- the client should be able to continue call objects with this interface, even though his IDL doesn't list said method. (This seems to be answered with yes here.)
  • Add a member to the end of an enum, as long as the client never sees this new value.
  • Add a member to a union, as long as the client never sees this Union type with the discriminator set to the new value.

My aim is to get to something like a short list of stuff one can do in an existing IDL to extend "the server" with new stuff without having to recompile exiting clients with the modified IDL.

Community
  • 1
  • 1
Martin Ba
  • 37,187
  • 33
  • 183
  • 337
  • 2
    I don't think you should even contemplate this. It will end in tears. – user207421 Sep 15 '12 at 08:07
  • @ejp - have you ever worked with corba? are you an expert wrt IIOP? – Martin Ba Sep 16 '12 at 11:01
  • I know enough about computing to know that you shouldn't flirt with undocumented and unspecified behaviour. – user207421 Sep 22 '12 at 21:57
  • @EJP - Ah OK, thanks for this info. I was afraid your comment was based on more specific info. In this case though I'm happy to ignore it. :-) – Martin Ba Sep 23 '12 at 17:00
  • It is based on the specific information that Corba and IDL are not designed for this kind of thing. – user207421 Sep 25 '12 at 12:08
  • @EJP: Not explicitly designed for it: yes. But built to communicate via GIOP, and GIOP(IIOP) makes some differences undetectable by specification. – Martin Ba Sep 25 '12 at 19:21
  • GIOP is just a communication protocol. Specs can be read understanding that is possible and that is not. If some information like list of all methods is not included in GIOP protocol it is not included. – Audrius Meškauskas Jan 13 '13 at 13:22

1 Answers1

1

  • Yes, the server and client method set need not match completely as the methods are accessed by name (the operation field in GIOP message) and independently. In other words, GIOP call includes the method name as string, later the parameters are encoded as they are expected by this parameter. See the example of the CORBA tie and CORBA stub.

  • Yes, if you create and export a new interface, it is just a new interface. It can be bound to any name service independently from others, and clients unaware of this new interface just will not be able to use it. The will be able to use the known types bound to the same name service.

  • Yes, GIOP writes enums as unsigned longs, first value is always encoded as zeros, successive identifiers take ascending numeric values, in order of declaration from left to right. Hence it is perfectly safe to append new enum identifies but not to remove and not to reorder.

Read GIOP specification, helps a lot. It is also very good to look into the code, generated by IDL compiler, and how does it change when something is changed in the IDL.

Surely it is not a good practice to use mismatching IDLs just because of the lack of care as it is also easy to introduce incompatible changes. This makes any sense probably only in cases if you cannot longer reach and update the client as it has been released to the user.

Audrius Meškauskas
  • 20,936
  • 12
  • 75
  • 93