This is the third blog in a series of 6 blogs about integration 2.0. Read the first blog Integration 2.0 and second blog Integration 2.0:Introdution!

EAC-s may be integrated through their standard interfaces. API-s are centrally exposed to the enterprise though an API-hub. Events are exchanged from publishers to subscribers through an Event-hub.

Event Hub

The Event-hub is responsible for receiving events that are published by any component (“publishers”) and forwarding them to any interested party (“subscribers”). It maintains an administration of publishers and subscribers, the message types and optionally rules that may impact the delivery of messages to specific subscribers.

This publish/subscribe mechanism is not new. The Integration 2.0 event-hub however guarantees delivery, provides central functionality for routing, storing and logging events for compliance and optimization analysis.

Figure 8: The general concept of the Event Hub

An example of an Event Hub implementation is the Apache initiative Kafka ®

The event hub is intended for massages that do not extend a specific maximum size (>10 Mb). The hub should be scalable though when data is sent in continuous streams one should consider using streaming Ingress functionality (see BI and Analytics section). Further note that multiple instances of the Event Hub may be used to support different service levels, e.g. for critical and less critical Events.

API Hub

The API Hub provides central access to exposed synchronous services provided by IT components, generic IT functions and external services. It is intended for any data size up to 10Mb. (Larger data may be supported e.g. through a specific claim-check pattern, or else through other integration capabilities like ETL or Managed File Transfer). It provides a “proxy” interface to accept any synchronic request and redirects them to the correct component-API.

Figure 9: Internal and external API hub

The internal API-hub is responsible to provide access to internal consumers.

The external API hub is intended to facilitate synchronous traffic across the enterprise boundaries. It exposes a specific part API services to external parties, with additional security measures and policies. A second function is to access external API-s, e.g. provided by B2B-partners or other commercial or governance organizations. It may take care of all security and other policies and make the allowed external API available on the internal API-hub for internal consumers.

Note that multiple instances of the API Hub may be used to support different service levels, e.g. for critical and less critical API-s.

Process Hub

Where EAC-s are responsible for local functionality and local work-processes does the Process Hub support end-to-end processes that cross functional borders. As the Process Hub may depend on multiple EAC-s these processes themselves depend on the availability of the EAC-s. Process logic can simply be short-lived orchestrations, but also complex end-to-end Business Process Management (BPM) processes, or Adaptive Case Management (ACM) cases. Integration 2.0 adopts this principle through the Process Hub: a component responsible for running any type of process mentioned above. The process hub does not access EA components directly. It requests data or triggers transaction only through the API hub. This way the processes remain stateless and agnostic which EAC-s provide the required logic.

Figure 10:Process Hub

At the same time the API hub may allow processes to be started or process state and data to be queried. The process hub is also connected to the Event hub to trigger process events and to receive external events that may impact the state of a process.

Note that multiple instances of the Process Hub may be used to support different service levels.

This is the third blog in a series of 6 blogs about integration 2.0. Read the fourth blog Integration 2.0: Interactions!