Modèle des services Runtime

Statut documentaire : architecture — voir Maturité et preuves.

Un service déclaratif n'implémente pas à lui seul une queue, un scheduler, un agent, un journal ou un serveur HTTP. Il sélectionne et configure une capacité Runtime enregistrée par le moteur ou par un package Runtime.

métadonnées service
  -> parser / structure déclarative
  -> définition du service
  -> lookup moduleClass / registre Runtime
  -> instance Runtime configurée
  -> cycle start / stop
  -> comportement du service

Trois niveaux doivent rester distincts :

• serviceGroup : regroupement au niveau package et frontière de déploiement ;
• serviceGroupDefinition : contrat et configuration réutilisables ;
• serviceInstance : instance concrète avec adresse, port, base, activation et paramètres spécifiques.

Les métadonnées communes incluent un identifiant stable, la famille du service, le binding d'implémentation, les diagnostics, la politique de démarrage, base URL/path, pages, paramètres, parsers et dépendances de packages Runtime.

Les bindings d'implémentation montrés dans les exemples utilisent des noms normalisés publics. Ils sélectionnent une implémentation concrète ; ils ne sont pas des concepts métier et ne doivent pas contaminer le vocabulaire du domaine.