Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

JOSIF Main Page | JOSIF Guidebook | Modeling | Shared Framework Model | Common Framework Model

The Common Framework Model covers objects that can be used by all interfaces. It covers:

  • Common Exceptions
  • Common Notifications

Common Exceptions

The optional common exceptions are used as needed for a given operation. They must be explicitly added to an operation. Interface developers should try as much as possible to reuse these common exceptions rather than creating new ones.

All common operations inherits from CommonException. CommonException is the root of the TIP Framework user modifiable Exception Hierarchy. All exceptions defined by an interface designer using the TIP Framework should extend from CommonException.

The figure below provides the hierarchy of optional common exceptions:

The optional common exceptions are:

*CapacityExceeded : This is the type of exception raised when the operation fails due to resources being created or activated beyond the capacity supported by the NE or target OS (the OS to which the operation is directed).

*Duplicate : This exception is thrown if an entity cannot be created because an object with the same identifier/name already exists.

*EntityNotFound : This exception is thrown to indicate that the specified entity does not exist.

*NotInValidState : The state of the specified object is such that the target OS (the OS to which the operation is directed) cannot perform the request. In other words, the environment or the application is not in an appropriate state for the requested operation.

*UnableToNotify : The target OS (the OS to which the operation is directed) is unable to connect to the Notification Service.

*ObjectInUse : The object identified in the request is currently in use.

*InventoryOutOfSync : This is the type of exception raised when the operation fails due to out of synchronization of inventory between requesting OS (the OS which invokes the operation) and target OS (the OS to which the operation is directed).

*AlreadyInPostCondition : in case the operation does not support idempotence, this exception is used to indicate that the server is already in the post-condition that the operation is attempting to define.

*AtomicTransactionFailure: Only in JOSIF V1.1. This exception is raised when an atomic operation does not succeed due to the failure of one of its sub-part. The details would indicate which object/ part failed.

*FilterNotSupported : Only in JOSIF V1.1. This exception is raised when a filter definition is not supported by the filter. The details might provide more precise reason.

Common Notifications

The common notifications defined the base objects used for various notifications. None of the common notifications defined below contains attributes. They are shown on the figure below:

The common notifications are:

*CommonNotification : This is the root of the TIP Framework user modifiable Notification Heirarchy. All Notifications/Events defined by an interface designer using the TIP Framework should extend from CommonNotification.

*OCNotification : a generic Object Creation event, ancestor of all specific Object Creation events.

*ODelNotification : When an instance of an entity type has been removed, an event of the type will be sent out. in TIP, this is the only common Object Deletion event.

*ODisNotification : a generic Object Discovery event, ancestor of all specific Object Discovery events.

*AVCNotification : a generic Attribute Value Change event, ancestor of all specific Attribute Value Change events

  • No labels