PEtALS

Why distribution is so important in PEtALS

Integration is about distribution

Fundamentally, application to application (A2A) integration is about distribution. Indeed, applications are most of the time hosted in different data center, of at least in different "domain of responsabilities". More, this distribution aspect is obvious for B2B applications, because applications are then hosted in diferent data centers, and under the responsabilities of independent.

We think that even if this two types of integrations focus on different stakes (among security, interoperability), the common point is "distributed integration".

Distributed integration means that you can design your integration logic independantly of the deployment issues. More specifically, you can create efficient integration configuration by running some integration logic (like transformation to a common format) near applications.

Hub and Spoke architectures fail

Classical MOM and EAI solutions are designed according to an "Hub an Spoke" architecture. But even if this type of architecture can be perfectly valid for departemental integration, it does not scale to the enterprise wide, and obviously does not fit extended business integration.

Main problems encountered are both technical and organisational : From a technical point of view, the main issue is that the Hub is a SPOF (Single Point Of Failure). Thus it becomes a bottleneck and needs to be supported by costly clustred hardware architecture. In some cases, the hub and spoke architecture can't support all the data flow of the enterprise, and it may be split in several interconnected hub and spoke configurations. It becomes quickly a nightmare for management and monitoring.

From an organisational point of view, in such an architecture, the central element becomes critical in term of responsabilities. Inside the enterprise, the creation of an integration competency center, responsible for the "hub" can be a part of the solution, but it appears in many cases that "business application owners" don't delegate much responsability to the hub.

For B2B, it must be noted that the hub and spoke pattern does not fit well and that many market places fail to be really adopted. The future of B2B exchange is certainly in more direct, distributed peer to peer integration infrastructure.

By definition, an ESB is a distributed integration infrastructure

When he first described the concept of ESB, David Chappel introduced it as a distributed integration infrastructure, which leverages interoperable standards, and provides centralized view for monitoring and administration.

But when the term ESB became a buzz word, all integration solutions, including the new versions of classical EAI solutions where rebranded a ESB.

In the PEtALS team, we adopted the initial definition from the beginning of the project, because we think it brings new opportunity to create more scalable and robust solutions.

PEtALS distributed architecture is scalable and robust

The distributed architecture is at the heart of PEtALS, and the most important piece in this architecture is certainly the distributed registry.

This distributed registry, is certainly the mot important part PEtALS in term of distributed integration infrastructure. It is replicated across the "nodes" of a PEtALS configuration : in each node, the registry is authoritative for the data concerning services deployed of the node, and have a copy of the data describing services deployed in all the distant related nodes. This mecanism enables to call services that run in distant nodes. In case the distant node is unavailable, it is still possible to call its services asynchronously. When the distant node becomes available again, the service is called. If the service is not present on the node anymore, it's just an error that can be processed by any error management element.

This distributed architecture will be tested on 100 to 200 nodes.

Other caractristics are that exchanges between nodes are done directly from one peer to another. Thus, this architecture is very scalable, the same way the Internet is.

A future evolution of this type of architecture would be that some node could be used as proxy to establish a route between one node to another. Thus, the system would mimic TPC/IP and the DNS more, and surely, it would be even more scalable.