A proof of concept Apache ActiveMQ Artemis + ASP.NET WebAPI2 to model a Brokered Request-Reply Enterprise Architecture Pattern
- AMQRR.Caller Console Runnable - POSTS randomly generated Order objects at .API with a HttpClient and waits for a response.
- AMQRR.API ASP.NET WebAPI2 Runnable - Receives Order objects and sends them to a message queue with a request-based correlationId and waits for a response message with the same correlationId from a reply queue.
- AMQRR.Common Shared Class Library - Contains shared models and reusable common classes.
- AMQRR.Processor Console Runnable - Consumes messages from a messagequeue, before returning a new message with the same correlationId into a reply queue.
The main process generates a random CustomerId and then uses RandomOrderFactory to create randomised Order and child OrderLine instances with per-caller incremental OrderId & OrderLineId counters.
These Order instances are then submitted to the api/orders/post http action on the AMQRR.API, one every second.
A response is expected from each request, containing the same Order & child OrderLines.
20 seconds is given by the HttpClient before failure, roundtrip time is displayed.
MqController Superclass to handle the grunt of the work for both Request-Reply and Point-To-Point brokering interactions with Apache Artemis, running on a default localhost instance (port 61616).
This is in turn inherited by OrdersController which only has to worry about queue selection and serialization concerns.
Request-Response demands a reply queue and a timeout/expiry, as the external caller will likely be waiting for a response within a standard http timeout (20 secs), waiting any longer would serve no purpose. Broker messages are additionally supplied with an expiry to match this, a seperate reply queue, and a correlationID so that the request can quickly identify the correct reply message to consume when available.
Point-To-Point carries no enforced expiry or reply queue concerns, by definition it only needs to ensure that the message reaches the broker.
MqService singleton is spawned during Global.asax so that broker Connection and Session instance can be re-used across controller/action invokes.
The main process opens two listener delegates on two queues.
The handlers
Contains shared models and libraries primarily for the API and Processor.
MqSession is used to collate the instantiation of a broker client and is used in both of these projects.
