1 / 14

Elements of LCG Architecture

Elements of LCG Architecture. Application Architecture Blueprint RTAG 8 th June 2002 P. Mato / CERN. Reminder: The Goal is Integration. The Goal is to facilitate the integration of LCG and non LCG software to build coherent applications

evan
Download Presentation

Elements of LCG Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related