Gird Services API

All ORBIT support services have web based XML interfaces. eachs service is a group with a path and name.

To find out which services are available at a particular server issue the following:

http://<server>:5022/

After sissuing the following html querry:

http://repository2.orbit-lab.org:5022/

the server will respond with the list of service groups available:

<serviceGroups>
  <serviceGroup path="/inventory" name="inventory">
    <info>
      Service to retrieve information about nodes or testbeds from the Inventory Database
    </info>
  </serviceGroup>
  <serviceGroup path="/frisbee" name="frisbee">
    <info>
      Service to control frisbee servers to stream specific images
    </info>
  </serviceGroup>
  <serviceGroup path="/pxe" name="pxe">
    <info>
      Service to facilitate PXE to boot into specific image
    </info>
  </serviceGroup>
</serviceGroups>

In this particular case, theserver has three service groups for three services: PXE, fribee and inventory.

They all use the same framework and, therefore, have like syntax. The services are accessed using either of the following schemes:

http://<server>:5022/<service name>?<1st arg>=<arg_1_value>&<2nd_arg>=<arg_2_value>

For instance, to turn on node1-1 using the CMC (from the console of one of the sandboxes or the grid), you would issue the following:

wget -O - "http://cmc:5022/cmc/nodeSetOn?nodes=[1,1]"

The services API allows for location (domain) awareness to allow resources only for that specific domain. For instance, querying the CMC to turn on node1-1 from the console on sb1 will turn on node1-1 on sb1 and not any other resource. Also, it is impossible for users in one location to issue commands for another. For example, it is impossible to turn on nodes on the grid from the console of sb1. One of the obvious advantages of this is experiment scripts/applications need only mention the service name to be portable.

The grid service framework allows for service authentication module trough …