Evolutions of a Middleware

A Middleware is unlikely to be removed (though it still may be replaced) once it is built into a system. There are few evolutions as a Middleware is a third-party product and is unlikely to be messed with:

• If the Middleware in use does not fit the preferred mode of communication between some of your services, there is an option to deploy a second specialized Middleware.
• If several existing systems need to be merged, that is accomplished by adding yet another layer of Middleware, resulting in a Bottom-Up Hierarchy (Bus of Buses).

Add a secondary Middleware

Patterns: Middleware.

Goal: support specialized communication between scaled services.

Prerequisite: the system relies on a Middleware for scaling.

If the current Middleware is too generic for the system’s needs, you can add another one for specialized communication. The new Middleware does not manage the instances of the services.

Pros:

• Supports specialized communication with no need to write code for tracking the instances of services.

Cons:

• You still need to notify the new Middleware when an instance of a service is created or dies.
• There is an extra component to administer.

Merge two systems by building a Bottom-Up Hierarchy

Patterns: Bottom-up Hierarchy (Hierarchy, Middleware).

Goal: integrate two systems without a heavy refactoring.

Prerequisite: both systems use Middlewares.

If we cannot change the way each subsystem’s services use its Middleware, we should add a new Middleware to connect the existing Middlewares.

Pros:

• No need to touch anything in the existing services.

Cons:

• Performance suffers from the double conversion between protocols.
• There is a new component to fail (miserably).

<< Evolutions of a Pipeline	^ Evolutions of architectures ^	Evolutions of a Shared Repository >>