| Re: [ee4j-community] Approach to Reactive in Jakarta EE |
Werner
Send ee4j-community mailing list submissions to
ee4j-community@xxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
https://dev.eclipse.org/mailman/listinfo/ee4j- community
or, via email, send a message with subject or body 'help' to
ee4j-community-request@eclipse.org
You can reach the person managing the list at
ee4j-community-owner@eclipse.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of ee4j-community digest..."
Today's Topics:
1. Approach to Reactive in Jakarta EE (James Roper)
2. Re: Approach to Reactive in Jakarta EE (Mark Little)
3. Re: Approach to Reactive in Jakarta EE (Martijn Verburg)
------------------------------------------------------------ ----------
Message: 1
Date: Thu, 8 Mar 2018 22:08:03 +1100
From: James Roper <james@xxxxxxxxxxxxx>
To: ee4j-community@xxxxxxxxxxx
Subject: [ee4j-community] Approach to Reactive in Jakarta EE
Message-ID:
<CABY0rKOBhFq+Z4Eij_yXFU01RLU0Jj78gMOreGqa2UoG6BE8 >5A@xxxxxxxxxxxxxx
Content-Type: text/plain; charset="utf-8"
Hi all,
There are a number of different efforts in different Jakarta EE specs to
provide support for reactive features. As many of you may know, I myself
have been talking to and investigating a number of different places where
Reactive Streams could be useful in Jakarta EE, but these efforts aren't
limited to my work - JAX RS 2.1 introduces reactive features in the client,
JSR 356 WebSockets support asynchronous streaming of messages, Servlet 3.0
introduced support for asynchronous sending of responses while Servlet 3.1
introduced asynchronous streaming IO. I've also talked to some spec
implementers, such as CDI, who are interested in reactive features but
aren't sure where to start.
While it's great that this innovation is happening, there is a risk that
all these efforts, being done in isolation, will produce a platform that
doesn't integrate well with itself, and feels disjointed. For example, if
messaging uses an asynchronous streaming API that is incompatible with the
streaming offered by the WebSocket spec, then how are people meant to use
these two APIs together? If the streaming API for response bodies offered
by the JAX RS client is incompatible with the streaming API for response
bodies offered by the Servlet spec, how are people meant to use these two
APIs together?
So I'd like to propose that we start an intentional effort of formalising
an approach to reactive in Jakarta EE. What I think we should have answered
is questions like:
* When should an API use CompletionStage?
* When should an API use Reactive Streams?
* How should Reactive Streams based APIs be offered?
* When should an API introduce its own mechanism/API for handling
asynchronous data flows?
* How should CDI context be addressed when much of the business logic of an
application is moved to callbacks executed by unmanaged threads?
I don't know what such an effort would look like in practice - the product
might be a wiki page, or perhaps a document with code samples on GitHub.
Maybe a dedicated mailing list is needed, or perhaps discussion can be had
on another mailing list.
Does this resonate with anyone? It's perhaps not on front of everyones
minds right now, but it's something that needs to be addressed before mass
adoption of reactive features in Jakarta EE happens, and as there are
efforts currently in place, the sooner its addressed, the better.
Regards,
James
--
*James Roper*
*Senior Octonaut*
Lightbend <https://www.lightbend.com/> ? Build reactive apps!
Twitter: @jroper <https://twitter.com/jroper>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/ee4j- >community/attachments/ 20180308/029bf249/attachment. html
------------------------------
Message: 2
Date: Thu, 08 Mar 2018 11:23:49 +0000
From: Mark Little <mlittle@xxxxxxxxxx>
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Approach to Reactive in Jakarta EE
Message-ID:
<CAEcX1=tARq=NyDpeD=LfTBFWq-cNruL0igcZtQP_pRK0PAHH0A@mail. >gmail.com
Content-Type: text/plain; charset="utf-8"
I agree it's an important topic. Not sure about timing but I will ask the
vert.x team to give some input too.
On Thu, 8 Mar 2018 at 11:08, James Roper <james@xxxxxxxxxxxxx> wrote:
> Hi all,
>
> There are a number of different efforts in different Jakarta EE specs to
> provide support for reactive features. As many of you may know, I myself
> have been talking to and investigating a number of different places where
> Reactive Streams could be useful in Jakarta EE, but these efforts aren't
> limited to my work - JAX RS 2.1 introduces reactive features in the client,
> JSR 356 WebSockets support asynchronous streaming of messages, Servlet 3.0
> introduced support for asynchronous sending of responses while Servlet 3.1
> introduced asynchronous streaming IO. I've also talked to some spec
> implementers, such as CDI, who are interested in reactive features but
> aren't sure where to start.
>
> While it's great that this innovation is happening, there is a risk that
> all these efforts, being done in isolation, will produce a platform that
> doesn't integrate well with itself, and feels disjointed. For example, if
> messaging uses an asynchronous streaming API that is incompatible with the
> streaming offered by the WebSocket spec, then how are people meant to use
> these two APIs together? If the streaming API for response bodies offered
> by the JAX RS client is incompatible with the streaming API for response
> bodies offered by the Servlet spec, how are people meant to use these two
> APIs together?
>
> So I'd like to propose that we start an intentional effort of formalising
> an approach to reactive in Jakarta EE. What I think we should have answered
> is questions like:
> * When should an API use CompletionStage?
> * When should an API use Reactive Streams?
> * How should Reactive Streams based APIs be offered?
> * When should an API introduce its own mechanism/API for handling
> asynchronous data flows?
> * How should CDI context be addressed when much of the business logic of
> an application is moved to callbacks executed by unmanaged threads?
>
> I don't know what such an effort would look like in practice - the product
> might be a wiki page, or perhaps a document with code samples on GitHub.
> Maybe a dedicated mailing list is needed, or perhaps discussion can be had
> on another mailing list.
>
> Does this resonate with anyone? It's perhaps not on front of everyones
> minds right now, but it's something that needs to be addressed before mass
> adoption of reactive features in Jakarta EE happens, and as there are
> efforts currently in place, the sooner its addressed, the better.
>
> Regards,
>
> James
>
> --
> *James Roper*
> *Senior Octonaut*
>
> Lightbend <https://www.lightbend.com/> ? Build reactive apps!
> Twitter: @jroper <https://twitter.com/jroper>
> _______________________________________________
> ee4j-community mailing list
> ee4j-community@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/ee4j- community
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/ee4j- >community/attachments/ 20180308/1d58df95/attachment. html
------------------------------
Message: 3
Date: Thu, 08 Mar 2018 13:57:55 +0000
From: Martijn Verburg <martijnverburg@xxxxxxxxx>
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Approach to Reactive in Jakarta EE
Message-ID:
<CAP7YuARZL_GCtTgO5vVbg4gxVjgioedKGzUxPWKo >1946FpShuA@xxxxxxxxxxxxxx
Content-Type: text/plain; charset="utf-8"
Hi James,
Totally agree as well. FYI I think most folks are focussing on porting the
existing Java EE projects across, so if you don?t get a lot of immediate
discussion that?s the likely culprit ?
Cheers,
Martijn
On Thu, 8 Mar 2018 at 11:08, James Roper <james@xxxxxxxxxxxxx> wrote:
> Hi all,
>
> There are a number of different efforts in different Jakarta EE specs to
> provide support for reactive features. As many of you may know, I myself
> have been talking to and investigating a number of different places where
> Reactive Streams could be useful in Jakarta EE, but these efforts aren't
> limited to my work - JAX RS 2.1 introduces reactive features in the client,
> JSR 356 WebSockets support asynchronous streaming of messages, Servlet 3.0
> introduced support for asynchronous sending of responses while Servlet 3.1
> introduced asynchronous streaming IO. I've also talked to some spec
> implementers, such as CDI, who are interested in reactive features but
> aren't sure where to start.
>
> While it's great that this innovation is happening, there is a risk that
> all these efforts, being done in isolation, will produce a platform that
> doesn't integrate well with itself, and feels disjointed. For example, if
> messaging uses an asynchronous streaming API that is incompatible with the
> streaming offered by the WebSocket spec, then how are people meant to use
> these two APIs together? If the streaming API for response bodies offered
> by the JAX RS client is incompatible with the streaming API for response
> bodies offered by the Servlet spec, how are people meant to use these two
> APIs together?
>
> So I'd like to propose that we start an intentional effort of formalising
> an approach to reactive in Jakarta EE. What I think we should have answered
> is questions like:
> * When should an API use CompletionStage?
> * When should an API use Reactive Streams?
> * How should Reactive Streams based APIs be offered?
> * When should an API introduce its own mechanism/API for handling
> asynchronous data flows?
> * How should CDI context be addressed when much of the business logic of
> an application is moved to callbacks executed by unmanaged threads?
>
> I don't know what such an effort would look like in practice - the product
> might be a wiki page, or perhaps a document with code samples on GitHub.
> Maybe a dedicated mailing list is needed, or perhaps discussion can be had
> on another mailing list.
>
> Does this resonate with anyone? It's perhaps not on front of everyones
> minds right now, but it's something that needs to be addressed before mass
> adoption of reactive features in Jakarta EE happens, and as there are
> efforts currently in place, the sooner its addressed, the better.
>
> Regards,
>
> James
>
> --
> *James Roper*
> *Senior Octonaut*
>
> Lightbend <https://www.lightbend.com/> ? Build reactive apps!
> Twitter: @jroper <https://twitter.com/jroper>
> _______________________________________________
> ee4j-community mailing list
> ee4j-community@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/ee4j- community
>
--
Cheers, Martijn (Sent from Gmail Mobile)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/ee4j- >community/attachments/ 20180308/9c387830/attachment. html
------------------------------
_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j- community
End of ee4j-community Digest, Vol 7, Issue 20
*********************************************