Rétrocompatibilité et Web Services

Question

Je suis un peu nouveau pour les services Web et une situation récemment venu où nous avons ajouté un élément à un type de données qui sont renvoyées au client. Les clients se sont plaints que cela a cassé leur mise en œuvre parce qu'il étouffait sur le nouvel élément qu'il ne s'attendait pas. (Nous fournissons les services via Axis2).

Pour moi, cela semble un changement inoffensif que le client doit être capable de gérer correctement (je l'ai travaillé avec des cadres de service non-Web où l'ajout d'informations en option était tout à fait acceptable). Je pourrais comprendre si nous supprimé ou renommé des champs qui causerait des problèmes pour le client.

En fait, je serait logique que la wsdl d'agir comme une interface. Si nous faisons un changement qui sous-types essentiellement cette interface, j'attendre le client d'ignorer joyeusement des éléments étrangers. Est-ce juste une courte venue des services Web, ou est-il une façon saine de faire des changements passifs aux services afin que les nouveaux clients peuvent obtenir les données supplémentaires alors que les anciens clients peuvent mettre à jour à loisir?

Answer 1

WSDL agit en fait comme un contrat plus d'une interface. Le WSDL décrit exactement ce que l'opération prévoit de « recevoir » et ce qu'elle attend de « retour ». Le plus proche analogie avec ce serait en C changer le prototype d'une fonction sans changer la fonction elle-même, ils correspondent à l'habitude et qui cause des problèmes.

Le WSDL plus spécifique est le comportement plus que vous « garantissez » d'être en place.

Si vous avez besoin de flexibilité dans vos données renvoyées (à savoir l'ajout / suppression de champs, etc.), vous pouvez faire une des opérations suivantes:

1. Version vos définitions WSDL et publier des services qui peuvent rediriger les anciennes versions pour les nouvelles versions
2. Utilisez plus abstraites types de retour de données, telles que XML pour masquer la complexité ou la modification des données.

2 a un peu plus de risques, mais il peut être géré avec XSD ou d'autres technologies. Vos exigences particulières du projet dicteront ce qui est acceptable.

Answer 2

Dans le passé, lorsqu'ils traitent avec les API WebService exposés, je suis toujours allé avec la philosophie de la date-versionnage. Malheureusement, il faut faire face à la rétrocompatibilité pour une API que vous relâchiez au public une fois que vous êtes hors du mode « bêta » (et parfois même à l'époque).

Ce que nous avons fait était très simple; le jour de la nouvelle API a été libéré, nous avions créer une structure de dossiers comme ceci:

http://mydomain.com/path/to/service/2009/12/17/servicename.svc

De cette façon nous savoir quelle version est la dernière juste en vérifiant la structure des dossiers, et nos clients ne seraient pas à vous soucier de casser des changements jusqu'à ce qu'ils soient prêts à mettre à niveau. A travaillé comme un champion pour nous; la seule chose que je pourrais avoir changé était d'utiliser un seul dossier afin qu'ils seraient plus faciles à voir tous ensemble:

http://mydomain.com/path/to/service/2009-12-17/servicename.svc

Answer 3

WSDL est efficacement votre interface SOAP publiée de votre service Web. De nombreux clients utilisent pour générer leurs mandataires clients qui exposent toutes vos méthodes de WebService dans leur langage de programmation de choix. La plupart de ces clients du code généré, sont très fragiles et choisiront de jeter une exception s'ils voient un élément qu'ils ne reconnaissent pas (ce ne est pas dans le WSDL) plutôt que de l'ignorer. Certains sont plus détendus et il est vraiment à la technologie client qu'ils utilisent de nouvelles années DataContract de dire Microsoft ont une interface IExtensibleData sur leurs clients pour tenir spécifiquement les données qu'ils ne reconnaissent pas qu'ils seront largement ignorer les éléments inconnus.

SOAP et proxy client le code généré se prête à ce genre de problèmes, car ils génèrent des clients qui veulent comprendre « le schéma ensemble » plutôt que seulement les bits qu'ils sont intéressés. La solution est pour eux d'utiliser un fichier XML Parser et il suffit de tirer les morceaux dont ils ont besoin.

Si votre service Web est en cours de développement ou le changement constant alors SOAP est vraiment pas le meilleur choix que cela signifie à chaque changement, ils devront se régénérer, reconstruire et redéployer leurs clients de services. En fonction de votre situation, vous voudrez peut-être envisager de fournir des services Web REST + POX (Plain Old Xml) à la place comme plus simple à analyser, car il ne possède pas les frais généraux de SOAP, peut être appelé via une URL normale et par la consommation par des environnements ne pas une bibliothèque SOAPClient (par exemple directement dans un navigateur, en utilisant AJAX)

Answer 4

Une réponse possible serait d'utiliser des groupes de substitution pour permettre aux modèles abstraits en vous de la XSD importer. La possibilité de traiter un tel groupe de substitution doit encore être validé par les cadres que vous utilisez pour appeler ces services.