activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: Message Groups
Date Tue, 15 May 2007 08:12:55 GMT
On 5/8/07, Banana Man <> wrote:
> Thanks for your help.
> I was thinking that the interceptors might be a good idea. I like the idea
> of the
> responsibility being in the broker because, you could argue, it is the
> broker and
> not the client that should concern itself with HA and load balancing etc.

Yeah - its mostly one of performance that makes it better to add to
the client - as the clients always have the de-serialized message
payload in RAM; the broker often just moves the payloads around
without having to look inside them.

> The Transformer on the Producer sounds quite clean but it still assumes the
> client
> takes responsibilty.
>  I really like the idea of Camel. I was reading about the EIP's the other
> day. I'm afraid
> I probably haven't understood its purpose properly. I thought it was a
> framework
> of recommended patterns which Active actually implements.

Not quite. ActiveMQ is a message broker and message brokers have a
number of things they implement, such as load balancing, selectors,
sticky load balancing and so forth; however lots of the EIP patterns
implement above a message broker in clients; such as idemptent
consumer, splitter, recipient list, content enricher, message
transformation and so forth.

So the aim of Camel is to be a reusable EIP engine - or integration
rules engine - which can be then used both inside and outside of

> Are you saying
> that
> I can specifically get Active to use some of those patterns? Sorry - a bit
> thick here.

So ActiveMQ does some of the EIP patterns in relation to JMS; but
Camel is a full implementation of all of them on top of any transport.
I think it'd make sense to have Camel configured in the ActiveMQ
broker by default so folks can easily implement all of the EIP
patterns inside the ActiveMQ broker.


View raw message