OpenHIM mediators are components that mediate transaction for the OpenHIM. This includes the following sort of functionality:

• Adapting and transforming between different message formats (normalising incoming message formats and denormalising outgoing message formats)
• Performing transaction orchestration - that is executing a business process that may need to consume the interfaces of multiple other external systems and precess the result to perform some function.

There can be multiple mediators attached to the OpenHIM-core. Each of these should be independent and perform a single function. These mediators should plug into the OpenHIM-core so more mediators can be added over time and so that implementations can deploy only the mediators that are required for their use case.

Each of these mediators should be an external service so that they can deployed independently and they can be build using any technology stack that makes sense for the mediators use case as long as they can communicate with the OpenHIM-core though the defined interface. This enables great potential for scalability and also allows mediators to focus on a single concern. This follows a micro service architecture. For additional benefits and details of this architecture please see the following resources:

• http://martinfowler.com/articles/microservices.html
• https://blog.yourkarma.com/building-microservices-at-karma

For each mediator to communicate with the OpenHIM-core it will need to be able to talk to the OpenHIM's interfaces. There are 2 major interactions the mediators should have with the OpenHIM-core:

1. Mediators register themselves with the core
2. Communicate metadata about transactions that the mediator processes

Registering mediators

Some thoughts:

Have a interface where a mediator can contact the OpenHIM and register itself. Registering will allow the following function:

• Allow the OpenHIM-core to display the registered mediators
• The mediators register their endpoint (host path, other details) with the core, this allows the OpenHIM to allow a user to easily configure a mediator by name
• ...

Communicate transaction metadata

Some thoughts:

Then mediators can populate a token with metadata about the transaction as they process it. this token can then be returned to the core to provide insight into what the mediators did. This metadata can include:

• metrics about the external services that were contacted
• errors thrown while processing
• responses or errors returned by the external services