I'm not really sure how your example really differs from the camel one: http://camel.apache.org/pojo-messaging-example.html
The main difference is that the Camel one is actually working, whereas yours is just an idea. I guess it depends if Dominik is looking at writing such an abstraction layer or if he wants to use something in the short term. 2017-04-06 9:02 GMT+02:00 Christian Schneider <[email protected]>: > I think we will need an abstraction for this. In my opinion it would be > bad if the user code has to directly depend on camel. > Some time ago I experimented a bit with an API for events. It is unrelated > to push streams though. > > See > https://github.com/cschneider/typesafe-eventing > > The idea was to look into ways to abstract the process of sending and > receiving type safe events. In the code the Starter does the plumbing but > the idea is of course to let a DI framework do the plumbing. > > One idea is to use the java.util.function.Consumer interface for sending > and receiving typesafe messages. > In OSGi we could use something like this on the sender side: > > @Reference(filter="(topic=mytopic)") > Consumer<Customer> sender; > > Even nicer would be something like: > @Topic("mytopic") > @Reference > Consumer<Customer> sender; > > The user code would send simply by doing: > sender.accept(customer) > > On the receiver side the obvious pattern would be: > @Component(property="topic=mytopic") > class MyReceiver implements Consumer<Customer> { > public void accept(Customer customer) { ... }; > } > > I also experimented a bit with things like: > > class MyReceiver { > @Transactional > @Topic("mytopic") > public void receive(Customer customer) { ... }; > } > > The problem with this approach is that it requires introspection and a > injection framework that allows extensions and some kind of aop. So it > would be less useful for DS but could be nice for CDI. It is also similar > to eventing > in plain CDI. > > Another question is of course how to combine this with push streams or > another reactive programming model. I also think we need two levels of > this. One level is a kind of whiteboard model based on OSGi services which > could be common for the whole platform. The other level is the integration > with different DI systems which could be different for DS, blueprint and > CDI. > > To be honest I am not sure my approach is a good idea but I think it is > important we discuss about different approaches to find a good solution. > > Christian > > > > On 06.04.2017 08:26, Guillaume Nodet wrote: > >> The PushStream is a streaming api. It focuses on defining a pipeline, but >> the implementation is not related to any distribution mechanism. >> >> If you want to send messages across VMs on your network, you really should >> focus on ActiveMQ. >> There's no real OSGi specific facade I know of, so my best bet would be >> Camel too, as others have said. >> You can just show the minimum of camel, just what is needed to actually >> consume the JMS message from a pojo or to send messages from a pojo. You >> don't have to look at everything Camel can do. >> >> > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > > -- ------------------------ Guillaume Nodet
