My starting point was actually the camel pojo messaging. I like the way
camel can abstract away the messaging handling. The problem with camel
though is that the user
code needs a dependency to camel and it also needs to setup camel. This
is where we need something in between.
Like Dominik wrote a whiteboard approach could help with receiving
messages and a sender could be injected.
We need to make sure the the user code only needs to depend on a very
small API for this. Then behind it we can use camel to implement the
actual sending and receiving but we can then also
use other implementations.
In my example I experimented with possible ways to define this API.
Christian
On 06.04.2017 11:48, Guillaume Nodet wrote:
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
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
