A brief glossary of software integration

We now present to you a brief glossary of software integrations, so that you find an easier way of understanding these often used terms.

Integration is one of the main topics with which we most often come across on our projects. Sometimes the projects are clearly and explicitly integrational. In such projects, our main focus is to come up with and build connections between various IT systems. On the other hand, we encounter projects in which integration is seen as an implicit task or an unforeseen challenge. In both cases, the engineering challenge is distinct. It is needed to analyze and understand the interfaces of the system that we are connecting, to choose a platform and tools which we will use and therefore design and perform specific integrations.

Today, it is difficult to imagine a business system that can accomplish its purpose in isolation without the need for integration. We live in an age where cloud services and SaaS models are becoming the primary way of delivering software and presenting your own while using someone else’s API is an inevitable element of every serious software project. The micro-service paradigms, the use of containers and the PaaS environment give us an extra level of freedom, but also more complexity 🙂 , in combining different technologies and approaches to achieve integration. All this makes the story of integration sound extremely interesting and exciting. It is impossible without an integrator. For example, to be able to pay online with your favorite banking application, or any banking app  which you need to be able to buy a new mobile phone on the web shop of your favorite telecom. For this simple task, your favorite telecom will need to check the availability of the selected cell phone in the warehouse through the ERP system, create an order in the order management system, connect to the external payment system, record your order in the CRM system … and probably do a little more. For just one click on the “Buy” button in the web shop, integration with at least four to five other systems is required to make that purchase happen. Different protocols, data sets and rules, performance requirements and expectations, security rules … and in all of this, we need to think about robustness, sustainability and manageability. The challenge is as clear as the space for engineer creativity and research. 🙂

Did you know?

The world of software integrations is in no way simple. If we take into consideration the time of the formation of the data systems, the integrations must be capable to connect the newest state-of-the-art system which what we call legacy. Within integrations, we encounter different paradigms of the building of the system and we often need to find a common denominator to connect them. Thereat we have to be cautious not to infringe the architectural foundations of any system. We now present to you a brief glossary of software integrations, so that you find an easier way of understanding these often used terms.

Term


Definition


EAI – Enterprise application integration A set of integration methods and technologies – a concept that encompasses all integration efforts that are generally aimed at exchanging data and business processes between isolated applications.

P2P – Point to point

An integration in which applications merge as needed – it results with complex bonds that are difficult to track. In order for the n applications to be integrated, n * (n-1) / 2 connections are needed, which means that for example, 15 links are needed to be made in order for the six applications to connect to each other.
Hub and spoke An architecture that resembles a classic wheel with spokes and a central hub – it implies the existence of a central component, a broker, through which a communication between applications area made, each of which connects to the hub with the connector (adapter).
ESB – Enterprise Service Bus Software that falls into the MOM category (message oriented middleware) – it is the fruition of a hub and spoke concept with an emphasis on the standards (mostly WS-*) and the orientation towards services. It just about always connects with SOA endeavors, with solving the problem by connecting applications from point to point and bringing service concepts which eliminate the need of connectors.
SOA – Service Oriented Architecture A service oriented architecture – a way of building software systems that set the service as the main agenda. The service deals with the business defined activity singly through documented interfaces. A service of a higher level, also known as a composite service, uses other services for performing certain business activities.
WS – Web Service Web services enable system integration through standardized protocols. They are based on standards of SOAP, WSDL, XML, and XML Schema. There are more specialized standards for security, addressing, secure delivery, etc. that provide complex connectivity in enterprise systems at the expense of increased complexity. In many cases, they can be replaced by REST services.
REST –Representational State Transfer A way of designing a web service while using the HTTP protocol (and depending on it), and some sort of standardized message descript. The most commonly used is the JSON message format, but what also can be used is XML. Web API is almost always defined through REST, at which point REST API is created.
Orchestration The central orchestrator in service-oriented architectures (where the services must communicate in order to execute a business scenario) -It is conducted through the exchange of messages between the service. It is often used in the implementation of business processes through BPEL or BPMN standards.
Choreography Choreography – although a kin to the orchestration, it does not use a central orchestrator. For every service knows how to behave in a given scenario, in other words, every service knows which services are necessary to call after them. You can say that every service is aware of the business process in which it is used. It is often used in micro-system architectures.
Distributed transaction Distributed Transactions – Ensure ACID (atomicity, consistency, isolation, durability) properties between two connected systems, both of which, like the connection protocol, must support the so-called XA (two phase) transactions. Distributed transactions imply the existence of a coordinator completing transactions.