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 <[email protected]> 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 
>> <[email protected]<mailto:[email protected]>> 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
> 

Reply via email to