Nothing much worth seeing from a Karaf OSGI perspective yet. We're working on some stuff for the next release that's not going to be open until then, but you can see the API now. We have one main Producer interface:
https://github.com/pentaho/pentaho-kettle/blob/ael/pdi-execution-engine/api/src/main/java/org/pentaho/di/engine/api/reporting/IProgressReporting.java ________________________________ From: Nick Baker Sent: Monday, January 16, 2017 3:58:04 PM To: [email protected] Subject: Re: Opinionated... Nothing much worth seeing from a Karaf OSGI perspective yet. We're working on some stuff for the next release that's not going to be open until then, but you can see the API now: ________________________________ From: David Daniel <[email protected]> Sent: Monday, January 16, 2017 1:56:10 PM To: [email protected] Subject: Re: Opinionated... 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]<mailto:[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]<mailto:[email protected]>> Sent: Monday, January 16, 2017 12:49:31 PM To: [email protected]<mailto:[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
