The steps for developing an ISBM adapter are the same as any software module:

1. Identify the requirements and develop a design

The analysis and identification process of functional requirements may leverage material such as the OIIE Use Cases. The functional requirements and subsequent design will help indicate which sections of the ISBM specification are relevant for an application. Typical requirement and design decisions that will be encountered are:

  • What role does my application play? Which transaction models will my application need to support? Which channel management WSDL methods need to be supported?
  • Will my application be able to host a Web Service for asynchronous callback or will I need to revert to polling?
  • What events will trigger a payload to be sent on the ISBM? What events will be triggered when a message is received?
  • How will the ISBM module be configured including channel, topic and token configuration?
  • How are other configuration items, such as polling or retry intervals, configured?
  • How are channels and topics persisted across application restarts?
  • Where will ISBM activity be logged and how are errors presented to users?
  • What ISBM activity needs to be persisted for audit purposes?

Once requirements have been identified, a design should be conducted that will address the system and user workflows, screen mockups, data models, test cases and other typical design artefacts used.

2. Implement the design

As indicated by the requirements and design, the actual development time required for the communications section of an ISBM module is fairly minor, particularly as most language frameworks have good support for WSDL and SOAP with code generation (e.g. Java has Axis2 and JAX-WS while .NET has WCF). The majority of the time will be spent integrating the module with workflows and cross-cutting concerns such as error handling, logging and persistence.

3. Test the implementation

While unit testing can always (and should always) be performed, integration testing is also invaluable. There are two options for integration testing: using an ISBM server developed by an external provider or developing a test ISBM server in-house.

Assetricity have provided a test ISBM server for use by all OGI Pilot participants. For access to the Assetricity ISBM test server endpoints, contact Assetricity.

ISBM Adapter Software Libraries

Below is a list of software libraries that can be used by software vendors to support the inclusion of ISBM functionality in their products:

ISBM Testing Tools

To facilitate ISBM testing, the following tools can be used to publish to or receive messages from an ISBM server: