INFO : PETALS

PETALS

Un projet d? ESB conforme au standard JBI ou comment les standards XML=20
contribuent a l?integration des systemes d?information

Gael BLONDELLE=A0 , Adrien LOUIS=A0 et Jean-Pierre LORRE=A0=20
([email protected], http://www.ebmwebsourcing.com)
---------------
Retrouvez cet article en ligne
(http://xmlfr.org/actualites/decid/051109-0001).

Donnez votre avis !
mailto:[email protected]?subject=3DRe:%20INFO%20:%20PETALS
---------------

Introduction
Les standards XML sont au c?ur des nouvelles solutions d?integration=20
proposees actuellement. Elles sont issues de la convergence de=20
plusieurs technologies :

- Les technologies middleware en general ( MOM , ORB ) et l? EAI=20
  (Enterprise Application Integration) en particulier. Ces derniers ont=20
  participes a la generalisation des outils de communication=20
  inter-applications ( A2A ) et a la diffusion des concepts. Bien qu?un=20
  effort de standardisation ait eu lieu au niveau des couches basses de=20
  communication ( CORBA / IIOP ) ces outils sont tres souvent=20
  specifiques a un editeur et manquent de standardisation et=20
  d?interoperabilite.
- Les technologies de l? EDI (Electronic Data Interchange) ont ete=20
  developpees pour l?echange de donnees inter-entreprises ( B2B ).=20
  Essentiellement orientee vers l?echange de documents, la communaute=20
  s'est surtout focalisee sur la definition de standards metiers pour=20
  les processus d?echange et la representation des informations (=20
  Edifact en Europe et Ansi X12 aux Etats-Unis).
- Les services Web qui s?appuient sur un ensemble de specifications XML=20
  ( SOAP , WSDL et UDDI ) afin de publier sous une forme accessible par=20
  Internet les interfaces des applications. Les principaux avantages de=20
  cette technologie sont bien sur lies a sa standardisation et a sa=20
  facilite de mise en ?uvre, notamment dans le cas de l?implementation=20
  Web de SOAP ( HTTP ).
Ces technologies mais surtout les concepts d?architectures associes a=20
SOA (Service Oriented Architecture) sont a la base d?une nouvelle=20
generation de middleware ; les ESB (Entreprise Service Bus).

L?objet de cet article est de decrire le projet PETALS (http=20
://petals.object.org [1] ) qu? EBM WebSourcing a initialise=20
conjointement avec une entreprise Bresilienne, Fossil E-Commerce , au=20
sein du consortium ObjectWeb (http://www.objectweb.org [2] ) dedie au=20
logiciel libre.

Fonde en 2002 par France Telecom , Bull et l? INRIA , ObjectWeb est un=20
consortium d?acteurs industriels et academiques mondiaux qui conjuguent=20
leurs efforts pour creer en open-source du logiciel middleware de=20
nouvelle generation. Le consortium s'appuie sur des standards ouverts=20
et developpe une offre alternative aux systemes proprietaires dans le=20
domaine de l'e-business, de l' EAI , des grilles de calcul et des=20
messageries d'entreprise. ObjectWeb propose ainsi des solutions pretes=20
a l'emploi, dont la mise en oeuvre est immediatement rentable. JOnAS=20
(implantation open-source des specifications J2EE TM), JORAM (bus a=20
messages conforme JMS ), Enhydra (serveur d'application Java / XML ) en=20
sont des exemples.

Ce document est organise de la maniere suivante : la premiere partie=20
fait un tour d?horizon des concepts SOA et ESB , la seconde partie=20
detaille le standard JBI (Java Business Integration) alors que la=20
troisieme donne des informations sur le projet PETALS .

SOA et ESB
SOA est un concept (pattern) d?architecture faiblement couplee, dont l?=20
ESB est une mise en ?uvre possible ; nous allons detailler ces notions=20
dans ce paragraphe.

SOA (Service Oriented Architecture)
La notion de SOA (Service Oriented Architecture) definit un style=20
d?architecture reposant sur l?assemblage de services proposes par les=20
applications. Dans ce style d?architecture, les differents composants=20
logiciels sont connectes par un couplage lache.

Dans une architecture de services, chaque element applicatif doit=20
fournir tout ou partie de ses fonctionnalites sous formes de services=20
pouvant etre appeles par d?autres applications. Pour fournir ses=20
services, un element applicatif peut utiliser des services proposes par=20
d?autres applications, pouvant etre issues de technologies heterogenes.

Globalement, =AB l?approche SOA =BB est l?union :

- D?une methodologie pour identifier et concevoir des applications=20
  comme des assemblages de services,
- D?un ensemble d?outils et d?infrastructures pour faciliter la=20
  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=20
lie a la conception des services et notamment a leur granularite. Les=20
principales regles specifient que les services doivent pouvoir etre=20
decouverts dynamiquement, qu?ils sont interoperables, faiblement=20
couples, de forte granularite et composable (au sein d?une application,=20
d?un service de plus forte granularite ou orchestre dans un processus=20
metier). Ces regles ont pour corollaire un mode de communication=20
asynchrone par messages base sur l?echange de documents.

Un des patterns de base de ce type d?architecture est le =AB find, bind=20
and execute =BB qui autorise un consommateur de service a demander a un=20
repertoire partage un service correspondant a un critere specifie. Si=20
le repertoire dispose d?un service correspondant a la requete, il=20
retourne au consommateur un contrat, une adresse et un point de contact=20
pour ce service que le consommateur est alors susceptible d?invoquer.

Bien que pouvant etre mis en ?uvre par differents types de technologies=20
( CORBA , Jini , etc.) la SOA s?appuie generalement sur les standards=20
Web Services : SOAP (format d?echange de messages en XML standardise=20
par le W3C ), WSDL (description de l?interface d?un service standardise=20
par le W3C ), UDDI (annuaire distribue qui permet de publier les=20
interfaces des services Web ) et la gamme WS-* qui comprennent=20
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=20
bout en bout des messages SOAP.

SOA est donc principalement un ensemble de bonnes pratiques qui, comme=20
nous allons le voir ci-dessous, trouvent une realisation efficace dans=20
une mise en ?uvre ESB .

ESB (Enterprise Service Bus)
L? ESB est un concept apparu en 2003, defini par le Gartner Group , et=20
pousse tout particulierement par Sonic Software et son evangeliste Dave=20
Chappell=A0 dont le livre sur =AB Enterprise Service Bus =BB a ete publie=
 en=20
2004.

L? ESB emprunte a l?approche EAI la possibilite de proposer des outils=20
pour :

- L?acheminement et le routage des messages.
- La connexion des progiciels ( ERP , CRM ) ou des technologies=20
  standards ( SGBDR , XML , etc.).
- La transformation des donnees.
- La gestion du workflow applicatif.
Un =AB Enterprise Service Bus =BB est une solution d?integration=20
implementant une architecture totalement distribuee, et fournissant des=20
services comme la transformation des donnees ou le routage base sur le=20
contenu ( CBR ), ainsi qu?une interoperabilite accrue par l?utilisation=20
systematique des standards comme XML , les Web Services et les normes=20
WS-*.

La notion de distribution est centrale pour un ESB . En effet, par=20
essence les applications a integrer sont reparties sur differentes=20
machines. Par la mise en ?uvre de ce principe de distribution, le =AB bus=
=20
=BB de l? ESB devient virtuel, les donnees de configuration et=20
d?administration etant alors distribuees sur les extremites de l? ESB ,=20
c?est-a-dire au plus pres des applications a integrer. Ceci permet de=20
contourner les problemes lies a l?architecture =AB hub and spoke =BB=20
proposee classiquement par les solutions EAI , et amene a des=20
architectures sans SPOF (Single Point Of Failure : point unique par=20
lequel passent tous les traitements et qui paralysent un systeme en cas=20
de panne).

Une offre ESB doit offrir des services techniques comme la=20
transformation des messages, le routage base sur le contenu et=20
eventuellement l?orchestration des services.

Le standard JBI
JBI est un standard permettant d?assembler des composants pour=20
construire des solutions d?integrations. La norme JBI se base sur=20
quelques elements fondamentaux : les =AB Binding Components =BB, qui sont=
=20
des composants d?integration de type connecteur ; les =AB Service Engines=
=20
=BB qui sont des composants d?integration de type transformation de=20
message, workflow, ou autre traitement ; le =AB Normalized Message Router=
=20
=BB qui assure le couplage faible entre les composants ; le =AB Normalize=
d=20
Message =BB, qui reprend l?approche orientee document adoptee par la=20
communaute Web Services.

L?interet de JBI par rapport a d?autres specifications reside=20
principalement dans le fait qu?elle reprend les =AB bonnes pratiques =BB =
du=20
monde XML et Web Services pour les appliquer a l?assemblage de=20
composants Java :

- Definition des interfaces en WSDL .
- Utilisation de la notion de Normalized Message Router qui introduit=20
  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=20
standards Web Services comme WSDL au centre des solutions d?integration=20
en Java . Ainsi, une implementation JBI doit obligatoirement fournir un=20
Binding Component respectant le WS-I Basic Profile pour etre certifiee.

Cependant, il faut noter que les utilisateurs finaux utiliseront peu la=20
specification JBI , si ce n?est pour adapter ou etendre une solution=20
d?integration a leur besoin specifique. En effet, la bonne pratique=20
pour se connecter a un environnement de type ESB est d?utiliser les=20
standards Web Services, qui fournissent la meilleure independance entre=20
le client, l?infrastructure ESB , et le serveur.

C?est donc pour les editeurs ou les integrateurs de solutions de type=20
ESB que la norme JBI est pertinente. Elle prend tout son sens dans le=20
cadre d?un consortium comme ObjectWeb en servant de catalyseur entre=20
les differents projets du consortium pour etre capable de les assembler=20
rapidement en creant de nouvelles solutions d?integration. Ceci est=20
vrai aussi bien pour les projets fournissant principalement des=20
connexions au niveau protocole, que pour des projets fournissant des=20
traitements de plus haut niveau comme des outils de transformation ou=20
d?enrichissement, ou encore des outils de Workflow.

Le projet PETALS
Le projet PETALS s?inscrit dans l?initiative ESB lancee par ObjectWeb=20
en juin 2004 afin de federer les efforts autour des projet open source=20
dans le domaine du middleware d?integration.

Les principaux objectifs du projet sont de proposer une implementation=20
d?une plate-forme JBI prenant en compte les problematiques=20
d?environnements d?integration hautement distribues, et fournissant les=20
bases pour la construction de passerelles B2B en proposant des Binding=20
Components du type ebXML , et autres.

Le projet PETALS travaille en etroite collaboration avec le projet=20
Celtix pour realiser une integration bidirectionnelle entre les deux=20
projets : PETALS utilisera des composants Celtix pour fournir un grand=20
nombre de Binding Components y compris certains protocoles de la pile=20
SOAP , et Celtix utilisera PETALS comme niveau d?implementation de JBI=20