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
(http://camel.apache.org/pojo-messaging-example.html). 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:
http://liquid-reality.de/display/liquid/2011/10/19/Using+Camel+to+do+light+weight+messaging+over+any+protocol).
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
activemq.
Christian
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 http://camel.apache.org/cafe-example.html:
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:
http://camel.465427.n5.nabble.com/Desktop-applications-tp5753788.html
Sent from the Camel - Users mailing list archive at Nabble.com.
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
