Interview de Marc Gardette

	Marc Gardette s'explique sur la stratégie de Microsoft par DNG (webmaster@dotnetguru.org)

epuis l'annonce la sortie de .NET en version 1.1 et les dernières annonces relatives à Whidbey, nous souhaitions interroger le responsable de la division architecture de Microsoft : Marc Gardette. Une interview qui s'inscrit dans un contexte de forte activité chez l'éditeur. En effet, avec la présentation prochaine (fin Mai) des futurs outils de développement pilotés par les modèles, Microsoft tente de ravir à J2EE ce qui a fait et continue de faire ses lettres de noblesses : "l'approche entreprise". La méthode utilisée suscite en revanche bon nombre d'interrogations, UML est-il écarté ? les autres acteurs ont-ils un rôle à jouer ? Marc Gardette nous répond.

Marc Gardette

Bonjour Marc Gardette,

Presque 3 ans après la sortie de .NET, peut-on dire vraiment que cette plateforme est un succès ?

Marc Gardette : Quelle est la définition d’un succès ? Il n’y a pas de mesure scientifique me permettant de répondre sans contestation à cette question, mais compte tenu des chiffres, des faits, des études de marché, d’enquêtes dont nous disposons, j’aurais tendance à répondre oui. Même si cela va sonner très marketing (mais la question ne l’était elle pas ?), voici quelques éléments pour étayer ma réponse. Aujourd’hui, .NET n’est plus une nouvelle technologie, mais une réalité pour de nombreux clients : http://www.microsoft.com/france/net/temoignages/default.mspx. Le retour que nous avons de la part de nos clients ou partenaires ayant adopté .NET est unanimement positif. D’ailleurs, d’après nos enquêtes de satisfaction auprès des développeurs, le niveau de satisfaction de VS.NET est très élevé, surpassant VS 6.0 et tous les outils Java. Nous avons une communauté de développeurs .NET en forte croissance : 7 newsgroups France dédiés aux technologies .NET avec plus 3500 messages par mois, 16 sites communautaires en français, représentant plusieurs dizaines de milliers de développeurs francophones qui publient des dizaines d’articles et de codes sources par semaine, plus de 20 MVP en France (Most Valuable Professionel) sur .NET partagent et échangent leurs compétences au travers de leurs articles, leurs livres mais aussi en tant que présentateurs techniques.

Certains chiffres témoignent de la bonne santé de .NET et de son adoption croissante : .NET déployé dans plus de 50% des « Fortunes 100 », plus de 70 Millions de systèmes avec le Framework .NET déployé, (pré-installé sur 60% des nouveaux systèmes, plus de 20 millions de download avec Windows Update), plus de 450 livres disponibles sur .NET, plus de 250 sociétés offrent des formations sur .NET, plus de 2.5 Millions de développeurs équipés avec VisualStudio .NET….

Je crois que DNG avait déjà eu l’occasion de relayer les résultats d’une enquête Netcraft qui montrait que pour la première fois les sites ASP.Net avaient dépassés les sites JSP/Servlet http://news.netcraft.com/archives/2004/03/23/aspnet_overtakes_jsp_and_java_servlets.html

En France, selon une enquête que nous avons fait mener en février dernier par un organisme indépendant, l’adoption de la plate-forme .NET progresse significativement et pour la première fois passe devant J2EE : la répartition des technologies de développement d’applications utilisées au cours des 6 derniers mois donne le résultat suivant : .NET : 22% - J2EE : 19%

La part des développements J2EE dans les grandes entreprises de plus de 1000 employés restant légèrement au dessus de celle de .NET, mais la tendance est inversée sur les entreprises plus petites (PME). Selon notre dernière grande enquête Dev-Tracker, la part des développeurs .NET seraient de 37% vs 30% pour Java sur le continent nord américain.

Il semble que beaucoup de nouveautés soient prévues dans les années à venir, notamment concernant les outils "d'entreprise" ? Pouvez-vous nous en dire plus ?

Marc Gardette : Résumer en quelques mots les nouveautés à venir sur le framework .NET et sur VS. NET est difficile. Pour une synthèse de notre roadmap alignée sur 2 versions majeures de VS .NET dont les noms de code sont Whidbey et Orcas, je renvoie les lecteurs de DNG à l’adresse suivante : http://www.microsoft.com/france/vstudio/info/info.asp?mar=/france/vstudio/info/20040305_roadmap-devtools.html.

Whidbey, maintenant connu sous Visual Studio 2005, est attendu courant premier semestre 2005 et apportera des améliorations majeures dans de nombreux domaines : Langages, IDE, .Net framework, développement Office, développement SQL Server 2005. En ce qui concerne les outils entreprise, un certain nombre de fonctionnalités ont déjà été présentées à la PDC en octobre dernier notamment sur la partie modélisation (nom de code whitehorse). Je ne peux hélas vous en dire plus aujourd’hui, mais fin mai à TechEd US de nombreuses annonces seront faites par Microsoft dans le domaine de la gestion du cycle de vie. Consultez nos sites MSDN d'ici là pour en savoir plus sur le sujet.

Orcas sera la prochaine version majeure de Visual Studio à l’horizon Longhorn nom de code pour la prochaine version majeure de Windows. Les outils de développement et le framework .NET intégreront alors les nouveautés introduites par Longhorn dans les domaines de l’interface utilisateur (AVALON et XAML), de la communication (Indigo, RTC…), du stockage (WinFS…) de la gestion de l’identité... Cette version intégrera également le Microsoft Business Framework qui est une extension au framework .NET et à Visual Studio pour faciliter le développement d’application de gestion. MBF élève encore le niveau d’abstraction du framework .NET en proposant un modèle de programmation de plus haut niveau intégrant des notions comme les business entity, activity, process, gestion des meta données…

Un grand débat concerne l’intégration éventuelle des standards de l’OMG (UML, MDA), Microsoft va-t-il ou non fournir une implémentation fidèle à ces normes ? si non, pour quelles raisons ?

Marc Gardette : Tout d’abord, pour ceux qui ont besoin d’un support UML dans VS .NET, Microsoft offre déjà un support d’UML à l’aide des outils Visio. Nous avons également des partenaires comme IBM/Rational ou Borland fournissant des supports d’UML encore plus riches et intégrés comme XDE ou Together.

Pour comprendre la position de Microsoft concernant UML et MDA dans notre stratégie plus long terme, il est important de comprendre quelle est notre stratégie pour industrialiser les développements et quelles sont les limitations perçues au niveau de UML et de MDA. Ceci mérite une analyse et une réponse complète qui a déjà été faite dans un excellent article publié dans le MDA journal par Steve Cook, article d’ailleurs par ailleurs relayé sur DNG : http://www.bptrends.com/publicationfiles/01-04%20COL%20Dom%20Spec%20Modeling%20Frankel-Cook.pdf

Notre objectif avec Whitehorse (nom de code pour la couche de modélisation de Visual Studio 2005) est de généraliser l’usage des modèles spécifiques à certains domaines ou perspectives. Il y a au niveau du cycle de développement de nombreux éléments à gérer : modèles métier, SOA collaboration, process orchestration, Object mapping (relational, XML..), diagramme de classe, déploiement, description de datacenter, interface utilisateur…… Nous appelons ces domaines des DSL ou Domaine Specific Languages. Ils sont souvent représentés graphiquement. Il est important que les modèles et les langages qui les supportent restent parfaitement synchronisés et qu’un mapping ou une transformation entre ces différentes perspectives soit possible. Dans VS 2005 de nouveaux modèles sont introduits comme par exemple le Distributed Service Designer : http://msdn.microsoft.com/vstudio/productinfo/enterprise/enterpriseroadmap/default.aspx?pull=/library/en-us/dnvsent/html/vsent_soadover.asp.

Certains de ces domaines comme le Service Designer ou la structure logique du data center (Logical Infrastructure Model) ne sont pas couverts par une notation graphique ou un méta modèle UML. Il n’y a pas dans ces domaines de standards qui puissent être choisis. UML est un méta modèle générique qui ne couvre pas tous les aspects d’une architecture ou du processus de développement et qui peut manquer de précision pour décrire correctement un domaine spécifique avec un niveau de détail suffisant.

UML offre une notation intéressante pour décrire certains éléments de design ou de documentation mais présente certaines limites pour être réellement vue et gérée comme un artifact de développement. Les extensions complexifient l’utilisation de UML. Le Designer de Classes de VS 2005 s’inspire d’UML pour ce qui est de la représentation graphique mais permet de représenter fidèlement tous les types CLR (classes, méthodes mais aussi propriétés, events, enum…) A ce niveau ce n’est plus du round-tripping entre le meta model UML et les types CLR, mais une représentation graphique des types de la CLR. Tous les nouveaux modeleurs introduits par VS 2005 partagent la même infrastructure de modélisation ( surface de design, gestion du méta-modèle, sérialisation, règles de validation, in memory model…). Les équipes de VS travaillent à des outils permettant aux partenaires de développer très facilement de nouveaux langages et modèles. Nous pensons que des partenaires utiliseront cette fondation pour fournir un support complet de UML, Microsoft se concentrant sur le court terme sur les modeleurs déjà annoncés (SOA, LIM, Class Diagram…).

Il semble que l’opinion de MS ait quelque peu évolué sur l’intérêt d’une solution de mapping objet/relationnel pour .NET, qu’en est-il ? A titre personnel, croyez-vous en cette démarche ?

Marc Gardette : Il n’y a pas une réponse universelle et une seule stratégie possible quand il s’agit de l’accès aux données. Nous voulons fournir les services d’accès aux données les plus riches possibles et les plus faciles à utiliser selon la situation : dataset, datareader, SQLXML, ObjectSpaces. Les critères de choix dépendent de nombreux facteurs : comment sont représentées les business entity : XML, DataSet, Typed Data Set, objet métier. L'application est-elle déployée localement ou à distance. Les contraintes non fonctionnelles : performance, scalabilité, maintenabilité, facilité de développement
Quand le contrôle et la performance sont en jeu, je pense que la majorité des développeurs préfèrent une solution explicite d’accès aux données avec une classique DAL encapsulant des procédures stockées, plutôt qu’une solution implicite laissant au framework le soin de gérer l’accès aux données. La preuve en a été faite avec Java et les EJB CMP Entity peu utilisé dans les projets. Mais il y a un besoin pour certains développements très orientés objet métier d’avoir un service de mapping objet relationnel. D’ailleurs, le future Microsoft Business Application framework s’appuiera sur Objectspaces pour sa couche de persistance et le WinFS dans longhorn aura un modèle de programmation client très proche d'Objectspaces. L’important est d’avoir le choix et nous voulons donner aux développeurs un maximum de flexibilité : le databinding dans whidbey supportera indifféremment un data binding sur dataset, sur XML ou sur des objets métier.

Préconiseriez vous en l’état actuelle de l’offre .NET de Microsoft une démarche agile basée uniquement sur des outils Opensource (nunit, nant, draco, cvs/subversion, draco.net) ? Y a-t-il des choses prévues chez Microsoft dans ce sens dans whidbey ?

Marc Gardette : Une démarche agile consiste à intégrer dans le cycle de vie du logiciel une forte réactivité aux changements des besoins du client ou changements technologiques. C’est un travail d’équipe souvent réduite visant à garantir une qualité maximum du code et une réponse optimum aux besoins. Elle nécessite une approche incrémentale avec des livraisons continues, des développements et test simultanés... Mais pour que tout cela fonctionne, il faut être capable de gérer de manière efficace dans un environnement de travail de groupe tous les artifacts de développement tout le long du cycle de vie du projet (modèles, codes, tests, pattern… transformation…) Il ne doit pas y avoir de transformation irréversible ou des gaps importants entre le code modélisé et le code déployé, entre le code et les tests… Il doit être possible de changer rapidement un des éléments et de recréer le résultat final. Il faut donc pouvoir gérer de manière efficace des metadonnées décrivant chaque élément et les relations entre ces éléments au niveau du tout le cycle de vie. Les différents outils utilisés sur le cycle de vie doivent donc pouvoir partager facilement des schémas communs décrivant ces méta-données. L’intégration de tous les outils est donc essentielle pour un cycle de développement agile. Pour ce qui du support dans Visual Studio de cette vision, je vais refaire la même réponse que pour les outils entreprise précédemment, attendez fin mai ou Microsoft va annoncer un certain nombre de nouveaux outils.

Dernière question, parler Design et Architecture avec un public de développeurs Microsoft pas toujours "bien" formé à .NET ne risque t-il pas de les décourager à terme ?

Marc Gardette : Il est difficile de répondre à cette question de manière générale : De quels développeurs parlons nous : des hobyistes, des développeurs Web (asp, php..), des développeurs RAD (VB 6, Windev), des développeurs techniques (C++…) des développeurs entreprise (serveur d’app, J2EE, .NET..) ? Et de ce que l’on entend par design et architecture : sensibilisation au pattern de code (singleton pattern), aux architectures applicatives (architecture distribuée en couche, MVC…) ou architecture niveau entreprise (integration pattern, EAI, SOA, architecture de données, urbanisation…).

Ce que nous essayons de faire, c’est d’adapter notre communication et nos outils tout en essayant de vulgariser les meilleures pratiques à tout niveau.

Pour être efficace en J2EE un développeur doit maîtriser un certain nombre de pattern (MVC, DVO). Le framework .Net au contraire intègre déjà de nombreux design pattern. (MVC dans ASP.NET, DVO dans le DataSet…) Nous offrons donc de base un environnement qui permet à un développeur d’écrire du code propre et efficace sans se prendre la tête avec des concepts compliqués. Nous élevons le niveau d’abstraction et intégrons des outils graphiques orientés RAD (Web form designer, Windows form designer, datagrid…) facilitant la tâche du développeur. Avec Whidbey, nous voulons aller encore plus loin et mettre à la portée de tous des outils graphiques orientés architectes (whitehorse, DSI, etc..). Le framework et les outils sont assez faciles à prendre en main, mais le développeur est souvent confronté à des choix de design : quel design pour ma couche de données, pour ma couche de présentation pour l’instrumentation de mes applications…

C’est pourquoi, Microsoft a beaucoup investi sur les PAG ou Prescritive Architecture Guidance qui offre à la fois des documents d’architecture permettant de se poser les bonnes questions et de prendre les bonnes décisions, mais aussi des « application block » qui implémentent un ensemble de meilleures pratiques de design et de programmation. Whidbey devrait offrir de nouvelles fonctionnalités (du type entreprise template) rendant encore plus simple l’utilisation de cette documentation et de ces mini-frameworks. L'important n’est pas de se dire si l’on doit parler d’architecture et de design à des développeurs, mais d’essayer de fournir les bons messages, les bons contenus, les bons événements et les bons outils pour la bonne audience. Ceci est également vrai au niveau des communautés : certaines comme DNG sont très orientées design et architecture applicative, d’autres sont plus centrées sur le code, les langages et les technos. Et cette richesse est bénéfique puisqu’elle permet de trouver au final ce que l’on recherche. Microsoft a toujours eu une approche pragmatique et nous ne voulons pas nous transformer en intégriste de telle ou telle architecture ou de telle ou telle méthodologie. Les principes à retenir : à chaque besoin son outil, faire très simplement les choses simples, faire simplement les choses compliquées, et pouvoir faire les choses très compliquées (extensibilité..).

Merci Marc Gardette !

Propos recueillis par : DNG