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