Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

IntegrationKernel.java
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;
}
  • No labels