An Order microservice and a Fulfillment microservice are being designed to communicate with their clients through message-based integration (and NOT through API invocations).
The Order microservice publishes an Order message (a kind of command message) containing the details of an order to be fulfilled. The intention is that Order messages are only consumed by one Mule application, the Fulfillment microservice.
The Fulfillment microservice consumes Order messages, fulfills the order described therein, and then publishes an OrderFulfilled message (a kind of event message). Each OrderFulfilled message can be consumed by any interested Mule application, and the Order microservice is one such Mule application.
What is the most appropriate choice of message broker(s) and message destination(s) in this scenario?
A. Order messages are sent to an Anypoint MQ exchange
OrderFulfilled messages are sent to an Anypoint MQ queue
Both microservices interact with Anypoint MQ as the message broker, which must therefore scale to support the load of both microservices
B. Order messages are sent to a JMS queueOrderFulfilled messages are sent to a JMS topic
Both microservices interact with the same JMS provider (message broker) instance, which must therefore scale to support the load of both microservices
C. Order messages are sent directly to the Fulfillment microservicesOrderFulfilled messages are sent directly to the Order microservice
The Order microservice interacts with one AMQP-compatible message broker and the Fulfillment microservice interacts with a different AMQP-compatible message broker, so that both message brokers can be chosen and scaled to best support the load of each microservice
D. Order messages are sent to a JMS queueOrderFulfilled messages are sent to a JMS topic
The Order microservice interacts with one JMS provider (message broker) and the Fulfillment microservice interacts with a different JMS provider, so that both message brokers can be chosen and scaled to best support the load of each microservice
|
Download Printable PDF. VALID exam to help you PASS. |
 |
when we focus on the line “The intention is that Order messages are only consumed by one Mule application”, in this case, we cant use topic, because the topic has multiple subscribers, and each subscriber receives a copy of the msg, so we can not use the topic for the first message so we go with queue
after consuming the message its again broadcasts the message i.e we can focus on the line “can be consumed by any interested Mule application” we can see that we have to use the topic for this,
ie. we required two configurations first is a queue and the second is topic
we can find the combination of these two in the option D
so i will go with the option D
A central message broker is an anti-pattern for microservices .
Order microservice can communicate with 2 JMS providers ( 1 for publishing side and another for consuming side ).
So, D is an ok answer .. since, we should not anti-patterns. But, still B will also work if infra/jms instances is properly scaled ….
Most of these questions are incomplete and answers are not upto the point … Makes us confused … Not sure if these are actual questions :)!
…
B and D both will work. But B makes more sense.
Firstly most company don’t have 2 JMS brokers.
Secondly, two jms brokers may have compatibility issue.
Thirdly, the maintenance is an issue if we use two brokers, say, ActiveMQ and IBM MQ
Thus B is the best choice.
Based on Microservice principle of Distributed systems, each Order and fulfillment should have differen JMS providers which can be scaled up and down. Yes there will be more work related to Operational Overhead but we agree to that while following microservice approach
So the answer should be D
B should be correct. If you need to scale a JMS provider just add nodes to it scale horizontally or vertically by adding memory. Adding another provider adds Operational overhead and possibly cost.
I’ll go with B.
D says that the brokers (JMS providers) should be different, I dont agree with that part.
It can and should be the same broker in my opinion.
I agree on D… one of the brokers will be used by just two services… but the other will be used by many more… so the idea of scale both brokers make no sense… just scale the one that will have the most load..
I think D is the correct answer.
B