karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: [Proposal] New subproject rcomp - Reactive components framework
Date Tue, 08 Aug 2017 12:26:46 GMT

I will do a new review round tomorrow morning.


On Aug 8, 2017, 13:04, at 13:04, Christian Schneider <chris@die-schneider.net> 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 
>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.
>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
>> 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
>> 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
>>> 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
>>> / 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
>>> 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
>>> (http://www.reactive-streams.org/). So they are well defined and
>>> 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
>>> 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
>>> Akka and reactive streams
>>> Reactor and reactive streams
>>> Another integration is with REST. It is already possible to
>>> 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
>>> 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
>>> barrier of entry is low.
>>> I also hope that this might become a new foundation for a simpler
>>> more modern Apache Camel.
>>> So this all depends on getting some support by you all.
>>> Christian
>Christian Schneider
>Open Source Architect

  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message