GIOP Blunders


Last Modified: May 18, 2004

Version: 1.6

<Ken Cavanaugh>

It's interesting to take a look at the errors (and outright blunders) that were committed in the design of GIOP. I am just looking at GIOP and some items directly from CORBA, rather than all of CORBA. Here's my list:

  1. Lack of separate session layer. This needs to top the list, because this is probably the worst of the blunders. Addressing this problem would allow us to introduce very powerful session-dependent compression, which would substantially reduce the size of the messages. It would clean up other problems as well, such as assigning an FVD to a session.
  2. Inadequate versioning support. We need to be able to version the protocol separately from the encoding.
  3. Use of padding in CDR. The alignment rules force complications in the code, and don't really buy anything for performance.
  4. Use of indirection instead of labelling for references to shared data. Correctly computing the indirections affects the code in many places, due to the presence of fragmentation and encapsulation. It would be simpler to just reference the position of the item directly, instead of an indirection to the item.
  5. Inadequate semantics for location forward. We tried to fix this once with the location forward permanent idea, but that broke down into semantic difficulties. The whole area of what a client should do when a request completes other than normally is underspecified.
  6. Overly complex wide character support.
  7. IDL has become too complex yet remains insufficiently expressive. There are a lot of areas here that can be criticized, because every mistake in IDL directly translates to a problem in GIOP. Here's my list:
    1. Strings and characters should all be unicode.
    2. Unions should not exist.
    3. Structs, Exceptions, and ValueTypes should be unified.
    4. Truncatable valuetypes are a mistake and should not exist.
    5. XML should be a first-class citizen in IDL.
    6. Sequence and Array should not both exist.
  8. Too hard to get GIOP through a firewall. Of course, any number of ORBs (including some in the past at Sun) have done things like base64 encoding through HTTP. The problem is that no real standard exists. The OMG firewall spec efforts aimed at changing firewalls to handle IIOP, which was not possible. Instead, a standardized means (even if slower) to encode IIOP in a firewall friendly manner would make more sense.
  9. IOR design is more complex than needed. We end up mostly just needing opaque target object information, plus an open ended and extensible list of transport end point addresses. A single level list structure would handle this nicely.
  10. Request ID belongs in the GIOP header. This simplifies the transport dispatch code, because reading a GIOP message requires first reading the fixed 12 byte header, which given enough information to read the rest of the message. Since the request ID is needed very early in the request processing, it would be nicer to simply include it in the GIOP header (even in those cases where it is not needed).
  11. Fix an endianess choice and be done with it. I've actually changed my mind about this. Even in Java, it turns out that there are significant marshalling efficiencies that are possible if the byte order matches the native platform byte order. Receiver makes right is still the correct choice, and I think GIOP is about right here.
  12. Encapsulations require versioning. In fact, multiple parts of the GIOP protocol require versioning, notably encoding and protocol (in PEPt terms), which really should be versioned separately.
  13. Repository IDs should always be meaningful. This should be required in all cases, rather than allowing users to specify arbitrary repository IDs in an IDL definition.
  14. Chunking is a bad idea. Instead, introduce enough meta-data so that it is always possible to unmarshal the data, even if the type is unknown.
  15. Encapsulating complex typecodes is not needed.
  16. It's almost too easy to pick on, but Bidirectional GIOP is a mess, and is not getting any better.
  17. Clients should be able to determine whether to locate or not.
  18. Clients should be able to determine when to cache a location forward.
  19. Client behavior for multiple endpoints and location forward is underspecified.