Subject: RE: [Rserpool] Comparison of Protocols for Reliable Server Poolin g

From: [email-masked]
Date: Fri, 7 Dec 2001 10:41:50 +0200

Hi Andrew,

Thanks for your comment.  I will try to make sure I cover the
issues when I update the document.

Just for clarification, do you feel that CORBA may be applicable
for the Reliable Server Pooling architecture or are you more
interested in clearing up misunderstandings about CORBA?

thanks,
John

> -----Original Message-----
> From: ext Andrew Watson [mailto:[email-masked]]
> Sent: 07 December, 2001 02:52
> To: [email-masked]
> Cc: Kimmo Raatikainen; Richard Soley; Fred Waskiewicz; Jon Siegel
> Subject: [Rserpool] Comparison of Protocols for Reliable 
> Server Pooling
> 
> 
> 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/realt
> ime2001/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/realt
> ime2001/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
> 

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

---

From: Andrew Watson <[email-masked]>
Date: Mon, 10 Dec 2001 10:25:29 +0000

John,

> issues when I update the document.

Thanks. If you need clarification on any particular point, please don't
hesitate to get in touch with me.

> interested in clearing up misunderstandings about CORBA?

The former.

                            Regards,

                                 Andrew

---

From: Andrew Watson <[email-masked]>
Date: Mon, 10 Dec 2001 10:25:29 +0000

John,

The former.

                            Regards,

                                 Andrew