Hi Christian,
the proposal is interesting, and I see a first potential use in Decanter for
sure.
The comment about Camel is fair as it looks very similar at first glance.
However, the scope is slightly different IMHO.
I checked about the legal. The code should be cleanup for donation (ASF headers,
package names, ...). About the dependency license, for the reactive-streams, it'
OK as it uses Creative Commons Zero into the Public Domain. And Reactor is
already under Apache license.
The DSL is a hot topic. I understand that leveraging Akka or Reactor is easier,
but I'm a bit concern that we could be too much "coupled".
Maybe our own simple DSL could help. Thoughts ?
Thanks anyway !
Regards
JB
On 07/19/2017 01:02 PM, Christian Schneider wrote:
Scope
I recently experimented with reactive streams and built a small component
framework on top of this spec.
See https://github.com/cschneider/reactive-components
The goal is to have a small API that can encapsulate a protocol and transport.
The code using such a reactive component should not directly depend on the
specifics of the transport or protocol. Another goal is to have reactive
features like back pressure. Ultimately I am searching for something like Apache
Camel Components but with a lot less coupling. In camel the big problem is that
components depend on camel core which unfortunately is much more than a
component API. So any camel component is coupled quite tightly to all of camel
core.
Proposal
I propose to donate my code to Apache and establish this as a Apache Karaf sub
project. Some people like Jean-Baptiste and Hadrian have already expressed that
they support this and I hope for some more feedback and help.
I chose the Karaf project at the moment but am also open to placing this in
another Apache project. Some matching projects would be Apache Camel, Aries or
Felix.
Component API
I was trying to find the simplest API that would allow similar components to
camel in one way mode.
public interface RComponent {
<T> Publisher<T> from(String destination, Class<T> type);
<T> Subscriber<T> to(String destination, Class<T> type);
}
A component is a factory for Publishers and Subscribers. From and to have
similar meaning as in camel. The component can be given a source / target type
to produce / consume. So with the OSGi Converter spec this would allow to have
type safe messaging without coding the conversion in every component. Each
component is exposed as a service which encapsulates most of the configuration.
All endpoint specific configuration can be done using the destination String.
Publisher and Subscriber are interfaces from the reactive streams api
(http://www.reactive-streams.org/). So they are well defined and have zero
additional dependencies.
I also considered to use OSGi push streams which is an OSGi spec and would also
be an interesting foundation. I decided against that though as push streams have
no API that is separate from the DSL and will probably not be used a lot outside
of OSGi.
See the examples for how to use this in practice.
https://github.com/cschneider/reactive-components
Possible use cases
Two big use cases are reactive microservices that need messaging as well as
plain camel like integrations.
Another case are the Apache Karaf decanter collectors and appenders. Currently
they use a decanter specific API but they could easily be converted into the
more general rcomp api.
We could also create a bridge to camel components to leverage the many existing
camel components using the rcomp API as well as offering rcomp components to camel.
Components alone are of course not enough. One big strength of Apache Camel is
the DSL. In case of rcomp I propose to not create our own DSL and instead use
existing DSLs that work well in OSGi. Two examples:
Akka and reactive streams
https://de.slideshare.net/ktoso/reactive-integrations-with-akka-streams
Reactor and reactive streams
https://de.slideshare.net/StphaneMaldini/reactor-30-a-reactive-foundation-for-java-8-and-spring
Another integration is with REST. It is already possible to integrate CXF Rest
services with reactive streams using some adapters but we could have native
integration.
Risks and Opportunities
The main risk I see is not gathering a critical mass of components to draw more
people.
Another risk is that the RComponent API or the reactor streams have some
unexpected limitations.
The big opportunity I see is that the rcomp API is very simple so the barrier of
entry is low.
I also hope that this might become a new foundation for a simpler and more
modern Apache Camel.
So this all depends on getting some support by you all.
Christian
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
