RabbitMQ and ESB

[AM]

Hello.

My company (a financial Enterprise, about 1000 employees) used to be very much batch-based. It started a pretty successful SOA initiative some years ago, and in recent times it introduced RabbitMQ for leveraging loosely coupled and asynchronous communication.

In these last weeks, it is evaluating the adoption of an ESB (Tibco or JBoss Fuse), either as a complement or a replacement of RabbitMQ.

I spent some days reading posts and comments around, and I understood this is a hot topic: some say the ESB is an old, useless dinosaur that adds little or no value to a message broker such as RabbitMQ; some claim it is the panacea and an enterprise could not live without it.

I'd love to hear from you some recommendations and your experiences. 

Thank you.

[Michael Klishin]

ESB as I understand it is just a communication pattern. RabbitMQ can be used by ESBs (I believe Mule has RabbitMQ integration)

and other approaches to inter-service communication.

So it's not an either/or proposition. If you have any specific questions, we'd be happy to answer them, otherwise it probably

comes down to what tool your team prefers/is familiar with/can obtain support for and what client libraries for your languages of choice

are available. RabbitMQ is quite good on at least the last couple of points.

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-users+unsubscribe@googlegroups.com.
To post to this group, send email to rabbitmq-users@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

MK

Staff Software Engineer, Pivotal/RabbitMQ

[Fredrik Sörensson]

Hello.

 

The definition of the term ESB is, in my humble opinion, too ambiguous to be useful.

 

I often divide integration software into layers, defined as 1. transport and routing, 2. transformation (or processing), 3. orchestration. Granted, this is mapped mostly on my experience with IBMs software stack.  :-) Even so, the borders are somewhat unclear, technical functions like routing can exist in both the first and second layer. Another aspect of the layering would be that in layer 1 we are mostly unaware of data formats, whereas in layer 2 data is parsed, transformed and otherwise processed. Layer 3 adds complex orchestration and human interaction tasks. I generally recommend strongly against layer 3.

 

The pattern called ESB covers, again in my humble opinion, the entire software stack, from transport to orchestration. So a full-stack ESB would contain several pieces of software (which all could use the term ESB somewhere in their name…)

 

Most often though, when a software is called ESB-something, it is a message transformation engine, so placed in layer 2. It can accept data, parse and process the data, and pass it on. Using these products we can implement a number of patterns, such as canonical data separation and simple orchestrations.

 

Do you need an “ESB”, in the Mule definition? As always, the answer is “maybe”. It is not a silver bullet. It is a specialized Application Server with strong service and/or messaging capabilities. It is generally programming driven rather than configuration driven (even if the programming may be graphical), so you will need developers. And you still need a solid methodology for defining your integrations.

 

But if you have systems that you need to integrate with a system without a flexible interface capability, or if you need simple orchestration between systems, an ESB may prove to be a useful tool. Use when needed. But do invest in a good design methodology and perhaps also a service registry.

 

/Fredrik

--

You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
To post to this group, send email to rabbitm...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

---

Den 1:a november byter Fritidsresor namn till TUI. Läs mer om namnbytet på www.fritidsresor.se/tui

On the 1st of November we are changing name to TUI