Detector Data Service
Purpose and Functionality
The detector data service manages the transient detector data store. The service
interacts with several other components: the application manager, algorithms and event
data converters whenever event data structures have references to detector data.
Besides acting only as a data loader, the detector data service has to handle the
validity of the related detector data: detector data are not "static" over the
entire lifetime of the job, but may change e.g. when calibrations constants change over
time. Hence the detector data service must be capable to distinguish between valid
and invalid data with respect to a given event. Invalid data may be discarded. This means:
given a valid time stamp the detector data service is capable to
- direct new detector data requests to the proper, valid data objects.
- if the up-to-date detector data objects are not present after the invalidation, they
must be loaded.
- Algorithms will initialize references to detector data at startup time. The objects
these references must stay valid over the analysed event range. They will have to be
updated rather than recreated.
This means, that the detector data service is no longer stateless, but is either able
to serve proper detector data valid for a give time range or not. The detector data store
will have to be validated for every event ensuring that contained references are valid. In
order to optimize data validity the detector data objects which should automatically be
updated must be marked.
- The detector data service is used by the algorithms as an input/output channel of
detector data objects:
- The detector data service delivers references to detector data objects on request. If
the requested data objects are not present, the detector data service asks the detector
persistency service to deliver the objects and makes them availible to the algorithm.
- Detector data objects meant to be available to (other) algorithms must be registered to
the detector data service.
- Once detector data objects are registered to the detector data service, the algorithm
gives up ownership. The detector data service releases the objects on request of the
application manager.
- Detector data objects must be identifiable in order to be added to the data store.
- The registration of data must follow the hierarchy of the detector data objects. This
means starting from an detector root object, navigation in the data store is like
travelling through the delivered detector by the use of pointers. The registration of
detector data objects will be tree like, similar to a file system.
- Clients of the detector data service can decide which data should be made persistent:
- Clients may decide to discard partially or completely the data objects managed by the
service.
- The detector data service must be able to deliver transient data objects to the services
in charge of creating other data representations like the persistency service or the
service responsible for creating graphical representations.
Interfaces
The detector data service implements the following interfaces:
- IDataManager
: This interface allows settings
necessary to deliver detector data like declaring the detector root etc. This interface is
used by the Application manager. Through this interface actions necessary to manilpulate
the scope of detector related data like requests to initialize a new detector, discard the
objects owned by the service etc. are handled.
- IDataProviderSvc: The interface
used by the algorithms to request or register detector data objects.
Dependencies
- Organisation of the transient detector data store
- Generic service,
- Interface of the detector data persistency service
- Data item selector
- Standard Templarte Library.
Known clients