Elements of LCG Architecture Application Architecture Blueprint RTAG 8 th June 2002 P. Mato / CERN

08/07/2002LCG Application Architecture2 Reminder: The Goal is Integration  The Goal is to facilitate the integration of LCG and non LCG software to build coherent applications –We should establish the specifications (“blueprint”) of the model that would facilitate this integration.  Two possible forms of integration: –A) Implementing the software components using a defined number of low and high level building blocks (Rene’s proposal) –B) Defining interfaces and protocols without any assumption on the way the implementation is made.

08/07/2002LCG Application Architecture3 Component interface specifications  Integration technologies –Mainly for distributed computing –CORBA, DCOM (.NET), Web Services, JavaBeans  Abstract interfaces –C++ “in process” integration –Robust and efficient. A bit awkward for end-users.  Scripting extension modules –Ideal for prototyping. Rapid application development (RAD). –Dependent of the scripting tool Probably the best solution but unrealistic in our environment Works well within a given Framework Minimal coupling, maximum flexibility. Lacks performance. 

08/07/2002LCG Application Architecture4 Abstract Interfaces  Pure abstract interfaces minimizes compilation and linking coupling with the implementation. Typically, not directly usable by end-users.  Interfaces capabilities (communalities): –Identification (interface ID) –Versioning (major and minor version numbers) –Lifetime support (reference counting)  What can be used in the definition of interfaces? –Basic types? STL? CLHEP? class IMagneticFieldSvc : virtual public IService { public: // Get the magnetic field vector at a given point in space. virtual StatusCode fieldVector( const HepPoint3D& xyz, HepVector3D& fvec ) const = 0; }; Base Class Interface? IInterface

08/07/2002LCG Application Architecture5 Not everything should be Abstract  Handling abstract interfaces is rather “painful”, “inefficient”, etc.  So, decide what needs to be abstract and what not –“Data-like” classes are candidates to be concrete classes –“Service/Manager-like” classes are candidates to be classes implementing abstract interfaces  No absolute rule –Tradeoff between inconveniences and benefits –Example: it makes sense to have a “data-like” class like an histogram to be abstract

08/07/2002LCG Application Architecture6 Component Capabilities  Typically components implements multiple interfaces (capabilities) –Each one specialized on a given domain (persistent-able, configure- able, draw-able, …) –Minimal coupling between domains  There exist the need to “navigate” from one interface to another –“queryInterface()” vs. dynamic_cast<> Algorithm IAlgorithmIProperty Event Loop Service Interactive Component Configurator

08/07/2002LCG Application Architecture7 Composition vs. Inheritance  Composition is often a good design solution for code re-use –Low coupling. The aggregate do not need to be compiled/linked with the components –Ex: complex Algorithm composed of simple ones –queryInterface() facilitates composition  Inheritance is used to extend functionality –Very often unavoidable. Strong coupling  No absolute rule Aggregate Component1 Component2 I1 I2 I3

08/07/2002LCG Application Architecture8 IInterface // Interface ID static const InterfaceID IID_IInterface(1,0,0); class IInterface{ public: /// Retrieve interface ID static const InterfaceID& interfaceID() { return IID_IInterface; } /// Query other interfaces from this interface virtual StatusCode queryInterface(const InterfaceID& riid, void** ppvInterface) = 0; /// Increment the reference count of Interface instance virtual unsigned long addRef() = 0; /// Release Interface instance virtual unsigned long release() = 0; }; ID major version minor version

08/07/2002LCG Application Architecture9 DLL Factories & Dynamic Loading DLL SvcFactory IFactory Service {new} Service Service / Algorithms / Converters SvcFactory xxxFactory FactoryTable Manager getFactoryTable Client {instantiate} Plug-and-Play Factory pattern to avoid using concrete implementation. Run-time discovery of components. Only pure abstract classes (interfaces) are accessible.

08/07/2002LCG Application Architecture10 Factories in Practice #include “IMagneticFieldSvc.h” // Magnetic Field service implementation class MagneticFieldSvc : public IMagneticFieldSvc { StatusCode fieldVector( const HepPoint3D& xyz, HepVector3D& fvec ); }; MagneticFieldSvc.h #include “SvcFactory.h” #include “MagneticFieldSvc.h” // Instantiation of a static factory class used by clients to create static SvcFactory s_factory; MagneticFieldSvc::MagneticFieldSvc( const std::string& name, ISvcLocator* svc ) : Service( name, svc ) {... } StatusCode MagneticFieldSvc::fieldVector( const HepPoint3D& xyz, HepVector3D& fvec ) {...} MagneticFieldSvc.cpp Static factory instantiation. Factory identified by class name. Component name Component Locator

08/07/2002LCG Application Architecture11 Basic Infrastructure  Interfaces without a minimal infrastructure are “useless” –Basic types (status, exceptions, etc.) –Set of Core services  Core Services: –Component Loader/Unloader »Loads dynamic libraries, discovers available factories, etc. –Component Creator/Locator »Needed by any component that requires to interact with another. Identification by component “name”. –Incidents and Incident Manager (“event”) –Properties and Property Manager –Error Reporting/Exception Handling –Data Dictionary (for data-like objects and interfaces) –GUI Manager,...

08/07/2002LCG Application Architecture12 Software Structure  Foundation Libraries –Low level, fairly independent class libraries to complement the “standard” types –These types can be used freely in interfaces  Basic Framework –Set of core infrastructure services to allow development of other framework components  Specialized Frameworks –Simulation, reconstruction, Interactive analysis, etc. Frameworks ReconstructionSimulation Analysis Foundation Libraries Triggers Basic Framework

08/07/2002LCG Application Architecture13 Don’ts and Do’s  Don’ts –Global data (e.g. errno, singletons) –Communication under hidden channels. –Invent new C++ dialects. Use standard C++ (templates, namespace, exceptions, etc.)  Do’s –Hire technicalities of “component model” to end-users (small templated methods may help here, powerful base classes) –Minimize dependencies. Favor run-time dependencies (decided at the application level) to compile-time dependencies at lower level.

08/07/2002LCG Application Architecture14 Proposals for Discussion  Foundation Libraries: –STL(native), CLHEP  Interface Model: –As presented: naming conventions, interface ID, interface discovery, factories, naming services, …  Adopt AIDA: – AIDA interfaces for data analysis components  Develop/adapt set of core services –Component loader, Naming service, Dictionary, etc.