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

Point-to-Point Integration
Point-to-Point Integration

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

Centralized Integration Processing Hub
Centralized Integration Processing Hub

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.

Distributed Integration Architecture

Distributed Integration Processing Agents
Distributed Integration Processing Agents

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)

Applications comprised of loosely bound Web Services
Applications comprised of loosely bound Web Services

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.

More by this Author

  • Online Payment Basics
    3

    When did payments via the Internet first begin? The Internet has been used as a vehicle for the payment of goods and services online since the mid 1980s, but only really took off in the 1990s when more online...

  • Systems Integration Explained
    2

    An explanation of Systems Integration for IT managers and software developers who would like to have a simple overview of Systems Integration and not get lost in technical jargon.

  • Returns and Chargebacks Explained
    4

    It’s important to understand the relationship between returns and chargebacks. Both are ways for customers to get their money back, but the processes involved are very different. What Exactly are Returns and...


Comments 26 comments

Barbara E Simon 8 years ago

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


Russell O'Brien 8 years ago

Thanks Barbara,

The diagrams are a real must when explaining architecture.

Russell.


George Deer 8 years ago

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 8 years ago

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.


sligobay profile image

sligobay 8 years ago from east of the equator

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 profile image

Russell O'Brien 8 years ago from Sydney Author

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


Ken Burt 8 years ago

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 profile image

Russell O'Brien 8 years ago from Sydney Author

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.


Karen 8 years ago

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 profile image

Russell O'Brien 8 years ago from Sydney Author

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.


Nathan 8 years ago

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 profile image

Russell O'Brien 8 years ago from Sydney Author

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.


Russell O'Brien profile image

Russell O'Brien 8 years ago from Sydney Author

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.


Latest Technology Editor 8 years ago

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


Mfin 6 years ago

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?


Patty Brown 5 years ago

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

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


James 5 years ago

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


Russell O'Brien profile image

Russell O'Brien 5 years ago from Sydney Author

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


Aleks 4 years ago

Like your article, very informative, congratulation!!!


Max Ndaba 4 years ago

Good article indeed, it cleared all confusion I had


Hari Haran Arulmozhi 4 years ago

Very helpful.. Thanks.


Naveen 3 years ago

Hi Russell, This is very informative, Thanks.

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


sridevi 3 years ago

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


Anadirunika 3 years ago

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


sournetriowet 3 years ago

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


Mylindaminka 3 years ago

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

    Sign in or sign up and post using a HubPages Network account.

    0 of 8192 characters used
    Post Comment

    No HTML is allowed in comments, but URLs will be hyperlinked. Comments are not for promoting your articles or other sites.


    Click to Rate This Article
    working