|Date and Author(s)|
The XML schema defines the framework for components in the meatball diagram to communicate with each other, but each component only iplements a small portion of the possible requests and responses, at least at first. A given instance of a component defines a "binding" to that schema that says what portions of the schema apply to it and how. For example the System & Job Monitor has to define what hardware information is available, how it is to be requested, and what responses are possible to querys.
Here at NCSA, we are working on an implementation of of the System & Job Monitor. Kevin Walker is also working on an XML wrapper around PBS that will perform an identical set of functions. Dave Jackson's Scheduler needs to be able to talk to both of them, without having to know which implementation is which.
To make this work, I believe it is a good idea to write down what the minimum required interface is, and have a list of "good to have" features. This provides a checklist against which these components can be verified. On this page, I am going to attempt to write down that binding.
Let me stress here that I am not trying to say what the binding is or should be for the System and Job Monitor. I'm writing this down so that people can all be look at the same document, comment on it, add, subtract, and change what's in it. I believe this is much easier when there is a common starting point, and I am going to attempt to provide that here.
This Binding defines the communication between the Scheduler component and the System and Job Monitor. This protocol can also be used by components external to the system to monitor the hardware; a monitor/display/alarm client, for example.
The philosophy of this revision is to optimize for simplicity and ease of implementation (SC '02 is coming right up); it is not optimized for scalability or efficiency of protocol.