In order to be able to stage jobs to resources and launch them there on behalf of a user, host-dependent information must be obtained dynamically by the Workflow Broker after scheduling the node to run. While it would be optimal if every Grid resource exposed this information consistently and through a uniform set of APIs, that is unfortunately not (yet?) the case. Hence we have developed a small information service with an administrative interface to store this data and make it readily available both for viewing and for workflow configuration. This is once again a GSI web service requiring authentication and authorization via certificate.
Mode of Usage
In most cases, the user, if administrator, will interact with this service through a specially designed Siege view (refer to the tutorial for specifics). The programmatic interactions, such as those accomplished by the broker, take place via the web service ports. The sections which follow thus are only of interest to potential developers wishing to gain understanding of what lies "under the hood". There is an example of the XML data representation at the end of this page.
Info be obtained through its
retrieve ports, updated or modified through its
remove ports. In addition, the
find calls can be used to do simple listings.
Defines an entire resource. Aside from a generic name for the entire resource tree, architecture and OS, a host can have a set of environment properties applicable to all users, a set of user accounts, and a set of node names which can define their own protocols for job submission and file movement.
Defines a node mapping for a resource. This is usually the name of a physical "head node" with a specific IP address, but a logical name is also possible, provided the protocol contacts actually point to physical nodes. The node is thus a way for specifying independent configurations of interactive, batch and file movement protocols available on the resource.
Maps user to home directory on the resource, and provides any specific environment variables needed to run the user's jobs there.
Defines protocols for job submission and file movement that are available on the given resource. Associated properties for optimal performance can also be stored for configuration purposes. The ranking is an indexed position used in conjunction with the
orderProtocols() method on the
NodeInfo object; for instance, a ranking of '0' puts the protocol at the head of the list in front of any alternates with a higher ranking value.
Note on Implementation
Updates to the service are achieved by diff'ing the current representation of the object against the new one. In order for this to work with a given bean, a special interface must be implemented:
As can be seen, special XML namespaces for adding and deleting are used in the diff'ing process. The code responsible for merging the XML is in the
UserFacingUtils class of the
ncsa.tools.common plugin. Siege's
HostInfoAdmin view handles the namespace semantics required by those methods.