| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
package org.openregistry.integration;
/**
* An abstraction representing an integration subsystem for Open Identity Registry.
* The role of <code>IntegrationKernel</code> is to de-couple the core parts of OIR from 3rd party systems and abstract away the
* mechanism of actual integration and make it pluggable. For example different ESB-based implementations could be provided, configured and plugged into the core OIR system
* or web services-based one could be used, etc.
*
*<p><strong>Concurrent semantics:</strong> implementations of this interface must be thread-safe
*/
public interface IntegrationKernel {
/**
* Take the 'raw' identity data comming into the system and put into the 'processing pipeline'
* The typical implementation could use an ESB with a predifined message flow which would for example normalize the data,
* persist it into one or more OIR internal repositories and make the data available to any configured 'downstream' systems afterwords.
*
*<p>Note: implementors should assume the asynchronous invocation semantics
*
*<p>Note: the details about downstream systems should be configurable in implementing classes
*/
void processAndDispatchToDownstreamSystems(Object identityDataPayload) throws IntegrationFlowException;
/**
* Make the canonical OIR identity data available to 'downstream' systems
* The typical implementation could use an ESB with a predifined message flow which would for example make the data available to any configured 'downstream' systems.
*
*<p>Note: implementors should assume the asynchronous invocation semantics
*
*<p>Note: the details about downstream systems should be configurable in implementing classes
*/
void dispatchToDownstreamSystems(Object identityDataPayload) throws IntegrationFlowException;
/**
* Make the canonical OIR identity data available to 'peer' systems
* The typical implementation could use an ESB with a predifined message flow which would for example make the data available to any configured 'peer' systems.
*
*<p>Note: implementors should assume the asynchronous invocation semantics
*
*<p>Note: the details about peer systems should be configurable in implementing classes
*/
void dispatchToPeerSystems(Object identityDataPayload) throws IntegrationFlowException;
}
|
One possible Mule ESB based implementation would look like:
| Code Block | ||||
|---|---|---|---|---|
| ||||
package org.openregistry.integration.internal; import org.mule.module.client.MuleClient; import org.openregistry.integration.IntegrationKernel; public class MuleIntegrationKernel implements IntegrationKernel { @Autowired private MuleClient mule; public void processAndDispatchToDownstreamSystems(Object identityDataPayload) throws IntegrationFlowException { //The name of the endpoint to dispatch to could be configured of course this.mule.dispatch("oir-inbound-endpoint", identityDataPayload, null); } void dispatchToDownstreamSystems(Object identityDataPayload) throws IntegrationFlowException { //The name of the endpoint to dispatch to could be configured of course this.mule.dispatch("downstream-inbound-endpoint", identityDataPayload, null); } void dispatchToPeerSystems(Object identityDataPayload) throws IntegrationFlowException { //The name of the endpoint to dispatch to could be configured of course this.mule.dispatch("peer-inbound-endpoint", identityDataPayload, null); } } |