Warning: This document describes an old release. Check here for the current version.
Workspace Status Service
The status service allows a client to query the usage data the service has collected about it.
Currently there are two operations, queryCurrentWorkspaces and queryUsedAndReserved.
queryCurrentWorkspaces returns some status information on all instantiated workspaces that the caller controls. It returns the schedule, network addresses, ID number, etc. for each.
queryUsedAndReserved returns the time (in minutes) used so far by the client as well as the currently reserved time.
The used time is measured from creation time to WSRF resource destruction time. Note that the end of the measurement is not when the workspace's running time is over. Thus if you have lengthy stage-out transfers or extend the resource termination time for no good reason (which ties up allocations, including networking addresses), you will still be charged for this time.
The reserved time is the aggregate of all your current deployments' requested durations. When a deployment ends, the used time for that deployment is added to 'used' and the appropriate time is substracted from 'reserved'.
Reserved time is tracked separately mainly for authorization purposes: the authorization policy can look at your past and current deployments together to render a decision. If 'used' were the only thing tracked and consulted during authorization, a client could conceivably "blast" the service with requests that would ultimately put it above its quota down the line because the current used tally would be low at creation time.
There is currently one resource property chargeGranularity. This is an integer that tells how running time is being "counted". If this value is one then anything between zero and one minute (inclusive) is counted as one minute. If this value is e.g. thirty, then anything between zero and thirty minutes (inclusive) is counted as thirty minutes.
Why would chargeGranularity ever be set differently than a value of one? There may be organizational accounting reasons, but the workspace service backend is usually the cause of this. For example, the alternative backend to Amazon's Elastic Compute Cloud would cause the chargeGranularity to be sixty. On this backend, the same amount of money is currently charged for any time used between zero and sixty minutes (inclusive), and so this parameter can be altered to accurately express a usage value that directly translates to the real charges.
The Status Service WSDL can be viewed online.