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.