This Schema was generated by the OSS through Java XML Toolkit Doclet 3-30-2005 15:27
The Threshold Definition interface provides a mechanism for the configuration
of the parameters that specify the criteria that determines the setting and
the clearing of threshold crossing states (threshold crossed and threshold
cleared). A threshold enters a threshold crossed state when it reaches the
threshold value specified by the setValue operation. It will remain in this
state until it enters a threshold cleared state. A threshold cleared state is
achieved when a threshold reaches a value that is calculated using the
offset and the threshold value. If the direction of the threshold is
rising, the value is computed by subtracting the offset from the
threshold value. Once the threshold reaches this value, it will remain in a
threshold cleared state until it rises to the threshold value again. If the
direction is falling, the offset is added to the threshold value and it
will remain in the threshold cleared state until it descends to the threshold
value again.
<p>
The valid attribute types are defined in
<code>javax.oss.cbe.measurement.PerformanceAttributeDescriptor</code>. However the
<code>STRING</code> type is not allowed for a threshold attribute.
This interface represents the attributes of a measurement job that can be used to make queries for
measurement jobs.
<p>
The attributes will be used to filter out the measurement jobs that match the values of the attributes.
The attributes are concatenated using logical AND-operation.
This interface is the base value representation of a measurement job.
<p>
The <CODE>JVTPerformanceMonitorSession</CODE> manages measurement jobs. A client can create and retrieve
measurement jobs indirectly by using the methods of an <CODE>JVTPerformanceMonitorSession</CODE>.
<p><ul>
A measurement job shall include:
<li>a granularity specifying the rate at which performance data is read (scanned).
<li>a reporting mode indicating the manner in which clients are notified of the generation
of a measurement results.
<li>a report format indicating the format of the result reports to be generated.
<li>a schedule specifying the schedule of the monitoring activity.
<li>a key that identify the measurement job.
<li>a state of the measurement job.
</ul>
<p>
The granularity period is the time between the initiation of two successive gatherings
of measurement data within the timeframe specified in the scheduling attributes.
<p>
The reporting mode is used to specify the reporting method of the measurement result
reports of the measurement job.
The reporting mode can be either file or event or both. If the reporting mode is
set to event the system will emit an event that carries the measurement result reports.
If the reporting mode is set to file, the measurement job will capture the measurement
result reports into a data storage and then emit an event to the client about the
availability of the data. The frequency of this event is determined by the data
storage creation frequency and can not be set by the client. If the reporting mode is set
to both file and event both ways applies.
When a client receives an event of data availability, the client can retrieve the data,
by using the URL to make a connection to the system.
If reporting mode is set to <CODE>ReportMode.FILE_SINGLE</CODE> the reporting period specifies how
often measurement result report will be generated.
<p>
The report format defines the format of the result reports to be generated.
If the report mode is set to <CODE>ReportMode.FILE_MULTIPLE</CODE> or <CODE>EVENT_MULTIPLE</CODE> the
client should not set the report format, it will be assigned by the server.
<p>
The measurement schedule specifies the time frames during which the measurement job
will be active. The measurement job is active as soon as the start time - if supplied
in the schedule - is reached. The system shall support a measurement job start time of
up to at least 30 days from the measurement job creation date. If no start time is
provided, the measurement job shall become active immediately. The measurement job
remains active until the stop time - if supplied in the schedule - is reached. If no
measurement job stop time is specified the measurement job will run indefinitely and can
only be stopped by system intervention, i.e. by deleting or suspending the measurement
job.
The time frame defined by the measurement schedule may contain one or more recording
intervals. These recording intervals may repeat on a daily and/or weekly basis and
specify the time periods during which the measurement data is collected. The start time
and end time define a recording interval, which lie between 00.00 and 24.00 hours,
aligned on granularity period boundaries. Thus the length of a recording interval will
be a multiple of the granularity period. If daily interval is omitted, the measurement
job will run continuously through the day. If weekly schedule is omitted the measurement
job will run all days of the week. Alternatively the weekly schedule will indicate which
days of the week the measurement job will be run.
The timer-synchronization between the client and the server is not part of this
interface and is left over to the implementers.
<p>
The measurement job can have several states: Active and on duty, Active but of duty and
suspended. The following shows how the states are changed in accordance to the schedule.
<p>
(A) Duration (A schedule represents by startTime and stopTime)
<p>
State Transition table (1), the startTime and stopTime is set
<blockquote><pre>
---------------------++------------------------+
Time Stream || Operation |
|| ---suspend()--> |
|| <--resume()---- |
---------------------++-----------+------------+
1. before startTime || off-duty | suspended |
---------------------++-----------+------------+<> startTime
2. within schedule || on-duty | suspended |
---------------------++-----------+------------+<> stopTime
</blockquote></pre>
<p>State Transition table (2), the startTime is not set and the endTime is set.
<blockquote><pre>
---------------------++------------------------+
Time Stream || Operation |
|| ---suspend()--> |
|| <--resume()---- |
---------------------++-----------+------------+<> startTime not set
1. within schedule || on-duty | suspended |
---------------------++-----------+------------+<> stopTime
</blockquote></pre>
<p>If startTime is not set means that monitoring will start immediately.
<p>State Transition table (3), the startTime is set and the endTime is not set.
<blockquote><pre>
---------------------++------------------------+
Time Stream || Operation |
|| ---suspend()--> |
|| <--resume()---- |
---------------------++-----------+------------+
1. before startTime || off-duty | suspended |
---------------------++-----------+------------+<> startTime
2. within schedule || on-duty | suspended |
---------------------++-----------+------------+<> forever
</blockquote></pre>
<p>(B) Daily Scheduling
<p>The daily scheduling is set to have 4 elements, two start times and two stop times.
<p>State Transition table (4)
<blockquote><pre>
---------------------++------------------------+
Time Stream || Operation |
|| ---suspend()--> |
|| <--resume()---- |
---------------------++-----------+------------+
1. off schedule || off-duty | suspended |
---------------------++-----------+------------+<> 1st element
2. within schedule || on-duty | suspended |
---------------------++-----------+------------+<> 2nd element
3. off schedule || off-duty | suspended |
---------------------++-----------+------------+<> 3rd element
4. within schedule || on-duty | suspended |
---------------------++-----------+------------+<> final element
5. It will be back to 1. because of day-line crossing.
</blockquote></pre>
<p>(C) Weekly Scheduling
<p>The weekly scheduling is set to Monday and Friday and the daily scheduling is set
to have 4 elements, as above.
<p>State Transition table (5)
<blockquote><pre>
---------------------++------------------------+
Time Stream || Operation |
|| ---suspend()--> |
|| <--resume()---- |
---------------------++-----------+------------+
1. off schedule || off-duty | suspended |
on Sunday || | |
---------------------++-----------+------------+
2. off schedule || off-duty | suspended |
on Monday || | |
---------------------++-----------+------------+<> 1st element
3. within schedule || on-duty | suspended |
---------------------++-----------+------------+<> 2nd element
4. off schedule || off-duty | suspended |
---------------------++-----------+------------+<> 3rd element
5. within schedule || on-duty | suspended |
---------------------++-----------+------------+<> final element
6. off schedule || off-duty | suspended |
on Monday || | |
---------------------++-----------+------------+
7. off schedule || off-duty | suspended |
on Tuesday-Thursday || | |
---------------------++-----------+------------+
8. off schedule || off-duty | suspended |
on Friday || | |
---------------------++-----------+------------+<> 1st element
9. within schedule || on-duty | suspended |
---------------------++-----------+------------+<> 2nd element
10. off schedule || off-duty | suspended |
---------------------++-----------+------------+<> 3rd element
11. within schedule || on-duty | suspended |
---------------------++-----------+------------+<> final element
12. off schedule || off-duty | suspended |
on Friday || | |
---------------------++-----------+------------+
13. off schedule || off-duty | suspended |
on Saturday || | |
---------------------++-----------+------------+
14. It will be back to 1. because of weekly-line crossing.
</blockquote></pre>
This interface encapsulates all the information necessary to indicate the result
of a BEST EFFORT operation on a specific measurement job.
<p>
The performance monitor key result is used in operations involving multiple
measurement jobs, for example in the deletion or creation of multiple measurement
jobs.
<p>
The interface contains the primary key of the measurement job, a boolean value
indicating if the operation was successful for that measurement job and the
reason why the operation failed.
This interface is the primary key of a performance monitor instance.
<p>
It identifies the created measurement job. The key of the measurement job is a unique
identifier of the measurement job.
This interface is the value representation of a measurement job that monitor a set of
specified attributes on a set of observable object instances.
<p>
This interface extends the PerformanceMonitorValue interface with a new attribute:
<ul>
<li>a list of measurement attributes to monitor.
<li>a list of observable object instances.
</ul>
<p>
The new attributes, of the value object, are a list of observed object instances that
shall be monitored and an optional list of measurement attributes, that identify what
is monitored by the measurement job.
If the measurement attribute list is omitted, all measurement attributes in the observed
object instances will be monitored (scanned). The observable object instances should be of the
same type.
A PerformanceMonitorByObjectsKey type.
This interface is the value representation of a measurement job that monitor a set of
specified attributes on a set of observable object classes.
<p>
This interface extends the PerformanceMonitorValue interface with a new attribute:
<ul>
<li>a list of measurement attributes to monitor.
<li>a list of Observable Object classes.
<li>a scope that define from where to find the observable object classes.
</ul>
<p>
The new attributes, of the value object, are a list of observed object classes that
shall be monitored, with a scope, and an optional list of measurement attributes, that
identify what is monitored by the measurement job.
If the measurement attribute list is omitted, all measurement attributes in the observed
object instances will be monitored (scanned).
A PerformanceMonitorByClassesKey type.
Represent a measurement attribute that can be monitored in the observable object class.
<p>
The measurement attribute name is short form of the measurement name and it is used to
identify the measurement attribute in the measurement result reports.
<p>
The type of the measurement can be:
<ul>
<li>Integer
<li>Real
<li>String
</ul>
<p>
Each measurement job will be collecting result data at a particular frequency,
known as the granularity period of the measurement. At the end of the granularity period
a scheduled result report shall be generated for each measurement job that is actively
collecting performance measurement data. The measurement data can be collected in a number of ways:
<ul>
<li>cumulative incremental counters triggered by the occurrence of the measured event;
<li>status inspection (i.e. a mechanism for high frequency sampling of internal counters at pre-defined rates);
<li>gauges (i.e. high tide mark, low tide mark);
<li>discrete event registration, where data related to a particular event is captured.
</ul>