For years, information systems have been built as “stovepipes” [1], creating monolithic self-contained applications that have not been designed for integration with other applications. These systems were built with very specific requirements and not using standard data storage and application development methods [2]. However, even years after its implementation, they continued to be critical although their technology was outdated [2]. They are also known as legacy systems. If the data of these systems were necessary for one function or another, the data was treated manually [1]. But as organizations automated their processes, it started to become clear that it was necessary to integrate these systems and with this necessity came the point-to-point architecture.
Figure 1. Stovepipe Systems
Point-to-Point Architecture
In a point-to-point integration architecture, when two applications need to communicate with one another, a connection is established and a connector enables application A to speak to application B by sending a message or executing a procedure. A connector is a bridge that allows access to data or application functionalities in a structured manner. Connectors handle the complexities of message translation, integration and any other relating messages operations used to access the application features [3]. When is needed to change either application A or B, the interface needs to be updated in both, and if we add one more application C, for our applications universe to be fully integrated we have six connectors to update and maintain, and this number grows with each application added. Remember that each of these connectors must be separately developed and maintained across system version changes, scalability changes or, in some cases, even purchased at high cost from a vendor. With all these reasons, the unsuitability of point-to-point integration for complex enterprise scenarios becomes painfully clear [4]. While the advantage of point-to-point integration is its simplicity, the disadvantage is its complexity [4]. Even though it is highly advantageous in scenarios where the universe of applications is small, as this number grows, maintenance becomes very problematic and expensive; originating what is commonly called “spaghetti” architecture. If we want to avoid this “spaghetti”, we need to provide an intermediate layer that can isolate the changes between applications, effectively reducing the coupling. To do this, we use middleware.
Figure 2. Point-to-Point Architecture
Middleware is application-independent software that provides services that mediate between applications [3]. Middleware hides the complexities of the underlying operating system and network in order to facilitate the easy integration of new and legacy systems [2]. Is a means for connecting clients to servers, clients to clients, and servers to servers without having to navigate through many operating systems, networks or resources server layers [2]. There are two types of middleware, logical, that is related with how information moves through the organization and physical, that really moves the information and covers the technology used for this purpose [2].
In the next chapter I will talk about the different types of middleware that can help us make integration easier.
Ricardo Santos
EAI Consultant and IoT Evangelist at Polarising
References
1. Johnson, P.: Enterprise Software System Integration, An Architectural Perspective. Universitetsservice US AB, Stockholm (2002)
2. Linthicum, D.S.: Enterprise Application Integration. Addison-Wesley, Boston (2000)
3. Ruh, W.A., Maginnis, F.X, Brown, W.J.: Enterprise Application Integration: A Wiley Tech Brief. John Wiley & Sons, Inc. (2001)
4. Linthicum, D.S.: Next Generation Application Integration: From Simple Information to Web Services. Addison-Wesley, Boston (2004)
Figure 1 – http://ptgmedia.pearsoncmg.com/images/0201615835/samplechapter/eaich1.html
