In addition to the reply below, using an embedded broker means you tie the broker's lifetime to the application that runs the embedded broker. This may not be ideal for real world application (but again depends on your use-case). Typically a messaging system such as ActiveMQ is part of the overall applications underlying infrastructure and needs to be highly available at any time. In such requirement its better to run standalone brokers, perhaps configured for high availability.
Regards, Torsten Mielke tors...@fusesource.com tmie...@blogspot.com On Aug 23, 2012, at 12:51 AM, Gaurav Sharma wrote: > This is a difficult question to answer but briefly, it will depend on the > services' design, state management of the system, concurrency-model, the > domain and what the services will be doing. I presume they will have > different behaviors with a mixture of cpu-bound, diskIO-bound, > networkIO-bound, etc. That said, the embedded-mode broker is great for > testing. If your system has distributed consumers and producers and HA > requirements for the different pieces, it will not be the recommended > option. Again, depends on your use cases. > > On Wed, Aug 22, 2012 at 3:35 PM, Paddy Carman <paddy.car...@gmail.com>wrote: > >> Hi - >> I'm trying to figure out the architecture for a large scale system that >> I'm building that consists of hosting a number of services that would use a >> pub/sub pattern. Could some please let me know the pros and cons of using >> embedded broker Vs. standalone brokers especially in terms of scalability? >> Thanks, >> PC >> Torsten Mielke tors...@fusesource.com tmie...@blogspot.com
