IT Architecture Integration – SOA Model in Direct Communication

The model based on creating services without the use of a dedicated integration layer is one of the many ways to implement the concept of building a Service Oriented Architecture. Read this post to find out:

• the strengths and capabilities of this solution
• the potential and weaknesses of the solution
• when it makes sense to consider the SOA scenario in direct communication

---

In the SOA context, a service is a single component provided by IT for the business, supporting a specific task within one or more business processes. A single service usually uses many IT infrastructure components: such as networks, applications and databases.

Services should be:

• well described
• universal
• discrete
• available
• useful (providing a specific functionality that meets a business goal).

In the model discussed, communication takes place directly between systems (like in the P2P concept), but is organized and standardized using precisely defined services. The interaction is triggered by a request from the service recipient with a response given by the service provider by means of a specific communication protocol.

It is very important not to confuse a web service with an SOA service. The former is a program component, structured and defined by means of a specialized description language, independent of any platform or implementation. Web services are the most commonly used realization of SOA, but also more than that.

Strengths and capabilities of SOA in direct communication

• The reusability of services that allow multiple systems to be connected independently of each other (or “loose coupling”);
• Ease of maintenance – the implementation of a single service is in no way dependent on other services, which greatly facilitates the handling of a set of services (update, deactivation, monitoring) provided by a particular system;
• Closer to reliability – the decomposed components included in the architecture are easier to test and debug compared to massive homogeneous components that perform all inter-system data transfers of tens of thousands of lines of code;
• Greater scalability and availability – multiple instances of the same service can run in parallel, which significantly affects the service availability time and performance;
• Higher quality of software in the organization – shifting the center of gravity to system-provided reusable services, eliminating the redundancy of functionalities in the systems themselves, which reduces errors and increases consistency of data exchanged within the organization;
• Independence from platforms and technologies – services supporting data exchange between systems are completely independent from the technology and frameworks in which they were made.

Weaknesses and limitations

• “Higher initial costs, long-term savings” – the implementation of the concept discussed requires an in-depth business analysis to elaborate an effective division into services, and then to implement them. Compared to the P2P connection, the concept increases implementation costs, but in the long run the investment pays back, as it is easy to manage changes and add new systems.
• During each data exchange within the service, the values of all message parameters are thoroughly validated (to check whether they comply with the definition), which generates additional time overhead. However, in most cases this extra time is negligible.
• Difficulties managing messages exchanged within services – if the number of services in the organization is high, and so is the frequency of exchanging messages, problems may occur with respect to managing communication paths.
• There is no possibility of comprehensive service management and monitoring the entire integration layer in one place – each integration takes place directly between systems, so there are as many information sources as there are connected systems.

Application, SOA model selection criteria

The service-based approach in direct communication differs from the point-to-point method, as services need to be created in accordance with the described stringent requirements. The approach is a good integration direction for a firm:

• which uses several systems that do not need to communicate with each other at a very high frequency (hundreds of messages per second);
• whose systems and data sources can adapt to the services provided by other systems (the system design does not impede implementation of any mechanisms that use external interfaces);
• where the services to be created are not overly complex, and within those services no advanced data transformation is necessary;
• for which the homogeneity and “rigidity” of services providing a specified business value in the organization is not an obstacle (for example, it is OK if the whole infrastructure has only one service that provides access to employee data).

The SOA-based integration model is not recommended for integrating systems which:

• are characterized by high consistency due to the provider or technology used – in such a situation, implementing the direct communication SOA approach will not be cost effective. If there are easy ways to create communication paths between systems (e.g. ready-made system interfaces from one supplier or ready-made communication paths from a technology supplier) – use them;
• generate large volumes of exchanged data without storing them; their main functionality is based on operating on a graphical interface (e.g. applications for placing markers on maps);
• are stringent about real-time data exchange, i.e. exchange with minimal response times from synchronous services;
• operate in isolation and are not ready to handle request-and-response network communication with other services.