On retrouve XML dans les trois familles de composants d’Ilog. Pourquoi avoir introduit XML, plutôt que C++, dans votre moteur de règles Java ?D’abord, il est plus facile de manipuler des données XML en Java. Si nous avions dû traiter des objets XML en C++, il aurait fallu tout inventer. Ensuite, notre mouvement global de C++ vers Java, initié avec Jviews, s’amplifie. Certes, l’Europe s’est mise tardivement à utiliser le langage de Sun, son adoption n’ayant réellement décollé qu’il y a dix-huit mois. Mais si notre moteur de règles remporte un vif succès sur le créneau de la personnalisation auprès des éditeurs indépendants de logiciels (ISV, ou Independant Software Vendor – NDLR), comme Chordiant, BEA ou Intershop, il le doit à sa version Java Jrules. Et ce, même si les performances de Java sont encore de deux à quatre fois inférieures à celles de C++.La phase supplémentaire de lecture des données XML nuit-elle aux performances ?Avec Jrules 3. 5, les règles métier sont définies en XML et liées à un schéma XML. Les performances de notre moteur chuteraient si l’on convertissait les objets XML pour générer leurs équivalents en classes Java. Ce n’est pas le cas. Si Jrules 3. 5 continue d’exécuter des règles représentées dans un modèle objet Java, il sait aussi désormais lire directement un schéma XML pour en extraire de façon dynamique les objets XML auxquels seront appliquées les règles définies avec Jrules Builder. Avec XML, nous proposons ainsi un format d’échange de règles métier sur le web. L’une des utilisations de notre moteur consistera à traduire un document XML d’un format d’origine à un format cible, en filtrant son modèle DOM (Document Object Model). Une tâche que l’on peut remplir avec XSLT. Mais ces processeurs de transformation sont complexes. Un autre usage concerne les places de marché, où des règles métier XML s’avéreront utiles pour identifier instantanément, en cas de demandes d’achat, les fournisseurs les mieux placés pour répondre. A ce titre, i2 embarque Jrules dans Tradematrix, sa plate-forme de commerce collaboratif.Les règles XML régies par Jrules ont-elles un rôle à jouer dans l’intégration d’applications (EAI) ?Dans une plate-forme d’EAI, les règles XML détermineront la façon dont les données seront transformées et vers quelles applications elles seront dirigées. Nous cherchons à promouvoir notre technologie auprès des acteurs de ce domaine – Webmethods, par exemple. Nous fondons d’autant plus d’espoirs sur le marché des outils d’EAI qu’ils tendent à intégrer des moteurs de workflow pour orchestrer les flux de données générés par l’exécution de processus métier. Le BPM (Business Process Management) ressuscite avec les échanges collaboratifs sur internet. C’est l’usine du troisième millénaire, le futur travail à la cha”ne des intellectuels. Ce nouveau champ applicatif est énorme pour nos composants. A commencer par une nouvelle extension de notre bibliothèque vouée à la visualisation Jviews 4. 0, baptisée Jviews for Workflow. Avec elle, nous mettons notre expertise des environnements graphiques au service de la définition et de la modélisation de processus. Nous fournissons des objets graphiques prédéfinis, représentant des éléments standards de workflow, tels ceux préconisés par l’organisme WfMC – par exemple, les rôles, les tâches ou les connexions. Nos algorithmes de réarrangement de l’affichage permettront d’atteindre une bonne lisibilité des processus les plus complexes. Jviews for Workflow cible aussi la supervision du workflow en temps réel. XML joue-t-il un rôle dans vos techniques de visualisation du workflow ?D’une part, les modèles de workflow de Jviews for Workflow sont définis en XML. D’autre part, nous proposons deux mécanismes d’affichage des diagrammes de flux. Le premier se base sur une applet Java – une technique mieux adaptée au travail de définition du workflow. Pour la partie supervision, nous préférons un mécanisme d’affichage sur client léger, fondé sur HTML, des ” bitmaps ” et le langage XML SVG (Scalable Vector Graphics) de description des graphiques en deux dimensions. Ilog adhère d’ailleurs au groupe de travail sur SVG au W3C.Quels types d’éditeurs cherchez-vous à attirer avec Jviews for Workflow ?Nous approchons les fournisseurs de moteurs de workflow, comme Staffware. Mais notre outil devrait surtout séduire les éditeurs qui souhaitent embarquer des fonctions de workflow dans une offre plus globale. Si, par exemple, SAP désirait se lancer dans ce domaine, Jviews for Workflow contribuerait à réduire les délais de développement de sa solution – six mois suffiraient. A terme, tout éditeur ayant opté, dans un premier temps, pour notre nouvelle bibliothèque de visualisation peut potentiellement se changer en client de nos deux autres catégories de composants. En effet, une fois les modèles de processus élaborés, il faudra automatiser l’aiguillage des flux – Jrules couvre parfaitement ce besoin – et optimiser les tâches appartenant aux processus. Là, nous ne manquerons pas de placer nos composants d’optimisation, parmi lesquels Solver, pour l’approche par contraintes, ou Scheduler, pour l’ordonnancement.Quels sont vos axes de recherche pour demain ?Nous regardons de près la technologie d’agents, qui nous permettrait de rassembler tous nos produits d’intelligence artificielle. Dans des environnements de commerce électronique interentreprises, ces agents pourraient raisonner à partir de problèmes complexes – optimisation, filtrage, etc. – et communiquer entre eux. Et pourquoi pas au moyen du langage RDF, sur lequel s’appuie le concept de web sémantique.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
