170 likes | 172 Vues
An Interactive Browser For BaBar Databases. Adeyemi Adesanya Stanford Linear Accelerator Center. Why?. We need an interactive Objectivity/DB utilities, for physicists and administrators Program supplied by vendor offers limited functionality and does not scale. BaBar’s Functional Demands.
E N D
An Interactive Browser ForBaBar Databases Adeyemi Adesanya Stanford Linear Accelerator Center yemi@slac.stanford.edu
Why? • We need an interactive Objectivity/DB utilities, for physicists and administrators • Program supplied by vendor offers limited functionality and does not scale yemi@slac.stanford.edu
BaBar’s Functional Demands • Scalability! 64k database files • Presenting the right abstraction • No general external product is BaBar-aware • A logical, BaBar database hierarchy needs to be incorporated yemi@slac.stanford.edu
Java • Suitability: • Comprehensive set of GUI components • Platform independent for wide deployment • Objectivity/Java binding has limitations related to language interoperability (today). yemi@slac.stanford.edu
CORBA • A STANDARD for distributed inter-object communication (http://www.omg.org) • ORB’s form the middleware layer along with the IIOP • Java/C++ ORB bindings readily available yemi@slac.stanford.edu
The framework • 100% Java provides the client GUI • C++ servers handle Objectivity access • 1 server process per Objectivity federation • NamingService stores server addresses yemi@slac.stanford.edu
Key features • View the Database & Event collection hierarchy • Iterate through collections using simple selection (tags) • Access individual events and browse their headers • Identify “cloned” components • Scan a collection for databases yemi@slac.stanford.edu
CORBA performance • A high-level protocol, not an alternative to TCP-IP! • Data marshalling is a major factor • Consider size/complexity of data types • Database IO overshadows CORBA latency yemi@slac.stanford.edu
Minimizing the overhead • Server: Models the GUI components • No persistent objects are converted to CORBA • Transactions are kept as short as possible • Warn user of locking issues if necessary yemi@slac.stanford.edu
The TAO ORB • Designed for real-time environments • Aim is reliable, predictable CORBA service • Optimized client & server stubs • Fine grained thread control yemi@slac.stanford.edu
Multithreading • Reduce idle CPU time during IO tasks • Exploit multiprocessor hardware • Priority control • two models currently in use: • thread-per-connection • thread pool yemi@slac.stanford.edu
Future: admin. tools • Browser database tasks strictly read-only • Develop separate GUI for administrators • Aid import/export of files between sites • Search engine • Drag and drop files and event collections yemi@slac.stanford.edu
Summary • CORBA offers: • distributed object communication • platform interoperability • more than just a transport protocol • 100% Java for platform independent GUIs • Not all ORBs are created equally yemi@slac.stanford.edu