On 23 February 2010 22:03, Eibwen <gwal...@sedonatek.com> wrote: > > I'm completely new to message queues, i've been looking at the ActiveMQ and > Camel website all day but the concepts are not fully clicking for my > specific situation. > I've read most of the FAQs but i think i'm still not seeing how everything > will fit together. I'd love a link to something to help me understand the > protocol some more. > > Specifications: > Messages will be fairly low rate, I'd estimate at peak times 1 a minute > Messages will be fairly large, i'll say average 500kB, up to around 2mB > Messages are a combination of an xml document with a byte stream probably > encoded into that > Right now a single Producer, and 10-20 Locations, in the future 100+ > Locations, and a limited number of Producers > > > The Producer is being built by someone else > The Locations are C# and behind a firewall where they can connect out, but i > cannot connect in > > > Many terms are confusing me still > I don't really understand the virtual destinations
don't worry about those - they are only really for very advanced use cases. > and such > When a queue is "foo.bar" is that a subset of "foo" ? They are different; but you can use wildcards if you want to use a parent/child relationship on consumers. http://activemq.apache.org/wildcards.html > Questions (see image below): > 1. Is there any difference in the connection between Topic and Queue? the network connection (a JMS Connection) is shared across all destinations & sessions & producers & consumers created via it (its a JMS thing). To see how queues and topics compare http://activemq.apache.org/how-does-a-queue-compare-to-a-topic.html > a. Is it a persistent connection or will I code my client to connect into > the broker every 5 minutes to check if the queue has anything? A connection (e.g. a JMS Connection) is intended to be created on startup and kept open. ActiveMQ supports auto-reconnection if there is a network or broker failure http://activemq.apache.org/how-can-i-support-auto-reconnection.html > b. Or does the broker connect into the client when a message is put into a > queue? (if this is the case my custom filtering/queue piece would have > webservices the clients will connect to) clients connect to the broker. > 2. To filter/distribute the messages, would either of these be worse?: > a. asking the producer to put each location's messages in a different queue > b. Or have selectors on each Location pointing to the same queue? > c. Or have the producer put it into a single queue, and have forwardTo > filteredDestination split it into different queues? > d. Is filtering using an XPath on the xml message body horribly inefficient? it all kinda depends on the numbers of queues & message throughputs involved; its also easy to pick one of those and change over time if you feel the need. As a first approach I'd go with a) if you're less than say 5,000 locations as then you can more easily monitor how each location is performing. > 3. If i want to do these things, would ActiveMQ be able to accomplish > these/would Camel? > a. Put a copy of each message into a database for indefinite storage ActiveMQ uses a message store (there are various versions from JDBC to custom database on disk). If you want to put a copy in a database permanently, I'd use Camel or some custom persistence code etc. > b. Add in new Producers sending messages from other common languages (giving > this portal out to new customers that will send information down to our > Locations) > > 4. If I were to start with ActiveMQ, would i be able to switch to Camel > fairly easily in the future? Yes > Or at least without having to ask the > developers of the Producer to change their code? Camel could work off the messages on the queue/topics - irrespective of how they are produced. So no need to change producer code. -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/
