You are developing a solution that will use Azure messaging services.
You need to ensure that the solution uses a publish-subscribe model and eliminates the need for constant polling.
What are two possible ways to achieve the goal? Each correct answer presents a complete solution.
NOTE: Each correct selection is worth one point.
To achieve a publish-subscribe model and eliminate the need for constant polling, consider using Service Bus and Event Grid. Service Bus supports topics and subscriptions, which are essential components of the publish-subscribe model. Event Grid is specifically designed for event-based messaging and operates without the need for constant polling by pushing events to the subscribers. Meanwhile, Event Hub is more suited for large-scale event streaming but requires polling to process events. Queue, on the other hand, is designed for point-to-point messaging, which doesn't align with the publish-subscribe model.
Correct Ans is A & C https://docs.microsoft.com/en-us/azure/architecture/patterns/publisher-subscriber#issues-and-considerations
"In Azure, consider using Service Bus or Event Grid. "
Agree, but publish/subscribe is a feature of event-hub as well, but event-based receiving is not. That is why option B falls off.
The article has been updated, the new text says "In Azure, consider using Service Bus, Event Hubs or Event Grid." So A, B and C should be all correct. https://docs.microsoft.com/en-us/azure/architecture/patterns/publisher-subscriber#issues-and-considerations
Event Hubs : event-based receiving is not possible, you still need to poll. So B falls off
Correct answer is A and C Ref: https://docs.microsoft.com/en-us/azure/architecture/patterns/publisher-subscriber#issues-and-considerations. Wrong answer B (eliminate the need for constant polling)Ref: https://docs.microsoft.com/en-us/azure/connectors/connectors-create-api-azure-event-hubs#trigger-polling-behavior
A & C Triggers of Event hub are long-polling, so B is not correct. https://docs.microsoft.com/en-us/azure/connectors/connectors-create-api-azure-event-hubs#trigger-polling-behavior
Got it in exam 20/10/2022
I believe MS is rather picky about the distinction between events and messages, that why I go for Service Bus and Queues... However Event Hubs and Grid are also capable of delivering the requested functionality (as far as I understand them... but I'm still studying on them :-) )
Agree, see: https://docs.microsoft.com/en-us/azure/event-grid/compare-messaging-services?toc=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Fservice-bus-messaging%2Ftoc.json&bc=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Fbread%2Ftoc.json
Buddies, although there is a distinction between events and messages, all of these services (Service Bus Topics, Service Bus Queues, Event Grid, Event Hubs) are under the "Azure Messaging" umbrella. Queues do not satisfy the pub-sub model and Event Hub is long polling https://docs.microsoft.com/en-us/azure/connectors/connectors-create-api-azure-event-hubs#trigger-polling-behavior
A, B and C are all correct: Existing technologies. It is strongly recommended to use available messaging products and services that support a publish-subscribe model, rather than building your own. In Azure, consider using Service Bus, Event Hubs or Event Grid. Other technologies that can be used for pub/sub messaging include Redis, RabbitMQ, and Apache Kafka. (https://docs.microsoft.com/en-us/azure/architecture/patterns/publisher-subscriber)
This was on the exam (July 2023). Went with AC. Scored 917
A & C Correct
A and C as both service bus and event grid implement publish-subscribe and don't require polling.
exactly, Event HUB needs to poll and process an event
Got it on 03/2022, I chose A. Service Bus & C. Event Grid
Got this one 01/2022. Went with most voted (to avoid writing answers again)
Service bus Event Grid
Still no convinced why event hub is not a correct answer. Some say that the event hub consumer is polling? I read the following in the doc: Any entity that reads event data from an event hub is an event consumer. All Event Hubs consumers connect via the AMQP 1.0 session and events are delivered through the session as they become available. The client doesn't need to poll for data availability.
You are right, event hub can utilize push, in fact it does both now: pull and push models: https://learn.microsoft.com/uk-ua/training/modules/azure-event-hubs/6-event-hubs-programming-guide - as u see pull "with" ReadEventsFromPartitionAsync and push with Event Processor client. Seems the key thing here services that supports ONLY push ways
A, B and C should be all correct. It is strongly recommended to use available messaging products and services that support a publish-subscribe model, rather than building your own. In Azure, consider using Service Bus, Event Hubs or Event Grid. Other technologies that can be used for pub/sub messaging include Redis, RabbitMQ, and Apache Kafka. https://docs.microsoft.com/en-us/azure/architecture/patterns/publisher-subscriber
It seems that the selected answers are correct: "Existing technologies. It is strongly recommended to use available messaging products and services that support a publish-subscribe model, rather than building your own. In Azure, consider using Service Bus, Event Hubs or Event Grid. Other technologies that can be used for pub/sub messaging include Redis, RabbitMQ, and Apache Kafka." https://docs.microsoft.com/en-us/azure/architecture/patterns/publisher-subscriber
On exam 3-Nov-2023. Went with proposed answer - 932/1000.