Type Heirarchy
{http://java.sun.com/products/oss/xml/Common}ManagedEntityValue (by extension)  {http://java.sun.com/products/oss/xml/CBE/Core}CBEManagedEntityValue (by extension)   {http://java.sun.com/products/oss/xml/CBE/Core}EntityValue (by extension)    {http://java.sun.com/products/oss/xml/CBE/Measurement}PerformanceMonitorValue

Derived Types
{http://java.sun.com/products/oss/xml/CBE/Measurement}PerformanceMonitorValue  {http://java.sun.com/products/oss/xml/CBE/Measurement}PerformanceMonitorByClassesValue (by extension)  {http://java.sun.com/products/oss/xml/CBE/Measurement}PerformanceMonitorByObjectsValue (by extension)

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>

Stylus Studio XML Schema Library Home

Site Map | Privacy Policy | Terms of Use | Trademarks

Stylus Scoop XML Newsletter:

Stylus Studio®, a product from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2006 All Rights Reserved.