0

Why do we need JBoss Fuse as an integration layer? Why can't two application directly communicate in scenarios where we don't have to put message in Queue?

Mr.X
  • 21
  • 9
  • Fuse offers a variety of connectors (for JMS, FTP, REST, SOAP, File system, Social Media, etc.) This allows you to easily connect disparate applications and act as a mediator. (This lets you change the message exchange format, for example.) There are many advantages. Your code will be complete faster, with fewer lines, and better positioned for the future. Camel is the secret sauce. – RickJWagner Sep 19 '17 at 00:53
  • Thanks Rick, but i want to know when should we have a Integration layer and when not to have. – Mr.X Sep 19 '17 at 06:15
  • Hi @Mr.X, It's a matter of choice. You can always choose to write JMS producers/consumers by hand, write file pollers, etc. But these are inflexible and require lots of bespoke testing and full-logic rewrites when changes are needed. A layer like Fuse lets you encapsulate business logic in beans, the data translation and input/output are just plug-ins. So it's easy to add SOAP/REST/FTP, etc. Check out 'Camel in Action' for a great overview of the power it brings. It's truly a game-changer. – RickJWagner Sep 20 '17 at 02:09

1 Answers1

0

It's the classical raison d'etre of ESB (= Enterprise Service Bus); You can always connect two or more applications to talk directly to each other (and we used to), but you will soon reach the state of Integration Spaghetti while your systems evolve and need to talk to more and more applications. ESB was invented to solve this kind of problem by introducing itself as the central bus for the integrations. And JBoss Fuse is an ESB product.

You can read this Wikipedia article for more info:
https://en.wikipedia.org/wiki/System_integration

So you do not need to use JBoss Fuse for integrating your applications. After all, JBoss Fuse/ESB is mere one option for how to design and architect your entire applications system. But if you are concerned about or suffer from the integration spaghetti, then JBoss Fuse can always help to solve this kind of problems.

Tadayoshi Sato
  • 1,401
  • 11
  • 18
  • Thanks Tadayoshi, but lets say i have a CRM application at one end and at the other end i have a Java application. Then, In what scenarios i should be using JBoss Fuse as an Integration layer? If its just a CRM to Java webservice call should i be calling it directly or i should be having JBoss as an Integration? Because in scenarios where i need to store Webservice call as a message in Active MQ, i understand there is a need for JBoss. – Mr.X Sep 19 '17 at 06:11
  • JBoss Fuse itself doesn't require you to use ActiveMQ for message exchanges. You can also use CXF endpoints for SOAP and REST web services with JBoss Fuse. ActiveMQ may be used when you need an extra level of guarantees for message deliveries like persistent deliveries or idempotencies that are not by default available with HTTP-based web services exchanges. – Tadayoshi Sato Sep 19 '17 at 07:09
  • Future extensibility is also an important point of view. If you see no future possibilities to enhance the CRM-to-Java communications it's reasonable not to use JBoss Fuse and go for direct invocations. But if you are not sure, then JBoss Fuse can reserve the future extensibilities by introducing an additional integration layer. – Tadayoshi Sato Sep 19 '17 at 07:09
  • That was a very good explanation thanks a lot Tadayoshi! I have used CXF SOAP and REST endpoints in my project but all i wanted to know was why we do do it but now i have some insight. As you mentioned we use ActiveMQ for "extra level of guarantee for message delivery" is that the only reason or any other ?? Also in current codebas that i am working on , i could see in some scenarios 1 they are exposing CXF REST endpoint and calling Java application while in scenario 2 they are exposing CXF REST endpoint and storing message in ActiveMQ and then Read from Queue and call the Java App. – Mr.X Sep 19 '17 at 07:26
  • Can you tell me whats the difference between scenario 1 and scenario 2. And why we do it in such pattern? – Mr.X Sep 19 '17 at 07:27
  • 1
    You should ask your architect the specific question :-) but I can tell there is another benefit in ActiveMQ and messaging which some people call "temporal decoupling". With messaging a consumer and a producer doesn't need to be in sync like you call someone by phone. This allows your system some resilience and responsiveness and your architect might have chosen it for one scenario because of it. – Tadayoshi Sato Sep 20 '17 at 07:09