Afin d’illustrer les capacités d’extensibilité de WCF en terme d’invocation d’opération, je vais vous décrire l’exemple fonctionnel que je vais mettre en œuvre. Dans cet exemple, j’ai voulu sortir des sempiternels exemples de trace et de mise en cache des appels que l’on peut trouver de-ci de là sur le Web.

Ce besoin fonctionnel part en fait d’un regret que j’ai toujours eu en termes de simplification et d’outillage de WCF dans Visual Studio. Jusqu’à maintenant (VS 2008, SP1), la mise en place d’une solution WCF respecte des règles très strictes et pas forcément assimilables rapidement par les développeurs non expérimentés en distribution de couches logicielles.

J’ai en fait toujours rêvé d’un outil intégré où nous n’aurions qu’à lister graphiquement un ensemble d’assemblies et de choisir d’exposer ou non telle ou telle méthode, de telle ou telle classe métier, sur tel ou tel protocole, sur telle façade. Malheureusement et même si Visual Studio 2010 et WCF 4.0 apportent de nombreuses simplifications, nous n’en sommes pas encore là. Alors non, je ne vais vous développer un addin ou un package Visual Studio qui le ferait (même si l’idée me trotte dans la tête depuis longtemps, affaire à suivre …), mais je vais développer quelque chose d’un poil moins ambitieux mais qui pourra s’avérer pratique pour mettre à disposition dynamiquement une couche métier existante de manière distribuée, sans avoir pratiquement aucune connaissance de WCF.

L’idée sera simple : vous déposerez une Assembly métier traditionnelle et toutes ses dépendances (dont le fonctionnel est compatible avec une utilisation distribuée) dans un répertoire donné. Mon processus porteur se chargera alors de les rendre disponibles dynamiquement via WCF.

Et c’est là qu’apparait mon besoin d’utiliser les interfaces « IOperationInvoker » et « IOperationBehavior ». Je vais donc me servir de ce point d’extensibilité de WCF pour traiter un comportement d’invocation dynamique de la bonne méthode sur le bon objet, en insérant dans le Dispatcher WCF mon propre comportement d’invocation.

En d’autres termes, ce processus porteur permettra de rendre disponible n’importe quelle couche métier déjà développée sans avoir à gérer les règles de développement WCF (contrat de données, contrats de services, implémentation des contrats de service pour définir le métier et création et paramétrage du processus porteur), le tout sur un ou plusieurs bindings donnés.

Pour des raisons de simplification, les hypothèses suivantes sont posées :

• l’ensemble des opérations mises à disposition le seront via une façade WCF unique chargée du traitement
• Les objets à état ne seront pas gérés
• Le processus porteur sera développé sous la forme d’une application console
• Les méthodes et classes génériques ne seront pas gérées