Modification d’une interface existante

Dans la mesure du possible, implémentez une nouvelle interface pour votre application, plutôt que d’apporter des modifications à une interface existante. Si vous ne pouvez pas éviter de modifier une interface existante, utilisez de nouveaux types de données uniquement dans de nouvelles méthodes. L’introduction d’un nouveau type de données ou la modification d’un type existant est la source la plus courante de problèmes d’incompatibilité. Le modèle d’exécution RPC suppose que l’application de réception connaît les types de données qu’elle reçoit, de sorte que les données sont placées sur le réseau sans description de données générique. Lorsque le destinataire s’attend à un type de données différent de celui que l’expéditeur a placé sur le câble, le stub lève une exception (ou la transmission échoue d’une autre manière moins appropriée).

Une interface RPC est définie par son UUID et ses numéros de version principale et mineure. Lorsque vous modifiez une interface existante, vous devez ajouter les nouvelles méthodes à la fin de l’interface et modifier le numéro de version mineure. Si vous ajoutez des méthodes ailleurs ou apportez d’autres modifications à l’interface, vous devez également modifier le numéro de version principale.

De manière réaliste, il arrive que vous ne puissiez même pas modifier le numéro de version mineure, car un nouveau client ne peut pas communiquer avec un ancien serveur et vous ne pouvez pas mettre à jour le serveur. Le temps d’exécution RPC déclenche une exception, RPC_S_PROCNUM_OUT_OF_RANGE, lorsqu’un client appelle une méthode au-delà de celles spécifiées pour son interface avec le serveur. La solution de contournement consiste à laisser les numéros de version inchangés et à écrire votre code client pour gérer cette exception correctement, par exemple en dégradant ses performances ou par tous les moyens appropriés pour votre application.

Il existe une solution de contournement similaire pour un cas particulier de modification d’un type de données dans une méthode existante. Si vous avez une union dont les branches sont des pointeurs et qui n’a pas de branche par défaut pour les types non reconnus, vous pouvez ajouter une nouvelle branche qui utilise le nouveau type de données. Cela ne modifie pas la taille de la structure de données. Lorsque votre client communique avec un nouveau serveur, il peut utiliser le nouveau type de données. Toutefois, lorsque votre client communique avec un ancien serveur, l’heure d’exécution déclenche l’exception RPC_S_INVALID_TAG. Là encore, vous devez écrire votre code client pour gérer cette exception de manière appropriée.

Une interface DCOM est identifiée par son GUID. Dans DCOM, les interfaces sont considérées comme immuables et vous pouvez apporter des modifications uniquement en créant une nouvelle interface qui hérite de l’ancienne. Ces règles garantissent que les clients et les serveurs restent compatibles.