aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <>
Subject Re: OSGi and JMS
Date Thu, 06 Apr 2017 09:48:21 GMT
I'm not really sure how your example really differs from the camel one:

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 <>:

> 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
> 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
> Open Source Architect

Guillaume Nodet

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message