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é <[email protected]>: > Hi > > I will do a new review round tomorrow morning. > > Thanks > Regards > JB > > On Aug 8, 2017, 13:04, at 13:04, Christian Schneider < > [email protected]> 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
