J'en appelle au élites :
 
Je développe ce qu'on appelle ici (et surement ailleurs) une infrastructure : une appli utilisée par d'autres appli.
 
cette infrastructure est mise à disposition sous forme de webservice.
 
On me demande de gérer la rétro-compatibilité en cas d'évolution du code.
 
Je vois arriver un problème si les signatures des méthodes exposées par le WS changent, ou si les objets manipulés par le WS change.
 
Donc, je pensais dissocier le coté client du coté serveur. Coté client, je ne manipule en fait qu'une Map<String, String>, qui fait correspondre les noms des attributs avec leur valeur, et des attachement SOAP pour les flux de données. Coté serveur, quand le message arrive, je traduis la Map en un (arbre d')objet concret que je manipule coté serveur comme je veux.
 
Si mes objets concrets évolue coté serveur, il me suffit en fait de gérer des valeurs initiales pour les nouveaux attributs, et de ne pas traiter ceux qui ont disparus.
 
Je fourni au client des méthodes pour passer des dates, des int, des float (...) et des méthodes directes (genre setApplicationCode(String code), setDateDemande(Date date)) pour lui cacher la Map<String, String>.
 
est-ce que ça semble un design potable, une belle usine à gaz, une simple idée à la con () ?
merci de vos avis.

Coté serveur tu as le droit d'ajouter des <wsdl: operation/> au webservice sans que cela gène coté client (pour l'avoir fait en entreprise).
En fait cela revient a utilisé le principe de méthode @deprecate, elles sont tjs présentes mais non recommandées.
Tu laisses les anciennes opérations et tu en crées de nouvelles.
 
En fait la méthode que tu proposes, revient à ne pas utiliser la puissance des webservice en fait. Puisque tu ne vas passer qu'une seule structure de strings, autant ne pas perdre de temps avec le xml... et utiliser une servlet de communication, voir RMI.
 
Je te déconseille fortement cette méthode en tout cas, car tu perds tout ce qu'apporte les XmlSchema (validation des structures etc...)
 
EDIT: de plus il faut que tu détaches ta couche service de ta couche process, ce qui permet de faire pointer 2 methodes de service sur en fait le meme process.
Professionnellement j'utilise pas mal de couche dans l'application : service => process => transactional manager => dao => datasource

en fait, je suis d'accord avec toi sur le fond.
 
Malheureusement, le WS que l'on developpe est potentiellement installé sur une seule machine.
 
Coté applications appellante, deux serveurs de prod sont à disposition (prod 1 et 2). Ils ne sont pas forcement dans la même version des applications. Ce qui veux dire que potentiellement, un client obsolète peut essayé d'appeller le WS.
 
Le problème se pose si la signature de la méthode ne change pas, mais que les objets transportés sont différents : la structure XML reçue n'est pas valide pour le désérializer, qui ne trouve pas certains attributs, ou en trouve alors qu'il ne les attend pas (c'est plus ça qui bloque).

Je te conseille de dupliquer les méthodes. Avec des Version1 Version2 Version3 ...
Tu peux aussi avoir des wsdl: Port et wsdl: Service différent.

vraiment
 
dupliquer les méthodes, ça me semble bof, et le problème de modification des objets transportés impliquerait aussi de dupliquer les objets, puisque les noms des classes devraient changer...

Dans ce cas n'utilise pas de web services SOAP, ca serait se prendre la tete avec du xml pour juste une liste de string.
 
Le principe du contract de service wsdl, c'est de définir des appels de méthodes, les structures d'objets, les restriction nillable, multiplicité, etc... De telle manière qu'un client avec juste le wsdl devrait pouvoir comprendre comment appeler le service.
 
Si tu transfères des strings qui peuvent représenter tout et rien, tu es obligés de dupliquer l'interpreteur à la fois sur le serveur et le client...
 
On appelle ça réinventer la roue carrée.

je suis bien d'accord