Service Runtime Plane
Statut documentaire : architecture — voir Maturité et preuves.
Le Service Runtime Plane décrit les services techniques qui entourent l'exécution d'une application logiCells : exposition de capacités, communication, messaging, synchronisation, découverte ou adaptation à des systèmes externes.
Cette couche doit être distinguée de la publication métier. Une action ou collection publiée est un contrat du modèle ; un service Runtime fournit un moyen de transporter, héberger, router ou orchestrer ce contrat.
Positionnement
application model
-> published capabilities
-> service adapter
-> runtime service / transport
-> process, node, site or external system
Trois responsabilités à ne pas confondre
| Zone | Responsabilité |
|---|---|
| Publication | décider quelles capacités du modèle sont exposées |
| Communication | transporter appels, messages, événements ou flux entre frontières |
| Service Runtime Plane | héberger, configurer et opérer les adaptateurs et services nécessaires |
Familles de services
Selon la version et les modules installés, le Runtime peut être associé à plusieurs familles :
- HTTP / service endpoints ;
- messaging et brokers externes ;
- canaux ou RPC ;
- découverte et registre ;
- synchronisation ;
- WebSocket / flux interactifs ;
- adaptateurs vers des systèmes externes.
La présence d'une famille dans l'architecture ne garantit pas qu'un type de service, une balise de configuration ou un protocole précis soit un contrat public stable dans toutes les versions.
Contrat public vs configuration interne
La documentation publique doit privilégier :
- la capacité publiée ;
- le comportement observable ;
- les exigences de sécurité ;
- les garanties de transport ;
- les règles de durée de vie, retry, idempotence et compatibilité lorsqu'elles s'appliquent.
Les noms de classes privées du moteur, les tags de configuration historiques non certifiés et les détails d'instanciation internes ne sont pas des contrats publics.
Local et distant
Le même modèle de programmation doit pouvoir conserver ses contrats métier lorsque l'exécution passe d'un Runtime local à une frontière distante. Les différences opérationnelles — latence, erreurs réseau, authentification, timeout, cancellation ou retry — doivent rester explicites.
Pages détaillées
Les fiches sous Service-types/ sont publiées comme patterns d'architecture et d'exploitation. Elles n'exposent plus les anciennes classes internes ni les balises historiques comme contrats stables. Les formats de configuration exacts restent à valider contre la version du Runtime/module installée.