BTW there's now a vm:// component for communicating within the same
JVM, assuming that camel-core.jar is on the system/boot classpath...
http://cwiki.apache.org/CAMEL/vm.html
On 6/28/07, James Strachan <[EMAIL PROTECTED]> wrote:
On 6/28/07, borgel <[EMAIL PROTECTED]> wrote:
>
>
> James.Strachan wrote:
> >
> > On 6/27/07, borgel <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >> James.Strachan wrote:
> >> >
> >> > On 6/27/07, borgel <[EMAIL PROTECTED]> 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
> > URI)
> >
> > 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
> > http://activemq.apache.org/camel/jpa.html
> >
> > 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
> > --
> > James
> > -------
> > http://macstrac.blogspot.com/
> >
> >
>
> Thank you.
> I'll look into the alternatives. Sounds like JMS or SEDA are the most
> relavant alternatives for us then.
> It would be good with some more examples when version 1.0 is released... :)
Definitely :)
I'll try write up a little page on the wiki on communicating between
web apps as it seems a pretty common requirement
--
James
-------
http://macstrac.blogspot.com/
--
James
-------
http://macstrac.blogspot.com/
