First note, your message volume is pretty small as things go. You could really use either and whatever is easiest to maintain would probably dictate your choice.
Expanding on Petter's comment on restarts one thing to consider is the number of other machines that will be connecting to the broker.
Clients
If you have 100 machines connected to the broker then every restart of Tomcat w/ embedded ActiveMQ will break 100 connections that all need to reconnect. ActiveMQ supports reconnecting so can work out fine, but it can add some needless delay to message flow while everyone gets reconnected and sometimes a couple clients will fail to reconnect and you have to manually kick them into action.
With a standalone broker and say 100 clients, you can restart your Tomcat server as often as you like and only ever break the one connection from the broker to Tomcat. That can be very nice.
If you have just one client -- the Tomcat server itself -- then hands down go embedded and use the in-vm transport.
Memory
Another factor is memory. We use ActiveMQ in Amazon EC2 on a t1.micro which only has 613MB of memory which is pretty small. It's cheaper to run two t1.micros (one for ActiveMQ and one for Tomcat) than one m1.small that has both.
But again, the number of clients is a factor. If there are no other clients than Tomcat, running one m1.small and keeping everything in the same vm is probably way better.
FYI
If Tomcat and ActiveMQ are your primary targets you should consider Apache TomEE Plus which is Tomcat with ActiveMQ already integrated.
All the jars are there, everything is setup by default with an embedded ActiveMQ broker using the local transport that Petter talks about. You can easily configure it to use a standalone ActiveMQ broker as well. It also has
answered 2012-06-23T19:35:15.840