360T

Technical Interview Task Solution for 360T

This project implements a two-player communication system in Java, tailored for 360T. It supports two modes of operation:

1. Reactive In-Process Implementation: Both players communicate within the same Java process using reactive programming principles.
2. Separate Processes Implementation: Each player runs in a separate Java process, simulating real-world inter-process communication (IPC).

The system is built with modularity, clean design principles, and extensibility in mind.

---

Directory and File Structure

The project follows a structured layout to ensure maintainability and clarity:

src
├── main
│   ├── java
│   │   └── de
│   │       └── three
│   │           └── sixty
│   │               ├── reactive       # In-process implementation
│   │               │   ├── InProcessApp.java   # Main class for reactive implementation
│   │               │   └── Player.java         # Player class for message handling
│   │               ├── separate       # Separate processes implementation
│   │               │   ├── SeparateProcessApp.java # Main class to launch separate processes
│   │               │   └── PlayerProcess.java       # Logic for each player's separate process
│   │               ├── model          # Domain models
│   │               │   └── Message.java         # Encapsulation of messages
│   │               └── shared         # Utilities
│   │                   └── LoggerUtil.java      # Logging utility for players
├── test
│   ├── java
│   │   └── de
│   │       └── three
│   │           └── sixty
│   │               ├── reactive
│   │               │   ├── PlayerTest.java
│   │               │   ├── InProcessAppTest.java
│   │               ├── separate
│   │               │   ├── SeparateProcessAppTest.java
│   │               ├── shared
│   │               │   ├── LoggerUtilTest.java
├── run.sh                # Shell script for building and running the application
├── Dockerfile            # Docker configuration for containerized runs
├── pom.xml               # Maven project configuration file

---

Design Patterns Used

This project leverages several design patterns to achieve a robust and maintainable architecture:

1. Observer Pattern:

   • Where Used: In the Reactive In-Process Implementation.
   • Purpose: Players (Initiator and Responder) act as observers of reactive message flows.
   • Benefits:
     • Enables reactive, event-driven communication.
     • Decouples message handling logic from the main process.

2. Mediator Pattern:

   • Where Used: In the Reactive In-Process Implementation.
   • Purpose: The Flux stream acts as a mediator between the two players, coordinating message exchanges.
   • Benefits:
     • Simplifies communication logic.
     • Reduces dependencies between interacting classes.

3. Singleton Pattern:

   • Where Used: In the LoggerUtil class.
   • Purpose: Ensures a single instance of the logger exists for each player.
   • Benefits:
     • Centralizes logging configuration.
     • Ensures consistent log file handling.

4. Builder Pattern:

   • Where Used: Conceptually in the Message class.
   • Purpose: Encapsulates message data, providing flexibility for adding metadata (e.g., timestamps) in the future.

---

How to Run the Application

Pre-Requisites

• Java 21 or higher
• Maven 3.6 or higher
• Docker (for containerized execution)

---

Run Locally

1. Build the Project

Run the following commands from the project’s root directory:

mvn clean package

2. Run the Application

• For In-Process Reactive Implementation:

  ./run.sh inProcess 10

  This will run the communication system with 10 messages exchanged between Initiator and Responder.

• For Separate Processes Implementation:

  ./run.sh separateProcess 10

  This will run two separate processes for Initiator and Responder, simulating real-world IPC.

---

Run in Docker

1. Build the Docker Image

Run the following command to build the Docker image:

docker build -t player-communication .

2. Run the Application in a Container

• For In-Process Reactive Implementation:

  docker run -it player-communication ./run.sh inProcess 10

• For Separate Processes Implementation:

  docker run -it player-communication ./run.sh separateProcess 10

---

Testing

The project includes a comprehensive test suite to ensure the correctness of the implementation. To run the tests locally:

mvn clean test

Key Test Scenarios:

1. Player Class:

   • Validates the sendMessage and receiveMessage methods.
   • Verifies log file creation and content.

2. Reactive In-Process Communication:

   • Ensures seamless reactive message exchanges between Initiator and Responder.

3. Separate Processes Communication:

   • Tests the setup and interaction between separate processes for Initiator and Responder.

4. Logging Utility:

   • Confirms proper logging for each player's actions.

---

Logging

Each player’s actions are logged to separate files in the target directory:

• target/initiator.log: Logs actions for the Initiator.
• target/responder.log: Logs actions for the Responder.

The logs contain details of all messages sent and received.

---