About the scheduler
An architecture that allows evolution
From an evolutionist point of view, the scheduler is a wrapper on evolving technology. It started as a wrapper on the current STAR infrastructure, and is evolving to include piece of GRID middleware as soon as they are stable and provide required functionalities. In the end, it will become a thin layer that heavily relies on the GRID for all the functionalities.
Our architecture must be, therefore, as simple as possible. We simply divide the submission process in three steps:Job initialization - read the description provided by the user, validate it and create memory objects to hold it
Policy - the heart of resource brokering. It encapsulate the logic with which the request will be satisfied. It queries other middleware (i.e. the file catalog, ...) to collect the resources available, and creates the jobs that will use these resources to satisfy the user request.
Dispatcher - the connection to the batch system. Creates the specific elements required. We have created two dispatchers: LSFDispatcher for our site implementation and a CondorGDispatcher for our GRID implementation.
Every step corresponds to an interface (a pure abstract class) that is chosen at runtime. By changing these macro components, the scheduler can be reconfigured and adapted to different circumstances.
Gabriele Carcassi - page was last modified