Software Integration - Connection Points

If you have a quick look at the titles of my previous posts, you'll find that one of my interests in software engineering is the things related to software integrations, titles like stability patterns, feedback, and ... Although all of these topics can be get used in both inside single software design and in integration of many subsystems, but using them in software integration is much more important, because:

• When a team or person writes a software they know about the entire components well enough to adjust them to work well together.
• When you try to integrate software systems to work together in an ecosystem as a single software solution, you usually don't know how these subsystems behave in a different situation so the integration environment must have some intelligence itself to keep them working. And this is the place where the stability patterns, feedback, ... comes into play.

System integration is the process of gathering several subsystems or components together make them  work together as a single system while making sure the system works well in every condition. Now let us see what in an integration is that makes it difficult to make the whole system stable.

Sample integrated sub software subsystems.

Connection points
Connection points are the points in which different components / software systems meet each other and exchange information. Look at the picture, some systems are giving information and some are getting or some are doing both. For example, the S1 is feeding data into S2 and S3 while both sending data to S4 and ... Just note that data is what the subsystems understand and is not some that information we need to have to keep the whole system stable or healthy.

We define CP12 as the connection point from S1 to S2, CP41 as a connection point from S4 to S1 and ... The fact is the system should work at normal and good conditions when CPij are connected without any control. In fact, we have to develop the subsystems in a way that they work with each other at normal conditions at least. But let us see what happens if one of the subsystems gets crazy!

Here we just assume that all of the systems work linearly means what they give are more or less proportional to what they are gotten. In a normal and calm condition there is a balance between input and output flow for each system, which means for example the data enters in CP12 for S2 is being processed somehow that the injected result to CP24 keeps S4 in balance condition, as well as S2 itself and the same situation for all other systems.

But what happens if one of the systems experiences some fault or get unstable. For example, S4 starts to produce more than what S1 can handle of data. Here is what happens:

• S4 produces more data than usual
• S4's produced data passes CP41 and goes to S1's input terminal
• S1 tries to process data linearly so produces more output in its output terminals
• More than usual data passes through both CP12 and CP13
• S2 and S3 receive more than usual data in their input terminals 
• They both process more data and produce more output
• More than usual output in CP24 and CP34 results S4 produces more data in its output
• System gets a positive feedback

The above scenario continues until one of the systems reaches its limit of linear behavior and get saturated or get broken. Note that we just assumed systems work linearly just because wanted to describe the scenario easily, there is no need for having such a limitation. Even if systems have a very complex functionality the system can (and usually will) get into such an unstable situation after days of working and experiencing never tested conditions.

Central control mechanism for connection points
of sub systems of an integrated software solution.

Solution

The solution is nothing but what we already talked about it, using stability patterns and feedback. It means we need to have some controlled connection point or have the systems' input / output controlled by themselves to not let poison (I'll talk about poison data or message later) data or situation happens and gets the subsystem in trouble.

One general way of doing this is having active CPs and a central control center for connection points, like the picture. As you see all active CPs send information on what they receive or transmit to the integration control center (ICC). So ICC has the required information to check the health status of the whole integration points. And if we just provide it with the information about normal situation or flow of data, it can control the active CPs and order them to behave in a way that the whole system keeps itself stable in situations when one or more of them get unstable.

The ICC can be much more intelligent and effective if we provide some more information from the subsystems too. In this case, the ICC can make much more effective decisions to keep the system stable and running.