CODEWITHSUNDEEP
restesbsoamessagebrokerenterprise-integration
lapesunto59
lapesunto59

Reputation: 93

REST API vs Enterprise service bus to integrate several services (amount of 3-5 services)

I need to integrate 3-5 existing and ready services that are developed by different teams. That is something like integrating several independent monolithic applications.

The very wanted feature is having a central communication component where all requests can be logged (or partially logged in case they have a big payload) so that it can be quickly seen what service sent a request with what payload and when if something goes wrong.

The second task is security. It is needed to protect inter-service communication.

I have been researching this topic for several days. That is what I've come up with so far:

  1. Use Enterprise Service Bus (ESB)
  2. Use MessageBroker (ActiveMQ, RabbitMQ, Kafka, etc)
  3. Simply use REST API communication

I've read about ESB and I am not sure whether this solution is OK to use.

The picture from Wikipedia shows the following:

enter image description here

The problem with ESB that it not only implements communication between separate independent services. It also changes the communication itself from synchronous request-response model to an asynchronous messaging style. Currently, we don't need asynchronous messaging (maybe we will in the future, but not right now).

ESB allows to make request-response communication, but in a very inconvenient and complex way with generating correlation IDs, creating a temporary response-topic and consumer. With this, I have doubts whether it has more advantages to use ESB with its super complex Request-Response messaging style or simply use plain old REST API calls (RPC). However, with REST API it is not possible to have a centralized component that can log all communication between services. A similar problem exists with Message Broker too (because it also involves asynchronous messaging).

Is there any ready solution/pattern to integrate several services (not microservices) with centralized logging, security configuration and having simple to implement synchronous request-response model (with a possibility to add messaging, if needed, later)?

Upvotes: 0

Views: 1661

Answers (1)

Arnon Rotem-Gal-Oz
Arnon Rotem-Gal-Oz

Reputation: 25909

Make your services talk to each other via a proxy that will take care of these concerns (Back in 2007 I called this "edge-component" but the today it known as sidecar pattern)

A common way to do that would be to containerize your services, deploy to Kubernetes and use a service mesh (like Console's or istio, etc)

Upvotes: 0

Related Questions