Integration Architecture Explained

What is Integration Architecture?

In a well-designed building, the electrics and plumbing usually keep working no matter how many appliances are switched on. Such a building is also capable of extension without having to tear up the blueprints and start again. Why? Because it has good architectural design.

The same applies to software systems. Software architecture is the backbone of any complex computer system. The architecture encompasses all of the software elements, the relationships between the elements and the user interfaces to those elements. The performance and reliability of a software system are highly dependent upon the software architecture.

Well-designed software architecture can be extended with relative ease to accommodate new applications without requiring extensive infrastructure development.

This article describes the most common "Integration" software architectures.

POINT-TO-POINT INTEGRATION ARCHITECTURE

The original architecture used to support systems integration was called Point-to-Point. It derives its name from the direct, tightly bound connections that are made between applications and is the simplest of the integration architectures.

Point-to-Point Architecture

What are advantages of Point-to-Point architecture?

Point-to-Point solutions are often fast and efficient. The efficiency that derives from applications being tightly bound is one reason why at least a few Point-to-Point solutions will continue to be utilized for the foreseeable future.

What are the disadvantages of Point-to-Point architecture?

The down side of Point-to-Point is that, while each individual connection might be relatively straightforward, as the number of applications increases so too does the overall complexity of the environment. This can result in high maintenance costs and a lack of flexibility when it becomes necessary to make changes.

Any discussion with an integration vendor will often start with a presentation showing the mesh of Point-To-Point connections shown here. While Point-to-Point connections are not generally recommended, good software architecture will continue to support occasional Point-to-Point connections because they are often quick to implement and may fit perfectly with a particular requirement.

The drawbacks don't stop there, though. All other aspects of your integrated platform will be adversely affected by an overuse of the Point-to-Point option. Business Activity Monitoring (BAM), for example, is particularly difficult to develop where Point-to-Point connections are in use.

HUB AND SPOKE INTEGRATION ARCHITECTURE

The earliest formal integration technologies worked on the principle that all information coming from the applications had to be processed within a single machine or server called a "hub". Acting as a central point of control, the hub dealt with all message processing including routing, splitting and combining of messages, mapping, and so on.

Hub and Spoke implementations decouple the sending and receiving applications. Unlike Point-to-Point, the applications on either side of the hub can be modified independently of each other. Since applications no longer need to perform data mapping, centralized definition and control of business processes could be easily achieved for the first time.

Hub and Spoke Architecture

What are the advantages of Hub and Spoke architecture?

With Hub and Spoke, the integration environment becomes less complex. Whereas Point-to-Point becomes impossibly complicated as the number of connections increase, Hub and Spoke remains, in principle, simple since all the connections are to and from the hub. Hub and Spoke is the preferred architecture for achieving an easily controlled and managed environment in a medium sized integration project.

What are the disadvantages of Hub and Spoke architecture?

With Hub and Spoke, the initial setup of two-way communications can be challenging. The hub has to coordinate messages flowing between applications, and at the same time applications on both sides of the hub need to work well in a decoupled fashion. Both the source and target applications need some knowledge of each other in order to process messages. This sometimes makes it difficult to add or remove senders and receivers.

Since the hub must control all of the integrated processes, it is a viable option only when both sender and receiver agree on which hub to use. This will not be a problem for companies that are integrating internally, but may become a serious issue for Business to Business (B2B) and even cross-departmental integration projects.

Unfortunately, with so much processing taking place in the central hub, Hub and Spoke exacts high overheads. Processes within the hub often require significant processing power and lots of disk space. As the number and complexity of processes increase, performance can suffer and hubs often become difficult to manage, maintain, and extend.

Pure Hub and Spoke implementations do not scale well. One solution is to create a Federated architecture, which is an extension of Hub and Spoke that allows for multiple hubs to provide load sharing and back-up in case of failure.

DISTRIBUTED INTEGRATION ARCHITECTURE

One solution to the Hub and Spoke scalability issue is to perform message translation, routing, splitting, and combining closer to the source and target systems by using smaller computers known as "agents." Agent computers are connected to just one system and reduce the processing load on that system. Agents take information from the application they are connected to, process it, and send it to any target application(s) interested in receiving that information. The end result is Distributed Architecture. It is also known as Peer to Peer architecture.

Scroll to Continue

Sonic The Hedgehog 3 dropped a new trailer.

The Heinkel He 177 Greif (Griffin)

Sunset Sound’s Hallowed Ground: Behind the Scenes with Cinematographer Abel Padilla

Distributed Integration Architecture

What are the advantages of Distributed architecture?

Distributed architecture is governed by centralized rules and the requirements of the business flow. Most of the processing is performed in agent processors located near the source and target applications. Besides gains in processing efficiency by distributing the workload among dedicated processors, a Distributed Architecture is able to grow relatively easily. This ability to scale is a clear improvement on Point-to-Point and Hub and Spoke solutions.

Early attempts at Distributed Architecture would only work where the internal and external facilities operated under the same distributed technology. The choices available were:

1. CORBA (Common Object Request Broker Architecture) This was the Object Management Group's (OMG) open, vendor-independent architecture and infrastructure that computer applications employed to work together over networks.
2. Microsoft's COM (Common Object Model) This was later to become Distributed COM (DCOM) and a transactional version called COM+ was created later still. All of these have subsequently been combined with Microsoft's .NET initiative.
3. Java RMI (Remote Method Invocation) Java RMI enabled the creation of distributed Java-based to Java-based applications. It is now available in several software packages from Sun Systems.

What are the disadvantages of Distributed Architecture?

Many organizations have a mix of platforms and operating systems on which their business applications run, a situation that is often the result of mergers and acquisitions. When it becomes necessary to change or expand the system architecture, it is unfortunately not simply a matter of choosing one of the distributed technologies and implementing it. Opting for one technology may only provide a distributed solution for half of your organization due to the mix of systems that are being used.

Beyond these internal problems, there is also the issue of engaging in Business to Business (B2B) exchanges with other companies. This is another case where an eclectic mix of systems and technologies between businesses can impede the use of Distributed Architecture.

Vendors attempted to create various "bridges" between CORBA (Common Object Request Broker Architecture) and DCOM (Distributed Common Object Module) in an attempt to overcome these problems. However, these solutions never really gained acceptance in the marketplace. While the concept of a distributed environment showed promise for a long time, the business community never adopted it in great numbers.

SERVICE ORIENTED ARCHITECTURE (SOA)

Service Oriented Architecture (SOA) is the latest architectural approach, although it's not really very new. Service Oriented Architecture is essentially an enhanced version of Distributed Architecture that uses loosely coupled software services to support the requirements of business processes and software users. It goes a step further than the previous architectures by providing an integrated environment which spreads out the workload, breaking down the different "silos" of business functionality and opening their processes to other applications.

One way to think of SOA is like a Lego set. A Lego set is more than just the individual blocks; specialized bigger pieces for complex creations are also available. Similarly, with SOA, an application can customize and/or change the individual pieces or "services" that it uses. Using these concepts, vast and complex component based applications can be developed.

Service Oriented Architecture (SOA)

What new developments support Service Oriented Architecture?

The breakthrough for SOA came with the acceptance of Web Services. Although CORBA, DCOM, and the like have been available for constructing SOAs for a number of years, the advent of Web Services was the first time that Microsoft and IBM could finally agree on a communication standard. They both wholeheartedly embrace Web Services.

After Web Services came Enterprise Service Bus (ESB) technology. Based on Web Services, and exhibiting all of the characteristics of the Messaging and BPM solutions previously supplied by the integration vendors, ESB has become the accepted standard for the creation of an organization's Service Oriented Architecture.

Without exception all of the integration vendors now provide an SOA architecture built on the concept of an Enterprise Service Bus (ESB).

Thanks to Web Services there's now a thriving integration industry that is creating more and improved services that can be used to construct bigger and better business solutions. There were initial concerns about reliability and security but these have now been dealt with. There seems to be no stopping the universal acceptance of the Enterprise Service Bus and Service Oriented Architecture.

ADDITIONAL RESOURCES

• Systems Integration Made Friendly (Digital Book)
  For IT Managers and Developers who would like an overview of Systems Integration but don't need (or want) to get into specifics. Covers: Web Services, Enterprise Service Bus (ESB), Enterprise Portal, SOA, B2B, ERP & Integration Blueprinting.
• Systems Integration Resource Centre
  References to integration-related publications.
• Bluescribe.com
  Specialist provider of Integration Blueprinting services.
• Integration Competency Center (ICC)
  Shared service function within an organization for performing methodical Data Integration , System Integration or Enterprise Application Integration.
• Integration Technology Providers
  Links to over 20 key players in the Integration market.
• Systems Integration Explained
  Covering: Process Automation, Data to Data Integration, Enterprise Portal and Business Activity Monitoring

Comments

Mylindaminka on May 27, 2013:

Начинать окрашивание нужно с затылочной части, аккуратно разделяя расческой или пальчиками, выбранную часть волос, на мелкие пряди. Каждую прядь прокрашиваем от корня волос и одновременно прочесываем.

sournetriowet on March 08, 2013:

We helpful to obtain on top of existence although these days I've established a new level of resistance.

Anadirunika on February 18, 2013:

В разделе Ремонт сотовых Вы найдете необходимые инструкции и помощь, в случае если с Вашим маленьким другом приключилась беда, а его подстерегает очень много напастей это и вода и падения и стиральные машины всего не перечислишь, в этом разделе Вы найдете помощь, как действовать в той или иной ситуации, чем помочь, будут даны по возможности подробные инструкции и схемы.

sridevi on February 06, 2013:

thanku very much for a good structured description from old to new systems

Naveen on October 08, 2012:

Hi Russell, This is very informative, Thanks.

Can you please say something about latest trends in Integration architecture that is widely used currently

Hari Haran Arulmozhi on May 13, 2012:

Very helpful.. Thanks.

Max Ndaba on April 11, 2012:

Good article indeed, it cleared all confusion I had

Aleks on January 31, 2012:

Like your article, very informative, congratulation!!!

Russell O'Brien (author) from Sydney on September 11, 2011:

You're most welcome. Always good to hear a non-techi's able to get it.

James on September 11, 2011:

WOnderful explanation. You helped a non-technical person understand integration concepts. Thank you

Patty Brown on December 22, 2010:

You may be interested in Kovair's SOA-based Kovair Omnibus Integration Bus at the link below:

http://www.kovair.com/omnibus/index.aspx

Mfin on March 26, 2010:

You did a good job of explaining architectures but a very ordinary job of explaining how this relates to "integration". How do you apply these concepts should you have a need to integrate B2B applications?

Latest Technology Editor on June 15, 2008:

Open ESB is one of the most promising technology in enterprise software integration

Russell O'Brien (author) from Sydney on March 14, 2008:

What I forgot to mention is that all the players in the integration market will still (obviously) try to differentiate themselves. Pure players such as Cape Clear for example will say that the more traditional vendors such as Tibco still offer proprietary solutions and therefore if you buy a Tibco solution, you're "locked in" to Tibco.

The main thing for me though is not to get too caught up in the hype and jargon. And there's more to choosing a vendor than the quality of their technology ... the level of support for example.

Russell O'Brien (author) from Sydney on March 14, 2008:

To be honest there's a lot of good stuff out there Nathan. The likes of Tibco and WebMethods have been around for years, long before Web Services and Enterprise Service Bus. As soon as Web Services took hold they simply embraced them, treating Web Services as simply another message medium. In many ways the story of the Tibcos of this world just grew stronger because they also had tried and proven technologies like Rendezvous (Tibco's older proprietory middleware)and they could offer a mixture of old and new technologies, whatever fitted best.

So, all the players in the Integration world strongly support Web Services and ESB. It may not have been that way when the term Enterprise Service Bus was first used, but it certainly is today.

Nathan on March 13, 2008:

Good article. The whole Web Services / ESB thing certainly can be confusing. What do the traditional middleware vendors have to say about it all? Tibco, Webmethods and such? Who's got the best stuff?

Russell O'Brien (author) from Sydney on March 12, 2008:

Firstly, Web Services are self-contained, modular applications that can be described, published, located, and invoked over the Internet (or some other network). Web Services are important to all of this because they're based on standards that "everyone" out there has been happy to go for. It's a bit like Lego verses Macano. You can't mix and match pieces from a Lego and Macano set. It's the same in the Integration world and now everyone has accepted that Lego (or Web Services in the case of Integration) is the construction piece to be used by all.

After the birth of Web Services, the Integration market then went a step further and began developing completely new Integration platforms based on Web Services. The term Enterprise Service Bus (ESB) came from this, and organizations began using it as a development and operating platform for creating their own Service Oriented Architecture (SOA). By using an SOA, the organization could develop state-of-the-art business solutions quickly by using components that had been developed and service enabled either by themselves internally or by third parties. If better individual components show up they can be used as replacements without a major development effort.

A Service Oriented Architecture based on an ESB allows a business to become more technically agile. Using this technology, a company is able to develop better business solutions that can be upgraded quickly, and thus make the business more competitive.

It's easy to see why people getting excited about ESB. It's holy grail stuff in its way.

Hope this helps.

Karen on March 12, 2008:

Good article, but I'm still a bit confused about Web Services. Sounds like they're important and somehow fit with Enterprise Service Bus. Enlighten me please. I'd really like to understand Web Serices and ESB.

Russell O'Brien (author) from Sydney on March 08, 2008:

I think it's more a case of "In the land of the blind the one-eyed man is king". Glad to have been of assistance.

Ken Burt on March 08, 2008:

Russell, you are an expert. How do I know? Simply you explained technical points for a systems dummy & I understood. Thanks well done.

Russell O'Brien (author) from Sydney on February 29, 2008:

Always a great feeling helping people to understand. Welcome to Systems Integration.

sligobay from east of the equator on February 29, 2008:

Way beyond my experience Russell. This was my first lesson in software architecture. The diagrams and clearly written article helped to explain and demystify concepts which I previously thought to complicated to learn. These are the qualities of a good writer and an excellent teacher. Thanks for the hub.

Russell O'Brien on February 27, 2008:

True George,

There's lots of confusion out there and a lot of it pushed along by vendors who have sales to make. I'm setting up a separate page to cover off ESB and Web Services, but in short an Enterprise Service Bus or ESB is a way to create a Service Oriented Architecture (SOA) based on Web Services. It's not limited to Web Services however and may include more tradtional EAI technologies such as Message Oriented Middleware (MOM) and Java Messaging Service (JMS). On this point the purists may disagree and say that only Web Services should be involved.

Standing further back the difference between ESB and EAI / Middleware approaches is that ESB effectively sits on top as a separate layer with the different EAI technologies (Message Oriented Middleware, JMS and Web Services) underpinning and supporting it. There'll be lots of people who disagree with this view, but that for me is a very practical way of approaching it.

Russell.

George Deer on February 27, 2008:

That's a great overview, it is well written without the unnecessary jargon and hype that tends to surround and mystify integration technologies. It would be nice to have an explanation of the difference between ESB and EAI/middleware approaches as this seems to be a point of much confusion in the industry.

Russell O'Brien on February 25, 2008:

Thanks Barbara,

The diagrams are a real must when explaining architecture.

Russell.

Barbara E Simon on February 25, 2008:

That is quite a well structured site and I like the pictures linked to the explanations. Well done.