Dynamic adaptation to changes in resource availability in a distributed system requires timely, accurate relatively high-level integrated data. This data generally has to be synthesized from a set of simpler data of variable reliability and timeliness and must be distributed in an efficient way. The data synthesis can viewed as form of data fusion, or in some cases, as a kind of impedance matcher.
One way to envision such a service in the broad sense is as a hierachical confederation of local services communicating among themselves, each of which implements a particular Resource Model describing the data being represented at that level. Each such service is locally responsible for handling raw sensor data as well as requests for integrated data from consumers, where these consumers might be well other service instances.
This leads to two interfaces, which might be considered facets of an Resource Status Service (RSS) component: DataAccess, to retrieve data from an RSS, and DataFeed, to supply raw data to an RSS. We also need a specification for the data itself, which we'll call DataValue. Finally, the subscription style of query implies another interface for the callback. We'll call this DataSubscriber.
The data entering and leaving an RSS needs a set of attributes associated with each value. A minimal set of attributes would include the following dimensions (which, not coincidentally, are closely related to the familiar notions of timeliness, accuracy and precision).
timestamp and halflife fields, below.
In addition to being accessible to the ultimate consumer of the
data, these fields are used internally by the RSS in its own
management of timeliness and reliability. credibility field, below. As with the
time related dimenions, credibility is accessible to the end
user of the data and is also used internally by the RSS in
its own management of reliability. provenance
field, as an uninterpreted string. units
field, for now an uninterpreted string.
Given this, and assuming three kinds of raw data values (numeric, boolean, character), data in an RSS is represented as follows:
// Assume three sorts of values: strings, booleans and numbers.
enum data_types { number_data, string_data, boolean_data};
typedef union data_value_union switch(data_types) {
case number_data:
double d_value;
case string_data:
string s_value;
case boolean_data:
boolean b_value;
} data_value;
typedef struct DataValueStruct {
long long timestamp; // when was it gathered
long long halflife; // how long is it good for
double credibility; // how reliable is it
string units; // what is it measuring
string provenance; // where did it come from
data_value value; // the value itself
} DataValue;
The RSS is layered service, implemented by a hierachy of RSS instances in which the higher level data representations are computed in part on the basis of data supplied by lower levels. This layering is parallel to the layering structure of the resource management as a whole.
For the most part this hierarchy can be implemented simply by making any given RSS instance a client of the other RSS instances it depends on. But eventually this chain of RSS instances linked to one another has to bottom out into a simpler kind of data provider, a sensor, which communicates with the RSS through a different conceptual interface. This interface is what we call a DataFeed. To some extent the DataFeed notion is an implementation detail, of no concern to RSS clients. For completeness, it's described here briefly.
DataFeeds come in various flavor, each associated with a particular kind of sensor. Some examples might include static configuration data (eg from XML files); network measurements (eg from Cisco routers); and host measurments (eg from Eternal Systems monitors).
Sensors are assumed to be able to provide data to the RSS with a descriptive key indicating what the data represents and which particular sensor it came from. The interpretation of the key is handled by the implementation of the specific DataFeed associated with that kind of sensor, and should provide enough information to allow the RSS instance to find the right higher level data abstractions that use the raw sensor data. In other words, the interpretation of the keys is what makes possible the data dependency relationships within the RSS itself.
As an example, a host data key might look like this:
HOST_192.168.0.1_LOADAVERAGE_ETERNALSYS, indicating
that the corresponding data is a load average for the given host
as supplied by one of Eternal's host monitors.
Note that, while the DataFeed interface is described here in IDL for consistency, for reasons of efficiency the communication will most likely be in the form of direct function calls, not CORBA.
interface DataFeed {
void newData(in DataValue data, in string key);
};
[Some sensor/DataFeed kinds: ]
The DataAccess interface supports two styles of access, query and subscription. The DataSubscriber interface needs to be implemented by clients using the subscription style. The Qualifier interface allows subscription clients to restrict the callbacks they get.
// Client Interfaces
interface DataSubscriber {
void dataUpdate(in string path, in DataValue data);
};
interface Qualifier {
boolean qualifies(in DataValue old, in DataValue new);
};
// Server Interfaces
interface DataAccess {
// return a status as the result
boolean query(in string path, out DataValue data);
boolean subscribe(in string path,
in Qualifier qual,
in DataSubscriber subscriber);
boolean unsubscribe(in string path,
in Qualifier qual,
in DataSubscriber subscriber);
};
The path arguments need to describe the location of the
desired value in the data-dependency space of an RSS. These are
completely distinct from the key argument in DataFeed.
Keys describe low-level sensor data, whereas paths follow a kind
of naming or routing scheme for a particular high-level data
organization, for example a tree, and refer to place in that
organization, for example the means to reach a node in the tree
starting at the root. For more details on paths, see the Data Model section, below. As an example of
a path, the point-to-point network capacity between two hosts
might look like this: IpFlow(192.168.0.10,
192.168.1.100):Capacity.
The query call is used to fetch the current value described by the path. The subscribe call is used to setup a notification for changes in the value described by the path: if that value changes and if the change meets the qualifications, the subscriber will be notified via DataUpdate. Qualifiers are typically used to avoid unnecessary calls associated with minor or irrelevant changes. The most common form of Qualifier would specify an epsilon, below which changes in value are considered too small to matter. A qualifier might also be based on time, credibility or origin, or on any combination of these.
The abstract interfaces above completely describe the external view of the RSS, but the heart of the service for any particular domain is inside, in the form of a data model. The beginnings of a specific model for ARMS follows in the next section; here we describe the structure in general.
The data model in an RSS is represented as a graph of nodes, usually but not always a tree. The kinds of nodes available in any given RSS instance represent the abstract model of a domain type, while the collection of instances of each kind and their relationships represent a specific domain of that type. A node in this tree can best be thought of as a dynamic scope over a set of fixed attributes that are sufficient to distinguish that node from others of the same kind. In addition to these attributes, nodes also define formulas, ie expressions evaluated dynamically on the basis of attributes and formulas of the other nodes (or the same node) as well as raw data coming in from a DataFeed. This dependency relation defines the data chaining and propagation in the RSS. The tree relation, on the other hand, describes a form of containment: child nodes inherit the attributes and formulas of their ancestors (ie, the nodes which contain, directly or indirectly).
The form of this model should now make more clear the nature of DataAccess paths. A path describes the location of some node in the tree, in form of a sequence of parameterized node type names, followed by the name of an attribute or formula of that node.
TO BE DONE.
A resource model for ARMS would include at least the following node kinds: Applications, Pools, Nodes, and Links. Some of the relationships are already clear. For example the status of a Pool is dependent on the status of its Nodes. Similarly the status of an Application is at least in part dependent on the Nodes on which its component parts are running and on the network links between them.
The exact definitions of this model is still TBD.
BBN's existing Java implementation of RSS has show itself to be useful in very large distributed systems. Some issues in its application to ARMS would include: