Comparison of RabbitMQ, ActiveMQ, and ZeroMQ Message Brokers

RabbitMQ	ZeroMQ	ActiveMQ
RabbitMQ is one of the leading implementation of the AMQP protocol (along with Apache Qpid). Therefore, it implements a broker architecture, meaning that messages are queued on a central node before being sent to clients. This approach makes RabbitMQ very easy to use and deploy, because advanced scenarios like routing, load balancing or persistent message queuing are supported in just a few lines of code. However, it also makes it less scalable and “slower” because the central node adds latency and message envelopes are quite big. RabbitMQ is a Message Queue Server in Erlang It stores jobs in memory (message queue)	ZeroMQ is a very lightweight messaging system specially designed for high throughput/low latency scenarios like the one you can find in the financial world. Zmq supports many advanced messaging scenarios but contrary to RabbitMQ, you’ll have to implement most of them yourself by combining various pieces of the framework (e.g : sockets and devices). Zmq is very flexible but you’ll have to study the 80 pages or so of the guide (which I recommend reading for anybody writing distributed system, even if you don’t use Zmq) before being able to do anything more complicated that sending messages between 2 peers. The socket library that acts as a concurrency framework Faster than TCP, for clustered products and supercomputing Carries messages across inproc, IPC, TCP, and multicast Connect N-to-N via fanout, pubsub, pipeline, request-reply Asynch I/O for scalable multicore message-passing apps	ActiveMQ is in the middle ground. Like Zmq, it can be deployed with both broker and P2P topologies. Like RabbitMQ, it’s easier to implement advanced scenarios but usually at the cost of raw performance. ActiveMQ is an open source message broker in Java Supports many advanced featuressuch as Message Groups, Virtual Destinations, Wildcards and Composite Destinations.

Object Modeling

The goal in object modeling is to render a precise, concise, understandable object-oriented model, or "blueprint," of the system to be automated. This model will serve as an important tool for communication:

• To the future users of the system that we are about to build, an object model communicates our understanding of the system requirements.
• To the software development team, an object model communicates the structure and function of the software that needs to be built in order to satisfy those requirements. This benefits not only the software engineers themselves, but also the folks who are responsible for quality assurance, testing, and documentation.
• Long after the application is operational, an object model lives on as a "schematic diagram" to help the myriad folks responsible for supporting and maintaining an application understand its structure and function.

The design of complex systems invariably changes during their construction, so care should be taken to keep the object model up-to-date as the system is built.

Modeling Methodology = Process + Notation + Tool

According to Webster's dictionary, a methodology is
    A set of systematic procedures used by a discipline (to achieve a particular desired outcome).

A modeling methodology, ideally involves three components:

• A process: The "how to" steps for gathering the requirements and determining the abstraction to be modeled
• A notation: A graphical "language" for communicating the model
• A tool: An automated way of rendering the notation, typically in "drag-and-drop" fashion

Although these constitute the ideal components of a modeling methodology, they are not all of equal importance.

• Adhering to a sound process is certainly critical.
• However, we can sometimes get by with a narrative text description of an abstraction without having to resort to portraying it with formal graphical notation.
• And, when we do choose to depict an abstraction formally via a graphical notation, it isn't mandatory that we use a specialized tool for doing so.

Object modeling tools fall under the general heading of Computer-Aided Software Engineering, or CASE, tools. CASE tools afford us with many advantages, but aren't without their drawbacks.

The Advantages of Using CASE Tools:

• Ease of Use - CASE tools provide a quick drag-and-drop way to create visual models.
• Added Information Content - CASE tools produce "intelligent" drawings that enforce the syntax rules of a particular notation. This is in contrast to a generic drawing package, which will pretty much let you draw whatever you like, whether it adheres to the notational syntax or not.
• Automated Code Generation - Most CASE tools provide code generation capabilities, enabling you to transition from a diagram to skeletal C# (or other) code with the push of a button.
• Project Management Aids - Many CASE tools provide some sort of version control, enabling you to maintain different generations of the same model.
• Flexibility - Some CASE tools support multiple graphical notations, enabling you to initially create a diagram in one notation but to then convert the diagram to another notation quickly and effortlessly.

Some Drawbacks of CASE Tools:

• CASE tools can be expensive; it's not unusual for a high-end CASE tool to cost hundreds or even thousands of dollars per "seat."
• It's easy to get caught up with form over substance! This is true of any automated tool - even a word processor tends to lure people into spending more time on the cosmetics of a document than is warranted, long after the substantive content is rock solid.