About the scheduler

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.

The scheduler architecture

Our architecture must be, therefore, as simple as possible. We simply divide the submission process in three steps:

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.