I agree.
On 06.04.2017 12:00, Dominik Przybysz wrote:
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
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
