Decoupling Middleware

Realm of middleware

Middleware is a graceless name for tools that inhabit a singularly messy space, integrating systems that were never meant to work together. Rebranded as enterprise application integration, middleware became a hot property for a few years in the early 2000s and then faded back into its shadowy, thankless realm. Middleware occupies the essential interstices between enterprise systems. It is the connective tissue that bridges gaps between different islands of automation. How’s that for a mixed metaphor?.

Middleware job

Often described as “plumbing,” with all the related connotations; middleware will always remain inherently messy, since it must work with different business processes, different technologies, and even different definitions of the same logical concept. This complexity must be part of the reason why service-oriented architectures are currently stealing attention from the less glamorous, but more necessary, job of middleware.

Decoupling system

Middleware simultaneously integrates and decouples systems. It integrates them by passing data and events back and forth between the systems. It decouples them by letting the participating systems remove specific knowledge of and calls to the other systems. Since integration points are the number one cause of instability, this looks like a good thing.

Any kind of synchronous call-and-response or request/reply method forces the calling system to stop what it’s doing and wait. In this model, the calling system and the receiving system must both be active at the same time. They are synchronous in time, though they may be in different places. This category covers remote procedure calls (RPCs), HTTP, XML-RPC, RMI, CORBA, DCOM, and any other analog of local method calls. Tightly coupled middleware amplifies shocks to the system. Synchronous calls are particularly vicious amplifiers that facilitate cascading failures. Yes, this includes JSON over HTTP, too.

Less tightly coupled forms of middleware allow the calling and receiving systems to process messages in different places and at different times. The venerable IBM MQseries and any queue-based or publish/subscribe messaging systems fall into this category, as does system-to-system messaging via SMTP or SMS. These latter two protocols frequently have message brokers implemented with carbon, hydrogen, oxygen, and nitrogen rather than silicon. Latency also tends to be high. The following figure depicts the spectrum of coupling exhibited by different middleware technologies.