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