Protocole ODESA

Open Decentralized Exchange Software Alliance (ODESA) définit un standard ouvert pour la communication structurée et sémantique entre systèmes d'information et agents intelligents, avec une attention particulière au secteur du bâtiment.

Objectifs du Protocole

  • Normaliser les échanges entre systèmes d'information hétérogènes
  • Faciliter l'interopérabilité entre agents intelligents
  • Garantir la sécurité et l'intégrité des données échangées
  • Établir un mécanisme de régulation inspiré par la cybernétique
  • Créer un écosystème ouvert et extensible pour les agents logiciels
Origine et Inspiration

ODESA s'inspire des principes fondamentaux de la cybernétique établis par Norbert Wiener, tout en intégrant les avancées modernes de l'IA. Cette approche de communication standardisée pour les agents autonomes rappelle le projet chilien CyberSyn des années 1970, mais avec les technologies et besoins d'aujourd'hui.

Concepts Fondamentaux

Agent ODESA

Entité logicielle exposant des "Compétences" via le protocole. Un agent peut être un service SaaS, un système d'information, ou un assistant IA.

Compétence

Capacité spécifique offerte par un agent (ex: building.checkRoomAvailability, invoice.createDraft).

Requête ODESA

Message structuré envoyé à un agent pour invoquer une compétence. Contient l'intention, les paramètres et le contexte.

Réponse ODESA

Message structuré retourné par un agent, indiquant le résultat (succès, données, échec).

Contexte de Transaction

Identifiant permettant de lier plusieurs requêtes/réponses au sein d'une interaction ou d'un workflow.

Payload Sémantique

Données échangées, potentiellement enrichies de méta-données ou de liens vers des ontologies pour clarifier le sens.

Relation avec VAILS.distributed

Le protocole ODESA est implémenté en s'appuyant sur les concepts de VAILS.distributed, où chaque agent est représenté comme un site au sens du modèle de programmation concurrente. Cela permet:

  • La composition parallèle de multiples agents
  • La séquence d'opérations à travers différents agents
  • Le pruning pour sélectionner la première réponse pertinente parmi plusieurs alternatives
  • La gestion des erreurs en cas de défaillance d'un agent

Architecture Technique

Architecture ODESA

L'architecture ODESA repose sur trois composants principaux interconnectés:

Nœud ODESA

Composant logiciel autonome qui expose une API REST et implémente le moteur d'exécution du langage concurrent ORC. Chaque nœud:

  • Publie ses compétences comme des sites ORC
  • Fournit une interface de communication standardisée
  • Implémente les mécanismes de sécurité et de non-répudiation

Moteur ORC

Implémentation du langage de programmation concurrente ORC qui permet:

  • L'exécution de workflows non-déterministes
  • La gestion des appels vers des sites distants
  • La synchronisation et orchestration des interactions

Couche de Sécurité

Basée sur les preuves à connaissance zéro (Zero Knowledge Proof) et le protocole Baseline:

  • Garantit l'intégrité des transactions
  • Assure la non-répudiation des échanges
  • Préserve la confidentialité des données sensibles

Spécification du Protocole

Structure des Messages

ODESA utilise un format inspiré de VVL (VAILS Virtual Language) pour ses messages, qui s'appuie sur la nature homoiconique de ce langage. Les messages sont structurés comme des listes imbriquées, similaires à LISP.

; Structure d'une Requête ODESA
[request
  :id "req-12345"
  :timestamp "2024-04-06T10:15:30Z"
  :source_agent "agent:orchestrator-alpha"
  :target_agent "agent:building-management-beta"
  :target_competence "building.checkRoomAvailability"
  :context_id "ctx-abc987"
  :payload [
    :building_id "bldg-123"
    :room_id "rm-456"
    :start_time "2024-04-10T09:00:00Z"
    :end_time "2024-04-10T11:00:00Z"
    :requirements [:projector :video_conf]
  ]
  :security_token "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
  :signature "d8e8fca2dc0f896fd7cb4cb0031ba249..."
]
; Structure d'une Réponse ODESA (Succès)
[response
  :id "resp-67890"
  :request_id "req-12345"
  :timestamp "2024-04-06T10:15:35Z"
  :source_agent "agent:building-management-beta"
  :status :success
  :payload [
    :available true
    :room_options [
      [ :room_id "rm-456" :name "Salle A" :capacity 12 ]
      [ :room_id "rm-457" :name "Salle B" :capacity 16 ]
    ]
  ]
  :signature "7d9fda3f28b5c6c01049edafa4c39423..."
]
; Structure d'une Réponse ODESA (Erreur)
[response
  :id "resp-11223"
  :request_id "req-12345"
  :timestamp "2024-04-06T10:15:32Z"
  :source_agent "agent:building-management-beta"
  :status :failure
  :error [
    :code "INVALID_TIME_RANGE"
    :message "End time must be after start time."
    :details [ :start "2024-04-10T11:00:00Z" :end "2024-04-10T09:00:00Z" ]
  ]
  :signature "a2dc0f896fd7cb4cb0031ba249d8e8fc..."
]

Définition des Compétences

Les compétences sont définies à l'aide d'une syntaxe déclarative qui décrit les paramètres attendus, les types de retour, et les contraintes:

; Définition d'une Compétence
[competence:define "building.checkRoomAvailability"
  :description "Vérifie la disponibilité des salles selon les critères"
  :version "1.0"
  :params [
    [ :name "building_id" :type "string" :required true ]
    [ :name "room_id" :type "string" :required false ]
    [ :name "start_time" :type "datetime" :required true ]
    [ :name "end_time" :type "datetime" :required true ]
    [ :name "requirements" :type "list[string]" :required false ]
  ]
  :returns [
    [ :name "available" :type "boolean" ]
    [ :name "room_options" :type "list[room]" ]
  ]
  :constraints [
    "end_time > start_time"
  ]
  :semantics [
    :ontology "https://schema.org/Event"
    :domain "BuildingManagement"
  ]
]

Modèles d'Interaction

ODESA supporte plusieurs modèles d'interaction entre agents:

Modèle Description Cas d'usage
Requête/Réponse Modèle synchrone simple où un agent envoie une requête et attend une réponse Vérifications simples, consultations de données
Publication/Souscription Un agent publie des événements, d'autres agents souscrivent pour être notifiés Notifications de changements, alertes en temps réel
Workflow Multi-étapes Une requête déclenche un processus complexe impliquant plusieurs étapes et agents Processus métier complets, orchestration de tâches
Concurrence parallèle Exécution simultanée de requêtes vers plusieurs agents Recherche multi-sources, agrégation de données
Pruning (premier arrivé) Sélection du premier résultat disponible parmi plusieurs agents consultés Recherche de disponibilité, obtention rapide d'une réponse valide

Implémentation avec VAILS.distributed

Le protocole ODESA est directement implémenté en s'appuyant sur les concepts de VAILS.distributed, où chaque agent est représenté comme un site. Les combinateurs d'ORC permettent d'exprimer des interactions complexes de manière concise.

Définition d'un Agent comme Site

; Définition d'un Site pour un Agent du Bâtiment
[site [buildingManager #building_id #room_id #start_time #end_time #requirements]
  ; Corps du site qui envoie une requête HTTP vers le nœud ODESA
  [httpsPOST "https://building-manager.example.com/api/odesa" 
    [["data" 
      [stringify [request
        :id [guid]
        :timestamp [now]
        :source_agent "agent:orchestrator-alpha"
        :target_agent "agent:building-management-beta"
        :target_competence "building.checkRoomAvailability"
        :context_id "ctx-" [guid]
        :payload [
          :building_id #building_id
          :room_id #room_id
          :start_time #start_time
          :end_time #end_time
          :requirements #requirements
        ]
        :security_token [getToken]
        :signature [sign]
      ]]
    ]]
  ]
]

Composition de Sites pour l'Orchestration

; Composition de sites pour trouver une salle disponible dans plusieurs bâtiments
[site [findAvailableRoom #start_time #end_time #requirements]
  ; Combinateur | (parallèle) pour rechercher simultanément dans plusieurs bâtiments
  [buildingManager "bldg-A" "" #start_time #end_time #requirements] | 
  [buildingManager "bldg-B" "" #start_time #end_time #requirements] |
  [buildingManager "bldg-C" "" #start_time #end_time #requirements]
]
; Composition séquentielle et traitement conditionnel
[site [reserveRoom #start_time #end_time #requirements]
  ; Combinateur >#x> (séquentiel avec variable liée) pour chaîner les opérations
  [findAvailableRoom #start_time #end_time #requirements] >#availableRooms> 
    [if [empty? #availableRooms]
      ; Si aucune salle disponible
      [returnError "NO_ROOMS_AVAILABLE" "Aucune salle disponible aux horaires demandés"]
      ; Sinon, réserver la première salle disponible
      [roomBooking 
        [getIn #availableRooms [0 "building_id"]] 
        [getIn #availableRooms [0 "room_id"]]
        #start_time 
        #end_time
      ]
    ]
]

Gestion des Erreurs avec le Combinateur de Défaillance

; Utilisation du combinateur ~ (défaillance) pour la gestion d'erreurs
[site [robustRoomBooking #building_id #room_id #start_time #end_time]
  ; Tentative de réservation avec gestionnaire d'erreur
  [roomBooking #building_id #room_id #start_time #end_time] ~ 
    ; Si la réservation échoue, essayez une salle alternative
    [findAlternativeRoom #building_id #start_time #end_time] >#alternative>
      [roomBooking #building_id #alternative #start_time #end_time]
]

Timeouts et Gestion des Délais

; Ajout de contraintes temporelles aux requêtes
[site [timedRoomQuery #building_id #room_id #start_time #end_time]
  ; Combinateur <#x< (pruning) avec timeout pour limiter le temps d'attente
  [buildingManager #building_id #room_id #start_time #end_time []] <#result< 
    [timeout 5000 [signal "TIMEOUT"]]
]

Boucle de Régulation Sémantique

; Implémentation de la boucle de contre-réaction sémantique
[site [semanticFeedbackLoop #input #expectedOutput]
  ; Générer une sortie avec l'IA
  [generateWithAI #input] >#output>
    ; Évaluer la qualité sémantique
    [evaluateSemantics #output #expectedOutput] >#evaluation>
      [if [> #evaluation 0.8]
        ; Si la qualité est suffisante, retourner la sortie
        #output
        ; Sinon, ajuster et réessayer avec le feedback
        [semanticFeedbackLoop 
          [enhance #input #output #evaluation] 
          #expectedOutput
        ]
      ]
]

Exemples d'Utilisation

Scénario: Gestion Intelligente d'un Bâtiment

Exemple 1: Réservation de Salle avec Contraintes

Cet exemple montre comment un orchestrateur utilise ODESA pour trouver et réserver une salle de réunion qui répond à des critères spécifiques (capacité, équipement) dans un bâtiment intelligent.

; Workflow complet pour une réservation de salle
[site [smartMeetingBooking #requester #attendees #start_time #end_time #equipment_needs]
  ; 1. Déterminer le nombre de participants
  [count #attendees] >#attendee_count>
  
  ; 2. Vérifier les disponibilités des participants
  [checkAttendeeAvailability #attendees #start_time #end_time] >#availability>
  
  ; 3. Si tous les participants sont disponibles, chercher une salle
  [if #availability
    [findAvailableRoom #start_time #end_time 
      [:capacity #attendee_count :equipment #equipment_needs]
    ] >#room>
    
    ; 4. Réserver la salle
    [bookRoom #room #requester #attendees #start_time #end_time] >#booking>
    
    ; 5. Notifier les participants
    [notifyAttendees #attendees #booking]
  ]
]

Exemple 2: Automatisation du Processus de Construction

Cet exemple illustre comment ODESA peut être utilisé pour coordonner différents systèmes impliqués dans un processus de construction complexe.

; Orchestration d'un processus de construction
[site [constructionProcess #project_id #phase]
  ; 1. Obtenir les détails du projet
  [getProjectDetails #project_id] >#project>
  
  ; 2. Paralléliser les vérifications préliminaires
  (
    [checkRegulations #project #phase] >#regulations>
    [checkMaterials #project #phase] >#materials>
    [checkResources #project #phase] >#resources>
  ) >#checks>
  
  ; 3. Si toutes les vérifications passent, planifier les tâches
  [if [allPassed #checks]
    [scheduleTasks #project #phase #resources #materials] >#schedule>
    
    ; 4. Distribuer les tâches aux équipes
    [assignTasks #schedule] >#assignments>
    
    ; 5. Mettre en place le monitoring
    [setupMonitoring #project #phase #assignments]
  ]
]

Prochaines Étapes et Standardisation

Le protocole ODESA est en cours de développement actif, et plusieurs initiatives sont prévues pour en faire un standard ouvert:

  • Publication de RFCs (Request For Comments) détaillant les aspects techniques du protocole
  • Développement d'implémentations de référence open source
  • Création d'un registre centralisé pour la découverte des compétences
  • Établissement d'un comité de gouvernance pour superviser l'évolution du protocole
  • Organisation d'ateliers d'interopérabilité pour valider les implémentations
Pour Contribuer

Les développeurs et organisations intéressés par la participation au développement du protocole ODESA peuvent rejoindre l'alliance en contactant l'équipe via le site web ou en contribuant aux dépôts GitHub du projet.