I feel much the same way and think what is being proposed for JMS is a serious mistake.
Firstly, the very narrow focus on cloud and microservices lacks balance. JMS easily deserves to be carried forward for the very, very wide base of existing customers alone that may or may not be interested in cloud or microservices.
Secondly and perhaps even more importantly, whatever these new cloud and microservices requirements are, they should be retrofitted into JMS instead of creating yet another API that has a great deal of fundamental similarities with JMS.
We should be leveraging the hard earned market, adoption and mindshare of JMS instead of trying to fight an old messaging battle completely anew with little to stand on other than being a standard API on paper.
I hate to be a cynic, but this sounds to me like a decision being driven by the antiquated JMS implementation in WebLogic that is likely too hard to evolve. Instead of starting JMS anew, maybe that implementation should be scrapped in favor of something a little more adaptable like GlassFish's OpenMQ, HornetQ or ActiveMQ.
I do hope others chime in - especially existing JMS and Java EE vendors interested in preserving their jobs and years of existing investments in good, solid products. I imagine these folks have the greatest stake in this decision.
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------From: Stephan Knitelius <stephan_at_knitelius.com> Date: 10/7/16 5:25 AM (GMT-05:00) To: Nigel Deakin <nigel.deakin_at_oracle.com>, users_at_jms-spec.java.net Subject: [jms-spec users] Re: The future of JMS 2.1 and Java EE 8
I must agree with Nigel, cloud or not messaging systems are spread widely.
I would hope that we would take the chance and extend the specification to integrate other queuing/messaging systems such as Kafka.
Kind Regards,
Stephan Knitelius
On Fri, 7 Oct 2016 at 11:19 Nigel Deakin <nigel.deakin_at_oracle.com> wrote:
On 07/10/2016 05:44, vaquar khan wrote:
> Thanks Nigel for sharing useful information.
>
> It was most awaited and positive changes in Java , i have completed oracle survey and found focus completely shift to
> micro-service architecture.
>
> Micro-service architecture required resilience and circuit breaker , when we sent any request and service down then
> observer pattern is very useful and widely used across of development world.
>
> Most of cloud have messaging services as Amazon AWS has SNS,SQS notification messaging service for pull /push ,
>
> Another point here that we are planing to give standard for Nosql database however nothing noteworthy for Bigdata
> technologies.
>
> Apache kafaka is an another example of messaging in Bigdata .
> I am still not clear reason behind to drop jsr 368 as we can add few useful feature to help cloud platform.
>
> I have following queries .
>
> 1) Project jigsaw is coming with Java 9 have you seen any impact on Jsr 368?
> 2) Are we going to dissolve Jsr 368 group ?
> 3) What would be development approach for java cloud are we going to form new Jsr or it would be internal oracle
> development?
Many thanks for your comments.
The proposal (as I understand it) is that Java EE in future should focus on "eventing" for cloud applications rather
than specifically JMS, where eventing covers other technologies (e.g. CDI 2.0 events, websockets RAX-RS) *as well as* JMS.
In his JavaOne presentation on Java EE 9 (linked from my earlier email) Rajiv Mordani specifically mentions Apache
Kafka, Amazon Kinesis and Azure Event Hub as examples of non-JMS eventing systems used in cloud applications (though I
know they also have a lot of features in common with JMS). There's also a view that the API provided by eventing systems
needs to evolve to support reactive programming, especially the new java.util.concurrent.Flow API in Java SE 9.
Exactly what happens with eventing is still undefined (but a new JSR is certainly one of the options). This is an area
where community feedback and suggestions are very much invited. By definition this is a broader topic than JMS, so the
best place to ask questions and give comments is to the Java EE user mailing list and on the Java EE survey (see my
earlier email for details of both) rather than here.
As for JSR 368 (JMS 2.1): yes, the proposal is essentially to close it down, though what happens exactly will be
determined by JCP governance.
Just to reiterate: JMS will continue to be a part of Java EE 8, using JMS 2.0 (which was released in 2013). I continue
to be the maintenance lead for JSR 343 (JMS 2.0): we had a maintenance release for that last year (2015).
I'm grateful to the contributions that everyone here made to JSR 368 whilst it was still active, especially during that
flurry of activity after JavaOne 2015, when we started having regular video calls and I felt we were beginning to get
some momentum.
Nigel