Architecture orientée services et objets évolutifs partagés entre applications

Question

Je suis sur le point de commencer à écrire une suite de services WCF pour une variété d'applications métier. Cette SOA sera très immature au départ et finira par évoluer vers une couche de middleware puissante.

Malheureusement, je n'ai pas le luxe d'écrire un ensemble complet de services, puis de recréer des applications pour les utiliser, ce sera un processus itératif fait au fil du temps. La question que j'ai est autour de l'évolution (modification, ajout, suppression de propriétés) des objets métier. Par exemple: Si vous avez une SOA exposant un service qui renvoie obj1. Ce service est consommé par app1, app2, app3. Imaginez que l'objet est modifié pour app1, je ne veux pas avoir à mettre à jour app2 et app3 pour les modifications apportées pour app1. Si la modification est une propriété add, elle fonctionnera correctement, elle ne sera simplement pas mappée, mais que se passe-t-il lorsque vous supprimez une propriété? Ou changer une propriété d'une chaîne à un int? Comment gérez-vous le changement?

Merci d'avance pour votre aide?

PS: Je l'ai fait faire une petite image, mais apparemment je besoin d'une réputation de 10 de sorte que vous devrez utiliser votre imagination ...

Answer 1

L'objectif est de limiter les changements que vous forcer vos clients d'avoir à faire immédiatement. Ils pourraient éventuellement devoir apporter quelques changements, mais j'espère que ce n'est que dans des circonstances inévitables, comme ils sont plusieurs versions derrière et vous êtes en train de l'éliminer complètement.

changements insécable peuvent être:

1. Ajout en option propriétés
2. Ajout de nouvelles opérations

changements Casser comprennent:

1. Ajout nécessaire propriétée s
2. propriétés Retrait
3. Modification des types de données de propriétés
4. Changer le nom de propriétés
5. opérations Retrait
6. opérations Renommage
7. Modification de l'ordre des propriétés si spécifié explicitement
8. fixations Modification
9. Modification de l'espace de noms de service
10. Modification du m le fonctionnement de l'opération. Ce que je veux dire par là, par exemple, est que l'opération a toujours renvoyé tous les enregistrements mais qu'elle a été modifiée pour ne renvoyer que certains enregistrements. Cela casserait la réponse attendue des clients.

Options:

1. Ajouter une nouvelle opération pour gérer les propriétés mises à jour et la logique. Modifiez le code derrière l'opération d'origine pour définir de nouvelles propriétés et refaites la logique de service si vous le pouvez. N'oubliez pas de ne pas changer le signifiant de l'opération.
2. Si vous souhaitez supprimer une opération que vous ne souhaitez plus prendre en charge. Vous obligez le client à devoir changer à un moment donné. Vous pouvez ajouter une documentation dans le fichier wsdl pour informer le client qu'il est obsolète. Si vous laissez le client utiliser votre contrat dll, vous pouvez utiliser l'attribut [Obsolète] (il n'est pas généré dans wsdl final, c'est pourquoi vous ne pouvez pas l'utiliser pour tous)
3. Si c'est un grand changement, une nouvelle version du service et/ou de l'interface et du point de terminaison peut être créée facilement. -À-dire v2, v3, etc. Ensuite, vous pouvez les clients passer à la nouvelle version lorsque le moment est venu

Voici aussi un bon organigramme de « Apress - Pro WCF4: pratique mise en œuvre Microsoft SOA » qui peut aider .