Projet Privalis

1. Conception & Tests à Grande Échelle

L'application a été restructurée selon les meilleures pratiques de conception logicielle. Pour garantir la fiabilité du système sous charge, nous avons mis en œuvre une suite de tests unitaires massifs (JUnit) et des tests d'intégration simulant des centaines d'enchérisseurs simultanés.

2. Déploiement Conteneurisé (Docker)

Pour simplifier l'installation et assurer la reproductibilité de l'environnement, l'intégralité du système (Serveur, Client, Base de données Oracle) est désormais conteneurisée via Docker. Un simple docker-compose up permet de déployer l'infrastructure complète.

1. Dispatching Dynamique & Routage

Le serveur reçoit des requêtes JSON-RPC. Pour éviter un code spaghetti de tests conditionnels (if/else), j'ai mis en place un Routeur Dynamique. Ce dernier identifie le contrôleur et l'action à exécuter à partir du JSON pour invoquer la logique associée via une référence de méthode.

Automatisation Quartz : Le serveur s'appuie depuis la Phase 1 sur le scheduler Quartz pour automatiser l'ouverture et la fermeture des sessions d'enchères à la milliseconde près, garantissant une intégrité temporelle absolue sans intervention humaine.

// Dans Routeur.java - Recherche dynamique de l'action
private static Function<JSONObject, JSONObject> getMethod(JSONObject json) {
    String action = json.get("action").toString();
    String nomController = json.get("controller").toString();

    for (AbstractController controller : controllers) {
        if (controller.getNom().equals(nomController)) {
            if (controller.contientAction(action)) {
                IMethodeControlleur methode = controller.getAction(action);
                return methode::action; // Dispatching via référence de méthode
            }
        }
    }
    return null;
}

Logique : Cette approche découple totalement la couche réseau des contrôleurs métiers. Ajouter une fonctionnalité consiste simplement à enregistrer une méthode dans un contrôleur ; le serveur la reconnaîtra automatiquement sans modification du code source de routage.

2. Gestion Multithread & BufferSortie

Dans un environnement socket, l'envoi de messages est une opération bloquante. J'ai créé la classe BufferSortie pour implémenter un modèle Producteur/Consommateur thread-safe s'appuyant sur des CompletableFuture.

// Dans BufferSortie.java - Synchronisation via Future
public class BufferSortie {
    private static final Map<String, CompletableFuture<JSONObject>> buffers = new ConcurrentHashMap<>();

    /** Appelé pour envoyer la réponse au bon client */
    public static void setBuffer(String id, JSONObject buffer) {
        CompletableFuture<JSONObject> future = buffers.get(id);
        if (future != null) {
            future.complete(buffer); // Produit et réveille le client
        }
    }

    /** Appelé pour attendre le résultat du contrôleur */
    public static JSONObject readBuffer(String id) {
        CompletableFuture<JSONObject> future = buffers.get(id);
        return future.get(); // Bloquant jusqu'au setBuffer
    }
}

Logique : Cette architecture garantit qu'un client avec une connexion lente n'impacte jamais les performances globales du serveur. Le thread métier "dépose" le message et repart immédiatement s'occuper des autres requêtes.

3. Le Moteur de Persistance (ORM)

Sans utiliser de bibliothèque externe, j'ai développé un ORM capable de mapper des graphes d'objets Java complexes vers du JSON, gérant automatiquement les clés primaires et les relations entre tables.

// Dans MapperObjet.java - Détection de cycles
public static TreeMap<String, Object> mapper(AbstractDataObject modele, ArrayList<Object> visites) {
    visites.add(modele);
    // ...
    for (Field champ : champs) {
        Object object = methode.invoke(modele);
        if (!visites.contains(object)) {
            // Sérialisation récursive si l'objet n'a pas été visité
            map.put(nomAttribut, MapperObjet.mapper((AbstractDataObject) object, visites));
        }
    }
    return map;
}

Défi technique : Gérer les cycles (ex: Vente -> Enchère -> Vente). Mon ORM maintient un registre d'objets déjà visités lors de la sérialisation récursive, injectant des références là où une boucle infinie se formerait normalement.

Abstraction du Protocole

Côté client, la gestion du protocole cryptographique complexe (Vickrey) est isolée dans une interface ProtocoleEnchere. Cette abstraction permet de définir des étapes de communication séquentielles et interchangeables pour la gestion des enchères.

// Dans ProtocoleEnchere.java - Orchestration des étapes
@Override
public void run() {
    // Phase 1 : Soumission de l'enchère
    EnvoiDeEnchere envoiDeEnchere = new EnvoiDeEnchere(prix);
    byte[] chiffreOriginal = envoiDeEnchere.executer(getClient());

    // Phase 2 : Réception du broadcast et vérification
    VerificationBroadcast verificationBroadcast = new VerificationBroadcast(chiffreOriginal, idEnchere);
    Boolean signatureCorrecte = verificationBroadcast.executer(getClient());

    if (!signatureCorrecte) {
        // Signalement d'une fraude détectée
        new ErreurSignatureBroadcast(idEnchere).executer(getClient());
    }
}

Le modèle synchrone du client : Le client suit un automate fini. Il envoie une donnée et attend *précisément* le type de réponse attendu par le protocole (ex: Signature z du serveur). Cette certitude facilite la vérification des preuves cryptographiques à chaque étape.

Comparaison : Sync (Client) vs Event (Serveur)

Le projet force une cohabitation entre deux paradigmes :

• Client (Sync-like) : Précis, facile à vérifier cryptographiquement, assure que chaque phase est validée avant la suivante. Inconvénient : Moins souple.
• Serveur (Event-driven) : Réagit aux messages sans connaître l'historique complet. Avantage : Supporte des milliers de connexions simultanées sans blocage.

Phase 1 : Enchère Homomorphe

L'enchérisseur encode son prix bi et le chiffre via le protocole de Damgård-Jurik : ci = Enc(B^bi ; ri) mod N^s+1. Le serveur (S) recueille ces chiffrés sans pouvoir les lire et calcule le produit homomorphe c = Π ci. Cette propriété permet d'agréger les offres tout en préservant le secret total.

Phase 2 : Ouverture & Autorité

L'Autorité (A) reçoit le produit c, vérifie la signature globale du serveur, et utilise sa clé secrète pour déchiffrer. Grâce à la structure mathématique (1+N)^m du protocole Damgård-Jurik, l'Autorité peut extraire le second prix p2 sans jamais avoir eu accès aux offres individuelles originales.