The Ongoing Evolution of Integration Styles

Over the last couple of months I have been working on a Reference Architecture to support the design of modern Distributed Applications - now increasingly being referred to as Composite Applications. I am going to post a number of blogs over the coming weeks to share some of the learnings / highlights from this initiative.

The modern distributed application is designed first and foremost with integration in mind as opposed to the traditional n-tier models which focused first on the design of an application and secondly on integrating with the application or with other applications. Before I jump into any of the Reference Architecture material I wanted to first focus on some trends that I have observed in how Integration is evolving as people start to think more about designing for S+S and SaaS. I wanted to try to summarize to see if my observations align with your experiences.

Given my passion around the use of patterns as basis for a standardized representation of knowledge I have as you would expect attempted to ground this work in pre-existing patterns work. This includes a combination of the patterns & practices Integration Patterns and Application Architecture Guide – as well as Gregor Hohpe’s Enterprise Integration Patterns Guide and of course the SOA Patterns guide that I co-authored.

When you read any of the traditional Integration guidance such as Gregor Hohpe’s Enterprise Integration Patterns or David Trowbridge et al’s Integration Patterns they talk about a common set of integration styles (1). The set of styles that Hohpe and Trowbridge described are slightly different but fall roughly into the following five main integration styles that are typically considered when integrating applications:

• File Transfer – applications that interact through shared files created by a producer / consumer relationship
• Shared Database – applications interact by storing shared data in a common database
• Remote Procedure Invocation – applications expose functionality using RPC mechanisms that other applications sharing a common RPC mechanism can interact with
• Presentation Integration – a consumer applications simulates interacts with a dependent applications user interface
• Messaging – applications standardize on a common messaging infrastructure

Over the last 5 years or so there has been a movement towards using Messaging as the predominant means by which to integrate applications – normalizing around a pattern that Trowbridge called Service Oriented Integration. This pattern focuses on integration of applications through by exposing functionality (as opposed to exposing data or presentation tiers) in a way that supports interoperability, loose coupling and standardized contracts.

As new applications are for the most part moving towards adoption of a messaging based architectural style – primarily to ensure applications are proactively integrateable rather than reactively integrateable which is why other styles such as shared databases and presentation integration existed - the next major question is around whether all messaging based applications are the same. The answer to this is clearly no.  In the next couple of blog posts I will briefly review the major characteristics of each of the major messaging styles that exist starting first with the Point-to-Point Architectural Style which I will focus on in my next blog post.

(1) Just for a change, our industry has a number of differing opinions on what an architectural style is and I plan on talking more about that later, but for now think of an architectural style as represent the core architectural pattern that when selected establishes the fundamental architecture for a system (or major portion of a system).