John/all,
Those are valid points. CDI eventing was also described as "inside a single
JVM or container" in Oracle's presentation on Java EE 9, so it's not really
a full successor or equivalent to JMS.
However, often running on mainframe servers (I helped bridge those with
Java EE and a "microservice" approach on a few occasions) it can be seen as
"legacy" somewhat similar to e.g. CORBA which Java EE also declared
optional in recent versions.
John's last argument of restrictive licensing and TCK license costs is of
course absolutely the same for the 2 major "competitors" JAX-RS and
Websockets.
Each of these JSRs has an identical TCK license to JMS and license costs of
35k US$ per year, so if a product uses any of them it'll have to pay at
least the same amount for the TCK.
It's exactly the same for all the other Oracle led JSRs including e.g. 375.
Werner
On Sun, Oct 9, 2016 at 3:13 AM, <users-request_at_jms-spec.java.net> wrote:
> Table of contents:
>
> 1. [jms-spec users] Re: The future of JMS 2.1 and Java EE 8 - arjan tijms <
> arjan.tijms_at_gmail.com>
> 2. [jms-spec users] Re: The future of JMS 2.1 and Java EE 8 - "John D.
> Ament" <john.d.ament_at_gmail.com>
>
>
>
> ---------- Forwarded message ----------
> From: arjan tijms <arjan.tijms_at_gmail.com>
> To: users_at_jms-spec.java.net
> Cc:
> Date: Sat, 8 Oct 2016 15:01:59 +0200
> Subject: [jms-spec users] Re: The future of JMS 2.1 and Java EE 8
> Hi,
>
> Quite surprised that JMS is deemed not cloud worthy. If anything messaging
> is IMHO at the heart of loosely coupled services in the cloud.
>
> Things like pushing out configuration changes (that needs to be picked up
> by all nodes of a certain type) or at the other end of the spectrum
> messages about job handling (that can be picked up by any node, but one and
> only only) are very naturally handled by a messaging system.
>
> A few years back I architected a system in the cloud that made heavy use
> of this. The term microservices wasn't invented yet, and I don't know if it
> would be called microservices now, but certainly miniservices would apply.
>
> CDI eventing is hardly a replacement; it serves the completely different
> use case of mainly alerting in-thread event listeners, and only with CDI
> 2.0 is there some notion of multi-threading (async events). That however is
> far removed from server to server messaging (with or without message
> bridges), QA, transactional messaging and one and only one guarantees.
>
> REST in this scenario is more like a low level mechanism. You can use it
> to communicate with well known nodes, but it's not a natural fit to
> communicate to a very loosely coupled unknown number of nodes.
>
> Just my 2 cents
>
> Kind regards,
> Arjan Tijms
>
> On Wed, Oct 5, 2016 at 10:47 AM, Nigel Deakin <nigel.deakin_at_oracle.com>
> wrote:
>
>> As everyone will know, several Oracle-led JSRs (including JMS 2.1) have
>> made little progress this year due to the spec leads being diverted partly
>> or wholly to work on other things.
>>
>> At JavaOne last month Linda DeMichel, Java EE joint spec lead, gave an
>> update on progress and plans for Java EE 8.
>> You can watch the whole presentation online here:
>> https://www.youtube.com/watch?v=Th9faGLhQoM
>> or you can simply review the slides here:
>> https://java.net/downloads/javaee-spec/JavaEE8Update.pdf
>>
>> Linda's presentation proposes a shift in focus for Java EE, to reflect
>> recent developments in the industry, which she summarised as a "focus on
>> deployment into the cloud", a "focus on microservices", and an "emphasis on
>> more rapid evolution of applications".
>>
>> In order to address these changes, and modernise Java EE 8 for "cloud and
>> microservices", she proposed a two-fold approach:
>>
>> * Adjust the plan for Java EE 8
>> * Create a plan for, and start work on, Java EE 9
>>
>> Java EE 8 and JMS 2.1
>> ---------------------
>>
>> Linda confirmed the plan to complete Java EE 8 in 2017 as originally
>> proposed, but with a number of changes to its content. These are listed in
>> slides 27 and 28 of her slide deck.
>>
>> The Java EE 8 JSR and most of its constituent JSRs would continue as
>> originally planned. She proposed that two new constituent JSRs be added,
>> for health checking and for configuration.
>>
>> And she proposed to drop three of the existing constituent JSRs: MVC 1.0
>> (JSR 371), Management 2.0 (JSR 373) ... and JMS 2.1 (JSR 368).
>>
>> The reason for dropping JMS 2.1 was that JMS was "no longer very relevant
>> in cloud". JMS would continue to be part of Java EE 8, but at its current
>> version JMS 2.0 rather than at a new version JMS 2.1.
>>
>> Java EE 9
>> ---------
>>
>> Linda went on to propose a plan for Java EE 9, which would focus more
>> directly on the new requirements, with work running in parallel with Java
>> EE 8 and with a release date of 2019. Please see Linda's slides for more
>> details, and if you'd like to find out more about Java EE 9 I would
>> recommend watching a couple of JavaOne presentations:
>>
>> Rajiv Mordani, Josh Dorr, Dhiraj Mutreja -- Enterprise Java for the Cloud
>> https://www.youtube.com/watch?v=t7miysQP7Dg
>> Josh Dorr, Joe Di Pol, Rajiv Mordani -- Portable Cloud Applications with
>> Java EE
>> https://www.youtube.com/watch?v=nCqVSf5v37s
>> There are two presentations because there was too much material to fit
>> into a single presentation. They include some proposals for a new
>> "eventing" JSR in Java EE 9 which I suspect will be of particular interest.
>>
>> Your views
>> ----------
>>
>> Your views on all of these proposals are invited.
>>
>> You can make comments on proposal to drop JMS 2.1 from Java EE 8 here (
>> users_at_jms-spec.java.net) or you can reach a wider audience by sending
>> them to the Java EE users mailing list (users_at_javaee-spec.java.net). You
>> can sign up to the latter at https://java.net/projects/javaee-spec/lists
>>
>> Comments on the proposals for Java EE 9 (including the "eventing"
>> proposals) should be made to the Java EE users mailing list.
>>
>> In addition, the Java EE spec leads have launched a new Java EE community
>> survey. Please do take part and give your views on the future of Java EE.
>> This is at http://glassfish.org/survey . The survey closes on 21 Oct
>> 2016. This will be followed by a second survey that allows people to
>> prioritise the top items from the first survey.
>>
>>
>> Nigel
>> (JMS 2.1 spec lead)
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
> ---------- Forwarded message ----------
> From: "John D. Ament" <john.d.ament_at_gmail.com>
> To: users_at_jms-spec.java.net
> Cc:
> Date: Sat, 08 Oct 2016 15:05:55 +0000
> Subject: [jms-spec users] Re: The future of JMS 2.1 and Java EE 8
> I agree with Arjan's sentiments here. In my opinion, some of the terms
> and phrasing used thus far have been contradictory to the outward goals.
>
> I will say, there are some aspects of what has been put under the JMS
> umbrella that don't make much sense, in a cloud world.
>
> - Transactions
> - Embedded Brokers
>
> Looking at JMS as purely a client API, it makes a lot of sense for that to
> be agnostic. Suppose I'm using SQS, SNS, IronMQ out in my environment. It
> would give me much greater flexibility in switching between those if I'm
> using a standard client (the whole point of Java EE) than implementing a
> custom client. I suspect the two blocking issues:
>
> - There's no way to instantiate a connection factory in an app.
> - Vendor licensing/TCK costs
>
> Just my 0.02.
>
> John
>
> On Sat, Oct 8, 2016 at 9:02 AM arjan tijms <arjan.tijms_at_gmail.com> wrote:
>
>> Hi,
>>
>> Quite surprised that JMS is deemed not cloud worthy. If anything
>> messaging is IMHO at the heart of loosely coupled services in the cloud.
>>
>> Things like pushing out configuration changes (that needs to be picked up
>> by all nodes of a certain type) or at the other end of the spectrum
>> messages about job handling (that can be picked up by any node, but one and
>> only only) are very naturally handled by a messaging system.
>>
>> A few years back I architected a system in the cloud that made heavy use
>> of this. The term microservices wasn't invented yet, and I don't know if it
>> would be called microservices now, but certainly miniservices would apply.
>>
>> CDI eventing is hardly a replacement; it serves the completely different
>> use case of mainly alerting in-thread event listeners, and only with CDI
>> 2.0 is there some notion of multi-threading (async events). That however is
>> far removed from server to server messaging (with or without message
>> bridges), QA, transactional messaging and one and only one guarantees.
>>
>> REST in this scenario is more like a low level mechanism. You can use it
>> to communicate with well known nodes, but it's not a natural fit to
>> communicate to a very loosely coupled unknown number of nodes.
>>
>> Just my 2 cents
>>
>> Kind regards,
>> Arjan Tijms
>>
>> On Wed, Oct 5, 2016 at 10:47 AM, Nigel Deakin <nigel.deakin_at_oracle.com>
>> wrote:
>>
>> As everyone will know, several Oracle-led JSRs (including JMS 2.1) have
>> made little progress this year due to the spec leads being diverted partly
>> or wholly to work on other things.
>>
>>
>>
>> At JavaOne last month Linda DeMichel, Java EE joint spec lead, gave an
>> update on progress and plans for Java EE 8.
>>
>> You can watch the whole presentation online here:
>>
>> https://www.youtube.com/watch?v=Th9faGLhQoM
>>
>> or you can simply review the slides here:
>>
>> https://java.net/downloads/javaee-spec/JavaEE8Update.pdf
>>
>>
>>
>> Linda's presentation proposes a shift in focus for Java EE, to reflect
>> recent developments in the industry, which she summarised as a "focus on
>> deployment into the cloud", a "focus on microservices", and an "emphasis on
>> more rapid evolution of applications".
>>
>>
>>
>> In order to address these changes, and modernise Java EE 8 for "cloud and
>> microservices", she proposed a two-fold approach:
>>
>>
>>
>> * Adjust the plan for Java EE 8
>>
>> * Create a plan for, and start work on, Java EE 9
>>
>>
>>
>> Java EE 8 and JMS 2.1
>>
>> ---------------------
>>
>>
>>
>> Linda confirmed the plan to complete Java EE 8 in 2017 as originally
>> proposed, but with a number of changes to its content. These are listed in
>> slides 27 and 28 of her slide deck.
>>
>>
>>
>> The Java EE 8 JSR and most of its constituent JSRs would continue as
>> originally planned. She proposed that two new constituent JSRs be added,
>> for health checking and for configuration.
>>
>>
>>
>> And she proposed to drop three of the existing constituent JSRs: MVC 1.0
>> (JSR 371), Management 2.0 (JSR 373) ... and JMS 2.1 (JSR 368).
>>
>>
>>
>> The reason for dropping JMS 2.1 was that JMS was "no longer very relevant
>> in cloud". JMS would continue to be part of Java EE 8, but at its current
>> version JMS 2.0 rather than at a new version JMS 2.1.
>>
>>
>>
>> Java EE 9
>>
>> ---------
>>
>>
>>
>> Linda went on to propose a plan for Java EE 9, which would focus more
>> directly on the new requirements, with work running in parallel with Java
>> EE 8 and with a release date of 2019. Please see Linda's slides for more
>> details, and if you'd like to find out more about Java EE 9 I would
>> recommend watching a couple of JavaOne presentations:
>>
>>
>>
>> Rajiv Mordani, Josh Dorr, Dhiraj Mutreja -- Enterprise Java for the Cloud
>>
>> https://www.youtube.com/watch?v=t7miysQP7Dg
>>
>> Josh Dorr, Joe Di Pol, Rajiv Mordani -- Portable Cloud Applications with
>> Java EE
>>
>> https://www.youtube.com/watch?v=nCqVSf5v37s
>>
>> There are two presentations because there was too much material to fit
>> into a single presentation. They include some proposals for a new
>> "eventing" JSR in Java EE 9 which I suspect will be of particular interest.
>>
>>
>>
>> Your views
>>
>> ----------
>>
>>
>>
>> Your views on all of these proposals are invited.
>>
>>
>>
>> You can make comments on proposal to drop JMS 2.1 from Java EE 8 here (
>> users_at_jms-spec.java.net) or you can reach a wider audience by sending
>> them to the Java EE users mailing list (users_at_javaee-spec.java.net). You
>> can sign up to the latter at https://java.net/projects/javaee-spec/lists
>>
>>
>>
>> Comments on the proposals for Java EE 9 (including the "eventing"
>> proposals) should be made to the Java EE users mailing list.
>>
>>
>>
>> In addition, the Java EE spec leads have launched a new Java EE community
>> survey. Please do take part and give your views on the future of Java EE.
>> This is at http://glassfish.org/survey . The survey closes on 21 Oct
>> 2016. This will be followed by a second survey that allows people to
>> prioritise the top items from the first survey.
>>
>>
>>
>>
>>
>> Nigel
>>
>> (JMS 2.1 spec lead)
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
> End of digest for list users_at_jms-spec.java.net - Sun, 09 Oct 2016
>
>