aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Ward <timothyjw...@apache.org>
Subject Re: Prototype for reactive streams and a messaging component abstraction
Date Thu, 29 Jun 2017 11:50:27 GMT
Hi Christian,

PushStreams are a fundamentally different take on the way streams are controlled, mostly in
an effort to make them simpler. They do not implement the reactive streams API, although it
is possible to adapt between them. You mentions that you want to be independent of a stream
DSL, but also that you specifically want to use the reactor DSL. These two things seem to
be at odds with one another…

With Push Streams you have a Push Event Source, which can be implemented directly (it’s
lambda friendly) or you can use a SimplePushEventSource.

From the producing side you simply publish events as they arrive. A consumer can directly
connect to a source, or you can make a PushStream from it using a PushStreamProvider. A PushStream
is assembled just like a Java 8 Stream, and gets you answers at the end.

Push Streams are available in the sonatype OSGi repository, and are in the latest R7 draft
spec. I do suggest taking a look as I think it will save a lot of code.

Regards,

Tim


> On 29 Jun 2017, at 12:04, Christian Schneider <chris@die-schneider.net> wrote:
> 
> Hi Tim,
> 
> I did not look into Pushstreams in detail. Does Pushstreams also support the reactive
streams API?
> My goal was to create a component API that is independent of a specific stream DSL.
> 
> You mentioned that push streams are simpler to use. How would a component look like for
push streams. Can such a component then also be run with the reactor DSL?
> 
> For my experiments with the DSL I chose reactor as it will get a lot of attention as
the core of spring 5.
> 
> Christian
> 
> On 29.06.2017 11:10, Timothy Ward wrote:
>> Hi Christian,
>> 
>> Did you also take a look at the OSGi produced reactive libraries? PushStreams seem
to be a much more elegant solution for what you’re trying to do, and would let you simplify
the connectors quite a lot. I think the client examples would also be quite a lot simpler.
There’s also an OSGi RFC for messaging that might be helpful to look at https://github.com/osgi/design/blob/36a3ee74db246c5a73f8d043c7172494fefee948/rfcs/rfc0229/RFC0229-MQTT.pdf.
>> 
>> Regards,
>> 
>> Tim
>> 
>> 
>> 
>> On 26 Jun 2017, at 17:12, Christian Schneider <chris@die-schneider.net<mailto:chris@die-schneider.net>>
wrote:
>> 
>> I recently looked into ways to combine messaging and streaming on OSGi.
>> 
>> Interestingly the best streaming solution I found for my case was Reactor (by Pivotal)
which is the core of spring 5. It works out of the box on OSGi and only has a single dependency.
>> 
>> The next thing was how to combine this with messaging in a loosely coupled way. I
really like Apache Camel but I think it is not up to date any more and also acquired a lot
of weight over time (especially in camel-core). So I was looking into providing a light weight
component API and combine it with Reactor.
>> 
>> The result is this project:
>> 
>> https://github.com/cschneider/streaming-osgi/tree/master/reactortest
>> 
>> This is the Component API: https://github.com/cschneider/streaming-osgi/blob/master/reactortest/src/main/java/component/api/MComponent.java
>> Actually I am unsure if the converter must be part of the API but this is the current
state.
>> 
>> I created some POC components for Mqtt, EventAdmin and Mail.
>> 
>> and finally two examples:
>> 
>> Listen on eventadmin topic, log and forward to other topic:
>> https://github.com/cschneider/streaming-osgi/blob/master/reactortest/src/main/java/reactortest/ExampleEventAdmin.java
>> 
>> Listen to mqtt, compute average over sliding window and forward to other topic:
>> https://github.com/cschneider/streaming-osgi/blob/master/reactortest/src/main/java/reactortest/MqttExampleComponent.java
>> 
>> 
>> I think there is a lot of potential in Reactor and also in messaging components that
do not couple your code to the technology.
>> 
>> I would be happy about any feedback on the prototype. Beware the code is not yet
split into bundles but I hope the intention is still visible.
>> 
>> Best
>> 
>> Christian
>> 
>> 
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>> 
>> Open Source Architect
>> http://www.talend.com
>> 
>> 
> 
> -- 
> Christian Schneider
> http://www.liquid-reality.de
> 
> Open Source Architect
> http://www.talend.com
> 

Mime
View raw message