Real life "Out of the Box but within the Context"

The basic concept of "Out of the box but within the context" article.

To the request of many (just kidding, just 1) I would like to explain this idea with a real life personal example.

The background story is a project I was part of that was a telecommunication provider systems transformation.

My role was the architect responsible for all the system-to-system integrations, namely, API's, Messaging, Events etc.

The solution that I am going to use as example was part of migration from the legacy to new systems.

This kind of migration is not done as Big Bang because of the millions of customers and other records involved.

So, a population of customers is selected to be migrated with all their associated data.

For example, those with Customer address from City "x" or that the Customer ID is between 1-99999.

The period of time where legacy and new system function in parallel, is called co-existence period.

After such migration happens, then starts the co-existence period. Any call to API's we developed, needed to be routed according to the migrated records.

So, customer with ID 12345678 will be routed to the legacy system API and customer with ID 298 will be routed to the new system API.

Our "Box" was the ESB (Enterprise Service Bus) we used to develop all the integrations.

The immediate thought was to develop this routing in the ESB. In other words "In the Box".

Soon enough I found out that it has 2 issues:

1. The ESB is not flexible enough so we need to develop routing per API
2. It is throwaway code. The API's are for that customer only and the code will not be used once the co-existence period is over

So I looked for any other system/device/component that is doing routing of API calls. That is the meaning of "Within the Context".

The best fit was Reverse Proxy. Quoting from Wikipedia: "Reverse proxy is a proxy server that appears to any client to be an ordinary web server, but in reality merely acts as an intermediary that forwards the client's requests to one or more ordinary web servers".

?

This looks like exactly what we wanted!!

In principle, Yes, in practice, No.

The normal routing decision in a Reverse Proxy is based on the HTTP URI from the client.

The decision in our case, should be based on the API URI and the API headers and body.

What was missing for us was the mechanism for the Routing Decision.

In addition, since we handle Headers and Body, we needed to have a place to develop and deploy content adaptors.

You can see below the basic architecture with all the components.

The Co-Existence Router technology is Java.

It supports both WSDL/XML and REST/Json because these are all wrapped in HTTP Headers and Body.

The routing logic is the configuration that we load into the Co-Existence Router. Basically, very sophisticated Xpath.

?

?

We developed that for a particular project and we found out that it can be used in other routing use-cases and for other customers.

Apparently, we invented something new and received the acknowledgment with this Patent.

To summarize:

1. Our Box was the integration platform (ESB) we used
2. The Context was API routing that can be done in many ways
3. The Out of the Box solution was inspired by a network component that is considered as infrastructure.

I hope this demonstrates the phrase "Out of the box but within the context".

Thanks for your attention,

Noam

?

?