Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I want to choose a message broker between the ZeroMQ and RabbitMQ for micro-services communications.
Question is which one is faster for data transfer? ZeroMQ(ZMTP protocol) Or RabbitMQ(AMQP protocol)?
Q : " ... which one is faster for data transfer? "
My bet is ZeroMQ being fastest, using inproc:// Transport Class for PAIR/PAIR Scalable Formal Communication Pattern archetype. The same if moving data over cluster-wide using tipc:// Transport Class and having also a few vmci://-connections plus serving epgm://-multicast services at once. Not speaking about MIL-STD-grade norm:// Transport Class applications...
Q : " Differences between ZMTP and AMQP protocols ?"
Quite many. The first one, the ZeroMQ being a universality & many-protocol & many-archetype equipped spin-off of AMQP ( refactored if not reinvented from the core-architecture all the way bottom-up ) having since v2.1+ endless list of language-bindings & wrappers, as evolution continues forwards.
AMQP being a lingua franca for Financial behemots' systems, that are not so keen on re-architecting the massively deployed status-quo in their systems.
AMQP is an agreed, evolving standard, not a Product per-se.
RabbitMQ is a Product, conform with some parts of the AMQP standard, while RabbitMQ may use wire-level protocol and other AMQP-standard parts for declared compatibility reasons, it is not an AMQP per-se.
Did I mention that ZeroMQ is a Broker-Less almost Zero-Latency framework?
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I attended a seminar about API basics yesterday and something struck out as odd to me. We covered a basic synopsis of what REST is and what SOAP is and these were defined as architectures of an api.
The way the presenter defined it is that programs have languages and apis have architectures. Is this the proper definition of what an architecture is for an api?
I've looked around on google trying to compare the two terms programming language and architecture and haven't found a clear result.
That statement was almost definitely hand-wavey over-simplification, and was probably only correct within the context of the point he was trying to make.
Architecture is the design and documentation of the high-level functioning of programs and the interaction of those programs.
Programs are implemented in languages, APIs are implemented as programs.
APIs are a documentation of a particular interface to a program, and thus are part of an architecture. APIs are implemented as programs, that themselves have architectures, that fit into a larger system architecture.
I would ignore his statement, it is not helpful to your mental model. Understand what programs are, what languages are, and what architecture is.
REST and SOAP are not even peers. REST is an architectural style, often implemented as HTTP verbs. It is contrasted with RPC style web services, which are often implemented with SOAP. SOAP is a protocol that sits on top of HTTP to implement RPC style web services, it is not an architecture, it is a protocol. REST is not a protocol, it is an architectural element. None of these are a full architecture in and of themselves. SOAP/REST/HTTP/programs/languages all are components in an architecture.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
As I understood AMQP 0.9.1, the main benefit was that you could send and receive messages and configure your exchanges / bindings / queues in a broker-independent way, thus you were able to switch your broker implementation without too much headache.
Now, AMQP 1.0 only defines a wire-level protocol, so you actually have to know your broker specifics in order to implement most messaging patterns.
Then why would I favour a message broker that is AMQP compliant over one that is not?
If the broker implements AMQP 1.0, I'm still locked in with broker specific client code. With AMQP 0.9.1, I am theoretically broker independent but would most likely end up with RabbitMQ, since they seem to be the only ones to sincerely maintain the full support for AMQP 0.9.1.
Unfortunately, your concerns are very valid.
Pieter Hintjens has great post on that, claiming that "AMQP/1.0 will go down in history as a prime documented example of how to fail a standardization effort and hurt a lot of people in the process."
To your question: "why would I favour a message broker that is AMQP compliant over one that is not?" Definitely not because you get the option to change your message broker provider, as it is now not required. There are only two situations, I would think of favouring AMQP message broker:
1) You are already used to that and have that broker easily available
2) AMQP still brings the advantage of having clients available in multiple programming languages. But STOMP would serve here too.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have been working on Active MQ for quite some time and familiar with the Active MQ architecture.
Recently I have been hearing a lot about Kafka as a messaging system.
What advantages does it have over Active MQ and other messaging system? Is it just another Big data buzz word?
Also is kafka suitable for zero loss messaging system?
This is too broad to discuss but in my opinion the most important factor about Kafka over ActiveMQ is the throughput. From the wiki page
Kafka provides an extremely high throughput distributed publish/subscribe messaging system. Additionally, it supports relatively long term persistence of messages to support a wide variety of consumers, partitioning of the message stream across servers and consumers, and functionality for loading data into Apache Hadoop for offline, batch processing.
Also is kafka suitable for zero loss messaging system?
In very brief kafka Guarantees these following :
1) Messages sent by a producer to a particular topic partition will be appended in the order they are sent. 2) For a topic with replication factor N, it will tolerate up to N-1 server failures without losing any messages committed to the log.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I am trying to figure out the best MQ option for my requirements. I need to have the ability to transfer both text and binary messages within and across geographically diverse data centers with high reliability. Fast is nice but scaling is an option as well. Support is nice to have as with RabbitMQ.
Here are some assumptions:
Use federation or shoveling messages to push identical messages across data centers.
Use AMQP to transfer binary messages and since we are a .Net/Python shop.
I want to make sure my assumptions are valid and need help with which MQ to pick. I have used ActiveMQ+MySQL in the past but I like the option of Mnesia for messaging with persistance. Also, is it alright to use AMQP 0.9 instead of 1.0. Looks like RabbitMQ support 1.0 via a plugin.
Appreciate any alternate suggestions I can get.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
If you had to create a list of steps that a non-technical business layperson would understand for implementing workflows in something like Mule ESB -- what would it look like? The scenario would be to describe how the ESB is used to perform integration between two disparate systems and the steps you would need to perform to get the job done.
An Enterprise Service Bus is a technical middleware for system integration. It is doubtful whether mixing the business aspects into the picture makes sense. For business people to look at a picture and 'get it', the technical aspects would either be abstracted away and or require a tacit understanding of the technology. Better to keep them separate.
On the business logic level you should use BPML for workflow modelling:
http://en.wikipedia.org/wiki/Business_Process_Modeling_Notation
The technical aspects of a service bus are captured through Enterprise Architecture Integration patterns:
http://www.eaipatterns.com/toc.html
The EAI view is already abstract, but expecting business people to understand this is like handing them UML diagrams and assuming they're literate by nature (alas, they are not).