-1

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 ?

Community
  • 1
  • 1
Fasco
  • 233
  • 3
  • 18

1 Answers1

1

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
Matt Pavlovich
  • 4,087
  • 1
  • 9
  • 17
  • Firstly, I did a mistake it's not a Queue but a Topic that I use. The queue is a 1-to-1 destination and Topic 1-to-Many. I understand the good pattern you are explaining to me, I'll note that. I have a question, do you think using ActiveMQ is similar to an ESB architecture? Because I'm reading the documentation of Talend ESB (I don't know if you know this tool), and I don't really see the difference with an ETL. – Fasco Aug 16 '18 at 07:27
  • Yes, publish+and+subscribe pattern (generally implemented with Topics) is a generally accepted ESB pattern. ETL is different in that it is typically a synchronous and tightly-coupled-at-runtime process (meaning, all the systems have to be online for the duration of the process). Using an ESB (or messaging broker) allows for runtime-decoupling. Additionally, ESB's differ in that future listeners of the data stream can be added without making changes to the producer or other consuming applications. Typically, with ETL, its a "push" model where adding new consumers requires a code change – Matt Pavlovich Aug 17 '18 at 17:30