Elements of LCG Architecture

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

2. 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. LCG Application Architecture

3. 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. LCG Application Architecture

4. Abstract Interfaces 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; }; • 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? Base Class Interface?IInterface LCG Application Architecture

5. 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 LCG Application Architecture

6. 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<> Interactive Component Configurator Event Loop Service IAlgorithm IProperty Algorithm LCG Application Architecture

7. 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 I1 Component1 I2 Component2 I3 LCG Application Architecture

8. 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 LCG Application Architecture

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

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

11. 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,... LCG Application Architecture

12. Triggers Reconstruction Simulation Analysis Frameworks Foundation Libraries 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. Basic Framework LCG Application Architecture

13. 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. LCG Application Architecture

14. 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. LCG Application Architecture