Apparu il y a quelques mois pour faciliter la modélisation et l’orchestration de processus métiers au sein des offres d’intégration d’applications d’entreprise (EAI), le BPM (Business Process Management) est une couche applicative qui pilote les moteurs d’intégration entre applications. En d’autres termes, les opérationnels peuvent désormais assembler les composants applicatifs aussi simplement que l’on assemble un puzzle. Le secret ? Une interface graphique au sein de laquelle il suffit de dessiner pour programmer ! Rien n’étant réellement magique en informatique, derrière l’interface se cache un moteur chargé de traduire le “dessin” en un langage qui définit le processus, son comportement et son interface, les mécanismes de gestion des transactions, ainsi que le traitement des erreurs et autres exceptions lors de l’exécution du scénario. Le tout étant ensuite exécuté par un moteur de workflow qui pilote les processus.
Piloter le système du voisin ou, à défaut, l’interroger
Unanimes sur la nécessité d’un outil permettant de travailler au niveau fonctionnel, les éditeurs se disputent, en revanche, la normalisation de son langage. Trois approches s’opposent : Xlang, de Microsoft, WSFL (Web Services Flow Language), d’IBM, et BPML (Business Process Management Language), une initiative du consortium BPMI qui compte plus de cent membres dont Bowstreet, SAP, mais aussi IBM, HP, etc. Or, cette absence de consensus freine le développement des plates-formes d’échanges B to B utilisant, notamment, des services web. Un processus est en effet une suite d’interactions entre des personnes et des logiciels, chaque participant (humain ou application) pouvant être interne ou externe à l’entreprise. Lorsque deux ou plusieurs partenaires sont impliqués dans un même processus géré par un seul système de BPM, ce dernier doit pouvoir interroger les applications partenaires, ne serait-ce que, par exemple, pour vérifier qu’une commande est bien arrivée, pour connaître l’état d’avancement de la préparation, etc. Le cas échéant, si chaque partenaire dispose de son propre système de BPM, ces derniers doivent également pouvoir dialoguer pour échanger les mêmes informations. La normalisation est encore plus critique pour les plates-formes incorporant des services web où le BPM est supposé remédier à l’absence de mécanisme de gestion des files d’attente de la couche de transport HTTP/SOAP. Grâce à son moteur de workflow, le BPM peut en effet orchestrer et synchroniser l’exécution des transactions couplées (two-phases commit). A condition toutefois de pouvoir dialoguer avec le proxy SOAP qui exécute le service web afin, entre autres, de connaître son état. Là encore, un langage normalisé serait le bienvenu.Plutôt confiant, François Rivard, consultant senior responsable de l’offre EAI de la SSII française Cross Systems, estime que la normalisation ne devrait pas se faire attendre : “Je vois mal les éditeurs de BPM développer des outils de transformation pour passer d’un format de langage à un autre. Si une cohabitation des trois langages doit avoir lieu, elle ne durera pas longtemps”. Un point de vue confirmé par le Gartner Group, qui parie déjà sur un rapprochement entre Microsoft et IBM.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
