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
