Welcome!

Microservices Expo Authors: Pat Romanski, Elizabeth White, Liz McMillan, Stackify Blog, Andreas Grabner

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
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.
While some developers care passionately about how data centers and clouds are architected, for most, it is only the end result that matters. To the majority of companies, technology exists to solve a business problem, and only delivers value when it is solving that problem. 2017 brings the mainstream adoption of containers for production workloads. In his session at 21st Cloud Expo, Ben McCormack, VP of Operations at Evernote, discussed how data centers of the future will be managed, how the p...
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...
Most DevOps journeys involve several phases of maturity. Research shows that the inflection point where organizations begin to see maximum value is when they implement tight integration deploying their code to their infrastructure. Success at this level is the last barrier to at-will deployment. Storage, for instance, is more capable than where we read and write data. In his session at @DevOpsSummit at 20th Cloud Expo, Josh Atwell, a Developer Advocate for NetApp, will discuss the role and value...
DevOps is under attack because developers don’t want to mess with infrastructure. They will happily own their code into production, but want to use platforms instead of raw automation. That’s changing the landscape that we understand as DevOps with both architecture concepts (CloudNative) and process redefinition (SRE). Rob Hirschfeld’s recent work in Kubernetes operations has led to the conclusion that containers and related platforms have changed the way we should be thinking about DevOps and...
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...
Is advanced scheduling in Kubernetes achievable?Yes, however, how do you properly accommodate every real-life scenario that a Kubernetes user might encounter? How do you leverage advanced scheduling techniques to shape and describe each scenario in easy-to-use rules and configurations? In his session at @DevOpsSummit at 21st Cloud Expo, Oleg Chunikhin, CTO at Kublr, answered these questions and demonstrated techniques for implementing advanced scheduling. For example, using spot instances and co...
In his session at 20th Cloud Expo, Mike Johnston, an infrastructure engineer at Supergiant.io, will discuss how to use Kubernetes to setup 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....
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, discussed why containers should be paired with new architectural practices such as microservices rathe...
SYS-CON Events announced today the Kubernetes and Google Container Engine Workshop, being held November 3, 2016, in conjunction with @DevOpsSummit at 19th Cloud Expo at the Santa Clara Convention Center in Santa Clara, CA. This workshop led by Sebastian Scheele introduces participants to Kubernetes and Google Container Engine (GKE). Through a combination of instructor-led presentations, demonstrations, and hands-on labs, students learn the key concepts and practices for deploying and maintainin...