CMS Components Generic Infrastructure Bits. Lassi A. Tuura Northeastern University, Boston. Frameworks: Structure. Overview Graphics Classlib Plug-in Manager Components. Consistent User Interface. Data Browser. Generic analysis Tools. GRID. Distributed Data Store & Computing - PowerPoint PPT Presentation
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
LCG/Blueprint RTAGLCG/Blueprint RTAG
August 5-6, 2002 Lassi A. Tuura, Northeastern Universityhttp://iguana.cern.ch
5August 5-6, 2002 Lassi A. Tuura, Northeastern Universityhttp://iguana.cern.ch
Quick IGUANA OverviewQuick IGUANA Overview A generic toolkit for user interfaces and visualisation
Builds on existing high-quality libraries (Qt, OpenInventor, Anaphe, …) Used to implement specific visualisation applications in other projects Used in CMS and D0 (and L3—pretty static) Portable: UNIX and Windows actively used
– Few limits to porting to new platforms
Main technical focus: provide a platform that makes it easy to integrate GUIs as a coherent whole, to provide application services and to visualise any application object Many categories / layers: GUI gadgets & support, application environment,
data visualisers, data representation methods, control panels, … Designed to integrate with and into other applications Apart from a tiny kernel, virtually everything else is in plug-ins
– Plug-ins and dynamic linking are 100% orthogonal
8August 5-6, 2002 Lassi A. Tuura, Northeastern Universityhttp://iguana.cern.ch
Graphics ToolkitsGraphics Toolkits GUI and 2D Graphics: Qt
Easy to use Very rich functionality, lots of community experience Very portable, uses platform GUI conventions: looks “natural” Excellent documentation Free for our purposes
3D Graphics: OpenInventor Same as above—portability from OpenGL; both commercial and free exist An incredibly rich toolkit!
Qt and OIV limited strictly to these parts of IGUANA Not using Qt or OIV classes (containers and many other utilities) outside
their respective “natural” graphics domains: other parts use other libraries Reasons explained when discussing our component approach
August 5-6, 2002 Lassi A. Tuura, Northeastern Universityhttp://iguana.cern.ch
System AbstractionSystem Abstraction SharedLibrary Shared library loading, unloading;
list of currently loaded libraries Time, TimeSpan s-resolution calendar time, conversions,
formatting, calculations TimeInfo High-resolution (ns) monotonic time,
system and process times HostInfo Host itself, DNS lookups ProcessInfo PID etc ResourceInfo Program + system resource info, limits SystemInfo System information: memory, os, … UserInfo Users: home dir, login, real name, …
August 5-6, 2002 Lassi A. Tuura, Northeastern Universityhttp://iguana.cern.ch
Bits & NumericsBits & Numerics BitIterator Iterating over data as bits BitOps Collection of optimised bit magic operations BitPattern Construction of bit patterns BitTraits Bit type properties of integral types
IntBits Type selection by required number of bits:{exact, fast} x {signed, unsigned}
Base interface Buffered Filtering Linked Pushback (input only) C++ Standard (std::i/ostream) C Standard (FILE *) Storage (cf. I/O Basics) IOChannel (cf. I/O Basics)
Storage implementations Memory C++ Standard C Standard
August 5-6, 2002 Lassi A. Tuura, Northeastern Universityhttp://iguana.cern.ch
The Plug-In ManagerThe Plug-In Manager Maintains a list of directories with plug-in definitions Plug-in = shared library with well-defined entry points
Self-describing through a query entry point But really orthogonal to dynamic loading
– Some or all plug-ins can be built into the program Automatically detects new, changed or removed plug-ins
For new or changed ones loads the plug-in, queries for its capabilities, and unloads the plug-in
Maintains a cache of plug-in properties Updates the cache if the directory is writable
When requesting information from the database, uses the cache instead of loading all the plug-ins all the time
A separate generic package IGUANA architecture defines a specific implementation
August 5-6, 2002 Lassi A. Tuura, Northeastern Universityhttp://iguana.cern.ch
Abstract or Concrete?Abstract or Concrete? Abstract or concrete implementations?
We use both: a lot of abstract interfaces and decoupling at the bottom level,more concrete implementation usage on the top
If you need a specific service, you use it directly– Access through shared state object which records references to
“application state extensions”, but knows nothing about them– Clients ask specific services to look themselves up in the state– Services vary in “abstractness”: current selection state does not need to
know anything about GUI, object context menu is defined in terms of Qt– Only if the service has multiple alternative implementations the service
has an abstract interface; otherwise clients use a concrete implementation Services can and do have mini-plug-in architectures of their own Proxies and envelopes sometimes better than abstract interfaces
Catch-all IgExtension for those mini-plug-in systems but it’s not an IInterface– Concrete plug-in manager defines the interfaces specific to its mission
August 5-6, 2002 Lassi A. Tuura, Northeastern Universityhttp://iguana.cern.ch
External ComponentsExternal Components Qt and OIV: use concrete implementations only
Not trying to encapsulate these in any way– … but restrict them to their “native domains”
Reason: build modularity firewalls in the system– No point in trying to abstract so rich toolkits– Major benefits in going for full integration– Changing package known to incur limited pain
We know exactly what we are using and from where We know we can get rid of the original package Plan: expend N months to swap with equally rich or better product