Monday, May 31, 2010

Mediation Doesn't Require Something "In The Middle"

I blogged earlier about the subtle difference between federation and point-to-point connectivity, but didn't spell out how systems suffering from point-to-point connectivity ("the Dark Ages") could be effectively federated to bring them into the Modern Age without having to interpose a broker between them ("the Middle Ages").

Here's the problem - a point-to-point connection between two systems.
Here's the obvious solution - a broker that mediates all communication between the two systems. This is the ESB model, of course.
Is there another decoupling model for a federated system that can (by definition) have no centralised broker?

Consider an application that has the following hyperlink:

Now look at this one:

If we assume that both links are in fact referring to the same page, what's the difference between them? Yes, we know that in the second case, a DNS lookup is required to resolve the domain name to an IP address before the page can be accessed, but the actual HTTP call to GET the page is exactly the same (it uses the IP address) and the end result of the call is also the same. The HTTP GET seems to be point-to-point in both cases with no intermediaries.

So what's the real difference?

The first is truly an example of a point-to-point link. How do we know? Test it to see how brittle it is. If the intranet is now hosted on a different server with IP address, the link breaks immediately.

However, in the second example, if we change the server hosting the intranet but also update the relevant DNS entry so that "" points to "" instead of "", then the link continues to work and the application that embeds it is none the wiser. This is no longer a tight, point-to-point connection. It has been effectively intermediated by the introduction of a DNS lookup before the actual call is made.

This is what lookup-mediation looks like.
As we can see, we don't need to physically interpose a component between two systems to break the point-to-point link between them. We can use a lookup mechanism to achieve the same result.

Incidentally, web-style interaction with domain names in URIs instead of IP addresses is inherently loosely-coupled and therefore the REST style of integration that follows this approach is not an example of point-to-point connectivity. Any node can make HTTP calls to any other, yet nodes are not tightly coupled to each other. This is a practical example of federation.


David French said...

All very reasonable especially since you took the reasoning back to first principles rather than relying on some mantra on the moment.
Is there an analogous argument around centralising of a database or data-centric services versus federating? Consider the idea of Electronic Health Records ... do we aim for a single centralised service and require all health providers to work through it or do we have EHRs held in many health provider facilities? It seems to me that the smart addressing you illustrate obviates the 'need' for centralisation.

Ganesh Prasad said...


Sorry for the delay in responding.

I definitely agree that we shouldn't rely on physical centralisation. We can hide the distributed nature of data through appropriate interfaces. A lot of processing can happen behind the scenes, and this in fact provides an extra degree of flexibility to the implementation.

There may be performance impacts, though.