Production Experience with CORBA in the BaBar Experiment

1
Production Experience with CORBA in the BaBar
Experiment

• Scott D. Metzler
• California Institute of Technology
• For the BaBar Computing Group

2
Introduction

• BaBar computing planners embraced Object-Oriented
  design and the need for large numbers of Unix
  nodes from the outset.
• One unresolved issue was how to augment Unix
  system calls and TCP for use in the Online
  system.
• CORBA was provisionally adopted in early 1998 for
  a small number of pilot projects.
• Further use of CORBA followed later that year.

3
BaBars Usage of CORBA

• Primary Reasons for using CORBA
• Object-level interprocess communication (IPC)
• Language interoperability (C and Java)
• Extensibility (marshalling is internal to CORBA)
• BaBar adopted the TAO version of CORBA that is
  freely available with the ACE Unix system
  wrappers.
• Not all of BaBars CORBA projects use TAO.
• Only those that do use TAO will be discussed here.

4
Objectivity Browser

• Background
• 300 TB of physics events/year stored in
  Objectivity.
• Requirements
• Graphical tools needed to view information.
• Tools needed to assist administrators in
  exporting databases to remote sites.
• Reasons for CORBA
• Object-level IPC
• Language interoperability
• The C interface to Objectivity is much richer
  than the Java interface (C server).
• A portable client was desired (Java client).

5
Objectivity Browser GUI
6
Distributed Histogramming

• Background
• Online Event Processing runs on 32 farm nodes.
• Requirements
• Monitor online data in real-time to quickly find
  problems.
• Provide access to data for GUIs and automatic
  monitoring.
• Reasons for CORBA
• Object-level IPC
• Extensibility
• Language interoperability

7
JAS Display of BaBar EMC OnlineData
An adaptor converts the Distributed
Histogrammers CORBA protocol to JAS.
8
Ambient Data Handling

• Background
• Detector Controls monitors and archives detector
  and environmental information.
• Requirements
• Access to real-time data.
• Access to archived data.
• Reasons for CORBA
• Object-level IPC
• Language interoperability
• Reuse of Distributed Histogramming IDL means the
  same GUI can be reused without changes.

9
Ambient Data Handling GUI
10
Online Prompt Reconstruction

• Background
• Event Logger works with both Level 3 and OPR.
• OPR reconstructs events within a couple hours of
  data-taking.
• Requirements
• System configuration of Event Logger for L3 and
  OPR modes.
• Monitor data and system.
• Reasons for CORBA
• Object-level IPC (Configuration and control).
• Language interoperability (Java display of
  monitoring data).

11
Performance and Reliability

• CORBA is slower than TCP (as of 1/98)
• Factor of 10 for small data transfers.
• Factor of 2 for large data transfers.
• Rate is unnoticeable for our GUI applications.
• ACE/TAO are very reliable.

12
Operational Issues and Lessons Learned

• It is quick and easy to learn Elementary CORBA.
• Experienced programmers can be effective in less
  than a week.
• CORBA is very rich. Learning how to use most of
  the available services would take a significant
  amount of time.
• Name service has been very useful for connecting
  processes.

13
IDL

• Useful abstraction technique.
• Provides separation of client development (GUI in
  Java) from server development (server in C).
• Provides reuse (Ambient Data Handler reuses
  Distributed Histogramming IDL and GUI).
• (Multiple) Inheritance of IDL can be a powerful
  design technique.
• Avoids painful debugging and migrations in
  writing (de-)serialization code.

14
Multi-threading

• Useful for performance in many of our
  applications.
• Most applications send the same command to many
  (32-200) servers.
• We havent thoroughly pursued multi-threading
  yet.
• Early versions of TAO did not support
  multithreading.
• We have not yet returned to this issue, but we
  want to.

15
Conclusions

• CORBA is useful for IPC
• Slow, but acceptable for our GUI applications.
• Speed compensated by ease of use.
• Easy to learn and use Elementary CORBA.
• Easier and more tolerant than using TCP directly.
• Many services we have not explored.
• We recommend CORBA for applications that can
  afford to sacrifice better performance for ease
  of development.