Search code examples
activemq-classictalendesbmule-esbwso2-esb

Can we define my architecture as an ESB?


I have read many different definitions of ESB (enterprise service bus) and it is not clear for me.

Here is my own definition: An ESB is an architecture and not a tool that allows heterogeneous applications to communicate with each other through a BUS. The particularity of an ESB is that it can have producers and consumers. For example, a producer can send a message to a topic/queue inside the bus and three consumers who are subscribers will receive the same message, so it avoids point-to-point flows. The second particularity of the ESB is that it allows managing the security and logs in one place as everything goes inside the ESB. I've also heard about "routes" that set rules in moving a message (with Talend ESB), but I don't really see the point (if you have any examples I'm interested). And of course, Web services can be created to expose data. These services must be scalable and resistant to "Single Point of Failure".

I created an architecture and would have liked to know if it's an ESB architecture.

Architecture ESB

(I made a mistake on my draw, it's not a Queue but a Topic!)

The steps of the process above:

  • Producer: it listens the changes (update, insert, ...) in different databases and as soon as there is a change, it retrieves the data and sends it to the queue.
  • Queue: The queue contains all the messages sent by the producer and will send them to the consumers.
  • Consumers: Consumers will make the data quality and insert the new data into a database.

For me, this architecture respects ESB because activeMQ acts like a bus. He acts here as mediator. What do you think ?


Solution

  • I think you are on the right track. However, I think there is an important distinction to make sure each message flow is using different queues. It is generally a best practice to have a queue per-message type.

    The message flows can all co-exist on the same broker infrastructure, allowing you to have higher density, better utilization, and the ability to wiretap message flows in one place as needed.

    In your case:

    1. Database A -> queue://A -> Consumer A
    2. Database B -> queue://B -> Consumer B
    3. Database C -> queue://C -> Consumer C