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

The Internal Framework Model defines objects that are used by generators to be injected in the specifications.
This model cannot be referenced directly by interface developers. It will always be used implicitly. It covers:

• Entity Identifier
• Pre-defined Exceptions
• Extensibility
• Iterators
• Notifications

Entity Identifier

Entity Identifier is added to all entities by making all entities inherit by injection from EntityBase.
This is shown on the figure below:

It defines the following objects:

• EntityBase : This is the base definition used for all TIP entities. This type is injected by the TIP Generators into code generated from Tigerstripe Entity artifacts where the 'Extends' field has been left as an empty string. It contains the following attributes:
  • identifier : The entity instance identifier (EID).
  • extensionInfo : Used to add extensibility to entity. Please refer to #Extensibility.
  • aliasNames : The aliasNames attribute contains implimentation specific name value pairs for local alternative names for the Entity. This is provided to pass more user friendly names for entities between systems or for debugging. The aliasNames attribute MUST NOT be used by an implimentation when comparing EntityIdentifiers. There is NO GUARANTEE that the contents of the aliasNames attribute is unique.

• EntityIdentifier : The data type definition of the TIP Entity Identifier (EID). It contains the following attributes:
  • context : The context attribute contains a Context object which determines the system specific context for the Entity. The context defines an implementation specific context scheme and context valuePairs, a collection of named value pairs.
  • dn : The dn attribute contains a DistinguishedName object which determines the Distinguished Name of the Entity.
  • entityType : Defines the type of the referenced entity as a String. This string is implementation technology specific. For example in XML it is filled by the implementation with with an XML type reference. In java it is filled with a classpath reference.

Pre-defined Exceptions

The predefined common exceptions are automatically inserted into all operations, with the exception of one-way operations which do not have exceptions at all.

InternalException is the root of the TIP Framework Internal Exception Heirarchy. All TIP interfaces will as a minimum support the exceptions extending from InternalException. InternalException inherits by injection from ExceptionBase.

ExceptionBase : This is the base definition of all TIP operation exceptions. This type is injected by the TIP Generators into code generated from Tigerstripe Exception artifacts where the 'Extends' field has been left as an empty string or as 'java.lang.Exception'. ExceptionBase contains 2 attributes:

• reason : Free string to define the reason the exception was raised. It should be a short text. Might reference the step in the use case where this exception occurs, if a detailed use case was made for this operation. Daatatype: String

• details : The more specific details about the exception. Can also be a stack trace. Datatype: String

The figure below provides the hierarchy of predefined common exceptions:

The predefined common exceptions are:

• AccessDenied : This is the type of exception raised when the operation fails for security reasons. The requesting OS does not have access rights to request the given operation. Even if access control is implemented by policies, this exception shall be used in case of access denied.

• CommunicationLoss : The target OS (the OS to which the operation is directed) is unable to communicate with an underlying system or resource, and such communication is required to complete the request.

• InternalError : The request has resulted in an OS internal error.

• InvalidInput : This is the type of exception raised for all failures related to operation input parameters. Typicaly, the request contains an input parameter that is syntactically incorrect or identifies an object of the wrong type or is out of range.

• NotImplemented : The entire request is not supported by the target OS or the request with the specified input parameters is not supported. Operations in the interface that include this exception in their throw clause have to be considered as optional operations. In case of attributes, it can be thrown by the modification or the request of an optional attribute to indicate that the attribute is not supported by the implementation. This exception cannot be thrown for a mandatory attribute or operation.

• UnableToComply : The target OS (the OS to which the operation is directed) cannot respond to the request. May be raised whenever the OS cannot respond to a request. Use Cases may identify specific conditions that will result in this exception. This is a general exception. Please use more detailed ones (Communication Loss, Access Denied...) whenever possible.

Extensibility

Defines the datatype Any.

Any : This is an internal object used to add extensibility to entity, datatype or operations.
It allows adding a list of Any.

Iterators

The iterator model is shown below:

It consist of:

*CommonResponse : This is the base (abstract) definition used for all responses. The response maybe the IteratorInfo or a GetNextreponse. It contains the endOfSequence field to indicate if this is the end of the replies.
*IteratorInfo : This is the Info contained in the first reponse to a bulk based request. It may contain an Iterator ID if there are more replies.
*GetNextResponse : This is the response object to a getNextRequest.
*CommonRequest : This is the base (abstract) definition used for all Iterator requests.
*GetNextRequest : This is the Iterator getNextRequest. This retrieves the next batch of replies.
*ReleaseRequest : This is the Iterator release request. This release all the assocaited resources and ivalidate the iterator.
*ReleaseResponse : This is the response to a relase request.
*IteratorNotFound : This is the exception raised when the ID used when invoking an iterator is invalid. For example when trying GetNextResponse with an iterator ID that does not exist .
*InvalidIteratorContext : This is the exception raised when the context for the invocation of an iterator is invalid. For example when trying GetNextResponse out of an iterator that was released.

Notifications

It defines the base notifications that are injected:

*NotificationBase : This is the base (abstract) definition used for all TIP notifications. This type is injected by the TIP Generators into code generated from Tigerstripe Event (i.e. notification) artifacts where the 'Extends' field has been left as an empty string.
*CommonNotificationBase : This is the base (abstract) definition used for all TIP Common Notifications. This type is injected by the TIP Generators into code generated from Tigerstripe Event (i.e. notification) artifacts where the 'Extends' field corresponds to 'org.tmforum.tip.fmk.common.notifications.CommonNotification'.

This is shown on the figure below:

NotificationBase : This is the base (abstract) definition used for all TIP notifications.
This type is injected by the TIP Generators into code generated from Tigerstripe Event (i.e. notification) artifacts where the 'Extends' field has been left as an empty string.

NotificationBase includes the following attributes:

• sourceTime : The time at which the event was reported by the source system (NE, EMS or OS). It is the current time on the system where the event is generated. If a system (like an EMS) is carrying forward an event generated on a NE, then the time of the source (NE in this case) should be kept. Datatype: time.

CommonNotificationBase includes the following attributes:

• objectType : The type (class) of the object associated with the event. This attribute is needed to allow simple notification filtering based on the object type. Datatype: String.
• objectId : The identifier of the object associated with the event, as internal opaque identifier. Datatype: EntityIdentifier.