Introduction
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 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:
...
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's diagram
The diagram below shows the internals of the Core Node.
...
The bottom layer need not use an ESB, and may involve multiple JVM's.
In the middle, is a place holder for a ESB. The top and bottom layers handle very common use cases. If the need arises, an ESB could slot in at this point.
Ryan's diagram
This is an adaptation of Mark's diagram where I (Ryan) give my views on how the components of the interoperability layer should be structured. This links in with the descriptions given in the introduction. The key difference is that every message goes through the pass through component and the messages that need further orchestration or processing are forwarded on to a processor/mediation component to perform this orchestration. This allows security, persistence of messages, logging and auditing to occur in a single location.
