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
>
>
>
>
>
>
>