camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: Newbie: How to implement the Message Channel pattern?
Date Thu, 28 Jun 2007 08:38:58 GMT
On 6/27/07, borgel <> wrote:
> James.Strachan wrote:
> >
> > On 6/27/07, borgel <> wrote:
> >>> (...) Can I use Camel to send messages between these applications?
> >
> >>Sure! :)
> >
> > Great! :)
> >
> >>Are the 3 applications in the same JVM; or in separate ones? Also are
> >>they deployed as a single unit all the time; or could they come and go
> >>individually?
> >
> > Same JVM, but this might change. The applications are deployed separatly
> > and can come and go individually.
> >
> >
> >>The simplest way to deal with communication between applications or
> >>services (which may individually be started/stopped, be inside
> >>different class loaders or deployed across different JVMs) is often
> >>using messaging. Then the applications are completely decoupled across
> >>time, location and JVM. e.g. using ActiveMQ queues for example.
> >>Another option could be to use disk (file based messaging).
> >
> > This is what I tried, using direct connection. I sat up a Consumer in one
> > app (app C with employee information) and a Producer in another
> > application. From the producer i tried to call the consumer, but here it
> > stopped for me, because the Producer accesses a different context than the
> > Consumer. The same goes for JMS. For instance:
> > CamelContext container = new DefaultCamelContext();
> > (...)
> > JmsEndpoint endpoint = (JmsEndpoint)
> > container.getEndpoint("jms:employee");
> >
> > The Consumer which is listening on this endpoint never receives anything
> > becuase it's a different context. What is it I am missing?

Were you using ActiveMQ by any chance? If you were; ActiveMQ supports
embedded brokers. However the same kinda classloading issues occur
with ActiveMQ - to access the same broker via the VM protocol (to
avoid using sockets and marshalling stuff) - you must have ActiveMQ on
the system classpath; otherwise each web app ends up having its own
broker & the web apps can't communicate with each other.

The easiest way to ensure this works is to run a separate ActiveMQ
broker on the same machine (or in a WAR which is always deployed in
tomcat and never stopped) - then just use the ActiveMQ component in
Camel (which defaults to using tcp://locahost:61616 as the connection

using "activemq:employeeQueue" as the Camel URI will then allow
contexts to communicate with each other using the same queue.

> > Should each application (war) include Camel or should it be deployed to
> > Tomcat in a different way?
> >
> >>If you deploy the 3 WARs together, (...)
> >
> > I can, but I would prefer not to. I must be able to start and stop each
> > application independently from the others.

I get it, thanks.

JMS is definitely gonna be the most flexible (as you can stop and
start your entire Tomcat JVM whenever you like without loosing a
message); though I understand it adds a bit of complexity of learning
about MOM if you've never done much JMS before etc.

If you don't mind loosing all messages if you reboot tomcat (and are
happy to keep all your web apps in the same JVM) then you could also
look at a pure in-memory (in the system classpath) SEDA type approach.

Yet another approach; if you don't mind using JPA beans for your
messages, is to use the JPA component

Its not as efficient (in fact in the large scale it can be kinda slow)
and the load balancing sucks (basically 1 thread tends to grab most of
the messages on the consume side) - but for simple lowish volume
scenarios its worth considering.

The big-wins of using MOM is that its an awesome high performance load
balancer across threads and processes (queues) and also supports
efficient pulbish and subscribe (via topics); but for simpler
requirements, you can still use a database & if you don't mind loosing
messages on tomcat restart, there's the in memory SEDA alternative

View raw message