karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: [Proposal] New subproject rcomp - Reactive components framework
Date Sun, 22 Oct 2017 16:16:16 GMT
I have now organized the repo and did the initial push with my current code
of reactive components.

You can find the repo at:
https://github.com/apache/karaf-reactive-components

I would still be happy about a review. I think we should have no licensing
issues as the code was only developed by me and I have an ICLA.
So I can confirm that this is fully apache licensed and written by me.

Please let me know if we need something more formal.

Best
Christian

2017-08-08 14:26 GMT+02:00 Jean-Baptiste Onofré <jb@nanthrax.net>:

> Hi
>
> I will do a new review round tomorrow morning.
>
> Thanks
> Regards
> JB
>
> On Aug 8, 2017, 13:04, at 13:04, Christian Schneider <
> chris@die-schneider.net> wrote:
> >I now adapted the package names as well as the maven coordinates. All
> >files should now also have the apache headers.
> >I also made sure the build now works without any running mqtt or kafka
> >server.
> >
> >I would be happy about a quick review of the current status. If there
> >are no objections then I will go ahead and ask for a git repository.
> >
> >Christian
> >
> >On 03.08.2017 08:02, Jean-Baptiste Onofré 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
> >>> 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
> >>>
> >>>
> >>
> >
> >--
> >Christian Schneider
> >http://www.liquid-reality.de
> >
> >Open Source Architect
> >http://www.talend.com
>



-- 
-- 
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>

Computer Scientist
http://www.adobe.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message