flozano
Moderator
Moderator
  • 991 Views

Red Hat middeware in a non-Java EE world

Red Hat middleware products used to focus on the Java and Java EE world, but the world of microservices praises selecting the 'righ tool' over standardization, and teams are supposed to use different programming languages and runtimes.

Do you think Red Hat middleware, such as AMQ, Decision Server, Fuse, and Data Grid are still relevant in this brave new world? Do you have any resources to share about using Red Hat middleware with non-Java EE frameworks, such as Vert.x, and non-JVM programming languages, such as Python and Node.js?

Tags (4)
0 Kudos
3 Replies
RuGI
Mission Specialist
Mission Specialist
  • 980 Views

Re: Red Hat middeware in a non-Java EE world

Of course, they will continue to be relevant, with microservices we are just beginning to choose the main deployment patterns, the new deployment forms and even how to monitor better.

For example, Fuse has a long way to go and will surely be a guide.
In the case of AMQP, its characteristics continue to be far ahead of other solutions.
Adapting what already exists to this new brave world is the challenge.

"Aurum nostrom non est aurum vulgo"
Reply
Loading...
flozano
Moderator
Moderator
  • 934 Views

Re: Red Hat middeware in a non-Java EE world

The Red Hat Developer blog has an article about using AMQ with Vert.x:
https://developers.redhat.com/blog/2018/08/30/microservices-async-communications-amqp-vertx/

Note that his post uses the AMQ internconnect server (also known as router) not the broker. but communication uses the AMQ protocol and so the same programming concepts and code should work with the AMQ Broker.

0 Kudos
Reply
Loading...
oldbenko
Moderator
Moderator
  • 864 Views

Re: Red Hat middeware in a non-Java EE world

I fully agree with @RuGI - the Java EE market is worth billions, the platform is amazing at what it does, and neither are going away soon, if at all.

As far as adopting it for the microservices paradigm goes - I think Thorntail (what was known as Wildfly Swarm) is a wonderful start, and it just gets better - Jakarta EE is a perfect example of the community taking things into its own hands when the official processes have proven to be too rusty and impotent to respond (and the stewards of those processes being negligent, we all know who I'm talking about here Smiley Wink).

Just one note, @flozano - mind that that the one thing AMQ Interconnect doesn't have is support for JMS. It is simply a wire-protocol proxy, and as such has no notion of durability and transactions that the JMS standard prescribes. I think persistence and transactions are rather important concepts in messaging.

Since AMQP is just a wire protocol, it doesn't address the behaviour of clients. It doesn't define the concept of producers and consumers, it doesn't even distinguish between a JMS client and a JMS broker, much less address destination behaviour (in terms of what happens once a message is delivered). So naturally, it can't distinguish between such client functions. In consequence, this requires client APIs that simulate JMS using AMQP to use various "hacks" to implement behaviour like delivery acknowledgements, transaction boundaries, request-response, etc.

In other words, you could say JMS is layer 7, and AMQP is layer 3/4 on the OSI model.

A black cat crossing the street signifies that the animal is going somewhere.
[don't forget to kudo a helpful post or mark it as a solution!]
0 Kudos
Reply
Loading...
Join the discussion
You must log in to join this conversation.