camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <>
Subject Re: Desktop applications
Date Tue, 15 Jul 2014 07:26:01 GMT
A UI and camel will only very rarely be a good match. So the first thing 
you should check is if you really need camel. Often
you only need an eventing mechanism.
One of the best methods to check for this is to try to implement 
something with camel and with pure java.
If the java solution is only a little more lines of code than the camel 
then better do not use camel.

So if you are sure camel is a good match then you have some nice 
integration points for your application.

An important one is pojo messaging 
( It allows to 
connect your UI with camel while still keeping both nicely separated.
When looking at the annotation examples keep in mind that annotations 
also make you depend on camel. (Here is another link that shows how to 
use interfaces to decouple your UI code from camel:

So for example if you want to send an Order then create an interface 
OrderReceiver with one method void onOrder(Order order).
You can let camel use this interface on sender as well as on receiver 
side. So from your UI code you either call onOrder to send out an Order 
or implement the interface to receive one.
(To decouple messaging using such an interface is btw. also a good 
practice if you do not use camel).

So the above gives you a general method to attach your UI to camel.
Now how about having one sender and several receivers. This is a typical 
messaging / eventing problem. So one simple solution is to use an 
embedded in memory ActiveMQ for this. Send an order to jms:topicname and 
receive it at several points using from("jms:topicname"). If you just 
need this in process there are even lighter weigthed solutions than 


On 14.07.2014 18:26, Jon Mithe wrote:
> Hello,
> I'm learning about camel but I'm struggling to write a complete swing
> desktop application with it nicely.
> All of the examples/tutorials I have read always have a route from listening
> to a port or a queue to being transformed and outputted into a
> database/webservice etc but what about if the endpoints are going to be a
> GUI?  I could see maybe a custom bean / endpoint being a consumer/producer?
> Also, how this works in a bigger application, so for example in the cafe
> example
>>    ProducerTemplate template = camelContext.createProducerTemplate();
>>    Order order = create order
>>    template.sendBody("direct:cafe", order);
> Would you really call camelContext.createProducerTemplate();? I dont see how
> that works bar there is only one route in camel that has an order.
> For example, what happens here if there is a second route to save an order
> halfway through it so it can be completed later, or for example another to
> fire off an update / amendment for an existing order?
> Likewise, if the Barista's had an application / order screen that they see
> the incomming orders so they could make them.
> If it were a simple list I could see maybe writing a bean and sending it to
> that / that updates the gui.  Are there any patterns for if there were n
> things that need updated (say the app had a counter on the menu bar counting
> total drinks made, or another widget to report stock levels up to the
> barista)
> I could see how a recipient list could be used, however, what happens if the
> system is very modular / the thing receiving them doesnt know who is
> interested -- I suppose this may be regarded as bad design / use but I can
> see that being a problem applying / improving a legacy system.  I see some
> things with eventbus that maybe useful to fire off generic events into the
> system but unsure.
> Any help / insight would be great thanks, I think I'm getting a reasonable
> grip with some EIP's and routes / flows and it really does look good, but
> having a black spot on tieing it together into within a desktop application.
> Thanks,
> Jon
> --
> View this message in context:
> Sent from the Camel - Users mailing list archive at

Christian Schneider

Open Source Architect

View raw message