Après avoir longtemps hésité, Ilog franchit le pas : selon l’éditeur, Java est désormais suffisamment mûr pour l’optimisation de ressources, un domaine dans lequel des performances élevées sont essentielles. L’éditeur français lance d’abord J/Solver, la version Java de son moteur d’optimisation par contraintes. Il s’agit là d’une première : à ce jour, seuls ses composants de visualisation et son moteur de gestion de règles étaient intégralement disponibles en Java. Le basculement s’est fait en trois étapes : développement de classes Java pour l’ensemble des variables de décision, définition d’opérateurs pour lier ces variables aux contraintes et, enfin, conception d’une interface de recherche d’une contrainte donnée.
A chaque nouvelle version des outils, Java gagne en rapidité
Ce virage vers Java tord le cou à la réputation de lenteur souvent associée à ce langage. “Ses performances ont évolué jusqu’au point où il devient possible d’exécuter des tâches de calcul lourd inhérentes à l’optimisation de ressources “, souligne Gregory Glockner, directeur produits chez Ilog. A chaque nouvelle version des JDK (Java Development Kit), le langage gagne en rapidité. “Les outils Java profitent d’une communauté de développeurs plus importante que celle qui se consacre à l’amélioration de compilateurs C++ “, renchérit Alain Chabrier, ingénieur développement chez Ilog.Dans la foulée, l’éditeur dote son composant d’optimisation mathématique, CPLEX, d’une couche de modélisation en Java. Mais son moteur, écrit en C, reste inchangé. En effet, “CPLEX est optimisé pour le code d’un Pentium 4 et dépend davantage de la performance du processeur, explique Gregory Glockner. Java n’exécute encore qu’un ” byte code ” générique. Le moteur CPLEX est donc plus gourmand en mémoire que Solver. Les modèles d’optimisation par contraintes sont moins complexes, alors que l’optimisation mathématique joue sur plusieurs dizaines de milliers de variables.”
Les surcharges d’opérateurs ne sont pas prises en compte
Autre léger inconvénient du langage : à la différence de C++, il ne prend pas en compte les surcharges d’opérateurs. Autrement dit, au sein d’une contrainte, qui stipule la relation entre plusieurs variables, il n’est pas possible de redéfinir la spécification des opérateurs. La parade consiste simplement à recourir à l’emploi de mécanismes alternatifs. “Dans J/Solver, les opérateurs sont simulés par l’emploi des méthodes Java, précise Gregory Glockner. De telle sorte que l’API contient des méthodes Java qui réalisent les calculs à la place des opérateurs.” Le lancement de J/Solver répond à une forte demande de la part des clients. Ces derniers s’équipent en effet de plus en plus de serveurs d’applications J2EE.Outre une facilité d’intégration accrue, J/Solver tombe également à pic pour rejoindre le catalogue croissant d’applications pré- intégrées à cette catégorie de serveur d’applications, souligne Gregory Glockner. Et d’ajouter : “J/Solver facilite une approche distribuée de la logique métier de l’optimisation dans l’entreprise et démocratise l’accès au travers de terminaux légers.”Dans l’immédiat, Ilog continue de gérer une transition de fond, qualifiée, par ailleurs, de coûteuse et complexe. Ainsi, Concert Technology est livré avec une interface d’accès à ses moteurs, en Java et en C++. Alors que l’outil de modélisation OPL Studio en offre trois ! Parmi les modules complémentaires à Solver, Scheduler, Dispatcher et Configurator, seul ce dernier est réécrit en Java. Il cible en particulier les applications d’optimisation en libre-service sur le web. Bien que les premiers clients à évaluer J/Solver pour leurs besoins de planification opérationnelle se trouvent être des grands comptes du secteur de la Défense.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
