[Up: Object Request Broker]
[Previous: Interoperability] [Next: Object Adapters]
After presenting the ideas of CORBA and praising its virtues, it is also important to recognize its weaknesses, what CORBA cannot do.
Like RPC, CORBA is foremost a Client/Server system, based on a sequential, synchronous request-response model of communication. Of the four design strategies for distributed systems mentioned in 2.1, CORBA supports only Client/Server delegation and resource sharing.
Parallel processing requires asynchrony, to distribute many tasks to the worker nodes simultaneously, and to react upon their results as they become available. This could be achieved, even with current means, using asynchronous DII, at the cost of having to construct requests manually and using a polling model to wait for results, or using callbacks and event-based programming [56]. Messaging [35] will improve in this area, providing asynchronous method invocations and callbacks.
Fault tolerance is not supported either, but can again be simulated using asynchronous DII. An effort to add fault tolerance by automating the multicast of requests to redundant servers, collecting and evaluating their responses is presented in [20].
Orthogonal to these three strategies are real-time requirements, such as latency, guaranteed response times or precise timing of request delivery. Design considerations for real-time ORBs are presented in [51]; an RFP about real-time issues has been answered by a joint submission [37] and is scheduled for CORBA 3.0. Precise timing will require the mapping of GIOP to a real-time aware transport mechanism like ATM (see section 2.2.1).
Somewhat dependent on real-time capabilities are data streams for audio or video data, which also don't fit into request-response communication. Again, the OMG is discussing possibilities for integrating real-time data streams.
An approach for a more generic quality of service infrastructure by allowing the negotiation of user-defined quality of service issues is presented by the Management Architecture for Quality of Service [4].
It seems fascinating to look into CORBA's future with its many intentions, considerations and forthcoming additions, but the feasibility should not be left behind. From looking at the stacks of paper, the CORBA specification exhibits almost exponential growth. From CORBA 2.0 [27] (July 1995) to CORBA 2.2 [28] (February 1998) alone, the core specification (excluding language mappings and common services) was extended by six chapters and doubled from 233 to 489 pages. CORBA 2.3 will again bring many extensions and two new chapters; the preliminary specification [30] (December 1998) totals 579 pages.
While these were minor revisions, adding features one at a time, the 3.0 update will be major, introducing Components, Real-time CORBA, Minimum CORBA, Messaging and Firewalling [23].
Consequently, the Object Request Broker becomes increasingly complex, and the vendor's task of keeping an ORB up to date with the specification and to verify its correctness is becoming harder still. On the user end, the entry into CORBA programming will become more difficult, too, as the possibilities become harder to choose from. With Components, Objects by Value and interfaces, CORBA 3.0 will offer three non-orthogonal paradigms for object implementation.
This progress is certainly due to CORBA's increasing popularity. After CORBA 2.0 ORBs were readily available, they have been put to use in many different environments from embedded systems to large-scale parallel architectures. It is under these extreme circumstances that shortcomings surface.
Maybe it would be prudent to limit the growth somewhat, and instead of extending CORBA in all directions simultaneously, to emphasize and improve upon the abilities that are readily available.
More features also cause the language mappings to grow. Between 2.0 and 2.3, the C++ mapping doubled from 94 to 174 pages, too, growing more complicated with more special cases to obey - the mapping of Objects by Value to C++ [31] is, in one simple word, a nightmare. The C++ mapping is a good candidate for revision from scratch. It still suffers from historical deficiencies in compiler implementations: before 1995, the preliminary ANSI C++ standard was still a moving target. Not using the Standard Template Library - decent implementations have not been available back then - and governed by performance considerations, the mapping contains many shortcuts and different strategies for passing parameters by value vs. by reference: for example, distinguishing ``fixed length'' and ``variable length'' structures is bound to cause confusion. It would be interesting to see a revised, straightforward C++ language mapping consequently based on STL containers and classes [22].
The goal to adapt only proven specifications is also not always enforced, and some parts of the CORBA specification have been found to be ill-designed or impossible to implement. One example is the Persistent Object State Service [39]. Well after its addition to the set of common object services, it was found to be ``too complex and imprecisely specified'' [38], and a new RFP has been issued, euphemistically proposing to apply the ``OMG sunset policy'' [40] to the original service.
The Basic Object Adapter has also been a source of confusion because of its design flaws.
[Previous: Interoperability] [Next: Object Adapters]
[Up: Object Request Broker]