ESB Based Provisioning

Enterprise Service Bus

The so called 'Enterprise Service Bus' (ESB) server fits nicely into the OIR integration subsystem as by definition an ESB, sometimes referred to as 'messaging middleware', is a platform that can carry data between different, disparate applications in the completely decoupled manner. Data is carried to and from a series of stops, known as 'endpoints', which must be defined for each application connected to the bus. The internals of an ESB contain transport protocols adapters which decouple each application from wire level details of communication, transformation mechanisms that know how to transform disparate data formats so that applications on the bus could understand them, and routing mechanisms that know how to direct data from point A to point B. The ESB plays a role of a logical channel that spans an enterprise and allows data to be sent, transformed, and received from numerous applications via the bus. Data is transferred to or from each endpoint using a particular communication protocol e.g. across a TCP connection, over HTTP, or perhaps via JMS topic/queue.

Mule ESB

Mule is an open source ESB which provides a rich set of integration functionality. Mule does not impose any limits on the use of one messaging  middleware over another, and it supports 25 different protocols out of the box. Apart from messaging, Mule has an object broker that can manage Java objects at runtime. The object broker uses a non-intrusive container that allows one to reuse existing Java objects without the need for additional coding. As well as transferring data to and from other applications, data can also be passed to and from these hosted objects. All this is performed at runtime using the staged event-driven architecture (SEDA) threading model.

Pushing identity data to downstream systems via Mule bus

The architecture of Mule ESB allows to assemble flexible 'message flows' between disparate systems in a very decoupled manner. The OIR's Mule implementation for example could define several message flows of identity data between inbound endpoints representing various 'Systems Of Record' [SORs] and outbound endpoints representing 'downstream systems' respectively. The Mule's outbound router collection for the downstream system endpoints could be configured in a numerous different ways, depending on the actual data availability, data delivery options, and types of downstream systems. For example in order to push data to LDAP, the simple 'pass-through' outbound router would be configured with an endpoint represented as a JMS queue. On the outside, the JMS queue listening component would need to be developed to pick up that data and persist it to LDAP. As an alternative, OIR's 'periphery' component could be developed which would be able to persist data to LDAP. This component then would be configured as a 'Mule service' component behind an endpoint with an inbound 'in-vm' pass-through router, etc. Should the additional downstream systems need to be added, the outbound router could be reconfigured as a 'multicasting' router broadcasting the same identity data message payload to all the configured outbound endpoints, etc.

The power and flexibility of Mule would allow to build and construct the OIR integration subsystem in a loosely coupled manner, with no code dependency on communication protocols, and with the property of being easily extensible.