The following provides a set of guidelines around the ISBM for the OIIE™ Use Cases. It is expected that the reader has a basic understanding of the OpenO&M ISBM and OpenO&M ws-CIR.

Actors

The guidelines in this document involve four systems apart from the ISBM: a Provider, Transform Engine, ws-CIR, and Consumer. While the patterns refer to a singular class of system, the patterns can be extrapolated to multiple applications of that system class. Multiple providers and consumers follow the same interactions as a singular system, while multiple transform engines and ws-CIRs imply multiple channels or topics if federation is performed by using the ISBM.

Opening Sessions

To be able to post or receive messages on the ISBM, a system must open a session on the ISBM to receive a session identifier. It is assumed that the requisite channel and topic/s have already been created, and the ChannelURIs, TopicNames and AuthorizationTokens have been configured within the application.

Open Session Pattern with Validation

The general pattern for opening a session on the ISBM is to first validate that the requisite channel and topic/s exist before opening the session. The figure below shows an example of the validation and open session pattern.

  1. The System will call GetChannel using a specified ChannelURI. If a ChannelFault is thrown or a required TopicName is not present, then the System can indicate as such and terminate.
  2. The System will call an open session method (i.e. OpenPublicationSession, OpenSubscriptionSession, OpenProviderRequestSession or OpenConsumerRequestSession) on the ISBM using the same ChannelURI as in the previous call. The returned session identifier will be subsequently used to post messages on or receive messages from the ISBM.

This general pattern of validating and opening sessions is recommended for all open session interactions.

Open Transform Engine Sessions

The Transform Engine is an important infrastructural component used within the OIIE Use Cases to semantically transform data from one standard to another. Its open session interactions with the ISBM must occur before providers post messages on the ISBM.

The Transform Engine will open subscription and publication sessions for receiving and posting messages. The number of subscriptions and publications will depend on the channel and topic design of the environment. Note: It is assumed that the Transform Engine is configured to forward messages from its subscription channels to the appropriate publication channels after message transformation.

For systems communicating with the Transform Engine, the ChannelURI and TopicNames used to open publication and subscription sessions must correspond to those used by the Transform Engine. This will enable the Transform Engine to be a seamless component in the message pipeline.

Open ws-CIR Sessions

The OpenO&M ws-CIR is an important infrastructural component used within the OIIE Use Cases to serve as an object registry. Its open session interactions with the ISBM must occur before providers post messages on the ISBM.

The ws-CIR will open read request and post response sessions for receiving ws-CIR requests and posting ws-CIR responses. For systems communicating with the ws-CIR, the ChannelURI and TopicNames used to open post request and read response sessions must correspond to those used by the ws-CIR. See the ws-CIR BODs for the format of the ws-CIR requests and responses.

Topics

It is recommended that topics follow the convention of describing the data type of the message content. This simplifies processing for consumers of the message when parsing the message content.

While the ISBM supports a message being assigned multiple topics, because of the above recommendation, only a single topic should be assigned to a message.

Message Exchange with a ws-CIR

The pattern for messaging in an environment with a ws-CIR is:

  1. The Provider will send a request to the ws-CIR to register new objects if necessary
  2. The Provider will send a request to the ws-CIR to obtain necessary identifiers for existing objects referenced in the message (if the identifiers are not cached)
  3. The Provider will post a message on the ISBM
  4. The Consumer will read the message from the ISBM
  5. The Consumer will send a request to the ws-CIR to obtain necessary identifiers for the objects referenced in the message (if identifiers are not cached)
  6. The Consumer will send a request to the ws-CIR to register new objects if necessary

The Provider or Consumer could either be a business application or the Transform Engine. This pattern applies to both publish/subscribe and request/response patterns.

Closing Sessions

All systems must close sessions if no messages are expected to be posted or received on that session. The duration for expecting to post or receive messages depends on the environment design.

Session Lifetime Management

Publication, subscription, post request and post response sessions only need to be available for the duration of posting or receipt of a message/notification. However, to avoid repeatedly opening and closing sessions, a single session can be opened for the duration where messages are expected to be posted or received. The session can be persisted over hours, days or permanently depending on the scenario and ISBM implementation.

Note As publication messages are immediately expired once a publication session is closed, providers should not close sessions until they are satisfied that published messages have been read by consumers.

Note Persistence of sessions by the ISBM is not addressed in this document, as it is unique to the implementation.