Flex vs. Silverlight - Les langages

On l'a vu dans l'article précédent, Adobe a une longueur d'avance sur Microsoft pour ce qui de démontrer la capacité de Flex/Flash à répondre à des exigences de design d'interfaces utilisateur évoluées. Pour autant, l'angle choisi pour cette comparaison Flex vs. Silverlight est le développement d'applications web d'entreprise. Dans ce contexte, le coût de développement de fonctionnalités métiers parfois complexes sera de toute évidence plus significatif que les coûts inhérents au look-and feel de l'application (pour autant que chaque technologie choisie ne soit pas trop limitée dans ce domaine). C'est donc par le langage de développement que je commence véritablement cette comparaison entre Flex et Silverlight.

Les deux technologies utilisent un langage de balises XML pour décrire l'interface utilisateurs. Les listes déroulantes, boutons radio, cases à cocher, zones de texte, menus, …) sont décrit dans le langage MXML pour Flex et XAML pour Silverlight. Pour le code-behind (fonctionnalités associées aux contrôles et développement des composants métiers), chaque technologie dispose de son propre langage. Pour Flex c'est le langage ActionScript, pour Silverlight c'est un langage .Net (VB .Net ou C#).

MXML vs. XAML

MXML et XAML adressent le même besoin: définir les éléments de l'IHM et les animations graphiques associées (effets, rendus, comportements, …). MXML est relativement simple à apprendre, intuitive et assez peu verbeux. XAML est pour sa part un peu plus verbeux dans sa syntaxe et moins rigide, il est donc plus puissant mais plus difficile à appréhender.

Silverlight est conçue de manière à faire une séparation beaucoup plus stricte entre le code et la description de l'IHM en proposant des classes partielles permettant l'écriture du code-behind. En Flex, il est possible (et même assez courant) de retrouver des blocs de code ActionScript à l'intérieur du fichier MXML ce qui n'est pas aussi facilement lisible et maintenable.

Langages C# et ActionScript

C# est un langage de programmation conçu dès son origine comme un langage orienté objet. Mature et large adopté par les éditeurs de solutions logicielles, C# a été largement éprouvé pour tout ce qui concerne le développement d'applications métier. ArctionScript est au départ le langage de scripting du Flash Player pour évoluer ensuite vers un langage de programmation avec ActionScript. Pour les puristes, pour être un véritable langage orienté objet, il manque à ActionScript quelques fonctionnalités que l'on trouve depuis un certain temps dans .Net ou Java (par exemple: Private constructors, Abstract keywords, Overloading Mmethod signatures, Public getters/private setters, …).

De mon point de vue, ces manques ne sont pas essentiels car ils sont contournables. On notera simplement qu'ils peuvent rendre le code moins clair et plus difficile à maintenir. Ce qui distingue les deux langages c'est plutôt les quelques éléments listés ci-dessous:

C#
- Support du Threading
- Notions de Structures et d'Enumérations
- Linq
- Typage implicite des variables

ActionScript
- Classes et types dynamiques

Une dernière remarque concernant la comparaison des deux langages, il semble que des écarts significatifs existent entre la performance du compilateur ActionScript qui serait plus lente que celle du compilateur C# sur des applications conséquentes (100000 lignes de code). De même, il semble que l'exécution du code ActionScript soit également plus lente que le code C# (ou VB .Net). Ces informations émanent de différentes sources mais je n'ai pas testé personnellement ces deux derniers points.

Flex vs. Silverlight - Concepts et historiques

Avant de commencer la comparaison proprement dite de Flex et de Silverlight, il est peut être intéressant de faire un petit point sur le concept de RIA (Rich Desktop Application). Sans aller trop loin dans les définitions, l’idée générale des RIA est d'offrir une expérience utilisateur riche au sein d’un navigateur Web. Une autre manière de le dire serait: "donner à l’utilisateur l’impression qu’il utilise un client lourd (une application "installée" sur son ordinateur) sans l’obliger à quitter son navigateur". Les RIA permettent donc de déployer un applicatif client-serveur sans aucune intervention de l’utilisateur (quand les pré-requis de son ordinateur sont respectés). Pour creuser le sujet des concepts de RIA (et RDA), je vous recommande cette série de 3 articles qui m'ont inspiré pour cet article.

La mise en œuvre des RIA repose généralement sur un des deux principes suivants. Le premier part de l’idée qu'un navigateur, seul, ne propose pas d’outils assez sophistiqués pour concevoir une interface riche. La technologie s’appuie donc sur un plugin qui vient enrichir le navigateur, c’est la solution retenue par Adobe, Microsoft ou encore Sun. Le deuxième principe s'appuie sur les outils standards du navigateur à savoir le HTML et le langage JavaScript. C'est ce mélange, par exemple, qui a été mis en œuvre par Microsoft dans IE 5 en 1999 et baptisé Ajax (Asynchronous Javascript And Xml) en 2005. Standardisé par le W3C en 2006, beaucoup d’acteurs gravitent autour d’Ajax et s’appuient sur ses concepts simples pour proposer des librairies de composants Ajax permettant de concevoir des applications riches dans le navigateur. Parmi les plus répandus, on peut citer JQuery, Dojo, YUI (Yahoo) et GWT (Google).

Ces deux approches se retrouvent dans les différentes APIs Web ArcGIS proposées par ESRI. La première avec les APIs Flex et Silverlight. La seconde avec l'API JavaScript et ses extensions pour Microsoft Bing Maps et Google Maps.

Un bref historique

Bien comprendre les enjeux de Flex et de Silverlight c'est également connaître l'historique de ces deux technologies.

Flex

Pour Flex, l'histoire commence avec la société Macromedia qui en 2004 propose sa version 1.0 de Macromédia Flex Server. La cible est alors clairement définie: fournir une plateforme de développement (Flex) permettant de créer des applications compilées sur le serveur en SWF (c'est-à-dire en Flash).

En juin 2006, Adobe a racheté Macromédia depuis un an et fait largement évoluer la ligne de produit Flex. Le SDK Flex 2 devient disponible gratuitement, l'IDE (Flex Builder) change d'architecture et tourne désormais sur la plateforme Open-Source Eclipse. La version Professionnelle de Flex Builder apporte de nombreux nouveaux composants comme le Flex Charting. ActionScript, le langage de programmation de Flex passe en version 3.0 et impose du même coup le passage au plugin FlashPlayer 9.

En février 2008, Adobe lance la version 3.0 qui correspond à l'arrivée d'un nouveau SDK Flex 3 et surtout l'apparition de la version 1.0 d'AIR. Cette dernière est la solution de RDA (Rich Desktop Application) proposée par Adobe pour permettre l'exécution d'une application MXML + ActionScript (Flex) en dehors d'un navigateur. La version 3.0 de Flex Builder, toujours basée sur Eclipse permet désormais de développer des applications Flex et AIR.

Silverlight

Silverlight a vu le jour officiellement fin 2007 avec une version 1.0 qui a été loin de convaincre les développeurs. Basé sur JavaScript, AJAX et le langage de balises XAML, tout le code behind était écrit JavaScript.

En octobre 2008, la version 1.1 beta change de nom et Microsoft sort une version 2.0. Cette nouvelle version marque alors le véritable début de l'adoption de la technologie Silverlight. Techniquement, beaucoup de choses ont évoluées avec notamment le support de code managed en .Net. Le plugin Silverlight devient une version allégée du runtime .Net (CLR) et peut accéder à une partie restreintes des ressources locales de machines, un stockage local isolé et des fonctionnalités multimédias (streaming vidéo progressif, deepzoom, …) offrant alors de véritables perspectives pour les développeurs. La version 2.0 marque également l'intégration beaucoup plus étroite avec les autres technologies Microsoft comme LINQ, ADO .Net, WCF ou encore WPF.

En juillet 2009, la version 3.0 de Silverlight est disponible et apporte de nombreux nouveaux composants d'inteface, des fonctionnalités avancées de transformation 3D et de manipulation des bitmaps. Cette dernière version de Silverlight optimise également des multiprocesseurs et des accélérateurs matériels de la machine. Enfin, depuis cette version 3.0, Silverlight support l'exécution hors d'un navigateur web (dans une Sandbox) de manière assez similaire à la technologie Adobe AIR.

Un nouveau site web pour Cartosphère

Cartosphère, spécialiste français dans le conseil, la prestation et la distribution de données géographiques inaugure aujourd'hui son nouveau site web. On y retrouve le descriptif des bases de données et des services web commercialisés. On y trouve également des jeux de données de test en libre téléchargement.

Flex vs. Silverlight - Introduction

Depuis l'arrivée des APIs Web ArcGIS, les technologies de RIA (Rich Internet Application) Adobe Flex et Microsoft Silverlight sont maintenant largement utilisées dans les projets ArcGIS Server. Depuis la sortie de la version 2 de Silverlight, la compétition règne entre l'offre d'Adobe et celle de Microsoft. Leurs architectures et leurs objectifs sont très proches et les débats les plus passionnés alimentent depuis des mois les forums de développeurs. C'est donc assez logiquement que la question du choix de la bonne technologie se pose aujourd'hui chez nos clients ArcGIS Server.

Autant l'évoquer dès maintenant, d'un point de vue des fonctions SIG de l'application web développée, les APIs Flex et Silverlight ArcGIS exploitent de manière strictement identique les fonctionnalités des services web ArcGIS Server. Ce n'est donc pas ce critère qui sera discriminant dans votre choix. Il faudra chercher les éléments de réponse ailleurs, en particulier dans les caractéristiques propres à chacun de ces environnements.

C'est en étudiant les aspects techniques de ces deux technologies et en les confrontant à la stratégie et aux compétences de votre entreprise que vous parviendrez à vous positionner. Après avoir utilisé (modestement) ces deux technologies depuis quelques mois et à la suite de nombreux échanges avec différents développeurs, je vais tenter une comparaison de ces deux alternatives.

Au travers d'une série d'articles qui seront publiés dans les prochains jours, j'essayerai de relever les éléments de Flex et de Silverlight qui me paraissent important dans le cadre de développements d'applications web d'entreprise.

Welcome to Wiki.GIS.com

Wiki.GIS.com est un Wiki (aujourd'hui anglophone) dédié à la diffusion de ressources et de connaissances pour la communauté des utilisateurs de SIG. En ligne depuis octobre 2009, il est sponsorisé par ESRI sans être pour autant propriétaire des contenus (le site est sous Creative Commons - Share Alike License). Le Wiki est hébergé sur une plateforme indépendante mais elle financée, pour l'instant, par ESRI. Les contenus sont ceux qui seront jugés intéressants par les contributeurs. Ce qui veut dire qu'ils peuvent traités de tous les sujets en lien avec les SIG y compris des produits ESRI, SmallWorld, Intergraph, Pitney Boss, etc…

En quoi est-ce différent de Wikipedia.com ?

Le principe est le même. Wikipedia.com est une encyclopédie généraliste. Wiki.GIS.com, les contenus ont un périmètre très ciblé qui est focalisé sur les concepts et les connaissances relatives à la cartographie et aux SIG. D'un point de vue légal, les conditions de licence de l'un et de l'autre permettent la copie de contenus dans un sens ou dans l'autre.

Quel est l'objectif de Wiki.GIS.com ?

L'idée est simple, construire une ressource communautaire pour les géomaticiens qui, dans le ton et le contenu soit le plus neutre et objectif. Comme pour tout Wiki, la clé du succès de ce site viendra de l'investissement des uns et des autres. Les contributeurs les plus actifs se verront rapidement proposé de rejoindre l'équipe des modérateurs, autre clé importante dans le succès d'un Wiki.

Pour plus d'informations sur les auteurs, les contenus et les conditions d'usage de Wiki.GIS.com, vous pouvez vous reporter à la page suivante.

ArcGIS 10, Cloud Ready !

Cette semaine a eu lieu la "Federal User Conference ESRI" à Washington. Rassemblant les utilisateurs SIG des agences fédérales américaines, ESRI a profité de ce premier grand rendez-vous de l'année 2010 pour exposer un peu plus en détails les évolutions d'ArcGIS 10.

ESRI met l'accent depuis quelques années sur l'articulation à mettre en place entre les serveurs SIG et les plateformes de Cloud Computing. Pour ses propres besoins, ESRI utilise en partie les services d'Amazon pour la plateforme ArcGIS Online (S3 pour toute la partie partage de contenus des utilisateurs).

Aujourd'hui, une étape va être franchie avec ArcGIS 10 et ESRI annonce un partenariat avec Amazon Web Services (AWS) lui permettant de rejoindre la communauté des Independant Software Vendors (ISVs). Autrement dit, ESRI va proposer très prochainement des solutions ArcGIS tirant profit de ces nouvelles architectures informatiques.

Mes serveurs ArcGIS Server sur Amazon EC2

Je reviendrai en détails sur ce sujet dans quelques semaines au moment du Developer Summit.

Compléments sur les API Web ArcGIS

En complément de mon article concernant le choix de l'API Web ArcGIS Server à utiliser, je voulais vous signaler deux documents qui peuvent être intéressant à parcourir.

Le premier document est une plaquette que nous avons publié fin 2009. Ce document décrit et compare les différentes APIs disponible en version 9.3 / 9.3.1, vous noterez qu'il ne prend pas en compte les évolutions prévues dans la version 10 d'ArcGIS.

Le deuxième document est une présentation réalisée par deux de mes collègues d'ESRI France lors de notre conférence SIG 2009. La présentation se focalise essentillement sur les API JavaScript, Flex et Silverlight.

Quelle API Web ArcGIS dois-je choisir ?

Depuis la naissance d'ArcGIS Server, ESRI propose des frameworks de développement d'application Web (Web ADF) pour .Net et pour Java. Depuis la version 9.3, ESRI propose également des APIs pour JavaScript, Flex et Silverlight/WPF pour étendre encore le choix des développeurs.

Revenant d'une série de déplacements chez quelques uns de nos clientsvenant d'acquérir ArcGIS Server et la question qui revient le plus souvent concerne le choix de l'API à utiliser. A cette question je réponds à mon tour par une série de questions que je reprends aujourd'hui pour vous donner quelques pistes de réflexion.

Avec quelle plateforme de développement vous sentez-vous le plus à l'aise ?

Toutes ces APIs consommes les services web d'ArcGIS Server, elles sont donc toutes assez proches en termes de fonctionnalités ainsi la question "Qu'est ce que vous voulez faire ?" devient désormais "Quelle plateforme de développement maîtrisez-vous le mieux ?". Si vous avez déjà une solide expérience avec la plateforme Microsoft .Net alors le Web ADF .Net ou Silverlight seront des bons choix. De la même manière si vous travaillez depuis 10 ans sur des applications web ArcIMS en développant des scripts, l'API JavaScript sera un meilleur choix pour vous.

Choisir une plateforme que vos développeurs connaissent déjà bien vous permet de faire des économies de coûts et d'entretenir leur motivation. Ce simple fait d'avoir le choix est un point essentiel pour démarrer votre projet avec ArcGIS Server plutôt qu'une autre solution.

Quel niveau et quelle expérience ont vos développeurs ?

Les développeurs débutant trouvent souvent que les API JavaScript, Flex et Silverlight sont plus simples à appréhender que les Web ADFs car l'architecture est plus simple. Pour ces API web, les centres de ressources en ligne d'ESRI proposent beaucoup de tutoriaux, d'exemple de code, des vidéos et des services de tests spécialement conçus pour les développeurs débutants. Par exemple, grâce à ses ressources, avec un Notepad et une connexion Internet un développeur peut en quelques minutes rapidement créer une application cartographique basée sur l'API JavaScript.

A l'inverse, les développeurs plus confirmés apprécieront l'accès bas niveau aux fonctionnalités et le les patterns de codage des ADFs .Net et Java dont ils sont familiers. En particulier, les développeurs .Net et Java ayant déjà manipulé les ArcObjects seront à l'aise avec Web ADFs.

Est-ce que l'usage d'un plug-in dans le navigateur en envisageable ?

Les APIs Flex et Silverlight nécessite la présence d'un plug-in dans le navigateur du client. Si vous ne pouvez satisfaire cette exigence, l'API JavaScript ou les Web ADFs devront être privilégié.

L'API Flex nécessite le plug-in Flash qui est présente (selon Adobe asserts) sur 99% des postes ayant accès à Internet. Le plug-in Silverlight n'en est pas à ce niveau d'ubiquité mais on peut imaginer que ce retard sera rapidement comblé dans les années à venir.

Les plug-ins existent dans différentes versions ce qui pose éventuellement un problèmes d'incompatibilités ou de dégradations de l'expérience utilisateurs vis-à-vis de votre applications web. Il est donc important, si vous vous orientez vers les options Flex ou Silverlight, de considérer la latitude que vous avez sur les versions supportées par votre application et sur la capacité des clients à mettre à jour la version du plug-in pour utiliser votre application. Pour l'API Flex, les versions 9 ou supérieures du player Flash sont supportées. Pour l'API Silverlight, les versions 2 ou supérieures sont supportées.

Dans les futures versions des APIs Flex et Silverlight, des versions plus récentes seront probablement nécessaires pour exploiter au mieux les dernières innovations des ces technologies de RIA.

Souhaitez-vous utiliser une IDE, si oui laquelle ?

Lorsque vous choisissez une API, vous faites souvent le choix indirectement de l'IDE (Integrated Development Environment) dans laquelle vous allez coder. Pour Flex, vous allez probablement opter pour Flex Builder. Pour .Net et Silverlight, vous opterez probablement pour la plateforme Visual Studio ou Visual Web Developer Express. Dans certains cas, vous utiliserez également pour Silverlight l'outil Expression Blend pour le Design et la conception avancée d'IHM. Les développeurs utilisant le Web ADF Java choisiront peut être Eclipse ou NetBeans. Enfin, les développeurs JavaScript auront beaucoup plus de choix car ils pourront utiliser du simple éditeur de texte aux environnements plus évolués comme Aptana Studio ou encore JSEditor for Eclipse.

Les arguments pour et contre chacune de ces IDE ne seront pas traitées ici mais ce qu'il faut retenir c'est que chacune de ces API d'ArcGIS Server intègre les ressources nécessaires pour bien s'intégrer à ces principaux environnements de développement.

Avez-vous besoins de mettre à jour les entités via le web ?

Une autre question importante concerne l'accès à des fonctionnalités de mises à jour d'entités (spatiales et attributaires) dans vos applications web. Au-delà de l'environnement de mise à jour prêt à l'emploi dans les modèles d'application de base (WebMap), les Web ADFs .Net et Java donnent accès aux couches basses des ArcObjects et permet donc d'aller très loin dans les opérations de modification des données via le Web.

Pour les APIs JavaScript, Flex et Silverlight ces fonctionnalités ne sont pas disponibles mais peuvent s'implémentées aujourd'hui en étendant l'API Rest d'ArcGIS Server. Ces fonctionnalités de mises à jour sont en cours de développement et seront disponibles à partir de la version 10 d'ArcGIS (mi-2010).

Avez-vous besoin de superposer vos données aux fonds de carte Microsoft ou Google ?

Votre application a peut être besoin de s'appuyer sur des fonds de carte issues de la plateforme Microsoft Bing Maps (anciennement Virtual Earth) ou Google Maps. Ce paramètre peut influencer le choix de l'API à utiliser.

• Bing Maps est supporté en tant que couche de fond de carte dans les API JavaScript, Flex et Silverlight ainsi qu'avec le Web ADF .Net. Une autre option est d'utiliser directement l'API Bing Maps avec l'extension Bing Maps de l'API JavaScript ArcGIS.
  
• Google Maps est supporté en utilisant directement l'API Google Maps avec l'extension Google Maps de l'API JavaScript ArcGIS.
  

Etes-vous plus à l'aise avec des technologies matures ou des technologies émergentes ?

Certaines entreprises abordent les nouvelles technologies avec la plus grande prudence alors que d'autres y voit une chance de développer des choses nouvelles et innovantes. Cette attitude vis à vis de la maturité des technologies est importante à considérer en particulier si vous choisissez entre une technologie très mature comme JavaScript, et Silverlight qui est né fin 2007. Cette question est une question de culture et de point de vue des responsables informatiques mais elle pèse lourdement dans le choix.

Avez-vous discuté avec d'autres utilisateurs de ce qui a pesé dans leur choix ?

Les conférences ESRI, les forums de discussion, les groupes d'utilisateurs et les blogs sont autant de sources d'information de la part d'organisations qui ont déjà eu cette réflexion. Je sais pour ma part que certains lecteurs de ce blog ont déjà eu ces réflexions et même utilisés largement certaines de ces technologies. Il y a probablement des expériences intéressantes à partager sur ce sujet, n'hésitez donc pas à poster vos commentaires au bas de cet article !

ArcPad 8.0 SP3 est disponible

Le Service Pack 3 d'ArcPad 8.0 est désormais disponible. Ce service pack (qui intègre les SP1 et SP2) corrige un certains nombre de problèmes liés à l'utilisation sous Windows 7 ainsi que des soucis de performance d'affichage. Ce service pack intègre également une version française pour l'application ArcPad Studio.

Vous trouverez le média d'installation, comme d'habitude, sur le site du support ESRI à la page suivante.

Animations avec l'API JavaScript ArcGIS

J'ai déjà eu l'occasion de dire sur ce blog tout le bien que je pense de l'API JavaScript ArcGIS et en quoi elle constitue une alternative intéressante à l'API Flex ou Silverlight lorsqu'il s'agit de réaliser des applications relativement simples en termes d'ergonomie et de fonctionnalités. Une nouvelle illustration aujourd'hui avec un sujet assez classique qui consiste à animer des couches dont les données évoluent au cours du temps. Pour cela, j'ai relevé deux exemples d'applications simples mais intéressantes. Toutes deux développées avec l'API JavaScript, elles montrent comment animer une carte en fonction du temps.

La première application présente l'évolution du niveau d'eau durant un épisode de crue (le code source peut se télécharger ici).

La seconde application présente l'évolution du taux de chômage aux Etats-Unis au cours de l'année 2009.

Réseaux-sociaux, Géoservices et ArcGIS Explorer

J'avais déjà évoqué dans arcOrama la disponibilité d'un plug-in pour ArcGIS Explorer permettant d'exploiter les géotags de Twitter. La vidéo ci-dessous illustre comment construire rapidement un modèle d'information temps-réel (ici autour de séisme en Haïti) à l'aide d'ArcGIS Explorer, de services web cartographiques répertoriés dans ArcGIS Online et de flux GeoRSS de différentes origines.