The best option for me is to use whiteboard pattern for message consuming and inject sender service for sending messages.
2017-04-06 11:48 GMT+02:00 Guillaume Nodet <[email protected]>: > 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 > -- Pozdrawiam / Regards, Dominik Przybysz
