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é <j...@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 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é > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com
