Sched: job scheduler service. It speaks BES and iBES as well. It implements a job queue and schedules job to other BES services like A-REX or iBES clients like Paul.

The Scheduler service acts like a computing service for one type of its client because it provides BES interfaces but instead of run jobs on its own computing resource it forwards jobs to other computing services which uses BES (eg. A-REX or other Scheduler) or iBES (eg. Paul service) interfaces. It is important to note that the Scheduler service does store files related to jobs these should be handled by other services like HTTP server, grid storage etc. The Scheduler service uses brokering algorithm to choose the best-fitting resources for the requirements of the incomming jobs. 
Since the Scheduler service is a Web servce it should be after SOAP message channel component in the configuration chain. The plugin name of the Scheduler service is grid_sched. 
The service specific options of Scheduler are define the internal behavior of this service like scheduling and cleanup cyles. All of the Scheduler configuration options should under the http://www.nordugrid.org/schemas/sched namespace.
The <Endpoint> elements should be equal to the public URL of scheduler service.
The Scheduler service use Berkeley DB to store persistently its job queue. The <DataDirectoryPath> defines the path of the directory where the database will be stored. The directory should exsist before the service started.
The <SchedulingPeriod> element defines the period of internal scheduling cycle in secounds. In one cycle the scheduler looks for jobs in NEW state and try to schedule them to any BES services founded in Information System. If the this value is 0 than the Scheduler service will only serv iBES clients.
The jobs after succesful running arrive to the FINISHED state. Because the client usually poll the Scheduler service to be informed about status changes of the jobs they cannot be removed after they finised. However if all the jobs in FINISHED state will be in the queue forever than the scheduler is overloaded. The <LifetimeAfterDone> parameter defines how long the job staying in the queue after FINSIHED or FAILED state.
It is obvious thet the resources where the jobs are running can be failed. The Scheduler have an internal mechanizm to rechedule jobs which was lost by resources. The mechanizm based on timeouts. The <ReschedulePeriod> element defines in seconds how often the Scheduler check which jobs should be rescheduled. The Scheduler put the job into RESCHEDULED state if the resource does not report status of job after time in secunds defined by the <RescheduleWaitTime> configuration element.
The <Timeout> parameter defines the socket timeout in secounds.
