At first glance, it looks similar related to http://camel.apache.org/rx.html Also, given what you say about Camel and OSGi Push Streams, I think it would make more sense to discuss that inside the Camel project instead.
2017-07-19 13:02 GMT+02:00 Christian Schneider <[email protected]>: > > 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-reacti > ve-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 > > -- ------------------------ Guillaume Nodet
