Nick do you have a link to pentaho where you are doing some of this. I am guessing you are using flow instead of the OSGI pushstreams api when you say that streaming was considered for the OSGI standards.
David Daniel On Mon, Jan 16, 2017 at 1:36 PM, Nick Baker <[email protected]> wrote: > The event bus model has served us well for certain things, broadcasting > application events consumed by unknown plugins for instance. It's certainly > extensible and easy from the consumer and producer standpoint. > > That said, we are basing much of our new work on Reactive Streams APIs. > This provides backpressure for composed streams inside the application and > ensures that no one is wasting time putting things on the bus which aren't > actually listened to. > > We're RxJava internally at the moment. Remote subscriptions is something > we're just now dealing with which is prompting a look at Akka Streams. > > I know Streaming is something that was considered for the OSGi standards, > but with Java 9 looking to adopt Reactive Streams as the new "Flow" API, I > would encourage us to look forward to that. In combination with remote > services and a simple event bus like Guava which can be remoted, I think > you have a pretty competent set of utilities to work with. > > -Nick Baker > ------------------------------ > *From:* Scott Lewis <[email protected]> > *Sent:* Monday, January 16, 2017 12:49:31 PM > *To:* [email protected] > *Subject:* Re: Opinionated... > > On 1/16/2017 2:20 AM, Christian Schneider wrote: > > <stuff deleted> > > > - One way messaging. I think the purest form of remote communication > > are one way messages backed by JMS or Kafka or other messaging > > brokers. Unfortunately I think this is only partially supported in > > Remote Services. > > and Nick Baker just wrote: > > >Where is Event Admin? > > In terms of standardization, there was a DistributedEventing rfp 158 > [1], but I don't know what's planned for that now by the EEG. There was > also some work on push streams and perhaps that's somehow absorbed the > distributed eventing. Someone on this list currently on the EEG can > probably speak to the state of standardization. > > In terms of implementation, ECF has had a DistributedEventAdmin > implementation for a very long time [2]. The description at [2] is > based upon ActiveMQ, but like ECF's remote services implementation, a > provider approach allows the substitution of other pub/sub > providers...for example mqtt [3], and others (e.g. Camel...and plenty of > others). > > Scott > > [1] https://github.com/osgi/design > > [2] https://wiki.eclipse.org/EIG:Distributed_EventAdmin_Service > [3] https://github.com/ECF/Mqtt-Provider > > >
