Microservices Expo Authors: Liz McMillan, Pat Romanski, Carmen Gonzalez, Elizabeth White, Jason Bloomberg

Related Topics: Microservices Expo

Microservices Expo: Article

SOA – Integration or Interaction?

We tend to forget that SOA is not just about integrating

SOA and integration have been working together so well that we tend to forget that SOA is not just about integrating and we often refer to SOA itself as mainly an integration architecture. The word ‘integration’ has been used for decades to describe the possibility for systems to interact, which makes it confusing when applying it to the SOA domain where it might be relevant to distinguish between integrating and interacting.

The point is that integration and interaction are two different things but how they differ depends on the way you define integration.

There are those that mean that two systems communicating with each other are in fact ‘integrating' (that's the traditional approach) and integration solutions are the components making this communication possible. I'd say that these systems are interacting instead, the use they do of the result of the interaction and the interaction's scope/context determine whether they are integrating or just interacting.

It's interesting to notice how the word ‘integration' took over different meanings within and outside the IT world. As mentioned, ‘integrating' in IT often means that two entities come in contact in some way. Applied to another domain the distinction between integration and interaction is easier to see: when speaking of immigration for example, integration means that the ones immigrating become part of the country they move to, sharing it's culture, values etc. Interacting on the other hand simply means you come in contact with something, like going on holiday abroad, thus ‘using', not creating any kind of permanent binding between you and the country you visit. Projecting the same principle to the IT domain it becomes more clear that using a service doesn't necessarily mean that you integrate with the system hosting it, you just interact with it through the service.

What does integrating mean then? Roughly, it means that two ‘entities' have something in common, that they share something more or less persistently. Interacting, on the other hand, means that two entities come in contact (temporarily) in some way.

But what is this ‘something' characterizing SOA integration?

That depends on the type of service. Looking at the distinction between infrastructure services and information services (where - roughly - information services have to do with information manipulation and infrastructure services perform some kind of operation) you see that in information services the integration taking place is an information-integration whereas in an infrastructure service the interaction might belong to a process integration. I'll try to explain.

Information services are used to retrieve information from systems/components etc., that information is often stored in the consumer's environment and reused thereby integrating the origin and destination systems information-wise, meaning that the information they share is what makes them ‘integrated'.

In infrastructure services the integration is often on a process level, meaning that the services belong (or contribute) to the same process.

A third type of integration is domain/scope-level integration, where several services are utilized within the same domain, for example an application using external services, the fact that the services are being used in the same context (the application) makes them integrated.

Having roughly clarified (and accepted) the distinction between integration and interaction it becomes more clear that SOA is not integration, even though information services are perhaps the most common in SOA implementations and they are often used in information-integrations.

Of course, interacting with a service makes two entities (the consumer and the provider) in some way logically ‘integrated' as they use the same functionality and they therefore have something in common (they share the ‘use' of the same functionality), but it's important to point out that we are speaking of logical integration and most importantly it has nothing to do with SOA or the architecture used but with the functionality itself. The service provider might not even use that same functionality that the client is using.

Besides different kinds of integrations there are several degrees of integration as well.

A web application needing to display information from some source will temporarily interact with the required service in order to get that information, use it and disregard it, thus it will ‘consume' (or interact with) the service and the information but it won't integrate with the system hosting the service. Even on a logical level the integration is very loose as the front-end is merely presenting the data, still you could say that there is a logical integration taking place as the service provider is now part of the application's flow.

If that same application was to save the data locally and most importantly was to reuse the data from the local storage rather than fetching the data from the originating system then we'd have a higher level of information integration (physical). The data the systems share is what integrates them. The more the information is reused the more the systems are integrated and if the system originally holding the information updates it (when changed) in the destination system then the integration gets even tighter.

Still, from a SOA point of view these systems integrations are in fact just interactions.

So why does SOA almost always turn up when speaking of integration? For a couple of reasons, the first being that SOA in it's nature makes it trivial to interact and therefore is the basis for building integrations and the second being the semantical non-distinction between integrating and interacting.

Furthermore, as information services are probably the most commonly used in SOAs and since these are often used in information and process integration we often tend to see SOA as integration as well.

I believe that the distinction between interaction and integration in SOA should be more evident, as they are in fact not only two different things but reside in two different abstraction levels. Integration might rely on a SOA or on any other architecture in order to work properly.

SOA in it's simplest form is services and services are not about integrating (thus the result of the interaction), services CAN be used to integrate but they are primarily a way to interact with the service provider.

Even though the difference between integration and interaction might seem subtle and more of a semantic kind there it is indeed important to keep it in mind when designing your architecture.

ESBs are for example often regarded as integration components whereas they are in fact just used to transparently enable interaction whereas there are specific products (integration platforms) providing tailored integration capabilities.

More Stories By Aristo Togliatti

Aristo Togliatti works as an IT Architect for the Swedish Railways (SJ). Previously he worked as Enterprise Architect at SVT, the Swedish State Broadcaster.

Comments (1)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

Microservices Articles
Modern software design has fundamentally changed how we manage applications, causing many to turn to containers as the new virtual machine for resource management. As container adoption grows beyond stateless applications to stateful workloads, the need for persistent storage is foundational - something customers routinely cite as a top pain point. In his session at @DevOpsSummit at 21st Cloud Expo, Bill Borsari, Head of Systems Engineering at Datera, explored how organizations can reap the bene...
"NetApp's vision is how we help organizations manage data - delivering the right data in the right place, in the right time, to the people who need it, and doing it agnostic to what the platform is," explained Josh Atwell, Developer Advocate for NetApp, in this SYS-CON.tv interview at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
The Jevons Paradox suggests that when technological advances increase efficiency of a resource, it results in an overall increase in consumption. Writing on the increased use of coal as a result of technological improvements, 19th-century economist William Stanley Jevons found that these improvements led to the development of new ways to utilize coal. In his session at 19th Cloud Expo, Mark Thiele, Chief Strategy Officer for Apcera, compared the Jevons Paradox to modern-day enterprise IT, examin...
In his session at 20th Cloud Expo, Mike Johnston, an infrastructure engineer at Supergiant.io, discussed how to use Kubernetes to set up a SaaS infrastructure for your business. Mike Johnston is an infrastructure engineer at Supergiant.io with over 12 years of experience designing, deploying, and maintaining server and workstation infrastructure at all scales. He has experience with brick and mortar data centers as well as cloud providers like Digital Ocean, Amazon Web Services, and Rackspace. H...
Skeuomorphism usually means retaining existing design cues in something new that doesn’t actually need them. However, the concept of skeuomorphism can be thought of as relating more broadly to applying existing patterns to new technologies that, in fact, cry out for new approaches. In his session at DevOps Summit, Gordon Haff, Senior Cloud Strategy Marketing and Evangelism Manager at Red Hat, will discuss why containers should be paired with new architectural practices such as microservices ra...
In his session at 20th Cloud Expo, Scott Davis, CTO of Embotics, discussed how automation can provide the dynamic management required to cost-effectively deliver microservices and container solutions at scale. He also discussed how flexible automation is the key to effectively bridging and seamlessly coordinating both IT and developer needs for component orchestration across disparate clouds – an increasingly important requirement at today’s multi-cloud enterprise.
The Software Defined Data Center (SDDC), which enables organizations to seamlessly run in a hybrid cloud model (public + private cloud), is here to stay. IDC estimates that the software-defined networking market will be valued at $3.7 billion by 2016. Security is a key component and benefit of the SDDC, and offers an opportunity to build security 'from the ground up' and weave it into the environment from day one. In his session at 16th Cloud Expo, Reuven Harrison, CTO and Co-Founder of Tufin, ...
DevOps is often described as a combination of technology and culture. Without both, DevOps isn't complete. However, applying the culture to outdated technology is a recipe for disaster; as response times grow and connections between teams are delayed by technology, the culture will die. A Nutanix Enterprise Cloud has many benefits that provide the needed base for a true DevOps paradigm. In their Day 3 Keynote at 20th Cloud Expo, Chris Brown, a Solutions Marketing Manager at Nutanix, and Mark Lav...
Many organizations are now looking to DevOps maturity models to gauge their DevOps adoption and compare their maturity to their peers. However, as enterprise organizations rush to adopt DevOps, moving past experimentation to embrace it at scale, they are in danger of falling into the trap that they have fallen into time and time again. Unfortunately, we've seen this movie before, and we know how it ends: badly.
TCP (Transmission Control Protocol) is a common and reliable transmission protocol on the Internet. TCP was introduced in the 70s by Stanford University for US Defense to establish connectivity between distributed systems to maintain a backup of defense information. At the time, TCP was introduced to communicate amongst a selected set of devices for a smaller dataset over shorter distances. As the Internet evolved, however, the number of applications and users, and the types of data accessed and...