Qu'est-ce qui est considéré comme des modifications non cassantes ou rétrocompatibles d'un contrat WSDL?
Cette page répertorie les exemples suivants:
- Ajout de nouvelles opérations WSDL à un document WSDL existant
- Ajout de nouveaux types de schéma XML dans un document WSDL qui ne sont pas contenus dans les types existants
Mais existe-t-il une définition ou une norme lignes directrices sur les changements considérés comme rétrocompatibles. Ou en d'autres termes, quels changements pouvez-vous apporter à votre contrat, et attendez-vous toujours à ne pas briser vos clients.
2 réponses
J'ai passé du temps sur ce sujet particulier, et j'ai trouvé quelques lignes directrices dans un livre de Thomas Erl auquel je me réfère en bas. Voici ce qu'ils ont à dire;
Modifications Compatibles
- Ajout d'une nouvelle définition D'opération WSDL et des définitions de message associées
- Ajout d'une nouvelle définition de type de port WSDL et des définitions d'opération associées
- ajout de nouvelles définitions de liaison et de service WSDL
- Ajout d'un nouvel élément de schéma XML facultatif ou déclaration d'attribut à une définition de message
- réduction de la granularité de contrainte d'un élément de schéma XML ou d'un attribut d'un type de définition de message
- Ajout d'un nouveau caractère générique de schéma XML à un type de définition de message
- Ajout d'une nouvelle assertion de stratégie WS facultative
- Ajout d'une nouvelle alternative WS-Policy
Des Modifications Incompatibles
- renommer une définition d'opération WSDL existante
- suppression d'une opération WSDL existante définition
- modification de la MEP d'une définition d'opération WSDL existante
- Ajout d'un message d'erreur à une définition d'opération WSDL existante
- Ajout d'un nouvel élément de schéma XML requis ou d'une déclaration d'attribut à un message définition
- augmentation de la granularité des contraintes D'un élément de schéma XML ou d'une déclaration d'attribut d'une définition de message
- renommer un élément ou un attribut de schéma XML facultatif ou requis dans un message définition
- suppression d'un élément ou attribut de schéma XML facultatif ou requis ou caractère générique à partir d'une définition de message
- Ajout d'une nouvelle assertion ou expression WS-Policy requise
- Ajout d'une nouvelle expression WS-Policy ignorable (la plupart du temps)
Il y a un grand livre sur ce sujet particulier de Thomas Erl et al; le nom est Web Service Contract Design & Versioning pour SOA.
HTH.
Disclaimer: comme je l'ai mentionné, c'est un travail effectué par les auteurs du livre et je suis simplement le partager. Je ne suis pas non plus affilié de toute façon; j'ai juste aimé le livre:)
Des éléments de requête optionnels supplémentaires (minoccurs=0) peuvent également être rétrocompatibles - cela dépend de l'implémentation du service côté hôte. En outre, changer un élément de réponse obligatoire en optionnel pourrait également être rétrocompatible-cela dépend de l'implémentation de votre client.
Cette Zone est délicate.
Si vous êtes vraiment préoccupé par la rétrocompatibilité, envisagez de créer une nouvelle version du service pour les nouveaux clients et de conserver l'existant mise en œuvre pour les clients existants. En outre, en général, évitez d'envoyer des objets de domaine sur vos services-utilisez des Dto.
J'espère que cela aide.