PETALS
Un projet d? ESB conforme au standard JBI ou comment les standards XML
contribuent a l?integration des systemes d?information
Gael BLONDELLE , Adrien LOUIS et Jean-Pierre LORRE
(com-xml@ebmwebsourcing.com, http://www.ebmwebsourcing.com)
---------------
Retrouvez cet article en ligne
(http://xmlfr.org/actualites/decid/051109-0001).
Donnez votre avis !
mailto:xml-decid@xmlfr.org?subject=Re:%20INFO%20:%20PETALS
---------------
Introduction
Les standards XML sont au c?ur des nouvelles solutions d?integration
proposees actuellement. Elles sont issues de la convergence de
plusieurs technologies :
- Les technologies middleware en general ( MOM , ORB ) et l? EAI
(Enterprise Application Integration) en particulier. Ces derniers ont
participes a la generalisation des outils de communication
inter-applications ( A2A ) et a la diffusion des concepts. Bien qu?un
effort de standardisation ait eu lieu au niveau des couches basses de
communication ( CORBA / IIOP ) ces outils sont tres souvent
specifiques a un editeur et manquent de standardisation et
d?interoperabilite.
- Les technologies de l? EDI (Electronic Data Interchange) ont ete
developpees pour l?echange de donnees inter-entreprises ( B2B ).
Essentiellement orientee vers l?echange de documents, la communaute
s'est surtout focalisee sur la definition de standards metiers pour
les processus d?echange et la representation des informations (
Edifact en Europe et Ansi X12 aux Etats-Unis).
- Les services Web qui s?appuient sur un ensemble de specifications XML
( SOAP , WSDL et UDDI ) afin de publier sous une forme accessible par
Internet les interfaces des applications. Les principaux avantages de
cette technologie sont bien sur lies a sa standardisation et a sa
facilite de mise en ?uvre, notamment dans le cas de l?implementation
Web de SOAP ( HTTP ).
Ces technologies mais surtout les concepts d?architectures associes a
SOA (Service Oriented Architecture) sont a la base d?une nouvelle
generation de middleware ; les ESB (Entreprise Service Bus).
L?objet de cet article est de decrire le projet PETALS (http
://petals.object.org [1] ) qu? EBM WebSourcing a initialise
conjointement avec une entreprise Bresilienne, Fossil E-Commerce , au
sein du consortium ObjectWeb (http://www.objectweb.org [2] ) dedie au
logiciel libre.
Fonde en 2002 par France Telecom , Bull et l? INRIA , ObjectWeb est un
consortium d?acteurs industriels et academiques mondiaux qui conjuguent
leurs efforts pour creer en open-source du logiciel middleware de
nouvelle generation. Le consortium s'appuie sur des standards ouverts
et developpe une offre alternative aux systemes proprietaires dans le
domaine de l'e-business, de l' EAI , des grilles de calcul et des
messageries d'entreprise. ObjectWeb propose ainsi des solutions pretes
a l'emploi, dont la mise en oeuvre est immediatement rentable. JOnAS
(implantation open-source des specifications J2EE TM), JORAM (bus a
messages conforme JMS ), Enhydra (serveur d'application Java / XML ) en
sont des exemples.
Ce document est organise de la maniere suivante : la premiere partie
fait un tour d?horizon des concepts SOA et ESB , la seconde partie
detaille le standard JBI (Java Business Integration) alors que la
troisieme donne des informations sur le projet PETALS .
SOA et ESB
SOA est un concept (pattern) d?architecture faiblement couplee, dont l?
ESB est une mise en ?uvre possible ; nous allons detailler ces notions
dans ce paragraphe.
SOA (Service Oriented Architecture)
La notion de SOA (Service Oriented Architecture) definit un style
d?architecture reposant sur l?assemblage de services proposes par les
applications. Dans ce style d?architecture, les differents composants
logiciels sont connectes par un couplage lache.
Dans une architecture de services, chaque element applicatif doit
fournir tout ou partie de ses fonctionnalites sous formes de services
pouvant etre appeles par d?autres applications. Pour fournir ses
services, un element applicatif peut utiliser des services proposes par
d?autres applications, pouvant etre issues de technologies heterogenes.
Globalement, « l?approche SOA » est l?union :
- D?une methodologie pour identifier et concevoir des applications
comme des assemblages de services,
- D?un ensemble d?outils et d?infrastructures pour faciliter la
creation de ces services et leur utilisation,
- De patterns de construction de services.
Un des principaux enjeux metier et technique de ce type d?approche est
lie a la conception des services et notamment a leur granularite. Les
principales regles specifient que les services doivent pouvoir etre
decouverts dynamiquement, qu?ils sont interoperables, faiblement
couples, de forte granularite et composable (au sein d?une application,
d?un service de plus forte granularite ou orchestre dans un processus
metier). Ces regles ont pour corollaire un mode de communication
asynchrone par messages base sur l?echange de documents.
Un des patterns de base de ce type d?architecture est le « find, bind
and execute » qui autorise un consommateur de service a demander a un
repertoire partage un service correspondant a un critere specifie. Si
le repertoire dispose d?un service correspondant a la requete, il
retourne au consommateur un contrat, une adresse et un point de contact
pour ce service que le consommateur est alors susceptible d?invoquer.
Bien que pouvant etre mis en ?uvre par differents types de technologies
( CORBA , Jini , etc.) la SOA s?appuie generalement sur les standards
Web Services : SOAP (format d?echange de messages en XML standardise
par le W3C ), WSDL (description de l?interface d?un service standardise
par le W3C ), UDDI (annuaire distribue qui permet de publier les
interfaces des services Web ) et la gamme WS-* qui comprennent
notamment des specifications telles que :
WS-Security : securite des services Web.
WS-Distributed Management ( WS-DM ) : gestion des endpoints.
WS-Reliable ( WS-ReliableMessaging , WS-Reliability ) : Acheminement de
bout en bout des messages SOAP.
SOA est donc principalement un ensemble de bonnes pratiques qui, comme
nous allons le voir ci-dessous, trouvent une realisation efficace dans
une mise en ?uvre ESB .
ESB (Enterprise Service Bus)
L? ESB est un concept apparu en 2003, defini par le Gartner Group , et
pousse tout particulierement par Sonic Software et son evangeliste Dave
Chappell dont le livre sur « Enterprise Service Bus » a ete publie en
2004.
L? ESB emprunte a l?approche EAI la possibilite de proposer des outils
pour :
- L?acheminement et le routage des messages.
- La connexion des progiciels ( ERP , CRM ) ou des technologies
standards ( SGBDR , XML , etc.).
- La transformation des donnees.
- La gestion du workflow applicatif.
Un « Enterprise Service Bus » est une solution d?integration
implementant une architecture totalement distribuee, et fournissant des
services comme la transformation des donnees ou le routage base sur le
contenu ( CBR ), ainsi qu?une interoperabilite accrue par l?utilisation
systematique des standards comme XML , les Web Services et les normes
WS-*.
La notion de distribution est centrale pour un ESB . En effet, par
essence les applications a integrer sont reparties sur differentes
machines. Par la mise en ?uvre de ce principe de distribution, le « bus
» de l? ESB devient virtuel, les donnees de configuration et
d?administration etant alors distribuees sur les extremites de l? ESB ,
c?est-a-dire au plus pres des applications a integrer. Ceci permet de
contourner les problemes lies a l?architecture « hub and spoke »
proposee classiquement par les solutions EAI , et amene a des
architectures sans SPOF (Single Point Of Failure : point unique par
lequel passent tous les traitements et qui paralysent un systeme en cas
de panne).
Une offre ESB doit offrir des services techniques comme la
transformation des messages, le routage base sur le contenu et
eventuellement l?orchestration des services.
Le standard JBI
JBI est un standard permettant d?assembler des composants pour
construire des solutions d?integrations. La norme JBI se base sur
quelques elements fondamentaux : les « Binding Components », qui sont
des composants d?integration de type connecteur ; les « Service Engines
» qui sont des composants d?integration de type transformation de
message, workflow, ou autre traitement ; le « Normalized Message Router
» qui assure le couplage faible entre les composants ; le « Normalized
Message », qui reprend l?approche orientee document adoptee par la
communaute Web Services.
L?interet de JBI par rapport a d?autres specifications reside
principalement dans le fait qu?elle reprend les « bonnes pratiques » du
monde XML et Web Services pour les appliquer a l?assemblage de
composants Java :
- Definition des interfaces en WSDL .
- Utilisation de la notion de Normalized Message Router qui introduit
un niveau de couplage faible entre les composants.
- Utilisation de XML pour representer les donnees echangees.
Il apparait clairement que la specification JBI met XML et les
standards Web Services comme WSDL au centre des solutions d?integration
en Java . Ainsi, une implementation JBI doit obligatoirement fournir un
Binding Component respectant le WS-I Basic Profile pour etre certifiee.
Cependant, il faut noter que les utilisateurs finaux utiliseront peu la
specification JBI , si ce n?est pour adapter ou etendre une solution
d?integration a leur besoin specifique. En effet, la bonne pratique
pour se connecter a un environnement de type ESB est d?utiliser les
standards Web Services, qui fournissent la meilleure independance entre
le client, l?infrastructure ESB , et le serveur.
C?est donc pour les editeurs ou les integrateurs de solutions de type
ESB que la norme JBI est pertinente. Elle prend tout son sens dans le
cadre d?un consortium comme ObjectWeb en servant de catalyseur entre
les differents projets du consortium pour etre capable de les assembler
rapidement en creant de nouvelles solutions d?integration. Ceci est
vrai aussi bien pour les projets fournissant principalement des
connexions au niveau protocole, que pour des projets fournissant des
traitements de plus haut niveau comme des outils de transformation ou
d?enrichissement, ou encore des outils de Workflow.
Le projet PETALS
Le projet PETALS s?inscrit dans l?initiative ESB lancee par ObjectWeb
en juin 2004 afin de federer les efforts autour des projet open source
dans le domaine du middleware d?integration.
Les principaux objectifs du projet sont de proposer une implementation
d?une plate-forme JBI prenant en compte les problematiques
d?environnements d?integration hautement distribues, et fournissant les
bases pour la construction de passerelles B2B en proposant des Binding
Components du type ebXML , et autres.
Le projet PETALS travaille en etroite collaboration avec le projet
Celtix pour realiser une integration bidirectionnelle entre les deux
projets : PETALS utilisera des composants Celtix pour fournir un grand
nombre de Binding Components y compris certains protocoles de la pile
SOAP , et Celtix utilisera PETALS comme niveau d?implementation de JBI
--
Devenez redacteur <XML>fr et contribuez au developpement
du xml francophone (http://xmlfr.org/infos/redacteurs) !
Liste de diffusion "xml-decid@xmlfr.org" (http://xmlfr.org).
Cette liste est a votre disposition pour discuter en francais de
tout sujet lie a XML.
Pour resilier votre abonnement, envoyez un message contenant la
commande "unsubscribe" a xml-decid-request@xmlfr.org
(mailto:xml-decid-request@xmlfr.org?Subject=unsubscribe)
Received on Thu Nov 10 15:23:18 2005
