Let me start with the background of integration & need of enterprise service bus which emerged from a concept called interoperability.

What is interoperability?

Interoperability is the ability of an enterprise and its architecture domains i.e., business, data, applications and technology to share information and services, and seamlessly communicate with other architecture domains. We can achieve this through the standardization and adoption of common systems, standards and data exchange protocols.

Why interoperate?

A connected business requires strategic collaboration and coordination with data & services. Exchange of data and services enable them with many new capabilities and deliver significant business value to their customers.

Interoperability architecture viewpoints

Interoperability architecture established in terms of establishing and identifying design architectures that used as the foundational blueprint for establishing collaboration between organizations or providing a reference guideline for solution architects to implement solutions. Interoperable architecture viewpoints established with different viewpoints depending on:

Architecture viewpoint for an enterprise architect

As a part of the enterprise architecture design and the development of an organizational blueprint, it is necessary that the blueprint considers inter and intra organization transactions and establishes a mechanism to facilitate smooth and seamless exchange of information between the two entities. Establishing interoperability demands focus on identification of the transactions or business processes inter-linked or dependent on other organizations, review of the information systems required or available around the data exchange requirements and the supporting technology for the same.

The architecture domain viewpoints entail focus on the core architecture dimensions of enterprise architecture including:

• Business
• Information systems (data and applications)
• Technology

Implementation viewpoint for a solution architect

In this context, it is essential to understand the two terminologies — interoperability and integration at the beginning. While interoperable looks at a broader spectrum of compatibility of two disparate and distinct systems, integration is a sub-component of interoperability as explained below

Enterprise Service Bus

In simple term, Enterprise Service Bus (ESB) is a flexible connectivity infrastructure for integrating applications and services.

An Enterprise Service Bus performs the following:

• Matches and routes communication between services (Routing, Mediation & Transformation)
• Converts between different transport protocols
• Transforms message formats between requestor and service
• Identifies and distributes business events from disparate sources
• An Enterprise Service Bus is based on open standards (Work of principal Connecting Anything to Anything)

At the heart of the Enterprise Service Bus architecture — is the enterprise services bus, a collection of middleware services that provides integration capabilities. The bus provides the medium for messages (In Message Broker architecture) to reach their destinations.

Enterprise Service Bus provided services are themselves distributed in the sense that different components come and play their role in providing the infrastructure services promised by the Enterprise Service Bus.

In short, ESB is a centralized middleware, which replaces complex point-to-point communication and provides flexible & highly scalable solution to integrate with multiple heterogeneous systems/applications.

API Gateway

API Manager is a solution for designing and publishing APIs, creating & managing API documentation. API manager is also known as API gateway, which is, used as an entry point for all your enterprise APIs so you can monitor, secure & transform them as per the need. These use case is more relevant for microservices architecture.

API Manager perform following

• Design and Prototype APIs
• Publish and Govern API Use
• Control Access and Enforce Security
• Create a Store of all Available APIs
• Manage Developer Community
• Manage API Traffic
• Monitor API Usage and Performance

Fundamentals of Microservices Architecture

When service-oriented architecture & REST has proven their solutions and widely accepted for system-to-system communications as compared to legacy technologies like EJB, distributed computing concept has been extended for service-to-service communications that emerged as Microservice architecture.

Microservices is an architecture style that designs an application as collections of services based on functions or any other logical unit. The aim is to breakdown services from not only functions/logical unit perspective but also consider maintainability & deployment strategy that can benefit the OSGi concept.

Let me share an architecture of Microservices, I have implemented recently. We have separated core data & business functions into respective microservices.

While developing Microservices has become very easy with the frameworks like spring boot, cross-cutting concerns like security, data validation, logging, caching, monitoring, etc. also made available as a pluggable component. So ideally, you do not want to bother about these cross-cutting concerns while developing your services rather you want to focus on your business logic.

Now if we observed the need in Microservices we do not see the scope of any to any connectivity (which is a concept of ESB). All cross-cutting concerns fulfilled by API Manager/Gateway if you refer features as described before. However, another driving principle that is not present in the architecture above is “third party integrations”. Therefore, if you see features of ESB and understand the need for third-party integrations, it is worth implementing along with Microservices.

The Mobile-first approach (due to the explosion in mobile device adoption), has forced most of the applications to expose their services over HTTP as REST by default irrespective of the technology you are using for development which has limited the scope for ESB.

Most of the ESB products come with build-in API gateway feature and I have seen examples where ESB is being implemented but actually utilizing API gateway features. We should avoid and assess well before buying ESB. We should pay only for what you use

Conclusion

Recent market demand and trends have unified the approach of service interoperability, which has limited the need for any to any connectivity ( Enterprise Service Bus ). API Gateway makes more sense to implement with Microservice architecture. However, the API Manager is not a replacement for an ESB.

For more information refer – API friends and explore more on Teknonauts

Awadhesh Pratap Dwivedi

Awadhesh Pratap Dwivedi is an IT industry leader with over 13+ years of experience. He is excellent at providing an easy solution to complex business problems with his tremendous problem-solving skills. Currently, he is working with Oracle as a Principal Solution Engineer.

teknonauts.com/