Gouvernance SOA : la phase de Change Time
Cohabitation de versions
Des services déployés en phase Run Time peuvent être changés pour s’adapter aux nouvelles exigences métier
Gestion des versions
- Règle 1
- Le message XML contient un numéro de version afin de permettre le contrôle du flux XML en production
- Via le namespace (espace de nommage) si non compatible ascendant
- Via l’attribute version XML si compatible ascendant
- Règle 2
- Le fournisseur doit favoriser la compatibilité ascendante
- Une nouvelle version N n’impacte pas les Consommateurs de la version N-1 (pas toujours possible)
- Règle 3
- Distinguer le cas d’une release sur les opérations (WSDL) et le cas d’une release sur les données (schéma XML)
Les contrat de services
- Expose une définition abstraite
- Nom du traitement
- Paramètres du message d’entrée et du message de réponse
- Nom, format, facettes de contraintes
- Exceptions (erreurs)
- Pré-conditions et post-conditions
- Expose une (des) définition(s) concrète(s) liée(s) à la définition abstraite (bindings techniques)
- Format techniques des messages
- Protocole de transport des messages
- En exploitation il faut garantir que les clauses du contrat sont exécutées… et pas d’autres
- Il faut découpler la validation du service de son code
- On peut utiliser :
- Un moteur de règles comme IBM - ODM (Operational Decision Management) ou JBoss BRMS (Business rules Management System) ou Drools pour la version open source de JBoss BRMS.
- WS-Policy - Xpath
Voir aussi : http://urbanisation-si.over-blog.com/
http://urbanisation-des-si.blogspot.fr/
http://urbanisation-si.eklablog.com/
A découvrir aussi
- Gouvernance SOA : la phase de Design Time (3)
- Un bon contrat, n'est pas un contrat signé mais un contrat standardisé
- Faites vos gammes : les design patterns de la gouvernance SOA
Retour aux articles de la catégorie Gouvernance SOA -
⨯
Inscrivez-vous au site
Soyez prévenu par email des prochaines mises à jour
Rejoignez les 719 autres membres