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
