This Schema is used to provide common framework components for the OSS/J XML Interfaces. This Schema was generated by the OSS Through Java XML Toolkit Doclet 1-26-2004 7:3 The ActivityControlException exception is thrown by a JVT ActivityControl Session Bean to report that the invoked Activity control business method could not be completed because of a Activity control specific exception. Returns the supported granularity periods for the provided ActivityValue or, if the value is null, return the summary of all supported granularity periods. This operation returns a list of granularity periods that can be used when a measurement job shall be created, with the specified definition of the measurement job. If no granularity period is supported for the specified instances and attributes, an empty array shall be returned. The returned granularity periods shall be a factor or a multiple of a hour. Returns the supported reporting modes of the system. Returns the supported reporting modes of a particular Activity. Returns the supported report formats of the system. Returns the supported report formats of a particular Activity. Returns the underlying protocol's names for the supported reporting mechanisms of the JVT Session Bean. At least one valid string value should be returned in the results, even if only pure OSS/J based reporting scheme is supported and this scheme is not based on any known protocol. In such case, the returned results should contain "OSS/J" string value. For various report modes, it is necessary to elaborate on exactly what type of protocol and version will be used to do the reporting. Examples are given below: <UL> <LI> Report mode is EVENT_SINGLE or EVENT_MULTIPLE: The protocol string is JMS. The version string is: "1.0.2'. <LI> Report mode is FILE_SINGLE or FILE_MULTIPLE: The protocol string could be "IPDR", if IPDR compliant file transfer protocol is being used. The version string could be: "3.0". <LI> Another example of Report mode being FILE_SINGLE or FILE_MULTIPLE: The report protocol being used might be pure "FTP". <LI> Report mode is STREAM_SINGLE or STREAM_MULTIPLE: The protocol strings could be any of "HTTP", "HTTPS", "GTP" or any other name that makes sense to both the Producer system and the client of the API. <LI> Report mode is ITERATOR_SINGLE or ITERATOR_MULTIPLE: The protcol string is "OSS/J". </UL> Returns the underlying protocol's names for the supported reporting mechanisms of the specified ActivityKey At least one valid string value should be returned in the results, even if only pure OSS/J based reporting scheme is supported and this scheme is not based on any known protocol. In such case, the returned results should contain "OSS/J" string value. For various report modes, it is necessary to elaborate on exactly what type of protocol and version will be used to do the reporting. Examples are given below: <UL> <LI> Report mode is EVENT_SINGLE or EVENT_MULTIPLE: The protocol string is JMS. The version string is: "1.0.2'. <LI> Report mode is FILE_SINGLE or FILE_MULTIPLE: The protocol string could be "IPDR", if IPDR compliant file transfer protocol is being used. The version string could be: "3.0". <LI> Another example of Report mode being FILE_SINGLE or FILE_MULTIPLE: The report protocol being used might be pure "FTP". <LI> Report mode is STREAM_SINGLE or STREAM_MULTIPLE: The protocol strings could be any of "HTTP", "HTTPS", "GTP" or any other name that makes sense to both the Producer system and the client of the API. <LI> Report mode is ITERATOR_SINGLE or ITERATOR_MULTIPLE: The protcol string is "OSS/J". </UL> Returns the underlying protocol's versions for the supported reporting mechanisms of the JVT Session Bean. If no information regarding the supported versions is available, empty string array may be returned. Returns the underlying protocol's versions for the supported reporting mechanisms of the specified activity. If no information regarding the supported versions is available, empty string array may be returned. This is the base interface for representing the subscription filter. This interface allows an Activity to specify the subset of data that is of interest to the client. This QueryValue interface represents the attibutes of an that can be used to make real-time queries for the Activity Reports. The attributes are cancatenated using logical AND operation for querying operations. The results of the query operations are always made available to the client using the ReportDocumentIterator. If this cannot be supported by an implmentation, it will throw an javax.oss.UnsupportedOperationException for the corresponding query operation. Interface for the Activity Creation event Raised by an OSS/J application, when an activity has been created. This interface specifies the time periods during the day, when the schedule is active. The hour schedule consist of two arrays of start times and end times, which defines the intervals when the schedule shall be active. The start time and end time lie between 00.00 and 24.00 hours. Defines enumeration values for report mode. The report mode for the measurement results can be done in different ways. The following report modes exists: <ul> <li> event per measurement job. <li> event for multiple measurement jobs. <li> report file per measurement job. <li> report file for multiple measurement jobs. <li> proprietary mechanism per measurement job. <li> proprietary mechanism for multiple measurement jobs. <li> iterator per measurement job. <li> iterator for multiple measurement jobs. </ul> If the reporting mode is set to event the system will emit an event that carries the measurement result report. 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. If the reporting mode is set to proprietary then the proprietary of the data. If the reporting mode is set to iterator, then the system will emit an event that includes the iterator. The frequency of this event is det ermined by the data storage creation frequency. When a client receives an event of data availability, the client can retrieve the data, by using appropriate mechanism. Also, the support for stream oriented protocol makes it real-time report forwarding feasible with no inherent delays introduced by Activity Scheduling mechanism. Example stream oriented protocols supported could include FTP, HTTP/HTTPS or low-level RAW SOCKET (or SSL socket) based transfers. The details of the actual transfer primitives are currently out of scope of this API specification and are left to individual implementaion. This is the base value object representation for all Activities in OSS/J activity package. This interface is an enumeration of the valid values for the Control State of an ActivityValue This QueryValue interface represents the attibutes of an Activity that can be used to make queries for the Activity instances. The attributes are concatenated using logical AND operation for querying operations. This is the base key value representation for a Activity in OSS/J. Base Interface for the Activity Creation event property descriptor. This interface specifies the filterable properties of the event. The clients should use these properties to filter out and receive the activity creation event meant for them on the system's JVTEventTopic. It is expected that if an implementation supports separate Destinations for Activities (i.e. not using JVTEventTopic) to disseminate notifciations to the clients, then the activityValue attribute in ActivityCreationEvent will return that destination type and name. These are retrievable by invoking the respective methods on the (@link javax.oss.cfi.activity.ActivityReportParams} interface. Base Interface for the Activity Removal event property descriptor. This interface specifies the filterable properties of the event. The clients should use these properties to filter out and receive the activity removal event meant for them on the system's JVTEventTopic. It is expected that if an implementation supports separate Destinations for Activities (i.e. not using JVTEventTopic) to disseminate notifciations to the clients, then the activityValue attribute in ActivityRemovalEvent will return that destination type and name. These are retrievable by invoking the respective methods on the (@link javax.oss.cfi.activity.ActivityReportParams} interface. This is the base interface for representing the controlling aspects of a Activity that utilizes a schedule. <ul> The following parameters constitute a ActivityControlParams definitions: <LI> OneShot Capability - Tells whether this Activity can be fired independently. This is a useful concept, if the a pre-created Activity defintion can also be used ad-hoc querying. <li> overlapAllowed - Tells whether a new run can be started, if the previous run is not yet finished. <li> failureTolerance - Tell how to proceed if there are intermediate failures. Works also with Best Effort Semantics. </ul> Base Interface for the Activity Suspend event property descriptor. This interface specifies the filterable properties of the event. The clients should use these properties to filter out and receive the activity suspend event meant for them on the system's JVTEventTopic. It is expected that if an implementation supports separate Destinations for Activities (i.e. not using JVTEventTopic) to disseminate notifciations to the clients, then the activityValue attribute in ActivitySuspendEvent will return that destination type and name. These are retrievable by invoking the respective methods on the (@link javax.oss.cfi.activity.ActivityReportParams} interface. Interface for the Activity Removal event Raised by an OSS/J application, when an activity has been removed by the client. The reporting results of a single activity may be shared by multiple clients (as listeners or receivers). Hence, it is important to notify all registered parties of the removal of an Activity by emitting this event to common "JVTEventTopic" JMS topic. This is the base interface for representing the subscription information. This interface allows an Activity to register for a subset of data that is of interest to the client. This is the key result value representation for a best effort operation on a Activity by its key, in OSS/J. Base Interface for the Activity Reporting Results Availability notification. Raised by an OSS/J implementation, when an Activity has report results ready, to be sent to the client. The Factory method for making empty instances of ActivityValue are not specified in this interface. It is expected that each API using this interface, will have its own sub interface of ActivityValue as well as a sub interface of ActivityEvent, so that the appropriate makexxxValue(String typename) will be provided by that API. It is sufficient for implementatations to just set the Key attribute of the ActivityValue for this notification. All the other attributes of the ActivityValue need not be present in the ActivityValue. This is the base interface for all schedules in OSS/J Activty package. It specifies the timeframes when the schedule is active. The schedule is active as soon as the start time - if supplied - is reached. The schedule remains active until the stop time - if supplied - is reached. If no stop time is specified the schedule will active indefinitely. The time frame defined by the schedule may contain one or more intervals. These intervals may repeat on a daily and/or weekly basis and specify the time periods during which the schedule is active. A daily schedule includes a start time and end time, which lie between 00.00 and 24.00 hours. If daily schedule is omitted, the schedule will run continuously through the day. If weekly schedule is omitted the schedule will run all days of the week. Alternatively the weekly schedule will indicate which days of the week the schedule will be active on. This is the base interface for all types of OSS/J Record values, that are not of ManagedEntityType. Example of such records could include the Usage Data Records of IP Billing API, or any other extenal data records. The instance of ReportRecord are returned by invoking <CODE>getNext()</CODE> class of operations on an instance of {@link javax.oss.cfi.activity.ReportIterator}. This is the base interface for describing an attribute or field. This is the primary key value representation for a Activity in OSS/J. Interface for the Activity Suspend event Raised by an OSS/J application, when an activity has been temporarily suspended by the client. The reporting results of a single activity may be shared by multiple clients (as listeners or receivers). Hence, it is important to notify all registered parties of the suspension of an Activity by emitting this event to common "JVTEventTopic" JMS topic. Base Interface for the Activity Resume event property descriptor. This interface specifies the filterable properties of the event. The clients should use these properties to filter out and receive the activity resume event meant for them on the system's JVTEventTopic. It is expected that if an implementation supports separate Destinations for Activities (i.e. not using JVTEventTopic) to disseminate notifciations to the clients, then the activityValue attribute in ActivityResumeEvent will return that destination type and name. These are retrievable by invoking the respective methods on the (@link javax.oss.cfi.activity.ActivityReportParams} interface. This interface represents the information about the records of report, that are returned by the {@link ReportIterator} as {@link ReportRecord} objects. Note that this descriptor is used as the base interface to define the attributes of a OSS/J Usage Data Record only. If the data is being exchanged by some other proprietary protocol/format (i.e. via raw socket connection or file exchange), this descriptor is not used. This can be Serialized to be sent to the receiving clients. It implements the SerializerFactory interface to provide the instances of Serializers, specific to handling the ReportRecord in question. This interface represents informat related to a generated Report file. Base Interface for the sending Activity Report Data in a notification to the client. It is sufficient for implementatations to just set the Key attribute of the ActivityValue for this notification. All the other attributes of the ActivityValue need not be present in the ActivityValue. Weekly schedule class. It specifies the weekly time frames during which the schedule will be active. Interface for the Activity Resume event Raised by an OSS/J application, when an activity is resumed, after it has been temporarily suspended by the client. The reporting results of a single activity may be shared by multiple clients (as listeners or receivers). Hence, it is important to notify all registered parties of the resumption of an Activity by emitting this event to common "JVTEventTopic" JMS topic. This interface represents the filterable JMS message properties based on which the clients can selectively receive availability notifications regarding the interesting Activity Reports. This is just base interface declaration. It is expected that the individual API would need to specify the necessary fitlerable properties, if any. An ActivityValue's attribute that specifies how often or how many times the specified Activity will be run. This interface allows one to specify granularityPeriod for applicable types of jobs (Performance/Threshold type). For other types of jobs, this interface allows optional specification of maximum runs and an optional delay interval between the two job runs. This provides for a Activities whose duration of completion of each run is not necessarily consistently the same. This interface also allows defining of a schedule that runs 'n' times without any delay between the runs. This interface represents the Reporting parameters of an Activity. The following reporting parameters constitute this interface: <UL> <LI> {@link ReportFormat}: Format of the report results. <LI> long ReportPerid: Specifies how often the reports will be generated. </UL> This interface represents the filterable JMS message properties based on which the clients can selectively receive interesting ActivityReportData. This is just base interface declaration. It is expected that the individual API would need to specify the necessary fitlerable properties, if any. This interface represents the format of the data reports. Base Interface for the Activity events. Raised by an OSS/J application, when individual Activities are created or removed or when there is a change an activity's Control Status. The Factory method for making empty instances of ActivityValue are not specified in this interface. It is expected that each API using this interface, will have its own sub interface of ActivityValue as well as a sub interface of ActivityEvent, so that the appropriate makexxxValue(String typename) will be provided by that API. activate a specific Activity by its key. activate a set of Activities by their keys. Best Effort operation. de-activate a specific Activity by its key. Deactivate a set of Activities by their keys. Best Effort operation. The Activity definitions are not deleted. suspend a specific Activity by its key. The on-going results, if any, of the activity are discarded. suspend a set of Activities by their keys. Best Effort operation. Resume a specific Activity by its key. Resume a set of Activities by their keys. Best Effort operation. One-shot running of a specific Activity by its key. One-shot running of a set of Activities by their keys. Best Effort operation. Base Interface for the Activity Event property descriptor. This interface specifies the filterable properties of the an activity related event. The clients should use these properties to filter out and receive the activity creation event meant for them on the system's JVTEventTopic. It is expected that if an implementation supports separate Destinations for Activities (i.e. not using JVTEventTopic) to disseminate notifciations to the clients. This interface is an enumeration of the valid values for the Execution State of an ActivityValue