Subject: [Rserpool] Comparison of Protocols for Reliable Server Pooling

From: Andrew Watson <[email-masked]>
Date: Fri, 7 Dec 2001 00:52:26 +0000

Good Evening,

I've been passed a copy of the Comparison of Protocols for Reliable Server
Pooling <draft-ietf-rserpool-comp-02.txt>, and I thought you might be
interested in some comments on the CORBA section of this document. Parts of
the CORBA section seem to be based on out-of-date information, and contain
misapprehensions that I'd like to correct.

I should immediately declare my interest - I'm the Technical Director of
OMG, the non-profit organisation responsible for publishing the CORBA spec.
However, I'm not going to make bald assertions about CORBA, but instead
point you to verifiable examples of deployed systems to make a few points.

The comparsion says:

> 2.1 CORBA
>
>     Often referred to as a Distributed Processing Environment (DPE),
>     CORBA was mainly designed to provide location transparency for
>     distributed applications. However, the following limitations may
>     exist when applying CORBA to the design of real time fault-tolerant
>     system:
>
>     CORBA has not been focused on high availability. The recent
>     development of a high availability version of CORBA by OMG may be a
>     step in the right direction towards improving this situation.
>     Nevertheless, the maturity, implementability, and real-time
>     performance of the design is yet to be proven.

Real-time CORBA has been extensively used in high-availability,
mission-critical systems:

 1. A real-time CORBA system forms the basis of the mid-life upgrade to the
    USAF FA-18, F-15, T-45 and AV-8B avionics systems, under the code name
    "Bold Stroke". This technology was demonstrated in 1998 with a
prototype
    dual-CPU, CORBA-based system flying on an AV-8B testbed. During a
    practice bombing run, one of the CPUs was artificially caused to fail,
    and the other took over within one head-up display refresh time (20ms).
    There's a video of that test here (30MB):

    ftp://ftp.omg.org/pub/presentations/OSATII_Boeing.avi

    A short overview write-up is here:

    http://www.cs.wustl.edu/~schmidt/TAO-boeing.html

    Here's a slide set with some performance data on TAO, the real-time ORB
    used in here:

    http://www.cs.wustl.edu/~schmidt/PDF/TAO-usecases.pdf

 2. US National Ignition Facility uses a CORBA-based control system:

    http://www.corba.org/industries/aerodef/nig.html

    http://lasers.llnl.gov/lasers/nif/ICCS/

 3. Use of CORBA in weapons control systems for the US Virginia-class
    nuclear attack submarine:

http://www.omg.org/news/meetings/workshops/presentations/realtime2001/9-2%20DiPa
lma-Kelly%20OMG%20WS%20Presentation%20-%20FINAL.pdf

>     CORBA's distribution model encourages an object-based view, i.e.,
>     each communication endpoint is normally an object. This level of
>     granularity is likely to be somewhat inefficient for designing real-
>     time fault-tolerant applications.

To counter this speculation that real-time fault-tolerant CORBA is "likely
to be somewhat inefficient", I offer several examples of systems where it
clearly does work very efficiently - see above and below.

>     CORBA, in general, has a large signature that makes the use of it a
>     challenge in real-time environments. Small devices with limited
>     memory and CPU resource (e.g., H.323 or SIP terminals) will find
>     CORBA hard to fit in.

CORBA is a specification, and it's possible to create both large and small
implementations of that specification. As with any software system, there's
a speed/code size trade-off, so the very smallest implementations aren't
usually the very fastest, but there are certain many small, fast CORBA
implementations. Some examples:

 1. The Orbacus/e product quotes a minimum client code size of 98KB:

    http://www.ooc.com/obe/

 2. Vertel's e*ORB quotes minimum client size of less than 60KB, and is
    available for the Palm Pilot, amongst other platforms:

    http://www.vertel.com/products/eorb_whitepapers.asp

 3. CORBA is being used on PDAs in experimental battlefield management
    systems by the US Army. See these slides:

http://www.mitre.org/support/papers/tech_papers_01/shrum_corba/shrub_corba.pdf

    Note the space/time trade-offs in the various CORBA implementations they
    tested. The smallest had a library (one-time) size overhead of less than
    100KB and 300 bytes per stub, and passed an argument of 1000 longs in
    400 microseconds. Not a bad size/performance trade-off.

 4. The MICO open source ORB has been ported to the Palm Pilot, and a
    client-only application is 45KB:

    http://www.mico.org/pilot/

>     CORBA has lacked easily usable support for the asynchronous
>     communication model, and this may be an issue in many applications.
>     An improved API for asynchronous communication has been added to the
>     CORBA standards recently, but many, if not most, CORBA
>     implementations do not yet support it. There is as yet insufficient
>     user experience with it to make conclusions regarding this feature's
>     usability.

CORBA has had asynchronous communication support for many years. There are
actually at least three different asynchronous communication models in
common use, and I'm not sure which one you're looking for, but the event
notification model has been supported in CORBA since at least 1995, and a
real-time event service is used in many RT CORBA applications, including
the  Boeing FA-18/F-16/AV8B avionics package, and this 6-CPU pick-and-place
machine application which moves two potentially-clashing robot arms around
each other at accelerations of over 3G and speeds of over 3 metres/sec:

http://www.omg.org/news/meetings/workshops/presentations/realtime2001/9-1%20Tras
k%20OMG20012.pdf

Finally, at the end of your paper is this comparison chart:

>    Y = Yes, meets requirement
>    P = Partially meets requirement
>    N = No, does not meet requirement
>    N/A = Not applicable

>                                  | CORBA | DNS | SLP | ASAP | ENRP |
>     -----------------------------+-------+-----+-----+------+------+
>     Robustness                   |   Y   |  Y  |  Y  |  Y   |  Y   |
>     -----------------------------+-------+-----+-----+------+------+
>     Failover Support             |   Y   |  P  |  P  |  Y   |  Y   |
>     -----------------------------+-------+-----+-----+------+------+
>     Communication Model          |   N   |  P  |  Y  |  Y   |  Y   |
>     -----------------------------+-------+-----+-----+------+------+
>     Processing Power             |   N   |  Y  |  Y  |  Y   |  Y   |
>     -----------------------------+-------+-----+-----+------+------+
>     Support of RSerPool          |   N   |  Y  |  N  |  N   |  N   |
>      Unaware Clients             |       |     |     |      |      |
>     -----------------------------+-------+-----+-----+------+------+
>     Registering and              |   N   |  P  |  P  |  Y   |  Y   |
>      Deregistering               |       |     |     |      |      |
>     -----------------------------+-------+-----+-----+------+------+
>     Naming                       |   Y   |  Y  |  Y  |  Y   |  Y   |
>     -----------------------------+-------+-----+-----+------+------+
>     Name Resolution only to      |   Y   |  N  |  Y  |  Y   |  Y   |
>      Active Elements             |       |     |     |      |      |
>     -----------------------------+-------+-----+-----+------+------+
>     Server Selection Policies    |   Y   |  P  |  P  |  P   |  P   |
>     -----------------------------+-------+-----+-----+------+------+
>     Timing Requirements and      |   N   |  N  |  Y  |  Y   |  Y   |
>      Scaling                     |       |     |     |      |      |
>     -----------------------------+-------+-----+-----+------+------+
>     Scalability                  |   N   |  Y  |  Y  |  Y   |  Y   |
>     -----------------------------+-------+-----+-----+------+------+
>     Security - General           |   N   |  P  |  P  |  P   |  P   |
>     -----------------------------+-------+-----+-----+------+------+
>     Security - Name Space        |   N   |  P  |  P  |  P   |  P   |
>      Services                    |       |     |     |      |      |
>     -----------------------------+-------+-----+-----+------+------+

To address some CORBA "N"s:

Communication model: Please look at the examples I give and note that
CORBA's object-based model is widely used in distributed fault-tolerant
applications, and plainly meets their requirements.

Processing Power: The overhead of a good CORBA implementation over raw
sockets communication is about 20%.

Timing requirements and scaling: CORBA certainly scales. The National
Ignition Facility system (see above) uses hundreds of CPUs. A good CORBA
implementation's performance is equal to any distributed infrastructure.

Scalability: See above.

Security: CORBA has excellent security support - the secure IIOP protocol
(SecIOP) is the basis of the wire-level security in EJB and J2EE.

In summary - I hope you'll revise the opinions expressed in your comparison
paper in the light of the hard data I've presented. If I can be of any
assistance, or you'd like me to put you in touch with any of the hundreds
of engineers working on scalable, fault-tolerant, real-time CORBA systems,
please don't hesitate to conatct me by 'phone or email.

Thanks for your attention.

                            Regards,

                                 Andrew
 Andrew Watson                              UK Tel:  +44 1223 510398
 Vice President & Technical Director,       US Tel:  +1 781 444 0404 x111
 Object Management Group,                   Fax:     +1 781 444 0320
 250 First Avenue, Suite 201                Email:   [email-masked]
 Needham, MA 02494, USA                     http://www.omg.org/~andrew

_______________________________________________
rserpool mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/rserpool