Finalement, lorsque nous concevons une application distribuée avec WCF, les étapes principales sont toujours les mêmes :

• Etape 1 : les contrats de données.
• Etape 2 : les contrats de service.
• Etape 3 : l’implémentation des services.
• Etape 4 : le processus porteur et la sécurisation éventuelle des accès.
• Etape 5 : les clients.

Dans notre exemple, nous disposons déjà des contrats de données et du métier que nous souhaitons mettre à disposition via WCF. Je fournirai donc le processus porteur sous la forme d’une petite application console ainsi qu’une petite application cliente de test. Par contre, il restera à générer à la volée les contrats de service et c’est justement l’objet de l’article.

Pour cela, je propose de créer une classe qui sera chargée de générer une Assembly à la volée via « CodeDom » et contenant une interface unique que je qualifierai de façade.

 

 

Le point d’entrée principal sera la méthode d’instance « GetContractAssembly » qui se chargera de renvoyer l’Assembly générée et chargée en mémoire. Pour simplifier l’exemple, tous les contrats d’opération (indifféremment selon leur classe d’appartenance) seront décrits sur cette façade. Ce qui nous donnera pour les classes métier exemples décrites plus loin dans l’article :

La manière d’architecturer une application WCF impose que le contrat de service soit forcément implémenté par le service proposé. Ce qui nous empêche de mettre directement à disposition les classes métiers. C’est pourquoi j’en profite aussi pour générer une implémentation « fake », elle-même implémentant l’interface façade regroupant tous les contrats d’opération, ce qui nous donne :

A partir de là, j’avais deux possibilités :

• Soit de générer un contenu « fake » par opération et de produire les appels sur les bons objets en mémoire moi-même via un « Operation Invoker ».
• Soit de générer directement le code d’appel vers les méthodes des bons objets dans l’implémentation de la façade.

Pour des raisons de simplicité, mais aussi pour montrer un exemple d’extensibilité d’opération d’invocation, j’ai choisi la première solution. Par contre, cette dernière impose quand même deux choses :

• Il faut générer quand même les bons paramètres des contrats d’opération (méthode « GenerateParameters » de la classe « DynamicHost »).
• Dans le cas d’une fonction renvoyant quelque chose, il faut générer une valeur de retour « fake » (méthode « GenerateReturnValueIfNeeded » de la classe « DynamicHost »).

J’en ai aussi profité pour ajouter un comportement permettant de récupérer via une url http, les métadonnées ainsi générées. Par contre, je n’ai ajouté aucune possibilité de paramétrage du binding utilisé (« NetTcpBinding »). Il en va de même pour le MexEndPoint (« MexTcpBinding »). Ce qui nous donnera en définitive les métadonnées suivantes accessibles via l’url suivante « http://localhost:1111/THB.Sample.ServiceContracts.IFacade/HttpGetUrl » :

Si vous travaillez sur Vista ou Seven, vous tomberez probablement sur ce message d’erreur à la première utilisation : « http could not register URL http://+:1111/THB.Sample.ServiceContracts.IFacade/HttpGetUrl/. Your process does not have access rights to this namespace (see http://go.microsoft.com/fwlink/?LinkId=70353 for details). ». Pour résoudre cela, il suffit d’exécuter l’instruction suivante à des fins d’autorisation :

Une fois tout ceci réalisé, il me restait quand même une problématique à résoudre au niveau de l’extensibilité d’invocation d’opération. En effet, je connaissais le nom de l’opération à invoquer, mais absolument pas le nom de la classe qui la portait, encore moins le nom de l’Assembly correspondante. J’ai envisagé plusieurs solutions pour résoudre cette problématique :

• Se servir de la notion d’action d’un service WCF contenu dans le WSDL
• Gérer un cache serveur fonction du nom unique de l’opération permettant de connaitre l’Assembly et la classe d’appartenance.

J’ai retenu la première solution car j’ai considéré que la propriété « Action » de l’attribut « OperationContract » servait justement à dispatcher le message vers la bonne opération, il me semblait donc naturel de procéder de la sorte. Il me restait donc à retenir format d’adressage unique que voici : « Assembly/Class/Method/MethodRenamed » où :

• « Assembly » : nom partiel de l’Assembly
• « Class » : nom complet de la classe
• « Method » : nom de la méthode à exécuter au final
• « MethodRenamed » : en cas de surcharge de méthode et/ou en cas de nom dupliqué de méthode dans plusieurs classes, « MethodRenamed » représente un nom unique de méthode déterminé par rapport au nom originel de la méthode et suffixé par un indice unique.