karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: [Proposal] New subproject rcomp - Reactive components framework
Date Tue, 08 Aug 2017 11:03:59 GMT
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


Mime
View raw message