MAX : Remoting.net : l'AMF à la sauce Microsoft

Cette conférence a débuté par une phrase d'anthologie nous indiquant que Flash était passé (je cite) "du canard qui va de droite à gauche en faisant coin coin" à (et là je résume) un soft capable de créer des Rich Internet Applications. Fort heureusement, l'intervenant n'a pas manqué de rappeler qu'on est quand même bien content que Flash soit d'abord un logiciel d'animation vectorielle et que c'est grâce à cela qu'il a connu un grand succès. Quoiqu'il en soit, le ton était donné.

La conférencier a commencé par une présentation rapide de Flash et de ses divers moyens de communication avec l'extérieur :

• le protocole HTTP et les méthodes POST et GET
• le XML et notamment sour la forme de SOAP pour les Webservices
• l'AMF avec les technologies Remoting
  (Ndlr : sans oublier le RTMP, protocole de Flash Communication Serveur)

Nos intervenants ont alors très justement noté que des 3 moyens, Remoting avait l'avantage (rapidité, sécurité et transtypage principalement).
Comme on pouvait s'y attendre, la diversité des technologies Remoting (notamment AMF PHP) n'a pas été évoquée, au profit de la technologie dont on nous vantait les mérites dans cette conférence: le framework .NET

S'en est suivi une série de slides Powerpoint nous décrivant très (trop) rapidement le framework. Il faut néanmoins avouer qu'il eût été difficile de décrire en détail ce sujet complexe. Je me garderai d'ailleurs de tenter ici une telle manoeuvre, et me contenterai de rapeller que .NET est le socle sur lequel reposent desormais l'ensemble des applications Microsoft, et qu'il permet au développeur de créer des applications de toutes sortes en utilisant (quasiment) n'importe quel langage pour peu qu'il soit un minimum adapté et... que ce ne soit pas PHP.
Les scripts sont compilés en un langage intermédiaire, le Common Language Runtime (CLR), un peu à manière de Java, les performances en plus.
Tous les Interface Development Environment (IDE), y compris un simple éditeur de texte, à condition d'avoir un compilateur (qui est, notons-le, disponible gratuitement) permettront de créer des applications pour le framework. Néanmoins, Microsoft indique que son nouveau Visual Studio, Visual Studio .NET, est le plus adapté. Le principal concurrent de .NET est sans aucun doute J2EE.

Un exemple très simple m'a permis de voir pour la première fois l'engin en action. La création "wysiwyg" d'une page aspx sous VisualStudio, ayant pour but de faire communiquer entre eux des composants .NET est assez explicite. Le code édité dans le developpement indique des balises étranges mais qui, une fois le script compilé, se voient remplacées par des balises "normales" HTML. Jusque là rien d'extraordinaire. On note néanmoins que notre formulaire est géré par une classe, rédigée en C# dans cet exemple, qui permet de coder de manière ma foi élégante les divers événements de l'application. Le programmeur nous indique d'ailleurs à ce propos qu'il est opportun d'avoir choisi un langage capable de pouvoir implémenter les design pattern de rigueur, qui furent décidemment à l'honneur en cette journée.

D'autre part, la communication avec les bases de données à l'aide de composant a l'air tout aussi intéressante (système de dataset), et si c'était bien entendu SQLServer qui était choisi pour exemple, il est agréable de savoir que la plupart des bases de données connues, y compris MySQL, avaient leur propre composant .NET (c'est du moins ce qui m'a été certifié par une personne de chez Microsoft).

Bien sûr, c'est avec la présentation d'une application Flash que les choses ont commencé a devenir vraiment intéressantes. Côté Flash, rien de nouveau pour ceux qui connaissent Remoting. C'est exactement le même fonctionement qu'avec, par exemple, AMF PHP. Mais c'est du côté de VisualStudio.NET qu'il y a du neuf. Premièrement, on constate que le client flash s'exécute dans l'IDE! Voilà qui peut être intéressant au niveau du debuggage. Mais la contrepartie, c'est d'avoir un client lourd qui fait ramer l'IDE, ce qui serait, vous en conviendrez aisément, bien fâcheux.

L'envoi de variables à Flash depuis la classe d'application .NET se réalise très simplement grâce à une instruction du type:

FlashMovie.MovieVariables.add[la variable et sa valeur]

C'est une classe FlaManager qui sert de point d'entrée à la communication avec le swf. La rédaction de la classe, et ses moyens de communiquer avec le swf est, à mon sens, et sans pouvoir juger sur une expérience peronnelle, plus élégante qu'en PHP (qui n'est pas un "vrai" langage de POO)

Enfin, le debuggage de l'application, avec un pas à pas à la manière du debuggeur Flash, montre une évidente supériorité de VisualStudio.NET sur les IDE PHP.

Difficile de porter un véritable jugement de valeur sur la technologie sans l'avoir essayé. Je dois avouer avoir éte séduit par de nombreux aspects de la démonstration, mais je suis persuadé que seule l'expérience du développement d'une application relativement complexe permettra de trancher de manière objective. Donc non Monsieur Bill Gates, je n'échangerai pas mon baril d'AMFPHP pour votre .NET, mais je garde quand même un oeil sur lui! Car il faut se rendre à l'évidence: c'est vers ce type d'outil qu'il faut évoluer pour développer nos applications dynamiques dans un environement à la hauteur des prétentions des fameuses RIA.

Bien sûr vous pourrez objecter que je manque d'objectivité et que j'aurais été bien plus indulgent si la technologie .NET était issue du monde du libre. Et vous auriez raison.

par Dehats.