The guidelines in this document involve four systems apart from the ws-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.
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
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.
- The System will call
GetChannelusing a specified
ChannelURI. If a
ChannelFaultis thrown or a required
TopicNameis not present, then the System can indicate as such and terminate.
- The System will call an open session method (i.e.
OpenConsumerRequestSession) on the ISBM using the same
ChannelURIas 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
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
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.
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:
- The Provider will send a request to the ws-CIR to register new objects if necessary
- 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)
- The Provider will post a message on the ISBM
- The Consumer will read the message from the ISBM
- 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)
- 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.
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.