karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject [Proposal] New subproject rcomp - Reactive components framework
Date Wed, 19 Jul 2017 11:02:33 GMT

      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


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