Skip to content

Instantly share code, notes, and snippets.

@dima767
Created December 1, 2008 17:18
Show Gist options
  • Save dima767/30771 to your computer and use it in GitHub Desktop.
Save dima767/30771 to your computer and use it in GitHub Desktop.
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;
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment