Mailing-List: contact dev-help@karaf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@karaf.apache.org
MIME-Version: 1.0
In-Reply-To: <08443db5-ec7d-7106-0e41-2c8e9e8faff3@nanthrax.net>
References: <9518195e-14c9-53ee-0c12-86cf3830e790@die-schneider.net> <08443db5-ec7d-7106-0e41-2c8e9e8faff3@nanthrax.net>
From: Luca Burgazzoli <lburgazzoli@gmail.com>
Date: Thu, 3 Aug 2017 08:26:30 +0200
Message-ID: <CAMpNYobfttCmMfRH5=1s0BZAJPaVGeJ364URyNgrv3=1F+rTPg@mail.gmail.com>
Subject: Re: [Proposal] New subproject rcomp - Reactive components framework
To: dev@karaf.apache.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
archived-at: Thu, 03 Aug 2017 06:27:09 -0000

In camel there is now a camel-reactive-streams component that bridges
camel and reactive-streams specs so the integration with the proposed
subproject should be easy.
There is also a camel-reactor and - I hope soon - a camel-rxjava2
component to provide an implementation of the camel-reactive-streams
api based on reactor or rxjava2.

Maybe we could have a new "camel-rcomp" component to ease the integration.


---
Luca Burgazzoli


On Thu, Aug 3, 2017 at 8:02 AM, Jean-Baptiste Onofr=C3=A9 <jb@nanthrax.net>=
 wrote:
> 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 componen=
t
>> 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 Kar=
af
>> sub project. Some people like Jean-Baptiste and Hadrian have already
>> expressed that they support this and I hope for some more feedback and h=
elp.
>>
>> 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 component=
s
>> 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 hav=
e
>> similar meaning as in camel. The component can be given a source / targe=
t
>> type to produce / consume. So with the OSGi Converter spec this would al=
low
>> to have type safe messaging without coding the conversion in every
>> component. Each component is exposed as a service which encapsulates mos=
t 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 ze=
ro
>> additional dependencies.
>>
>> I also considered to use OSGi push streams which is an OSGi spec and wou=
ld
>> 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 a=
nd
>> 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-foundatio=
n-for-java-8-and-spring
>>
>> Another integration is with REST. It is already possible to integrate CX=
F
>> Rest services with reactive streams using some adapters but we could hav=
e
>> native integration.
>>
>>
>>       Risks and Opportunities
>>
>> The main risk I see is not gathering a critical mass of components to dr=
aw
>> 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 mo=
re
>> modern Apache Camel.
>>
>> So this all depends on getting some support by you all.
>>
>> Christian
>>
>>
>
> --
> Jean-Baptiste Onofr=C3=A9
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com