On the interoperability layer call yesterday we discussed some of the issues that have been brought up by the interoperability layer community members. Specifically, our conversation revolved around the use of a ESB for the interoperability layer. We identified some key problems that present themselves in the current ESB tools that we would NOT like to see within the interoperability layer:
We don’t want the interoperability layer to be one large monolithic application. It should rather be modular such that it can be easily extended and it should not be a single point of failure.
For the heavy processing of messages within the interoperability layer we do not want to be using graphical programming tools to do so as some ESB tools require. We see the use of pure code to be more reusable, maintainable and easier to understand in the long run.
We also talked through the features that an ESB provides (message transformation, routing and orchestration) and found that these largely is what we want to achieve with the interoperability layer, however, we would like to be wary of the issues listed above.
In light of these point we discussed how a interoperability layer could be architected. We came up with two main independent components that could make up an interoperability layer:
Security and routing component: this component receives requests and can handle authorization and authentication, it can log and store the message it receives and it can route a message to the correct service provider or to component 2 if required.
This is a set of components that can handle more complex transactions that require orchestration. We can call these components processors or mediators. Each one of these processors/mediators will be able to transforms message and orchestrate specific message for a particular purpose (eg. for validation a messages content against the PR, FR and CR before sending to the the SHR). Only messages that require orchestration get routed to the correct processor/mediator from component 1.
I have included a very rough diagram of these components. Please let me know what you think and if I have captured this correctly. I’m sure I have forgotten something or mis-represented something.
Mark, Larry, Shahid, please let me know if this was your understanding of what we said on the call. If not, lets carry on the discussion here.
Thanks all!
Cheers,
Ryan
···
–
Ryan Crichton
Software Developer, Jembi Health Systems | SOUTH AFRICA
Sorry I haven’t been able to attend calls in the past couple of weeks, but I really like the sound of this.
As Derek and Mark have mentioned, this will make the most sense when we get a grip on what standards/formats will carry the messages.
Cheers,
Chris
···
On 24 July 2013 14:58, Ryan Crichton ryan@jembi.org wrote:
Hi all,
On the interoperability layer call yesterday we discussed some of the issues that have been brought up by the interoperability layer community members. Specifically, our conversation revolved around the use of a ESB for the interoperability layer. We identified some key problems that present themselves in the current ESB tools that we would NOT like to see within the interoperability layer:
We don’t want the interoperability layer to be one large monolithic application. It should rather be modular such that it can be easily extended and it should not be a single point of failure.
For the heavy processing of messages within the interoperability layer we do not want to be using graphical programming tools to do so as some ESB tools require. We see the use of pure code to be more reusable, maintainable and easier to understand in the long run.
We also talked through the features that an ESB provides (message transformation, routing and orchestration) and found that these largely is what we want to achieve with the interoperability layer, however, we would like to be wary of the issues listed above.
In light of these point we discussed how a interoperability layer could be architected. We came up with two main independent components that could make up an interoperability layer:
Security and routing component: this component receives requests and can handle authorization and authentication, it can log and store the message it receives and it can route a message to the correct service provider or to component 2 if required.
This is a set of components that can handle more complex transactions that require orchestration. We can call these components processors or mediators. Each one of these processors/mediators will be able to transforms message and orchestrate specific message for a particular purpose (eg. for validation a messages content against the PR, FR and CR before sending to the the SHR). Only messages that require orchestration get routed to the correct processor/mediator from component 1.
I have included a very rough diagram of these components. Please let me know what you think and if I have captured this correctly. I’m sure I have forgotten something or mis-represented something.
Mark, Larry, Shahid, please let me know if this was your understanding of what we said on the call. If not, lets carry on the discussion here.
Thanks all!
Cheers,
Ryan
Ryan Crichton
Software Developer, Jembi Health Systems | SOUTH AFRICA
