wildfly-extras/first-responder-demo

first-responder-demo's Issues

Architecture issue: ResponderSimulatorTask singleton bean and scaling out.

The bean ResponderSimulatorTask is annotated with @singleton.
The singleton bean has the doMoveResponderLocation method that retrieves all the MissionEntity objects from the database.

Consider what happens when more than 1 EAP instance is created. Each EAP instance will use it's own ResponderSimulatorTask bean instance. Each bean will retrieve and be processing either an identical or overlapping list of MissionEntity objects. This will cause the callee method MissionService.doResponderNextMove to cause the database to raise OptimisticLockExceptions or some sort of PSQLException to the same effect.

Create event for responders

When responders are created via the REST resource, a new event needs to be fired into Kafka. Currently we have updatedEvent only.
The benefit of doing this is, that the UI will listen to the create event and update the responders on the MissionCommanders screen.

The topic is: topic-responder-event
The CloudEvent generated should be as follows
HEADER: ce_source: emergency-response/responder-service, ce_specversion: 1.0, ce_time: 2022-08-31T13:28:40.871191Z, ce_type: ResponderCreatedEvent, content-type: application/json
{
"responder": {
"id": "34",
"name": "Ezekiel Rogers",
"phoneNumber": "[phone]",
"latitude": 34.1706,
"longitude": -77.949,
"boatCapacity": 10,
"medicalKit": false,
"available": true,
"person": false,
"enrolled": true
}
}

Human Responder in the emergency console

At the moment the human interaction element with the missions is disabled. this is also due to the fact that we have switched off the keycloak integration.
The flow works as such as that a user registers on the emergency console via keycloak. hence they would have a single-signon experience and the responder data will be written to our database.
This will allow the user logged in to participate in the simulation by acting as a real responder.

For the first draft this has been omitted.
To do this we will need to have a realm file e.g. https://github.com/Emergency-Response-Demo/install/tree/master/ansible/resources/sso_realm
And the following theme: https://github.com/Emergency-Response-Demo/emergency-sso

Architecture issue: Using a Singleton bean in a scalable application.

Using a Singleton bean in an application that is intended to scale out is flawed. For 2 reasons:

• Becomes a bottleneck that will limit the maximum rate of request processing on a single server instance
• Limits the number of EAP server instance. See #7

Instead it is better to architect the system to use work stealing or a messaging solution that supports JMS specification. Allowing the capability for EJB Message Driven Beans in EAP to process MissionEntity objects in the first responder application.
This is crucial in a distributed system with more than 1 EAP server instance.

Docker compose file for easier provisioning of the local environment

Currently we have the following services running on the local machine

• Kafka (Zookeeper, Server)
• Postgresql
• Wildfly 26 final
• Emergency-console

The emergency console can also integrate with Keycloak, at the moment this integration is disabled, but can be added.

To bring up the environment we should setup a docker-compose file.