I am very much in agreement with Reza, Nigel, and the others. While JMS
may not be specifically geared towards cloud and/or microservice
architectures, it is still an essential specification for the hundreds, if
not thousands, of organizations that will still be planning to move forward
with the traditional Java EE architecture.
Although Oracle's proposal does lack balance in this area, as JCP and
community members, we should voice our opinions and help to steer the
direction so that this important specification continues to evolve.
I also agree that it is important to utilize the investment that has
already been made in successful APIs such as JMS, and evolve them to suit
the needs of more modern architectures. Throwing everything away and
starting from scratch is not necessarily the best plan in all scenarios.
Josh Juneau
juneau001_at_gmail.com
http://jj-blogger.blogspot.com
https://www.apress.com/index.php/author/author/view/id/1866
On Fri, Oct 7, 2016 at 7:15 AM, reza_rahman <reza_rahman_at_lycos.com> wrote:
> 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
>>
>>
>>
>>
>>
>>
>>