On 5/8/07, Banana Man <[EMAIL PROTECTED]> 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 ActiveMQ.
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. -- James ------- http://macstrac.blogspot.com/
