A POC using Spring Boot and Apache ActiveMQ
The purpose of this proof-of-concept is to use Apache AMQ or Rabbit MQ as JMS Provider and develop a solution using Java to receive a message in a given text format, perform validations and invoke another REST-based microservice to convey the result of validations.
The scope of this project includes:
- Software code for the POC solution
- Test Automation with Jmeter
Below is the high level system architecture of this POC application.
The system is constructed from multiple distinct components. These components are briefly described as below.
- Message Producer API - This is the message producer layer, consisting of an API to accept/allow incoming messages and send them to the configured JMS queue. It provides a RESTful endpoint to accept text messages before pushing it to the queue.
- Message Consumer - This is a message consumer layer of the application which consumes the message from the queue, performs technical and business validations and further dispatches to the subsequent layer.
- Validation Manager API - This is the message validation layer of the application which exposes RESTful API to receive and manage messages.
- Data Manager API - This is the message processor/manager layer of the application which exposes RESTful API(s) to manage messages.
- Java 1.8
- Spring Boot 2.1
- Apache ActiveMQ 5.15
Below diagram is the typical sequence of events that occur during the consumption of a new message.
- For this POC, single instances of system components and queue server/node is considered. However, design allows any of the components to be scaled up as per the load.
- For reasons in #1, the Validation Manager API is separated from the Message Consumer component so that scaling decisions are not dependent on each other.
- No datastore is considered in this POC and all the information/data is visible diligently on persistent log files.
- Non functional requirements such as flexibility, extensibility, performance, reliability, testability and manageability are taken care while designing the solution.
- Failover/replay of queue messages is not configured in this POC. The commit mode is auto by default which can be changed easily in configurations.
- High availability of system components is not stressed in this POC.
Below diagram depicts the UML model for the Shipment Message Producer API. Operations depicted in this diagram originate from the RESTful interface. However, the incoming messages can be pushed to the queue via any other means as well.
Below diagram depicts the UML model for the Shipment Message Consumer application. Operations depicted in this diagram originate after the message is consumed from the queue. The action performed in the sequence in this component are shown under System Operations.
Below diagram depicts the UML model for the Shipment Message Validation Manager API. Operations depicted in this diagram originate after the message is is POSTed to this application using the RESTful interface by the consumer application. The validation of the message is performed pattern matching text parse technique alongwith simple conditions. The action performed in the sequence in this component are shown under System Operations.
Below diagram depicts the UML model for the Shipment Message Manager API. Operations depicted in this diagram originate from the RESTful interface provided to POST new messages to this manager application.
