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:
- 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.
- Inadequate versioning support. We need to be able to version
the protocol separately from the encoding.
- Use of padding in CDR. The alignment rules force complications
in the code, and don't really buy anything for performance.
- 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.
- 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.
- Overly complex wide character support.
- 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:
- Strings and characters should all be unicode.
- Unions should not exist.
- Structs, Exceptions, and ValueTypes should be unified.
- Truncatable valuetypes are a mistake and should not exist.
- XML should be a first-class citizen in IDL.
- Sequence and Array should not both exist.
- 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.
- 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.
- 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).
- 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.
- 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.
- 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.
- 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.
- Encapsulating complex typecodes is not needed.
- It's almost too easy to pick on, but Bidirectional GIOP is a mess,
and is not getting any better.
- Clients should be able to determine whether to locate or not.
- Clients should be able to determine when to cache a location
forward.
- Client behavior for multiple endpoints and location forward is
underspecified.