Skip to main content

Understanding Hybrid Integration Platforms

Based on the research done by researchandmarkets.com, market cap for Hybrid Integration Platforms (HIP) will grow from 17.14B in 2017 to 33.60B in 2022. This shows the importance of the Hybrid Integration Platforms and their relevance to the enterprises. First of all, it is essential to understand the concept. The term “Hybrid” means a combination of more than one entities (most of the time 2). I drive a hybrid Toyota vehicle which runs on electricity (battery) as well as fuel (petrol). In the world of integration, hybrid means integrating systems which resides on

  • On premise and
  • Cloud


When it comes to “on-premise” systems, they can be running on physical hardware, virtual machines, containers or in a virtual private cloud. The meaning of an on-premise system in the world of integration is that user has the control over application maintenance.

“Cloud” systems means the systems which are running on public cloud which runs on vendors own data centers (or public Iaas cloud such as EC2, Azure or GCloud) and fully managed by the vendor. Sometimes users may get some admin privileges, but it is most of the time the vendor who does the maintenance of the system.

The term Hybrid Integration Platform means a platform which can interconnct both on-premise and cloud based systems. Even though we differentiate the systems based on their installed location and the maintenance capabilities, all the systems communicate with the integration platform using 2 main principals.

  • Communication (Transport) protocol (e.g. HTTP, JMS, TCP, IDOC, etc.)
  • Content Type (message format) (e.g. XML, JSON, Binary, Text, etc.)

From the Integration Platform’s perspective, what it matters is to understand the transport protocol and the message formats. In most of the well known integration platforms, these are handled through

  • Protocol Connectors - to deal with communication protocols (HTTP, JMS, TCP, etc)
  • Message Builder/Formatter - to deal with message formats (XML, JSON, Binary, etc)

With the usage of above mentioned 2 components, Integration Platform can interface with any system and integrate with other systems using a canonical internal message representation (or not). Some platforms keeps a canonical representation while others do the transformations as and when necessary.

On top of these standard protocol connectors, some integration platforms has build specific connectors for cloud APIs like Salesforce, Twitter, Gmail, Facebook, etc. so that integration with those systems are abstracted and make it easier for the developers. These Cloud Connectors are one of the key factors when selecting a proper Hybrid Integration Platform. Some vendors offer these connectors for free while other offer these connectors at a cost.

Another important aspect of a HIP is the ability to extend their core functionalities through simple and well defined interfaces. When it comes to integration, there can be so many on-premise systems which has been written with proprietary standards (especially Commercial Off The Shelf (COTS) systems) and it is really important that HIP can extend its capabilities and deal with this kind of systems.


Another aspect of a HIP is the deployment flexibility. The platform must be able to deploy on premise as well as cloud. It would also be a value addition if that is available as a public cloud offerring.


If a particular Integration Platform or a product offers the above mentioned capabilities, we can consider that as a good candidate for your Hybrid Integration Platform requirement.

On top of these technical capabilities, another key factor in identifying a good HIP is the user experience when it comes to integrate multiple systems. The concept of Citizen Integrtor has become a key factor in selecting a good HIP. The term Citizen Integrator has many different meanings. But the high level idea is that a person who understands the business value of systems and their interconnections will become a citizen integrator if he is willing to learn about usage of the technology without going detail into writing code. Due to this factor, most of the vendors are building visual tools to help Citizen Integrators to easily achieve their targets without worrying about writing code.

In addition to the above mentioned capabilities, having following features would add icing on the cake.

  • Analytics capabilities
  • API management capabilities
  • Identity and Access Management capabilities

Given below are some of the leaders in this space
  • Software AG (Darmstadt, Germany)
  • Informatica (California, US)
  • Dell Boomi (Pennsylvania, US)
  • MuleSoft (California, US)
  • IBM (New York, US)
  • TIBCO Software (California, US)
  • Oracle (California, US)
  • Liaison Technologies (Georgia, US)
  • WSO2 (California, US)
  • SnapLogic (California, US)
  • Red Hat (North Carolina, US)
  • Axway (Puteaux, France)
  • SEEBURGER (Bretten, Germany)
  • Microsoft (Washington, US)

Comments

  1. Thanks for sharing like this content. I really appreciate sharing your post. and also you can go through this site and read the interesting thing Top Hybrid Integration Companies

    ReplyDelete
  2. Thanks for this amazing post. I really feel that Informatica is the leader in the integration space. Informatica Read Json

    ReplyDelete

Post a Comment

Popular posts from this blog

WSO2 ESB tuning performance with threads

I have written several blog posts explaining the internal behavior of the ESB and the threads created inside ESB. With this post, I am talking about the effect of threads in the WSO2 ESB and how to tune up threads for optimal performance. You can refer [1] and [2] to understand the threads created within the ESB. [1] http://soatutorials.blogspot.com/2015/05/understanding-threads-created-in-wso2.html [2] http://wso2.com/library/articles/2012/03/importance-performance-wso2-esb-handles-nonobvious/ Within this blog post, I am discussing about the "worker threads" which are used for processing the data within the WSO2 ESB. There are 2 types of worker threads created when you start sending the requests to the server 1) Server Worker/Client Worker Threads 2) Mediator Worker (Synapse-Worker) Threads Server Worker/Client Worker Threads These set of threads will be used to process all the requests/responses coming to the ESB server. ServerWorker Threads will be used to pr

How puppet works in your IT infrstructure

What is Puppet? Puppet is IT automation software that helps system administrators manage infrastructure throughout its lifecycle, from provisioning and configuration to orchestration and reporting. Using Puppet, you can easily automate repetitive tasks, quickly deploy critical applications, and proactively manage change, scaling from 10s of servers to 1000s, on-premise or in the cloud. How the puppet works? It works like this..Puppet agent is a daemon that runs on all the client servers(the servers where you require some configuration, or the servers which are going to be managed using puppet.) All the clients which are to be managed will have puppet agent installed on them, and are called nodes in puppet. Puppet Master: This machine contains all the configuration for different hosts. Puppet master will run as a daemon on this master server. Puppet Agent: This is the daemon that will run on all the servers, which are to be managed using p

How to configure timeouts in WSO2 ESB to get rid of client timeout errors

WSO2 ESB has defined some configuration parameters which controls the timeout of a particular request which is going out of ESB. In a particular  scneario, your client sends a request to ESB, and then ESB sends a request to another endpoint to serve the request. CLIENT->WSO2 ESB->BACKEND The reason for clients getting timeout is that ESB timeout is larger than client's timeout. This can be solved by either increasing the timeout at client side or by decreasing the timeout in ESB side. In any of the case, you can control the timeout in ESB using the below properties. 1) Global timeout defined in synapse.properties (ESB_HOME\repository\conf\) file. This will decide the maximum time that a callback is waiting in the ESB for a response for a particular request. If ESB does not get any response from Back End, it will drop the message and clears out the call back. This is a global level parameter which affects all the endpoints configured in ESB. synapse.global_timeout_inte