Passer au contenu

Patrick Albert (Ilog) : ” Le workflow tend à devenir un champ applicatif énorme “

En amplifiant leur mouvement vers Java et en introduisant XML, les composants d’Ilog s’ouvrent désormais à la gestion des processus métier.


Stéphane Parpinelli : 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 ?
Patrick Albert : 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.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. 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.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.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.


propos recueillis par Stéphane Parpinelli