[Architecture] Deprecation of Reactive Streams Operators

[Ken Finnigan]

All,

In today's Architecture Board meeting we discussed an issue that was raised around deprecating Reactive Streams Operators specification from MicroProfile [1].

For those that were able to make the call, we all see benefit in the Reactive Streams Operators specification being a part of MicroProfile, and being used as a basis for a Reactive programming model within other MicroProfile specifications.

However, as those on the call don't represent the entire MicroProfile community we wanted to bring the discussion to a wider audience before determining a resolution.

Thanks

Ken

[1] - https://github.com/eclipse/microprofile/issues/57

[Kevin Sutter]

This is an interesting discussion...  The Issue raised seems to be a single conversation between Romain and James.  And, to the best of my knowledge, Romain is not even a committer on the MicroProfile project.  Not that he can't raise Issues, but he wouldn't have the weight of community involvement behind him.  So, I'm a little confused.  Are we seriously considering dropping Reactive Streams Operators from MP?  Or, was this post to find out wider opinions before making a decision?  Since this topic has been open for a couple of weeks with literally no responses, I'm a little surprised...

On the other hand, I do think some of Romain's arguments are valid and should be discussed.  If we're going to continue down this Reactive Streams Operators path, then we should ensure that Romain's concerns are heard and discussed as part of that direction.  This is not the first time I have heard about the use of and enhancing JAX-RS in a Reactive environment.  But, just to remove Reactive Operators until that architecture gets straightened out seems short-sighted.  We shouldn't just sit on the sidelines and wait for an answer to appear.  The idea of MP is to innovate and experiment.  If our efforts with Reactive Operators doesn't pan out in the long run, then so be it.  But, we should continue to push the envelope and see where it takes us.

-- Kevin

[Ken Finnigan]

We discussed the issue as part of the Architecture Board meeting and we all agreed that this issue should be closed as we felt Reactive Streams Operators should be part of MP and that Romain's questions had been answered by James.

We felt it best to request additional input from the wider community before we did close the issue. As you point out, with no comments from the wider community in 2 weeks, it's reasonable to presume that the issue can be closed

Ken

[James Roper]

On Tue, 9 Oct 2018 at 00:10, Kevin Sutter <kwsu...@gmail.com> wrote:

This is an interesting discussion...  The Issue raised seems to be a single conversation between Romain and James.  And, to the best of my knowledge, Romain is not even a committer on the MicroProfile project.  Not that he can't raise Issues, but he wouldn't have the weight of community involvement behind him.  So, I'm a little confused.  Are we seriously considering dropping Reactive Streams Operators from MP?  Or, was this post to find out wider opinions before making a decision?  Since this topic has been open for a couple of weeks with literally no responses, I'm a little surprised...

As Kevin pointed out, we didn't want to close an issue without soliciting broader feedback.

On the other hand, I do think some of Romain's arguments are valid and should be discussed.  If we're going to continue down this Reactive Streams Operators path, then we should ensure that Romain's concerns are heard and discussed as part of that direction.  This is not the first time I have heard about the use of and enhancing JAX-RS in a Reactive environment.

If JAX-RS were the only place that Reactive Streams was useful, then I would agree - Reactive Streams, by design, is not useful when just one library uses it. It is an integration API for multiple libraries to interoperate with streaming. But Reactive Streams has uses far beyond JAX-RS. For example, if I have a database that streams data (whether the data is rows, bytes from a blob, events, or something completely different), modifying JAX-RS is irrelevant in that context because JAX-RS has nothing to do with databases, unless you wanted to put support for that database directly in JAX-RS. If not, then to connect the stream of data from the database to JAX-RS, you need an integration API. That's what Reactive Streams is for. Other use cases include connecting streams from MicroProfile REST client to JAX RS, connecting messaging streams to a database (no JAX-RS or even HTTP involved there), connecting to third party streaming libraries - the limit is only in your imagination as to what streams of data you want to plumb where.

And MicroProfile Reactive Streams Operators is an API for manipulating those streams, which is needed because if you were streaming database rows to an HTTP connection, you're not going to want to pipe those Row objects directly to the connection, you're likely going to want to convert them to something suitable for external consumption, eg JSON, or something else. Operators such as map, filter, concat etc are needed to adapt these streams to the expected data formats that are needed by the various endpoints that you might want to connect to each other.

The ideal place for such an API I believe is the JDK, and that's where we hope this API ends up. But previous attempts to propose this for the JDK have been met with a response that before such a library could be added to the JDK, it would need to be incubated and proven, which makes MicroProfile a perfect place to incubate it in - MicroProfile is a place to innovate and experiment, and also has a broader goal of seeing its APIs become part of larger standards - correct me if I'm wrong, but if this was released in MicroProfile today, and then sometime in the future the API was adopted into the JDK, this would be viewed by everyone in the MicroProfile community as a success and an important part of why MicroProfile exists.

 

But, just to remove Reactive Operators until that architecture gets straightened out seems short-sighted.  We shouldn't just sit on the sidelines and wait for an answer to appear.  The idea of MP is to innovate and experiment.  If our efforts with Reactive Operators doesn't pan out in the long run, then so be it.  But, we should continue to push the envelope and see where it takes us.

-- Kevin

On Tuesday, September 25, 2018 at 5:39:56 PM UTC, Ken Finnigan wrote:

All,

In today's Architecture Board meeting we discussed an issue that was raised around deprecating Reactive Streams Operators specification from MicroProfile [1].

For those that were able to make the call, we all see benefit in the Reactive Streams Operators specification being a part of MicroProfile, and being used as a basis for a Reactive programming model within other MicroProfile specifications.

However, as those on the call don't represent the entire MicroProfile community we wanted to bring the discussion to a wider audience before determining a resolution.

Thanks

Ken

[1] - https://github.com/eclipse/microprofile/issues/57

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/4d8b66dd-88e6-4d88-abc7-fdc4468da912%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

James Roper
Senior Developer, Office of the CTO

Lightbend – Build reactive apps!
Twitter: @jroper

[Ondro Mihályi]

Hi,

I've added comments on the github issue.

I fully agree with James's opinion. It would be great if we could get API for reactive operators into the JDK. But until that happens, it makes a lot of sense to collaborate on a solution within MicroProfile. The API can be used with many other MP APIs, e.g. JAX-RS, REST client, future messaging (streams), and maybe DB access (if we adopt jNoSQL or add support for CQRS).

However, I think that MP reactive operators should fully integrate with JAX-RS and provide RxInvokerProvider for relevant builders. There are some other aspects why I think that this spec isn't ready for a 1.0 release, discussed in this thread: https://groups.google.com/forum/#!topic/microprofile/GaVGpe7XaGY

Among them:

• big classes with a lot of methods
• too many classes instead of interfaces
• little integration with other MP specs, like JAX-RS and CDI
• API and SPI mixed in a single artifact
• suspicious Stage classes in the SPI

While a lot needs to be improved, I see no reason in deprecating the operators API completely. Supporting reactive programming makes a lot of sense for MicroProfile and it shouldn't be left only to external libraries.

--Ondro

[Kevin Sutter]

>   - correct me if I'm wrong, but if this was released in MicroProfile today, and then sometime in the future the API was adopted into the JDK, this would be viewed by everyone in the MicroProfile community as a success and an important part of why MicroProfile exists.

Absolutely, James!

-- Kevin

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/4d8b66dd-88e6-4d88-abc7-fdc4468da912%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mark Little]

+1

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/30d4d6cf-803a-4555-b7b9-a701517ac6d9%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

---
Mark Little
mli...@redhat.com

JBoss, by Red Hat
Registered Address: Red Hat Ltd, 6700 Cork Airport Business Park, Kinsale Road, Co. Cork.
Registered in the Companies Registration Office, Parnell House, 14 Parnell Square, Dublin 1, Ireland, No.304873
Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill, Keith Phelan, Matt Parson (USA)

[Emily Jiang]

I would have voiced here earlier if I was not on the Architecture call.  On the call, we agreed the Reactive Streams Operators spec is needed as it is depended by other specs.such as Reactive Messaging and it is very powerful to manipulate messages (merge messaging or modify messagings). I would love to see something prototyped here eventually making its way to JDK.

Thanks

Emily

+1

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/4d8b66dd-88e6-4d88-abc7-fdc4468da912%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

James Roper
Senior Developer, Office of the CTO

Lightbend – Build reactive apps!
Twitter: @jroper

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/30d4d6cf-803a-4555-b7b9-a701517ac6d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.