Episode 8: Mathias découvre COM

avril 19, 2011 1 Commentaire

Bonjour tout le monde, et merci de votre patience…
Ça fait presque 5 mois que je n’ai pas blogué, et que j’ai interrompu ma série “Mathias découvre…”
Comme j’en découvre tous les jours, j’ajouterai bien d’autres épisodes avant la conclusion finale, mais j’ai peur que ça dure une éternité :)
En réalité, je voulais “jouer la montre” avec ces blogs, afin de stabiliser mon projet et lui trouver un nom sympathique. Mais je n’ai pas vraiment trouvé le temps d’y travailler, alors je vais “pousser l’oisillon hors du nid”, et j’ajusterai plus tard s’il ne vole pas très bien ;D

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.

Classé dans Développement, DotNetServer Tag(s) associé(s): , , , ,

Episode 7 : Mathias découvre Unity+WPF+MVVM aux Techdays 2010

novembre 25, 2010 1 Commentaire

Je vous ai parlé de ma découverte de .Net dans l’épisode 6.
J’ai constaté un gros contraste avec Java: j’avais l’impression que Java était compliqué (EJB et tout ça) et que .Net était simple.

Cette simplicité n’est pas toujours positive, on peut même dire que Microsoft est “maudit” par ce fléau: rester attractif pour les développeurs débutants.

En général, cela donne des frameworks “sales” avec un fort couplage du code métier avec les interfaces, impossible à tester unitairement bien sûr.

Pour pouvoir découpler tout cela, on distingue 3 couches:

  • L’interface, appelée “view” ou “presenter”, c’est le moyen d’afficher l’information
  • La logique métier, appelée “model”, c’est ce que l’on va pouvoir tester à l’aide de tests unitaires
  • Les actions ou commandes, qui représente une action de l’interface par l’utilisateur qui va déclencher un traitement

Mais quand on sépare les responsabilités en plusieurs objets, on se retrouve avec un nouveau problème : comment coupler les vues, contrôleurs, etc. ? Comment “broker” les actions ?

Il y a une solution à cela: l’IOC. On peut dire aussi que le Databinding en est une autre.
Si Microsoft avait un train de retard sur les Framework IOC, ils connaissaient néanmoins déjà le problème depuis un moment, puisqu’ils l’avaient en partie résolu dans CAB.
C’est donc sans surprise que Microsoft nous livre son framework d’IOC “officiel” basé sur l’existant de CAB : Unity.

A la sortie d’Unity, j’étais déjà tellement convaincu par Spring.net que je n’ai jamais adopté le framework de Microsoft. De plus, les alternatives OpenSources étaient  bien présentes: Castle Windsor, Ninject, Autofac, etc.

A noter que les framework tel que CAB/RCP rendent vos clients lourds “extensibles”, ce qui veut dire qu’un plugin va pouvoir greffer de “vues” dans l’interface, et s’abonner aux “commandes”: chose tout à fait faisable avec de l’IOC.

Mais les frameworks IOC ne font pas tout, et ne suffisent pas à fournir une véritable architecture MVC pour client lourd, même s’ils peuvent nous y aider (voir mon poste précédent).

Pour résoudre le fléau du couplage fort entre l’interface et le code métier, Microsoft a sortie quelque chose de révolutionnaire: WPF et Silverlight!
Avec la venue de WPF et Silverlight, la communauté .Net OpenSource a commencé à se pencher alors sur le problème du MVC pour les applications lourdes. Divers frameworks apparaissent alors, comme Prism: http://compositewpf.codeplex.com/

Mais le MVC, comme on le connait dans le monde Web, ne s’applique pas bien aux clients lourds, surtout si on veut exploiter le Databinding et les événements.

Très franchement, je ne me suis jamais vraiment passionné pour WPF/Prism/etc. mais je voyais bien que quelque chose de gros était en train de venir…
J’ai ensuite assisté aux Techdays 2010 et j’en ai profité pour me mettre à jours sur le sujet.
Les sessions étaient d’ailleurs très accès sur Silverlight/WPF mais aussi sur le nouveau modèle MVVM (Model-View-ViewModel), et avec une bonne dose d’Unity bien sûr…
J’ai alors été très agréablement surpris par ces présentations, surtout celle qui montre comment supprimer tout le « code behind » des interfaces XAML avec des ViewModel et des Commands.

Pour mieux comprendre de quoi je parle, aller voir vite le screencast ici!!!

Bref, je ne sais pas si vous me suivez, mais l’IOC, le RCP, le MVC, la gestion de plugins, tout ça c’est intimement lié !

Petit à petit, .Net rattrape le retard vis-à-vis d’Eclipse RCP !
On peut même dire que .Net a pris de l’avance avec Silverlight/WPF, puisque la rédaction des interfaces en XML n’est qu’au stade de proposition pour Eclipse 4: http://wiki.eclipse.org/images/a/ab/XWT.pdf

Classé dans Développement, DotNetServer Tag(s) associé(s): , , , , , , ,

Episode 6: Mathias découvre .Net!

novembre 13, 2010 2 Commentaires

En fait, je triche, les épisodes ne sont pas dans l’ordre chronologique.
Je n’ai pas découvert .Net après Java, mais en même temps.

C’était le 6 Janvier 2005, j avais blogué à ce sujet: j’avais découvert qu’avec Mono, il était possible d’exécuter un même programme EXE sous Windows comme sous Linux ! J’en avais la larme à l’œil…

Ce qui m’a le plus impressionné c’était de voir qu’il était possible d’exécuter du Java dans .Net grâce à IKVM ! Cela marchait tellement bien qu’ils ont réussi à exécuter Eclipse sous .Net ! Mais ce n’était qu’expérimental à l’époque…

En découvrant .Net, j’ai tout de suite pris conscience du retard par rapport à Java, et j’ai alors voulu m’y atteler.
J’ai alors commencé à réaliser un framework « RCP » comme celui d’Eclipse, mais full .Net. Voici le résultat à l’époque :

On pouvait réaliser des plugins qui fournissent des vues qui s’encrent dans différents endroits, que ce soit dans la fenêtre principale ou dans un onglet d’édition.
J’en était plutôt fier, encore aujourd’hui… j’ai bien envie de le porter avec les technos modernes d’aujourd’hui…

C’est aussi à cette époque que j’ai découvert Spring, et au même titre Spring.Net, que j’ai utilisé dans mon entreprise pour réaliser, avec Romain, un framework MVC Winforms.

J’ai aussi découvert d’autres framework IOC, et par la même occasion CAB de Microsoft (Composite Application Bloc), mais sans en être convaincu.

A l’époque, on commençait à parler d’OSGI, mais je n’avais pas assez de connaissance dans le domaine

En conclusion, je restais sur ma fin avec .Net, et j’en étais même frustré. Mais j’ai toujours été convaincu que c’était aussi “une terre d’opportunités” et que je pouvais faire quelque chose…
L’IOC, le MVC pour client riche, RCP, OSGI… les idées émergeaient déjà, mais n’était pas matures.

Classé dans Développement, DotNetServer Tag(s) associé(s): , , , , ,

Episode 5 : Mathias découvre Gigaspaces

août 22, 2010 1 Commentaire 

Mathias: Re, désolé j’étais AFK… les vacances, tout ça…

Donc voila, je suis de retour avec un cerveau presque lavé.
Et comme j’ai commencé une série, il fallait bien que le la termine ;)

Dans l’épisode 4 je vous ai parlé de Spring Java, le serveur d’application.
Je vais maintenant vous parler de Gigaspaces, car j’y ai bossé un petit peu, et ça a changé ma façon de penser.

Pour commencer: MAIS C’EST QUOI GIGASPACES?

C’est plusieurs choses à la fois. Ce qui est drôle c’est que le terme à la mode en ce moment est “No-SQL” et Gigaspaces est cité comme faisant partie de la catégorie.

D’autres appellent ça un “Tuple Space” mais on parle plus souvent de “In-Memory Data Grid” ou “Distributed Caching”.

Et comme “distributed” rime souvent aujourd’hui avec “Cloud”, il y a la des mots clés bien commerciaux ;)

Mais comme je sais que vous, lecteurs, vous n’êtes pas la pour acheter une licence, mais vous êtes plutôt des Geeks du code, je vais expliquer cela de manière plus “pratique”.

Gigaspace est un cache mémoire: c’est un serveur qui fournie comme service de stocker et lire des données de type “clé+valeur” en utilisant la mémoire du serveur.
Un cache est pratique dans diverses situations:

  • Vous stockez en mémoire une donnée lu depuis une base de donnée, afin de la lire plus rapidement les prochaines fois
  • Vous stockez en mémoire une donnée calculée, qui va être traité par un autre programme
  • Vous stockez des “messages” afin de communiquer de manière asynchrone avec d’autres programmes

En général, quand on souhaite partager des données entre 2 programmes, on utilise une base de donnée. Mais quand cette donnée change souvent, ou vous avez besoin d’une lecture très rapide, il est préférable de la stocker dans une mémoire partagée.

L’inconvénient de la mémoire, c’est qu’elle est plus rare que l’espace disque. Gigaspaces permet d’avoir un “cluster” de serveurs, vous pouvez donc additionner la mémoire d’autant de serveur que vous voulez.

Un autre inconvénient c’est que la mémoire est volatile, et en cas de crash du serveur, cette dernière est perdue.
Gigaspaces permet d’avoir des nœuds “backup” dans le cluster, ce qui veut dire que la mémoire est répliquée sur un serveur de secours au cas ou le premier plante. Bien sûr, vous pouvez avoir autant de backup que vous voulez.

…OUAI, ET ALORS?

Si Gigaspaces fournit un service avec une très faible latence et met l’accent sur les performances, ce qui m’intéresse c’est l’aspect “Cluster”.

Sur cette architecture, il est possible de déployer un programme de tout type: le déploiement du ZIP se fait en 2 clicks sur tous les nœuds du cluster, avec une gestion d’activation Primary/Backup.

Que ce programme soit un cache ou un serveur Web, je trouve l’idée très séduisante: c’est la dessus que repose le Cloud Computing.

Bien évidement, si l’ont décide d’avoir plusieurs applications “Primaire” pour répartir la charge, ces dernières devront prendre en compte cet aspect dans l’architecture (communication entre nœuds primaires, mémoire partagée).

Il est aussi possible de basculer l’état actif/inactif d’un nœud en fonction d’une mesure de charge: si le serveur 1 manque de mémoire, l’application se désactive pour se re-activer sur le serveur 2.

Je voulais aussi parler d’un dernier truc sympathique concernant Gigaspaces: le point d’entré d’une application déployée n’est pas un EXE ou un JAR, mais un fichier XML Spring! Il n’est donc pas nécessaire de coder un Bootstrap qui va seulement charger ce fichier de configuration…

Vous avez peut-être compris ou je voulais en venir: je souhaite un serveur d’application .Net sur lequel on peut déployer une application facilement sans ce soucier de l’infrastructure: que ce soit un serveur Windows ou Linux, qu’il y ai 3 instances primaires ou 6 instances primaires avec 2 backups, que les services consommés soient locaux ou distant…

Classé dans Développement, DotNetServer Tag(s) associé(s): , ,

Episode 4 : Mathias découvre Spring (et un peu plus OSGI)

juillet 9, 2010 2 Commentaires

Dans l’Episode 2, je vous ai parlé de ma découverte de J2EE.
Si j’ai été émerveillé par la plateforme, j’avoue qu’elle était assez complexe.

C’est alors que la lourdeur des framework J2EE a donné naissance à une alternative qui s’est voulu plus simple : Spring.

J’aime bien Spring, je pense que vous le savez déjà :)
C’est pour moi en quelque sorte l’équivalent de l’esprit d’ALT.Net, mais en Java.

Ce fut alors la mode des IOC, et de l’approche orienté POJO. Quand j’ai découvert cela, je me suis rendu compte à quel point le framework d’Eclipse RCP pouvait être compliqué…
La gestion de dépendance et de publication/consommation de service devenaient extrêmement simple.

La ou Spring n’était qu’un framework, « SpringSource DM Server » est, quand à lui, un vrai serveur J2EE mais avec une architecture complètement différente de ses concurrents : il est basé sur le même moteur OSGI qu’Eclipse !

L’installation de nouvelles applications vous semble pénible ? SpringSource DM Server offre un « AppStore » pour installer un nouveau service et ses dépendances en 2 cliques!

Pour ceux qui ont lu mon billet sur WebMatrix, la fonctionnalité n’est pas tout à fait la même que c’elle du produit Microsoft.Vous pouvez ici installer bien d’autres choses que des applications Web: des ESB, des serveurs Web (car oui, en Java, on a le choix entre Tomcat, Jetty et autres), etc.
Vous voulez installer un serveur de Messaging ? Installer ActiveMQ en quelques cliques : http://www.springsource.com/repository/app/bundle/version/detail?name=com.springsource.org.apache.activemq&version=5.3.0

Vous trouvez plus d’infos sur http://www.springsource.com/products/dmserver/repository


En plus de tout ces avantages, SpringSource DM Serveur offre un interface d’administration d’un pure merveille, j’en bave quand je vois que Microsoft reste attaché à sa MMC…
Et comme si ça ne suffisait pas, SpringSource ont racheté Hyperic qui est une appli Web de Monitoring applicatif, ce qui rend l’administration de votre serveur  encore plus professionnel.

Petite conclusion:

  • l’IOC c’est cool, vive l’approche POJO
  • OSGI c’est de la bombe. Cela permet aussi bien de gérer des plugins dans un IDE, que des middleware dans un serveur d’applications
  • l’installation d’une plateforme applicative doit être simple et facile, autant que de lancer un Setup de EasyPHP ou de cliquer sur un lien d’un “AppStore”
  • vive les interfaces Web d’administration, à mort la MMC

Classé dans Développement, DotNetServer Tag(s) associé(s): , , ,

Episode 3 : Mathias découvre Eclipse (et un peu OSGI)

juin 29, 2010 5 Commentaires

Dans l’épisode 2, je vous ai dit à quel point les serveurs J2EE pouvaient être complexe dans la gestion d’application.
Il en est de même dans le monde des IDE avec la gestion des plugins.

Tout en étudiant J2EE, je suis tombé amoureux de mon IDE Java préféré : Eclipse. Pas seulement pour sont utilisation, mais aussi pour son architecture.

En effet, la réalisation de plugins pour Eclipse se fait de manière ultra puissante. A tel point que le « noyau » d’Eclipse peut être complètement extrait pour faire sa propre application qui n’a rien à voir avec un IDE : c’est le framework RCP (Rich Client Platform).
J’ai d’ailleurs à l’époque réalisé une application RCP pour la gestion de budget d’achat de livres pour les bibliothèques.

Malheureusement, la pauvreté des composants graphique en Java faisait du tors à cette plateforme.
Mais je restais subjugué par le moteur de plugins :

  • Les plugins sont isolés afin que si un plugin crash, les autres continuent leur vie
  • Les plugins sont aussi isolé coté sécurité : un plugin ne peut pas accéder aux codes d’un autre plugin si ce dernier ne l’a pas explicitement rendu « publique »
  • Les plugins peuvent publier et consommer des services, avec un model très élégant
  • Il y a une gestion de dépendance entre les plugins, avec la prise en compte des versions
  • L’installation et la mise à jour des plugins se fait d’une simplicité déconcertante

En fait, si la gestion des plugins est si balaise c’est car elle provient d’un standard de « développement par composant » : OSGI.

L’alliance OSGI est un organisme de personnes qui se mette d’accord ensemble sur des specs concernant les frameworks OSGI. C’est encore la que Java écrase .Net par sa maturité : il n’y a pas de monopole, il y a bien plusieurs acteurs derrière un « standard » ouvert qui va connaitre de multiples implémentations.

OSGI est donc un framework complexe de gestion de « modules » qui exposent des « services ». N’hésitez pas à lire le WIKI qui explique ça très bien : http://en.wikipedia.org/wiki/OSGi

En conclusion, Eclipse est une plateforme riche en plugins grâce au coté Open-Source de l’IDE, à l’API de plugins très bien faite mais aussi à l’aide du plugins pour développer des plugins :)

Qu’en est-il du coté .Net? VisualStudio a-t-il le même succès concernant le développement ce plugins? Offre-t-il une architecture de plugin aussi puissante? On verra ça dans un autre épisode ;)

Classé dans Développement, DotNetServer Tag(s) associé(s): , , , ,

Episode 2 : Mathias découvre J2EE

juin 29, 2010 4 Commentaires

En sortant de mes études, je me suis rapidement retrouvé dans le moule en adoptant Java. J’ai alors découvert les serveurs « conteneur de servlets » ou serveur J2EE, ce qui était quand même plus puissant que PHP…

Je vous ai parlé d’EASYPHP, avec lequel l’utilisateur avait une interface Web pour administrer sont serveur Apache: en 2 clicks n’importe qui peut créer un nouveau site web, sans connaitre le fameux “apache.conf”

Je suis fondamentalement contre la MMC de Windows, et je pense que IIS devrait aussi fournir une interface Web.
Encore aujourd’hui, je suis jaloux de la piètre interface de Tomcat qui permet de déployer à chaud une application web Java à distance avec une interface web, et de pouvoir gérer son cycle de vie (start/stop/reload).

Ca parait rien comme ça, mais il n’y a pas d’équivalent pour gérer les applications Web .Net, donc oui, je suis jaloux.

Tomcat n’est pas un serveur J2EE, on ne peut y déployer que des applications Web: WAR (Wab ARchive).
Mais un serveur J2EE est plus puissant: on peut y déployer des applications “service” (JAR/EAR) voir des tâches schédulées.
De plus, les applications offrent souvent des “MBean”: Managed Bean. Ce sont des objets qui sont accessibles à travers une couche de service, et tout les serveurs J2EE offrent une interface Web pour les gérer.
Vous pouvez ainsi exposer la bean “HttpCache” avec le service “Clear” par exemple. Bref, c’est le paradis des admins.

Alors quand vous allez voir les pages Web d’administration de JBoss ou SpringSource, on se dit qu’il manque clairement quelque chose à la plateforme .Net.

Classé dans Développement, DotNetServer Tag(s) associé(s): ,

Episode 1 : Mathias découvre PHP

juin 27, 2010 3 Commentaires

Bande de petits veinards, je vous offre le premier épisode aujourd’hui :)

PHP est l’un des premiers langages que j’ai étudié lors de ma formation. C’est en tout cas le premier avec lequel il était possible de « réaliser quelque chose », et non faire des « hello worlds »…

En fait, PHP était super simple à prendre en main, grâce à la magie de EASYPHP !
Ce dernier permet à tout débutant d’installer en quelques click un serveur Web, le module PHP, une base de donnée MySQL ainsi qu’un portail Web d’administration EASYPHP et un autre portail de gestion de la base PHPMyAdmin.

Je me suis alors dit : mais pourquoi un truc aussi magique n’existe pas pour .Net ?
De plus, le trio Apache+PHP+MySQL peuvent être installés sur Linux, ce qui a permis à cette techno de se répandre partout chez tous les hébergeurs à moindre coût !

Classé dans Développement, DotNetServer Tag(s) associé(s): ,

Introduction : Mathias est heureux… mais pourquoi ?

juin 27, 2010 Laisser un commentaire

YES !!! CA MARCHE !

Après des semaines de développement, j’ai finis par y arriver, et voici le résultat :

Mouhahahah, n’est elle pas merveilleuse mon applis ? Ah ? Non ?

Certes elle manque d’esthétisme, mais si elle a une carrosserie de Deudeuche, il y a la dessous un vrai moteur de Ferrari! (ou une usine à Gaz, c’est une question de point de vue).

Afin de comprendre mon excitation fasse à une pauvre fenêtre, il faut que je vous raconte un peu mon histoire….
Et comme c’est un peu long, je vais vous laisser digérer ça en plusieurs fois :

Classé dans Développement, DotNetServer Tag(s) associé(s):

DBus avec .Net

mai 5, 2010 1 Commentaire

Pour ceux qui ne le savent pas, je travail sur un serveur d’application .Net indépendant de la plateforme Windows: DotNetServer.

Après une version bonne pour une démo, j’ai voulu refactoriser le tout pour avoir quelque chose de viable.
Dans mon dernier billet, j’explique mon périple à la recherche d’un protocole de communication Inter-Processus, et j’ai choisi NDesk.DBus: l’implémentation full .Net de D-Bus.

La solution était sexy:

  • Déclaration des services par interface, ne pouvant exposer QUE des types simples ou Struct. Cela force à réaliser qu’en matière de communication, une instance d’objet ne veut rien dire et qu’on communique que par DTO.
  • Support des méthodes, propriétés et événements
  • Channel par Socket/TCP ou par Pipe
  • Communication optimisé binaire (pas d’XML ou de SOAP….)
  • Exposition des services sur le Bus avec un contrat au format XML (comme un WSDL en quelque sorte)
  • Cross-platform: provient du monde Linux mais existe sous Windows
  • Un standard de communication Inter-Processus, de plus en plus utilisé sous Linux, remplaçant CORBA (avec Bonobo)

Mais voila, tout n’est pas rose, et DBus me donne du fil à retorde.
L’implémentation .Net n’est pas très propre:

  • API pas très utilisable car quasiment tout est Internal
  • Pas de doc?
  • Ça manque de convention, le source n’est pas très lisible, j’ai envie de passer un coup de Resharper dessus :)
  • Beaucoup, beaucoup de commentaire du genre “//temporary hack” ou “//TODO“… beaucoup de code commenté qui prouve que la personne a voulu faire bien mais n’a pas eu le temps
  • Quand j’exécute DBusExplorer pour scanner mes services, cela plante 1 fois sur 2 mon client
  • Je n’arrive pas à faire marcher un service ou un client dans un Thread!!! Cela me bloque totalement

Je me demande si je ne vais pas revenir à une solution .Net Remoting:

  • implémentation .Net et Mono
  • channel IPC (par Pipe)
  • supporte les événements
  • DBus est vraiment orienté “Desktop” comme le D l’indique. J’en fait donc une utilisation détournée.

Mais une autre solution peut aussi faire l’affaire: ProtoBuf, un protocole performant inventé par Google.

Je vais tacher de vous tenir plus au courant, histoire aussi de recueillir des opinions concernant mes choix.

Classé dans Blabla, DotNetServer Tag(s) associé(s): , , ,

← Articles précédents

Suivre

Get every new post delivered to your Inbox.