Je change de sujet par rapport aux précédents postes, et je m’attaque à un autre sujet épineux: la communication inter-processus.

Au début de ma vie professionnel, je n’ai pas commencé à travailler en .Net, mais en Delphi.

J’avoue que Delphi était séduisant. Avant .Net, c’était la manière la plus efficace de réaliser des applications Windows lourde avec un Designer d’interface unique. Et puis, n’oublions pas que l’inventeur du langage Delphi n’est autre que Anders Hejlsberg, qui fut embauché par Microsoft pour inventer C# !

Quand .Net prenait de plus en plus d’ampleur,  j’ai alors réussi à convaincre tout le monde de s’y mettre.
Mais comme la migration devait se faire petit à petit, il fallait intégrer Delphi avec .Net.

Pour cela, j’ai découvert COM.
COM est une technologie 100% Microsoft, mais qui se base sur les mêmes principes que Corba.
COM permet de communiquer entre les applications, peu importe le langage. La communication se faisait en activant des services, à l’aide d’un contrat qui se rédigeait dans un langage indépendant du langage de compilation : IDL (Interface Definition Language).

C’était magique : on pouvait inclure un UserControl .Net dans une application Delphi existante ! On pouvait aussi appeler des services .Net depuis Delphi, et vis vers ça !

Les services étaient d’ailleurs enregistrés auprès de Windows, dans la base de registre. Donc, quand un programme Delphi demande un service qui répond à une interface, Windows se charge de le localiser (DLL ou EXE) de l’héberger dans un conteneur (dans le cas de l’EXE, il lance ce dernier, dans le cas de la DLL, il l’host dans DLLHOST.exe) et d’instancier le service pour qu’il puisse être utilisé.

Et ce n’est pas tout ! Il y avait aussi DCOM qui est la version distribué de COM. Cela veut dire que si la DLL n’est pas sur la machine actuelle, Windows se charge d’interroger les autres serveurs DCOM pour qu’ils instancient le service à distance ! Tout cela avec une couche de sécurité ultra complexe !

De plus, le langage IDL supporte les méthodes, les propriétés, les événements, les paramètres de type « out », l’héritage d’interfaces, la gestion des versions, etc.…

Si vous souhaiter exposer des services sous Windows, cette technologie semble la plus appropriée.

Dans le monde des serveurs J2EE, ce fût Corba, concurrent direct à COM, qui remplissait ce rôle.

Mais voila : COM est 100% Windows, 100% Natif (non managé) ce qui rend le pont COM-.Net peu performant.

Concernant CORBA, il existe bien des connecteurs pour .Net, mais pas de serveur CORBA 100% managé.
De plus, CORBA est abandonné dans certains domaines à cause de sa lourdeur : les distributions Linux ont migré de CORBA à DBUS pour avoir aussi leur « équivalent à COM ». A noter que DBus existent en 100% .Net: http://www.ndesk.org/DBusSharp

Microsoft abandonne d’ailleurs COM pour sa technologie de communication phare : WCF.
Avant WCF, Microsoft avait introduit une autre solution 100% .Net: .Net Remoting. Mais ce dernier était trop simple et a fini par être abandonné, même si c’est toujours la technologie par défaut pour communiquer inter-AppDomain.

Alors, que choisir comme technologie de communication et d’activation de service ? Point à Point ou par un intermédiaire (Bus/Broker)? Quel format de message/marshalling doit-on utiliser?

Pour ma part: COM n’est pas multi-plateforme, je ne suis pas convaincu par l’usine à gaz WCF, DBusSharp est trop bugué, .Net remoting est trop simple/limité… je reste un sur ma fin.

Mais entre temps, j’ai découvert le “Messaging” et la communication asynchrone, qui est parfaite pour un environnement distribué. On ne peut pas remplacer le RPC par le Messaging dans tous les cas, mais il a falloir que j’exploite cette voie.

Pour conserver une trace de mon incompétence, voici donc la solution:
Pour qu’on puisse dialoguer avec un service WCF dans une page Asp.net, je leur injecte un proxy à l’aide de Spring (voir Spring.net pour le web). Pour cela, j’utilise une “factory de proxy” à l’aide de l’interface IFactoryObject.
Crédule que j’étais, j’imaginais que le fait de retourner true pour la propriété IsSingleton allait faire en sorte que Spring.net ne fasse appel qu’une seule fois à la méthode GetObject().
Et bien non ! C’est à vous d’être cohérent: même si IsSingleton retourne true, rien ne vous empêche de toujours retourner une instance différente dans la méthode GetObject().

Pour en revenir à mon problème, vous l’aurez compris : ma méthode GetObject() retournait à chaque fois un nouveau proxy vers le service WCF.
Résulat : à chaque fois que Spring avait besoin d’injecter mon proxy à une page (postback par exemple), je créai une nouvelle connexion au serveur WCF. J’ai fini par atteindre le nombre de connexion max, et le serveur ne répondait plus.

Il est tout de même dommage que les traces WCF ne m’ont pas révélé d’exception expliquant cette limite max de connexion

Pour approfondir le sujet sur les IFactoryObject :
Un objet qui implémente IFactoryObject doit toujours être un singleton, si ce n’est pas le cas on obtient une exception:

<object id="maFactory" type="MonAssembly.MaFactory, MonAssembly" singleton="false"/>

La propriété IsSingleton de la factory indique seulement ce qu’elle est censée faire… mais sans aucune obligation/vérification du comportement. Dans mon cas, je retournais true mais rien ne m’a empêché de créer une nouvelle instance à chaque appel…

Dans le cas particulier d’une application Asp.net, on peut avoir des “presque singleton” en changeant le scope:

<object id="maFactory" type="MonAssembly.MaFactory, MonAssembly" scope="application"/>

• scope=”application” : c’est un singleton de toute l’application web. Firefox et Safari m’affiche toujours 1.
• scope=”session” : c’est un singleton pour chaque session cliente. Firefox et Safari m’affiche toujours 2 (1 instance pour Firefox + 1 instance pour Safari).
• scope=”request” : c’est un singleton dans le cadre de la requête. Firefox et Safari vois le compteur s’incrémenter à chaque rafraichissement de la page.

Pour plus d’infos sur les scopes.

Conclusion(s) :

1. Ce n’est pas la propriété IsSingleton qui détermine si Spring va faire appelle une ou plusieurs fois à votre Factory. C’est à elle de fournir le comportement adéquat.
2. Un singleton n’en est pas toujours un… ça dépend du contexte. Dans tous les cas, pour éviter les erreurs comme la mienne, n’oublier pas d’utiliser la destroyMethod pour libérer les ressources. (l’interface ILifeCycle de Java n’existe pas encore dans Spring.net mais la 1.2 sort en RC1 début mai…).
3. Un “Timeout” peut vouloir dire “trop de connexion au serveur”
4. Cette fameuse Factory de proxy WCF sera fournie dans Spring.net 1.2. j’aurais perdu moins de temps en prenant les sources des nightbuilds… vive l’OpenSource!