2

So I'll take the context of Red Hat FUSE as an example because this is what I know. I know that Apache Camel which is the library on which is based FUSE doesn't consider itself an ESB (http://camel.apache.org/is-camel-an-esb.html) but that they consider that Apache ServiceMix can be considered an ESB. But according to my research it seems that an ESB is a solution that use the enterprise integration pattern and is designed to solve problems related to integration between applications in an enterprise.

So I guess there is two questions:

  • If I use an ESB tool like Apache ServiceMix to develop a simple application which isn't in any way done to integrate applications together but is a regular REST API, is it still an ESB?

  • And if develop a solution with multiple independent applications that are doing integration tasks between multiples systems, can I still call it an ESB?

Nyamiou The Galeanthrope
  • 231
  • 1
  • 7
  • [Sharing your research helps everyone](https://softwareengineering.meta.stackexchange.com/questions/6559/why-is-research-important). Tell us what you've tried and why it didn’t meet your needs. This demonstrates that you’ve taken the time to try to help yourself, it saves us from reiterating obvious answers, and most of all it helps you get a more specific and relevant answer. Also see [ask] – gnat Oct 25 '18 at 17:02
  • 1
    I have redone the question. – Nyamiou The Galeanthrope Oct 25 '18 at 17:30

1 Answers1

2

I am not an "ESB" expert, I will try to answer by my experience.

If I use an ESB tool like Apache ServiceMix to develop a simple application which isn't in any way done to integrate applications together but is a regular REST API, is it still an ESB?

1) If it is a simple app, you could develop a "monolithic" application, although it sounds "old" fashioned.

2) If I were you and I had to interact with multiple services, in a simple way, I would try an "api-gateway" approach... api gateway link

For me, "ESB" is connected to software products (like Camel, biztalk, sap pi) and SOA. I have used these products to route and monitor messages between services, control deployments, etc.

In my opinion, if you didn't use these products, your architecture or solution is not an ESB. It could be a "distributed system", but not a ESB.

And if develop a solution with multiple independent applications that are doing integration tasks between multiples systems, can I still call it an ESB?

I think that it is a "microservice" approach maybe. ESB is more related to SOA. It depends how your multiple applications interact with each other. This image it is a good reference at least for me.

enter image description here

References:

JonathanLoscalzo
  • 96
  • 1
  • 2