karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: [Proposal] New subproject rcomp - Reactive components framework
Date Thu, 03 Aug 2017 06:02:47 GMT
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 !

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é
Talend - http://www.talend.com

View raw message