A logistics firm runs IBM MQ on premises and SOAP mainframe jobs, needs REST APIs for mobile apps with payload reshaping and durable buffering during outages. Which integration pattern modernizes legacy systems with data transformation?
Select an answer to reveal the explanation.
Short Explanation
You need a translator, not just a longer cable to the mainframe. You'll front old queues with modern doors using API Gateway shaping payloads on the fly. Buffered messages survive outages gracefully.
Full Explanation
Correct pattern works because API Gateway supplies managed REST APIs with auth, throttling and validation for mobile apps, Lambda supplies serverless SOAP-to-JSON reshaping without touching mainframe code, and Amazon MQ supplies managed ActiveMQ or RabbitMQ brokers with persistent queues and standard messaging protocols such as JMS and AMQP that can be bridged to on-premises IBM MQ for store-and-forward buffering during outages. SNS-based design keeps REST and Lambda transforms but fails durability since SNS is push fan-out without persistent per-consumer queues, replay, or JMS transactions, so cannot buffer through outages or mirror IBM MQ semantics. Kinesis-based design keeps REST and transforms with ordered scale but fails brokerage since Kinesis is an append-only stream log with retention and shard replay, not a JMS broker with queues, selectors, transactions and dead-letter handling required for MQ modernization. ALB-based container design keeps Amazon MQ durability but fails modernization since Application Load Balancer with ECS provides routing to services without API management, model validation, or lightweight transform logic, forcing custom mediation code. Exam caveat: map broker versus queue versus stream versus notification by protocol and persistence, as stems use durable buffering to signal JMS transactions. Practical check: confirm JMS client compatibility, test Lambda mappings with real SOAP envelopes, and simulate outage to verify buffered messages drain correctly on reconnect.