[
Date Prev][
Date Next][
Thread Prev][Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakarta.ee-spec] Defining Jakarta EE 12 Scope in Program Plan: JMS
|
I will readily admit I don't know as much about Kafka but I do
know the Messaging specification and implementations quite well. I
did speak internally with folks that work on the Microsoft
messaging products including Service Bus and Event Hubs. Should we
see tangible signs that Jakarta Messaging still has enough active
stakeholders to move forward, these teams will be in a position to
directly contribute.
What they told me is that Messaging in it's current form cannot
be bridged to Kafka easily. However, a modernized and streamlined
Jakarta Messaging Lite could indeed act as a bridge to Kafka
(personally I suspect anyone that can write a bridge like this
will quickly have a very successful project on their hands). The
situation is much the same for something like Azure Event Hubs.
It's more possible to support JMS via something like Azure Service
Bus (which is a much older product line than Azure Event Hubs and
Kafka - with similar ethos to the Java EE/J2EE era JMS).
On 10/30/2024 2:17 PM, Kito Mann wrote:
Why does modernizing
Messaging matter?
JMS has been one of the key
specifications in Java EE. It was virtually synonymous with
messaging in Java for a long time. ... In past years, Kafka
has largely
replaced JMS
for Cloud Native messaging. ... Messaging must be urgently
modernized to address these problems.
I've been wondering about this for quite some time. Is it
possible to extend JMS so that it works for Kafka and perhaps
cloud message services? That would make it very relevant
again. It looks like Spring Messaging handles Kafka.