Bonjour,

Je ne veux pas tomber dans le débat de "est il normal/souhaitable/logique" d'avoir ou non de la gestion d'état, d'avoir ou non de la gestion de cache de données dans une architecture SOA.

De par ma modeste expérience, je ne peux que constater que les cas se posent tout de même, que ce soit purement court terme avant d'aller vers du sans état ou d'éliminer cette gestion de cache, ou parce que cela s'avère réellement nécessaire à moyen-long terme compte tenu de la situation présente d'un SI.

Divisions le problème en deux.

Gestion d'état

Pour l'heure, la gestion d'état semble principalement se baser sur 4 solutions :
- ID de session SSL,
- ID de session web via support de cookie,
- ID de session web via support de la réécriture d'URL,
- ID de "pseudo-session"via un champ des messages échangés (en header ou body pour du WS SOAP par exemple),

D'un point de vue service vers l'extérieur, pour des raisons d'interopérabilité généralement plus drastiques qu'en interne ou l'on peut "bricoler entre amis", toute autre solution que l'ID de pseudo-session est difficile à envisager.

D'un point de vue servie en interne au SI, tout serait possible, mais comment se passe par exemple la cohabitation entre WS .Net et WS Java quant il y a réécriture d'URL ?

Avez vous envisager d'autres solutions ?
Quels sont vos retours d'expérience en la matière ?

Evidemment, vous l'avez deviné vis à vis du deuxième sujet, maintenir un état implique souvent de... maintenir du cache de données pour gérer dans le temps l'expiration de ces sessions et de leurs données liées dans les back-ends...

Gestion de cache de données

J'ai rencontré pour l'heure deux écoles :
- ceux qui sont partisans de gérer le cache au plus près de l'utilisateur final, généralement en privilégiant un cache agrégeant N sources de données,
- ceux qui sont partisans de gérer le cache au plus près des back-ends, généralement en privilégiant un cache restreint à un type de données,

Là encore, j'avoue pour ma part ne pas avoir encore de doctrine stricte: je suis plutôt approche mixte pour ce qui ets interne au SI, mais, il est vrai, plutôt pour l'approche cache proche de l'utilisateur finale dans le cas de services fournis à l'extérieur du SI : je préfère privilégier avoir un ensemble de données cohérent à un instant T, sans devoir rappeler le back-end par la suite, au risque d'avoir des données modifiées / supprimées / indisponibles.
Evidemment, cela pose le problème de fraîcheur de données...

Là encore, quels sont vos propres retours d'expérience en la matière, toujours en gardant une perspective orietée services ?

Merci pour vos avis éclairés.