PGI orientés services : l'approche SAP-Oracle
Les progiciels de gestion orientés services visent à composer des applications par simple assemblage de composants. Oracle et SAP sont les premiers.
01net.
le 09/02/06 à 07h00
Les progiciels de gestion intégrés (PGI) adoptent progressivement une orientation services, incarnée notamment par les architectures J2EE Enterprise Services Architecture (ESA) de SAP et Fusion Architecture (FA) d'Oracle.
Suivant leur principe, la manière dont les applications travaillent est écrite à l'aide du dialecte WSBPEL (Web Services Business Process Execution Language).
Cette logique de travail est stockée hors de l'application, au sein de référentiels. Intérêt ? Les applications deviennent fortement administrables. Grâce à des workflows, elles peuvent aussi être recombinées
par assemblage, ce qui facilite l'adaptation des processus aux besoins de l'entreprise. Ces architectures systématisent l'emploi d'interfaces WSDL (un dialecte de description), pour représenter le système d'information, et de services Web, afin
d'organiser l'appel des applications et le dialogue entre elles. Cela grâce à des serveurs d'intégration de type Enterprise Service Bus.
En pratique, les premiers composants exécutables suivant une logique de travail décrite en WSBPEL, et stockés par des référentiels, feront leur apparition en 2006 chez SAP (mySAP ERP Enterprise Core Components), et en 2007 chez
Oracle (Applications Fusion). SAP a déjà présenté son référentiel prototype Enterprise Services Repository. Oracle n'a pas encore levé le voile sur Fusion Service Registry, un serveur d'origine Systinet.
Ladite logique de travail précise a minima le mode d'exécution des applications (séquentiel, parallèle), leur type de dialogue (synchrone, asynchrone), et les mécanismes transactionnels à l'?"uvre lorsqu'elles
travaillent ensemble (compensation). La logique de travail est formulée à l'aide d'outils dédiés. SAP propose le logiciel Business Process Execution Language Process Editor, et Oracle, JDeveloper BPEL Designer.
Des applications administrables et adaptables
Au sein de ces architectures, la formation d'une application s'effectue par l'assemblage de plusieurs composants. Cette formation repose sur l'établissement de circuits d'exécution ou workflows applicatifs. Les
deux éditeurs proposent de nouveau des outils spécifiques afin de définir ces circuits d'exécution, dont SAP Business Workflow et Oracle BPEL Process Manager (d'origine Proforma).
L'exécution de ces workflows est différente chez SAP et Oracle. Le premier a décidé d'embarquer le moteur d'exécution au sein de son serveur d'intégration SAP XI. Oracle a opté pour l'environnement BPEL
Server, directement exécuté par son serveur d'applications Oracle 10g Application Server. D'autres workflows qualifiés ' d'humains ' peuvent également être mis en place, cela afin de diviser une
tâche globale en autant de sous-tâches confiées à différents utilisateurs.
La logique de travail des applications ainsi que les circuits d'exécution applicatifs et humains sont fortement administrables, au moyen de consoles. Ce qui rend les architectures ESA et FA très souples. Ni les objets métier EJB
exploités par SAP ni la combinaison de composants, procédures stockées et formulaires utilisés aujourd'hui par Oracle n'offrent cette possibilité. ' Cette approche présente aussi le risque de transformer le système
d'information en un jeu de Lego difficile à maîtriser ', modère Cory Eaves, directeur technique de l'éditeur de progiciels SSA Global.
En attendant la livraison d'applications idoines, les deux éditeurs proposent de migrer vers leur plate-forme respective, SAP NetWeaver 2004s de SAP et Fusion Middleware d'Oracle. Déjà disponibles, elles regroupent l'ensemble des
serveurs et des moteurs d'exécution nécessaires à l'établissement de ces architectures administrables. Soit un serveur d'applications J2EE 1.4 (double c?"ur J2EE/ ABAP pour SAP), une solution de portail, un logiciel décisionnel, un serveur de
gestion des métadonnées et un serveur d'intégration.
Des ESB facilitent l'intégration d'applications hétérogènes
Afin de surveiller l'exécution des composants, suivant un circuit prédéfini, les plates-formes NetWeaver 2004s et Fusion Middleware embarquent des serveurs de supervision de l'activité métier, dite BAM (Business Activity
Monitoring). Ils travaillent de concert avec les serveurs BPEL et mettent à disposition de l'utilisateur non informaticien, des tableaux de bord de déroulement de l'activité.
À chaque étape de l'exécution d'un workflow, le serveur BPEL notifie l'état de ladite exécution. Ce qui a pour effet de permettre le suivi ' temps réel ' d'une prise de commande ou d'une
livraison. Pour ce faire, SAP livre le serveur ARIS Process Platform d'IDS Scheer. Quant à Oracle, il propose le serveur BAM d'origine Istante. Ces plates-formes comprennent des serveurs d'intégration de type Enterprise Service Bus (ESB). Ils
combinent la prise en charge de services Web, un middleware orienté messages et des connecteurs point à point (SAP XI et Oracle Fusion Service Bus).
Leur travail consiste à organiser le dialogue interapplications au moyen de services Web. Et donc, à transmettre des commandes BPEL vers les composants (mode d'exécution, mécanismes transactionnels) au moyen du protocole Soap. Leur
nature hybride facilite l'intégration d'applications hétérogènes. ' Les clients français, tels Arcelor et Bouygues Telecom, déjà en production, notent la capacité du serveur à intégrer des applications SAP, mais aussi tierces,
ce qui est un point positif ', note Didier Gamain, président du club des utilisateurs de SAP France.
Oracle ne compte commercialiser son serveur d'intégration de type ESB qu'en 2006. Enfin, SAP NetWeaver de SAP et Fusion Middleware d'Oracle comportent aussi un serveur d'identités, qui concentre le travail d'authentification, de
gestion des identités, et de transmission des permissions en réseau avec des jetons formés en dialecte SAML 2.0. Oracle livre Identity Management, un logiciel d'origine Oblix, Thor et Octet-String. Quant à SAP, il s'appuie sur des solutions
tierces telle HiPath SIcurity DirX Identity de Siemens.
Au final, Oracle va devoir gérer une difficulté supplémentaire : intégrer les applications acquises, notamment celles de Siebel et de PeopleSoft, à cette architecture. ' Nous proposerons pour cela
l'annuaire Integration Repository, destiné à inventorier les API de l'ensemble de nos applications [Information Age Applications, NDLR], qui ne sont pas forcément orientées services. Celles-ci pourront alors être facilement
implémentées à notre serveur d'intégration Fusion Service Bus ', conclut Lionel Dubreuil, chef de produit technologie chez Oracle France.
A voir
SAP Developer Network (SDN) : un centre de ressources entièrement consacré à l'offre de SPA, notamment à son architecture ESA.
Oracle Technology Network : l'équivalent de SDN chez Oracle. Le site contient un guide des meilleures pratiques pour l'établissement de logiques de travail BPEL.
BPEL Source : un site ressource, qui documente les usages de ce dialecte.
Des PGI interopérables
Les PGI orientés services modernisent la proposition formulée depuis longtemps par le développement objet. Ils visent à composer des applications par assemblage de composants. Ils exploitent surtout des langages standard pour
représenter le SI (WSDL), spécifier la logique de travail des applications (WSBPEL), et procéder aux appels de composants (Soap). Cela, sous l'égide des organismes WS-I ou Oasis. Une condition indispensable pour administrer et intégrer
indifféremment les logiciels tiers et natifs, à l'aide d'outils identiques. Ce que les PGI d'aujourd'hui ne font pas.
Les architectures ESA et FA vont évoluer progressivement, pour prendre en charge un cortège de dialectes complémentaires à BPEL. Par exemple, WSBPEL for People, conçu pour spécifier des workflows humains. BPXL,
spécialisé dans la représentation des transactions, ou XPDL, un dialecte orienté modélisation.
Les PGI orientés services reposent sur trois fondamentaux : l'exploitation systématique d'interfaces WSDL pour représenter le système d'information (intégration, exécution, vues, données),
l'utilisation du dialecte WSBPEL afin de préciser la logique de travail, et l'usage du protocole d'appel Soap.
Une supervision métier temps réel : les serveurs BAM surveillent le déroulement d'un traitement en temps continu. Il devient donc possible de connaître l'état d'avancement d'une
commande, au fil de son exécution. Des outils dédiés permettent de modifier la logique de travail des applications. Les workflows en assurent l'assemblage.
nos newsletters
Abonnez-vous à Micro Hebdo : 4,90 €/mois
Abonnez-vous à l'Ordinateur Individuel : 3 €/mois
Abonnez-vous à la version digitale
Abonnez-vous à 01Business et Technologies : 19 €/mois
