Open registry real-time integration with consumers implementation patterns
- Dmitriy Kopylenko
Summary
There could be cases where 3rd party software consumers would be interested to consume and process OR data representing significant 'business events' happening in the registry. The examples of such event might be 'a new person is added to the registry' or 'an identifier for an existing person changed', etc.
Message-oriented-Middleware
Open registry chose MoM (message oriented middleware) as an underlying technology to integrate in a real-time fashion with 3rd party consumers (upstream/downstream). For example, an institution could set up an external JMS messaging broker with a PUB-SUB model i.e. set up JMS topics for different Open Registry events where interested consumers could subscribe to those topics and consume messages from them containing data related to those events. This part is completely independent from the Open Registry core codebase.
Open Registry 'Integration' subsystem
What Open Registry 'integration' subsystem provides is IntegrationGateway adapter API which provides means to send data (messages) to remote endpoints both synchronously (request/reply) and asynchronously as well as abstracts away any concrete means of doing so i.e. be it raw JMS API, any available ESB client API, low level web services calls, etc. Please note that the purpose of this API is not to re-invent the wheel or re-implement ESB, but to provide a very constrained and focused integration/messaging view to the core OR APIs implementations (the clients of the 'integration' subsystem). Out of the box, Open Registry provides CamelIntegrationGateway - an implementation based on Apache Camel.
Business events integration implementation patterns
Here's the outline of basic steps needed in order to implement sending real-time event messages to endpoints outside of Open Registry:
- Create a fine-grained interface representing the business event sending strategy with a createAndSendEventMessageFor method which has parameters representing the event data to be packaged in the message and sent to 3rd party consumers.
- Identify an event in Open Registry that needs to be passed to 3rd party consumers, by reviewing existing internal core APIs of Open Registry representing the event, or creating a new one.
- Create a POJO @AspectJ style Spring aspect with a Pointcut definition capturing JoinPoint of the API representing an event
- In the @AfterReturning advice for the Pointcut, capture the context of an event data, de-structure it if necessary and call the event notification service's createAndSendEventMessageFor method.
As for the implementation of createAndSendEventMessageFor for any particular event notification service, package the message into the appropriate message format that the consumers of this event expect e.g. XML or JSON message, etc. and call one of the methods on IntegrationGateway component.
It is assumed that Spring dependency injection is used to wire all the components together.