L'homogénéisation des outils de développement

Les frameworks des ateliers de développement pour .Net et J2EE ont de plus en plus de composants communs. Ce qui favorise l'harmonisation des offres et simplifie la vie des développeurs.

L'essor des standards, du développement par composants et du concept de SOA (Service Oriented Architecture) a eu un effet pervers sur les serveurs d'applications : le découplage du serveur de son atelier de développement, mais aussi du socle d'exécution de la bibliothèque de fonctions, ou framework. Celle-ci peut désormais être enrichie de fonctions tierces. Or, que l'on développe en PHP, en Java ou en C#, les entreprises utilisent globalement les mêmes services techniques : gestion des sessions, accès aux bases de données, reprise sur erreur, génération d'interfaces graphiques, etc. Dans ces conditions, pourquoi un service J2EE ne pourrait-il pas aussi servir pour un développement .Net moyennant une adaptation ? Une question à laquelle de plus en plus d'éditeurs, de SSII et de communautés open source semblent répondre par la déclinaison de leurs développements sur ces deux environnements techniques. Provoquant, par la même occasion, une homogénéisation des offres.

Le framework, véritable valeur ajoutée

Dans leurs premières générations, les serveurs d'applications étaient fortement couplés à un atelier de développement. Pour se différencier, les éditeurs s'évertuaient alors à enrichir le serveur de fonctions plus ou moins conformes aux standards J2EE, voire propriétaires, exploitables par leur seul atelier de développement. Poussés par la pression d'un marché toujours en attente de la portabilité de J2EE et, surtout, par les avantages de la réutilisation des services favorisée par la séparation des couches, ils ont progressivement découplé le socle d'exécution de la bibliothèque de fonctions, ou framework. Ce qui a eu pour conséquence de reléguer le serveur d'applications proprement dit au rang de simple socle d'exécution. La valeur ajoutée réside dès lors dans le framework, que l'on peut aisément enrichir sans remettre en cause le socle. Cette tendance a été répercutée sur l'atelier de développement. Aujourd'hui, celui-ci est aussi composé d'un socle, sur lequel on assemble des composants exploitant le framework des serveurs d'applications. Là encore, le socle étant devenu une commodité sans valeur ajoutée réelle, la plupart des éditeurs ont abandonné leur développement propriétaire au profit d'Eclipse. Dernier en date, Borland annonçait en mars 2005 le remplacement du socle de JBuilder, Prime Time, par celui d'Eclipse. ' La valeur ajoutée de l'atelier de développement ne provient pas du socle, mais des fonctions que l'on greffe dessus ', relevait alors Bruno de Combiens, chef de produit de Borland.

La double vie des composants

Même Microsoft n'échappe pas à la tendance avec la dernière version de son atelier de développement. ' Visual Studio .Net 2005 est composé d'un socle et d'un framework répondant aux besoins de .Net. Mais il peut être enrichi aussi facilement qu'Eclipse de frameworks tiers ', souligne Messaoud Oubechou, architecte senior chez Octo Technology. Ce qui est d'ailleurs déjà le cas, puisqu'Alain Le Hegarat, responsable marketing et ventes de la division plate-forme de développement chez Microsoft, revendique plus de 280 extensions tierces pour Visual Studio .Net 2005. Le phénomène nouveau, c'est que, dans ces extensions, on trouve de plus en plus de bibliothèques de fonctions, qui, en réalité, ne sont que des transpositions de frameworks initialement conçus pour les serveurs d'applications J2EE.C'est le cas de NUnit, transposition de JUnit, un ensemble de fonctions pour le test unitaire décliné de Java en C#. C'est aussi celui d'ANT (Another Neat Tool), un outil de construction de projets conçu au départ pour les environnements J2EE, aujourd'hui décliné pour .Net avec Nant (Not ANT). ' Les communautés open source sont à l'origine du principe d'assemblage de composants, évoque Sébastien Brunot, architecte chez Octo Technology. Raison pour laquelle le phénomène de transposition va plutôt dans le sens J2EE vers .Net. Reste que l'homogénéisation des frameworks entre environnements est à ce jour une réalité indiscutable. '

Le modèle de Microsoft freine la tendance

Pour Pascal Grojean, directeur associé de Sysdeo, du groupe SQLI, cette double vie des composants reste toutefois limitée : ' Sur le court terme, elle est indéniable. Fort heureusement, il existe des gens plus agnostiques que d'autres. Mais on n'évitera pas les querelles de chapelle, prévient-il. Ni, surtout, le modèle économique de Microsoft, dont le principe de base est d'occuper tout l'espace sur Windows. Donc, dès qu'une opportunité se présente, Microsoft développe et intègre la fonction. ' Pour preuve, Visual Studio .Net comprend désormais ses propres fonctions de tests unitaires et propose une alternative à Nant, MSBuild. ' Ce qui n'exclut pas la possibilité d'utiliser NUnit ou Nant ', prévient Alain Le Hegarat, de Microsoft. ' Sur les besoins banalisés, il est clair que nous préférons intégrer parce que nous sommes persuadés qu'au final le client est gagnant. Et cela pour la simple raison que nous lui épargnons un assemblage de composants, poursuit-il. De la même façon, notre modèle économique n'a jamais été de développer pour d'autres plates-formes que celle de Windows. Nous n'envisageons donc pas de décliner notre framework pour d'autres environnements que .Net. ' Reste à savoir quelle marge de man?"uvre Microsoft entend laisser à ses partenaires et à la communauté open source, qui investissent dans la déclinaison de composants pour .Net. S'il suffit qu'un besoin se ' banalise ' pour que Microsoft incorpore le composant à son offre, les velléités d'adaptation s'étioleront. Pis : ' L'entreprise qui fait le choix d'enrichir son framework .Net avec des composants ?" double vie ou pas ?" risque de se retrouver coincée si, par malheur, Microsoft oriente différemment les évolutions de sa plate-forme, estime Messaoud Oubechou, d'Octo Technology. Les entreprises équipées en .Net doivent donc inscrire le choix de leurs composants dans la pérennité ou, en d'autres termes, dans la stratégie de Microsoft. ' Un risque dont Schneider Electric a cherché à se préserver lors de l'enrichissement de son framework .Net. En effet, le leader mondial dans la gestion de l'électricité et des automatismes n'a sélectionné que des composants émanant de l'open source ou d'offres propriétaires, au code source accessible. ' Nous avons ainsi la certitude de pouvoir faire évoluer nos composants si le besoin s'en faisait sentir ', affirme Alain Fuss, directeur des technologies et de l'architecture logicielle de la division Customer Software & eBusiness de Schneider Electric.

Vers la plate-forme universelle

La double vie des composants pourrait pourtant simplifier les développements en entreprise. A ce jour, en effet, la plupart d'entre elles travaillent à la fois sur J2EE et .Net. Ce que démontre Pascal Grojean, de Sysdeo : ' Une personne qui maîtrise JUnit sera forcément à l'aise avec NUnit, car les interfaces API et la logique sont les mêmes. Les développeurs pourraient ainsi facilement passer d'un environnement à l'autre. ' Avec, à la clé, une meilleure exploitation des ressources humaines. Pour les experts du marché, l'enjeu va même beaucoup plus loin. ' Nous avons moins besoin de composants à double vie que d'usines multitechnologies, capables de traiter les serveurs d'applications J2EE, .Net, mais aussi les langages SQL, C et C++, Javascript, etc. ', justifie Messaoud Oubechou, d'Octo Technology. En effet, sur le moyen terme, Pascal Grojean, le directeur associé de Sysdeo, estime que l'encapsulation des services techniques des frameworks en services web aidera à résoudre aisément les problèmes d'incompatibilité du côté du socle d'exécution, et que le concept de MDA (Model Driven Architecture) en fera autant du côté de l'atelier de développement. ' Certains serveurs d'applications seront même multilingues. C'est déjà le cas avec celui de SAP, Netweaver, qui accepte aussi bien les développements Java qu'Abap, analyse le directeur de Sysdeo. L'idée est clairement de s'orienter vers une homogénéisation des couches basses. Mais le problème est moins technique qu'industriel, juridique et, surtout, politique. ' Cette évolution supposerait notamment une ouverture des développements de chaque éditeur pour permettre aux tierces parties de s'insérer directement dans le code des socles d'exécution et dans les frameworks. Qui détiendrait alors le produit ?