Académique Documents
Professionnel Documents
Culture Documents
MÉMOIRE
PRÉSENTÉ
COMME EXIGENCE PARTIELLE
DE LA MAÎTRISE EN INFORMATIQUE
PAR
HACÈNE MECHEDOU
AOÛT2007
UNIVERSITÉ DU QUÉBEC À MONTRÉAL
Service des bibliothèques
Avertissement
La diffusion de ce mémoire se fait dans leqrespect des droits de son auteur, qui a signé
le formulaire Autorisation de reproduire et de diffuser un travail de recherche de cycles
supérieurs (SDU-522- Rév.01-2006). Cette autorisation stipule que «conformément" à
l'article 11 dU Règlement no 8 des études de cycles supérieurs, [l'auteur] concède à
l'Université du Québec à Montréal une licence non exclusive d'utilisation et de .
publication qe la totalité ou d'une partie importante de [son] travail de recherche pour
des fins pédagogiques et non commerciales. Plus précisément, [l'auteur] autorise
l'Université du Québec à Montréal à reproduire, diffuser, prêter, distribuer ou vendre des .·
copies de. [son] travail de recherche à des fins non commerciales sur quelque support
que ce soit, y compris l'Internet. Cette licence et cette autorisation n'entraînent pas une
renonciation de [la] part [de l'auteur] à [ses] droits moraux ni à [ses] droits de propriété
intellectuelle. Sauf entente contraire, [l'auteur] conserve la liberté de diffuser et de
commercialiser ou non ce travail dont [il] possède un exemplaire.»
TABLE DES MA TJÈRES
RÉSUMÉ : ...... .. ....... ...... ............. ..... ....... ...... ............ .... ... ... ...... ... ..... .... .. ......... ..... ... ............... IX
CHAPITRE I .......... ... .. ................. ...... .................................................. ................ .... ... ............... 1
1.1 I NTRODUCT ION .... ... .. ........ .............. ........... ... .. . ....... ...... ...... ... .... .. .. .... ....... . . .. ................ .. 1
1.2 LA COMPOS ITION DE SERV ICES .. ... ...... ..... ........ . .... .. ............................... ........ ... .... . .... ..... 4
1.3 I NTÉRÊTSETMOTIVATIONS . ..... .... ....................... ..... ....... ............... .... ... . .. . .. ... ................ 5
1.3. 1 Réduction du temps du développement ... ..... ... ... ... ......................... .. ... ....... ...... ..... 5
1.3.2 Fourniture de services à va leur ajoutée .. .. ... ...... .... .............................. ...... .... .... .. 6
1.3.3 Disponibilité d 'un nombre de plus en plus grand de services ........ .. .. ................. 6
1.3.4 E.risten ce de standards XML pour la composition ............ .... .. ..................... ...... .. . 6
1.4 PROBLÉMAT IQUE .... .. .. . .......... ............... ............. .. . .......... ... .. .. .. ....... .. ....................... .. ..... 7
1.5 OBJECTIFS ................... .... ...... .. ........... .. . .. .. . ... ...... .... ... .... ............. . ······ ........... . ...... .. ...... .. 8
1.6 MÉTHODOLOGIE .. ... . .. ........... . ... . .. .. ....... ......... ........................... .. .. ..... .. .. .... . .. .. ..... .. ......... 8
1.7 PR ÉSENTATION DU MÉMOIRE .. ... ...... ................................ . ............. .......... .. ... .. .............. li
CHAPITRE II ........................................................................................................................... 12
2.3 INTRODUCTION ..... .. . ... .. ... .. ... . ...... ........... ....... .. ... ... .......... . .................. .... .... .. ....... .. ... .. .. 12
2.4 MODÈLE D' IMPLÉMENTAT ION DE SERV ICES WEB ............. .. .. ... ... .. ..... .. . .. .... .. ....... . ........ 13
2.5 DÉFIN ITIONS···· ···· ·· ·· ·· ··········· ·· ···· ····· ·· ···· ····· ··· ·· ·· · ·· ·· · ···· ·· ······ ··· ····· ·· ····· · ···· ····· ············· ·· 14
2.5.1 Processus ....... ..... ........................ .. .... .... .... .... ..... ........... ................. ..... ........... ..... 15
2.5.2 Orchestration ....... ........ ..... .................. ................... ... ... .. .... ..... .... .. .. .... ....... .. ...... . 15
2.5.3 Chorégraphie .. ... ... ....... ............ .... ....... .. ...... ............ .... ... .. .. ... .... ..... .. ... ...... ... .. ... .. 15
2.5.4 La composition de services .... .. .... ...... ...... ... ... ... ............. ..... ......... ......... .............. 15
2.6 UN EXEMPLE D' ILLUSTRAT ION DE LA COMPOS IT ION ............................ ...... . ...... ... ...... .. 16
2.7 APPROC HE INDUSTRIELLE .............. ......... ................ . .. .. .... .. .. ..... .... ..... .... ... ... ...... .. ....... . 17
2.7. 1 Description de services par WSDL ...... ..... ............. ... ......... .. .... ................ ... ... .. .. 17
2.7.2 Le flux de composition par BPEL4WS ....... ... ... ..... ...... ................... ..... ........... ... .. 18
2.8 APPROC HE WEB SÉMANT IQUE .......... ..... ......... .... .. ..... .. .. .. . .. .. ... . .... .... .. ......... ....... ..... ..... 19
2.8.1 Description de services .............. ..... ...... ... ......... ........ ......................... ......... ....... . 19
2.8.2 Description de la composition ... ......... ....................... ... .. ... .. .... .... .... .... .. .. .. ... .... .. 20
2.9 COMPAR AISON DES DEUX APPROC HES .. ...... . .................... ... ......... ............ ... . ...... ..... .... .. 20
2. 10 CONCLUSION ..... ................. . .... . .. .............. .... ..... .. ...... .... .. ... ..... .......... ... ....... ............ 2 1
3. 1 I NTRODUCT ION ... ......... . .... ......... .. ... .. .... . ........................... . .... ..... ... .. ........ .. .... ... .. .... .... .. 23
3.2 PR INC IPES DES SYSTÈMES À BASE DE CONNA ISSANCES . ... .. .. .. .... .... ... ... . .... . .. ................ . 24
3.2.1 Caractéristiques des systèmes à base de connaissances ... ....... ........ .... ..... ... .. ... .. 25
3.2.2 Anatomie d 'un système à base de connaissances ... ... ....... ... ..... ..... ....... ...... ........ 25
3.2.3 Élaboration d 'un système à base de connaissances .... .. .. .. ....... ..... .. .. ..... ... .... ..... 26
3.3 PRÉSEN TAT ION DE JESS ...... ..... ......... .... ... ... ..... .. ....... ... .. ...... ........... .... ..... .... ....... ........ 28
3.3.1 L 'algo riThme RETE..................... ... ........... ..... .. ........ ........................... ... ...... .. ..... 29
3.3.2 La mémoire de tra vail (ou la base de faits) ............. ............... ...... .... .... ... .... .. ..... 3 1
3.3.3 Les règles en JESS ....... ....... ... ..... ...................... ....... .. ... .................. ......... ... .. ...... 32
3.4 CONCLUS ION ..... . ... ....... .... . .. . .. .. ... ......... ......... .. .. ...... . .... ... .. ... .. ....... . .. .. ... . ... ...... ..... .. ...... 33
CHAPITRE IV ......................................................................................................................... 35
4.1 I NTROD UCT ION ... .... ... ..... .. ... . ... .. . .... .. ....... ..... .. ... ... .. ................ . . ............. . . ... ... . . ............ ... .. 35
IV
4.2 CONSTATS SUR LES APPROC HES ACTUELLES DE LA COMPOS ITI ON ..... .... ..... .. .... ....... .. ....... . 36
4.3 PRÉSENTATION DE L'A PPROCHE MIXTE ........................ .. ......... ... .... .. ... .... .. ... .... .. ...... .. ....... 38
4.4 P OS ITIONNEMENT DE L'APPROCHE MIXTE DANS LES STANDARDS ...... ................ ........ .... .. .4 1
4.2 L A DESCR IPTION DE L'ENVIRONNEMENT DE COMPOSITI ON .................... ..... ...... ..... .. ..... ... 43
4.4 LE CHOIS DE JESS COMME ENG IN D' EXÉCUTION DE RÈGLES ........... ............ ...... ............ ... 47
4.3 LE MODÈLE DE COMPOS ITI ON .... ......... ........ .. ............ ... .... .......... ... ......... .. .. ... .... ... ........ ... ... 49
4.3. 1 Un exemple d'illustration .... ....... ....... ..... .... ... .. .... .. ... .............. ....................... ..... ...... 5 1
4.3.2 Description de services parles règ les .. ..... .... ....... ..... ........... ....... .. ...... ..... ....... ........ . 54
4.3.3 La génération d'u n plan de composition ....... .. .. ... .... ...... ..... ..... ........... ........... .... ...... 58
4.4 L E MODÈLE CONCEPTUEL.. .... ... ........ ... ........... ....... ... ... .... ..... ... ....... ..... ............. ........ ...... ... 6 1
4.4.4 Les modèles UML ................. ... ... .... ..... .......... ....... ....... ......... ........... .... ....... ....... .... ... 62
4.4.5 Le modèle de systèmes de transition d' états .. .. ...... ... .. ..... .... ........ .. ...... ..... ... .. ........... 64
4.5 L A CONSTRUCTION DES SERV ICES COMPOS ITES ................ ........................ ... .... ... ..... ...... ... 72
4.6 L ' INCERTITU DE DE LA COMPOSIT ION .. ................ ... ......... .......... .. ......... ..... ..... ..... .. ...... ...... 76
4. 7 CONCLUSION ... .. .. ..... ... ... ...... ........... ................ ...... ................... ... ........ ..... .......... .............. 77
5. 1 I NTRODUCTION .......... ..... ....... ..... ..... ... ............................... ...... .. ................. .. .... ....... ... ... ... 79
5.2 DESCRIPTION DE L'ENVIRONNEMENT D' IMPLÉMENTATION ...... ........ .. ..... .... ... ....... .. ..... 79
5.2.1 Aperçud'axis ............. ... ....... ... ... ... .... ...... .... ............. ....... .. ....................... .......... . 81
5.2.2 Fonctionn ement d'Axis ... ................................................ .............. ... ................ .. . 8 1
5.3 DÉFINITION DES SERV ICES WEB DE REMISE EN CHARGE ........................ ..... ..... ....... .. ... . 82
5.4 LE DESCRIPTEUR WSDL DU SERV ICE DE CONNECT IVITÉ .... ....... .... .................. ... .......... 85
5.5 LE DESCRIPTEUR WSDL DU SERV ICE DE DISPONIB ILITÉ .. ....... ..... .. .. ........ ... ... .... ......... . 86
5.6 LES RÈGLES DES SERV ICES DE REM ISE EN CHARGE ...... ....... ..... ... ... .... .. ... ....... ... .. ......... . 86
5.7 EXÉCUT ION DU PROTOTYPE ................ ..................... .... ... ... ....... ..... ... ... ... .. .. .... .............. 90
5.8 CONCLUSION ..... ... .... .... ........ ..... .................... ...... .... .......... ......... ........ . ... .. .......... .......... 92
CHAPITRE VI ......................................................................................................................... 93
CONCLUSION ......................................................................................................................... 93
APPENDICE A ......................................................................................................................... 95
v
Figure 1.1 Architec ture client 1 serveur. .. .. .... ... .. .... .... .. ..... .. .. .. ... ......... .... ....... ... .. ... ... . 2
Figure 2 .2 Structure d' un processus ..... .. .. .... .. ........ ... ..... ... ..... .......... ...... .. ....... .... .. ... 15
Figure 2.3 Agrégati on de services .. .. ........... .. ...... ...... ... ....... ...... ......... ... .. .. ... .... .... .. .. 17
Fi gure 2.4 Structure d' un document WSDL. ..... ..... .... ..... ... ...... ........ ... .. .... .. .. ..... ... ... 18
Figure 2 .5 BPEL et les autres standards .... ..... ........... .. ... ..... ..... ...... .... .. .... .... .. .. ... .. ... 19
Figure 3.1 structure d'un système ex pert ... .... .. .... ..... ...... ... ... .. .. ............ ......... ..... ..... 26
Figure 3.2 les étapes de déve loppement d' un SBC ..... .... ... ... ........ ..... .. .. ... ... .. .... .. .... 27
Figure 3.3 Un exe mpl e de réseau RETE .. .. .. ...... .... .... .... ..... .... ....... ....... ..... .... .. .. ..... . 30
Figure 4 . 1 L' aspec t multidimensionnel de la co mposition .. .... ..... ..... ...... ..... ...... .. ... . 38
Figure 4 .2 Approc he mi xte ...... ....... .... .. .. .. .......... ..... ........ ... .... ...... ..... ... ... .... ... ...... ... . 40
Figure 4 .3 Modèle de l' aspect dynamique des services web .. .. ... ... ... .. ... ... ... ... ....... .. 4 1
Figure 4 .4 Approche de co mpos it ion ... .... .... .... .. ... .. ....... ... .. .. ... ... .... .... .. .... .. .... ... .... .. 42
Figure 4 .5 Le cycle de compositi on de services ...... .... .. ...... .... ......... .. ...... ....... ...... ... 43
Figure 4.6 Les diffé rents cas d' utili sati on du système ..... .... .. ....... ....... ... .. ... ...... .... .. 45
Figure 4.7 Le système de composition ............ .... ..... ...... .... .......... ....... ... ........ .......... 47
VIl
Figure 4 .8 Assoc iat ion d'un e règle à une opération de WSDL. ....... .. ..... .. ..... ..... .. ... 50
Figure 4.9 Le desc ripteur WSDL du service des tau x boursiers .......... ..... .... ......... .. 54
Figure 4.12 Transformation de l'arbre d'exécution en code BPEL .............. .... ........ 62
Figure 4 . 15 Invocation d ' un serv ice composé de l'extéri eur .... ...... .. ............ .... ........ 65
Figure 4.16 Représentation d'un processus BPEL par des activités ......................... 66
Figure 4.17 Modélisation d ' une activité .......... .. .. .... ........ ........... ....... ........................ 67
Figure 4.18 Représentati on d'une activité avec plusieurs états inte rméd ia ires ......... 68
Figure 4.21 Cas d ' in certitudes ........... .. .. ....... .. .................... .. .......... .. ................ .. ...... 77
Figure 5.1 Le compos iteur de serv ices web .................... ................ ...................... ... 80
Figure 5.2 E nviro nneme nt tec hnol ogique du composi teur ....................................... 80
Figure 5.3 Le modè le de traite ment des messages SOAP par axis ........................... 82
Fi gure 5.6 les différent s objets d' équipe ments constitu ant les entités des règles des
services web de remi se en charge .... ...... ...... ........ ..... .... ....... ... .... ..... ... ......... .. ... ... .... ... ........ .... 90
Fi gure 5.8 Le graphe de compos iti on des services de rec herche d' itinéraire ..... ... ... 92
RÉSUMÉ:
La compos iti on des services w e b, e n tant que moye n de fournir des applicatio ns à
valeur ajoutée a engendré un grand intérêt auss i bi e n d ans le mili eu indu strie l que dans la
communauté des c herc heurs. Dans le pre mi er cas, l' accent a été mi s sur la dé finiti o n des
standards basés sur le langage XML. E ll e est de nature e xclu sive me nt syntax ique . D ans le
deu xième cas, o n aborde la compositi o n sous une approc he basée sur le web sémantique et la
description de services est basée sur des info rmati ons sémantiques . Les deu x approc hes ayant
été développées séparé ment bien que 1'o bj ectif que 1' on veut atteindre est le mê me à sa vo ir la
fourniture d 'outil s de compositi on auto matique de services.
Dans ce mé moire, nou s proposo ns un e approc he« mi xte» qui essaye de rasse mble r les
avantages des deux mé th odes précéde ntes. L'ori g ina lité de la solution consiste à utili ser les
standards indu stri els de la c o mpos iti o n to ut en utili sant un systè me à base de conna issances
modé li sant les contraintes de la co mpos iti on de ser vices. Les mécani smes utili sés sont les
règles exprimées par la logique d' ordre 1 a vec les co ncept s ori entés obj et. Nous avo ns réali sé
un prototype qui a montré la concréti sati o n des idées a vancées afin de mettre en pl ace un
systè me de composition pou vant être utili sé pour des appli cati ons réell es. Le prototype est
illu stré par un exe mple prove nant de 1' industri e de la di stributi o n et du tran sport électrique.
INTRODUCTION GÉNÉRALE
1.1 Introduction
L ' un des souci s maj eurs des entreprises, est le partage et l' éc hange de données ainsi
que des informations entre les différe nts acteurs, qui interv iennent dans la réali sati on des
différe ntes activités. La collaboration de parte na ires (d'autres compagnies ou organisations)
est devenue une nécessité pour sati sfa ire et fidéliser la c li entèle. L 'environn e me nt de
communication et de collaboration pre nd une importance particulière e n ce sens qu ' il soul ève
les serveurs sont des processus différe nts. La répartiti on des processus est basée sur un
modèle logique car les processus ne sont pas associés nécessairement à des processeurs
différents [29]. Figure 1.1
c1 c2 c3,c4
Légende:
OS : Ordinateur Serveur
OC : Ordinateur Client
c : processus client
s : processus serveur
Architecture N-tiers: Cette arc hitecture élargit l' idée de « C li ent/Se rveur » pour
répartir les différents modules d ' une applicati on sur plusieurs couches, lesquell es
communiquent par le modèle RPC (R emote Procedure Cali). Les tec hn ologies supportant ce
modèle d 'architecture sont COM/DCOM pour les plates formes Windows et EJB/RMI pour
des applicati ons bâties en Java. E lles présentent toutes les deux l' inconvéni ent d'être des
so lutions propriétaires, i.e., le développement doit se faire uniqueme nt par l' une où l'autre
(COM/DCOM ou EJB/RMI). L' avantage (entre autres) est d'assurer le traitement des
transactions qu i permet de gérer la queue des requêtes et de leurs priorités. Ce modèle
s'applique pour des applications distribuées sur un réseau local (LAN) . CORBA avai t pour
objectif d' appliquer le principe de répart iti on à un réseau large(WAN) et de faire
communiquer des modules développés dans différentes plate formes et différents langages.
3
Par ai lleurs, CORBA opère sur des ports qui ne sont pas ouve11s par les firew all s dus
aux contraintes de sécurité; ce qui cause des problèmes de déploiement.
c
Q)
rchitecture SOA
E -Web Services
Q)
Q_
SOAP
Q_ W S DL
_Q rchitecture N- s UDD1
Q)
> -COR BA
'<1> -COM/DCOM
-o Client/Serve
Q) -EJB,RM I
-o -Socket
:J
C1l
Q)
-~
z
Temps
Une implémentation de cette architecture est basée sur la technologie des se rvi ces web.
L 'apparition du XML (Extensible Markup Language), qui possède la propriété de déc rire son
contenu et qui est structuré sous-forme d ' une arborescence a apporté un changement majeur
dan s les modèles de communication des applicati o ns. L'interprétation d' un document XM L
est donc faci litée par l'utili sation des schémas et des DTDs (Document Type Definiti on).
Cette architecture est basée sur l'uti lisation de services comme entité de construction d'un
systè me. L'ensemble des services communiquent par des messages SOAP (Simp le Object
Access Protocol). Les services sont décrits par WSDL (Web Services Descri ption Language).
XML constitue la base des protocoles utilisés par les services web (SOAP, WSDL,
UDDI). Nous reviendrons sur les détail s des services web au chapitre 2. SOA est donc basée
sur les services web. La communication se fait à travers Je web (HTTP) et du coup les
4
contraintes posées par les f irewalls so nt levées (contrairement à CORBA). Cette architecture
ou vre des perspec tives très prometteuses au développement du logiciel. C'est précisément
dans ce contexte que s'in scrit notre trava il à savoir la compos iti on de servi ces web.
L' idée et la moti vation derri ère la co mpos iti on de serv1 ces web est de fournir un
environn ement de déve loppement d 'application s de qua lité avec de moindres efforts. Les
applicati ons doivent s'ali gner aux processus d 'affaires qui , à leur tour, doivent être fl ex ibl es
pour s'adapter aux change me nts. Les processus d ' affaires subi ssent des change ments
continu s afin de répondre aux ex igences des entrepri ses qui veul ent sati sfaire les besoins des
clients en leur offrant un service personn ali sé et de qualité. Ce qui permet de les fidéli ser.
La nécessité d' automati ser les processus d'affaires et de les adapter continuellement et
rapidement aux nouvelles exi gences des clients, permettra aux entreprises d 'atteindre leurs
obj ectifs. Cette automati sati on est rendue possible grâce aux nouveaux paradi gmes et
standards essenti ellement basés sur XML.
L' intégration des applicati ons nécess itent de plus en plus d' interopérabilité et
d ' échange de données, et ce indépendamment des pl ateformes utili sées et des langages avec
lesquels ell es sont programmées.
Le concept de réutili sati on en géni e logiciel, qui est amplement justifié dans le
domaine d ' intégrati on des application s et des applicati ons B2B (business-to-business), est
précisément supporté par les serv ices web. E n ce sens, ces derni ers permettent d'enve lopper
des applications ex istantes et de les faire coopérer afin de répondre au x nouveaux beso ins des
entreprises moyenn ant le minimum de déve loppement de logiciel possibl e. Mieux enco re,
l'i nteropérabilité des services web se fa it à travers le web et ouvre de nouvelles perspecti ves
dans le domaine de développement de logicie ls.
Après avoi r exploité l'architecture basée sur les composantes (COM/DCOM, EJB) qui
se limi te à u ne même plate-forme et dont le développement d'applications se fait de mani ère
statique (manuellement par les développeurs), les services web rendent possible le
5
déve loppement « dynamique» (auto matiqueme nt par la mac hine) grâce aux di fférents
stand ards basés sur XML (UDDI, W SDL, SOAP).
Par aille urs, ce développeme nt « dynamique» relève encore de nouveau x défis car il
nécess ite de définir de nouveau x standards permettant de composer(ou d'asse mbler) les
services web de mani ère automatique. Ces standard s à leur tour nécess iten t des outil s pour les
gé nérer et les interpréter afin de pou vo ir construire des applicati ons à va leur aj outée
Le déve loppement du logicie l a touj ours été un souci maj e ur des entrepri se en ce sens
qu ' il occasionne des coûts élevés et nécess itant des ressources humaines qualifiées non
seule ment en tec hniques de programmati on ma is aussi dans le domaine de compétence
auquel elles veulent apporter des soluti ons informatiques en automati sa nt certaines tâc hes.
L 'ex perti se est donc un point clés pour la réuss ite de projets d 'envergu re. Cette ex perti se
n'éta nt pas di sponibl e et souvent chère à acquérir nécess ite le recours à des services de tierces
parti es (partenaires). D 'autre part, dans ce ge nre de projets, plusieurs domaines de
co mpétences interagissent pour ré pondre aux beso ins des clients. C'est préc isé ment à ce
ni veau que l'uti lisati on des services web peut j ouer un rôle prépondérant à partir du moment
où ces derni ers permettent de mettre à la di po itio n d' une entrepri se des services spéciali sés
dont elle a besoin . Ainsi la constructi on d'appli cati ons basée sur ces services spécialisés
permet d'atteind re les objectifs de l' e ntreprise ra pidement et de répondre aux beso ins de ses
c lie nts avec le mo indre coût.
6
Beaucoup de servi ces sont di sponible sur Intern et et prêts à être utilisés par des
entreprises à travers le w eb. Ces services parfois existent au sein d'une m ême entreprise
dans différents départements et donc peuvent être utilisés sans limitations en termes de
optimise l'utilisation de ses ressources pour se concentrer sur son domaine de compéten ce
Le nombre de services web ne cesse d'augmenter et leur nature (l eur valeur ajoutée) est très
vari ée; ce qui les rend de plus en plus util es et nécessaires pour le dé veloppement de
nouvelles appli cati ons. Le support des processus d'affaires par des services est rendu possible
pui squ ' il ne dépend plus directement des différents services utili sés. Si un servi ce donné n'est
plus di sponible, il est fac ileme nt remplacé par un autre avec la mê me qualité sinon me illeure
que celle du pre mi er. La créati on d' applicati ons à partir des services offre de nouvelles
perspectives en termes d' innovati on dans le domaine de développement du logiciel car il est
maintenant poss ible de faire abstrac ti on des détail s spéc ifiques. Il ex iste touj ours un service
web que J' on peut utili ser. Ce qui permet de se concentrer sur J' objecti f global de
1' application .
Les stand ard s XML li és aux services web en gé néral et à la co mpos iti on de services en
particulier offrent des outil s de planificati on, de définiti on et d' implémentati on pour la
composition de se rvices. Nous all ons voir, par la suite, que même l'ex istence des stand ards
re lève encore de nouveaux défis pour trouver des soluti ons au problè me de la compos iti on.
Peu d'outil s sont offerts pour supporter ces stand ards.
7
1.4 Problématique
Les processus d'affa ires des entrepri ses évolue nt constamment e n subi ssant des
changements li és à la conj o nc ture économique d' une part et aux ex igences des clie nt s d 'autre
pa11. Les clients veul ent rece voir des services de plus en plus personn ali sés et ce le plus
rapide ment poss ibl e.
Par conséque nt les e ntre prises doive nt di sposer d' une grande fl ex ibilité au ni veau de
leurs processus d 'affaires. Ces de rniers doive nt donc ê tre adaptés pour répondre aux obj ecti fs
que l' on veut atte indre. Le maximum d 'ac tivités nécess ite l'automati sati on des tâc hes qui les
composent. L' interacti on mutue ll e des acti vités est éga lement un fac teur détermin ant dans
l' atteinte des obj ectifs. H abitue ll e me nt, les ac ti vités correspondent à des applications
logicielles qui co mmunique nt et interagissent entre elles et en éch angeant des données et des
messages. II s'agit al ors d ' interopérabilité et d ' intégrati ons des application s. Vu sous cet
angle le problème d 'automati sati on du processus d 'affaires peut être ra me né à celui de la
compos ition des services web.
La compos ition de services web fait l'obj et de plusieurs travaux auss i bi en dan s la
communauté de recherche qu' au ni veau industri el [1]. Il ex iste deux approches qui ont
res pectivement é volué de faço n indépendante. E n industri e, beaucoup de standards XML et
de spéc ificati ons ont été défini s. L 'accent est mi s sur la spéc ifi cati on du flu x d'exéc ution des
processus et de compos iti on de servi ces. E n re vanche, la commun auté sc ientifique se
préoccupe plus de la sémantique li ée à la compositi on de services et utili se les systè mes
d ' inférences basés sur les connaissances de nature déc larative permettant de composer des
services. Dans les de ux cas il y a un manque d 'outil s pour la compos iti on.
1.5 Objectifs
L'obj ectif est de construire un outil de composition de services servant à gé nérer des
app li cations. L 'outil doit être suffisamment simpl e pour être utilisé par des déve loppeurs ne
connaissant pas nécessaire ment les détail s de services mi s en contribution dan s le processus
de composition .
Cet outil doit être construit sur la base des stand ards industriel s ex istants de telle sorte
que les plans de composition générés peuve nt être portables sur les e ngin s d' interprétati on
des pl ans de composition .
L'outil de composition utili se ra une base de conn a1ssa nce dont la mainte nance est
assurée par un spécialiste de la compos ition . La base de connaissances évo luera dans le te mps
en enrichissant son contenu et sa qualité dépe ndra des serv ices web modéli sés. Les services
dont la qualité n'est pas sat isfai sante seront re mplacés e n foncti on des besoins.
1.6 Méthodologie
composition de services.
3. Utilisation d'un système à base de connaissances basé sur JESS comme outil
de composition.
Pour atteindre les objectifs cités dans la section précédente, nou s avo ns étudi é les deux
approc hes qui ex istent dan s la littérature :
• D ' une part, l'approc he industrielle se base unique ment sur des
standards XML mais ne présente aucun moyen pour la composition
automatique de service. Le principe est que la composition doit se
faire manuellement, i.e., par une personne qui doit spécifier toutes les
9
comparaison
D ans le cadre de ce mé moire, nou s avons utilisé un e approc he mi xte. E ll e cons iste à
utiliser les stand ards XML de l' industri e pour la descripti on et la compositi on des services. Il
s'agit do nc de WSDL et du BPEL4WS respecti vement. L a générati on du pl an est fa ite par un
systè me à base de conn aissances comme dans les systè mes utili sés da ns l'approc he web
sé mantique .
Nou s pe nsons, que l' utili sati on d' un système à base de co nn aissances est poss ibl e car
nous pouvons limiter à un do maine do nné l'ensemble des services web à utili ser pour la
compos iti o n. L a di fficulté à déc rire les serv ices web e n termes d 'obj ectifs (vo ir tabl eau 1. 1)
est levée par cette hypothèse. D'autre part, la gestion de la base de conn aissances par un
expert de la compos iti on est faite de maniè re transparente aux utili sateurs de l' outil.
Le choix des standard s XML (W SDL, BPEL4WS ) est fait pour les ra isons sui vantes :
• Nous pensons que de plus e n plus de serv ices web à valeur aj outée seront
di sponibl es sur le web. E t comme ces serv ices utili seront les standard s
industriels, qui sont préconi sés par les grands ope rateurs, il est plus pertinent
de s'y conformer que d ' utili ser des fo rmats de descripti on et de co mpos iti on
spéc ifi ques.
• Pour avoir une me illeure qua lité de service, il est plus intéressant de di sposer
d' une certa ine fl ex ibilité au ni veau des services modé li sés dans la base de
conn aissances. Cette nex ibilité concerne le remplace ment d ' un service par un
autre qui est plus fiable et p lu s stable.
Dans le chapitre 2, nous présenterons la littérature liée à la co mpos iti on des services,
nou s analysons quelques systèmes et leurs caractéri stiques.
Dans le chapitre 3 nous aborderons les systèmes à base de conn a1ssa nces et les
concepts de re prése ntati on des conn aissances . Nous parl erons pa1ticuli èreme nt des systèmes
à base de règ les et de leurs diffé rentes composantes.
Dans le chapitre 4 nous présente rons notre outil de composi ti on de services web. Nous
décrirons les standards retenus pour la desc ripti o n des services. Nous all ons également
donner des exemples de modé lisati o n de la co mpos ition de services afin d ' illustrer les
fo ndements de notre approc hes (approc he mi xte).
Dans le chapitre 5, nous décriro ns une étude de cas où la co mpos ition de services est
pertinente. Il s'agit d' une application de rétabli sse me nt d' un réseau de di stributi on d 'énergie
élect1ique.
En conc lusion nous parl eron s des résultats atte ints dans le cadre de ce trava il et des
exte nsions qui peuvent être apportées à l'environne ment de compos iti on.
CHAPITRE II
2.3 Introduction
La compos iti on de services est un suj et de plusieurs travaux de rec herche auss i bien au
niveau industrie l que dans la commun auté uni versitaire. Cette problé matique est devenue
intéressante car il relève le défit de ré duire le coût et le temps de développement et de trouver
de nouve lles faço ns d' intégrer les application s à travers le web. Il faut souli gne r que la
compos iti on de services est le résultat d'une évo luti on nature ll e de l' arc hitecture des
appli cati ons et des techno logies sous-j acentes . Plusieurs aspects architecturaux da ns le cadre
d'appli cati ons di stribuées ont été amé li orés pour une utili sati on limitée à un réseau local
(LAN ). Par exempl e la di stributi o n des composantes sur des serveurs d ' un réseau local
permet d ' assurer un e interopérabilité des appli cati ons destinées pour une pl ate-forme donnée.
13
mode fo ncti onne l du mode opé rati onn el d ' un service web. Par contre, le processu s de
co mpos iti o n lui mê me ex ige la d éfiniti o n d 'autres ni veaux d 'abstraction pour modé li ser le
flu x de co mpos iti o n. Cette modé li sati on do it se faire par des outil s permettant la géné rati o n
auto matiqu e des pl ans de compos iti on pour répo ndre aux ex ige nces de modifi cati ons des
processus d 'affa ires.
D ans ce c hapitre, nous prése nterons les deu x approc hes de compos iti o n de services
ex istant dans la litté rature et nou s mo ntre rons les avantages et les in convé ni ents de chacune
d 'e ll es. Nous all o ns aussi définir un certa in s no mbre de concept s li és à la compos iti on de
D ans la secti o n proc haine, nous parle ro ns du modè le d ' impl é me ntati on de services
we b.
Un service web peut être publié d ans des registres afin qu ' il soit retrou vé par des
utili sateurs potenti els. La publi cati on de servi ces se fa it par U D D I (U ni versal Di scovery
Desc ripti on and I ntegrati on).
Dans la figure 2. 1, nous présen tons le modè le d ' implémentation des services web.
14
• Chaque se rvice We b est défini par un fourni sseur. Le fourni sseur de services déploie
et publie la description de son service dan s des registres en vue d 'être loca li sé par des
cli ents ;
• Les c li e nts locali sent leurs besoins en terme de services en effectuant des recherch es
sur les registres de services We b ;
• Sur la base des informations défini es dan s la desc ripti on du servi ce, le c li ent
entrepre nd une interaction.
Annuaire UDDI
service
nterraction
2.5 Définitions
2.5.1 Processus
Un processus est un ense mbl e d' acti vités exécutées dans un ce rtain ordre (worktl ow) .
L 'exécuti o n de ces ac ti vités implique des ressources humaines ou des systè mes, ou e ncore
des applicati ons [ 14] . Le cyc le de vie d' un processus peut être couve rt entiè re me nt par des
systèmes automati sés . V o ir la fi gure 2.2
() 0
0
Figure 2.2 Struc ture d'un processus
2.5.2 Orchestration
C' est un processus exécutabl e pouva nt interagir e n même te mps avec les services web
internes ou ex ternes et d écri vant les règles d 'affaires et l' ordre da ns leque l les services sont
exécutés [ 14]. Le processus est contrôlé par une des pa rti es (servi ces) interve nantes.
2.5.3 Chorégraphie
E ll e déc rit le rô le j oué par chaque parti e interve na nt dans le processus et garde la trace
des séque nces de messages éc hangés entre les pa rte naires, c li ents, fo urni sseurs. La
c horégraphi e possède un caractère coll aboratif e n ce sens que chaque pa11ie interve nant dans
le processus décrit le rô le gu' elle j oue dans 1' interact ion [ 14].
La compos iti on de servi ces regroupe les deux aspects «orc hestrati on » et
«c horégraphie» et s' intéresse au support des processus d 'affa ires e n leur fourni ssa nt des
standards et des outil s permettant de générer les flu x de co mpos iti on.
• La compos iti on dynamique, e n revanc he, se base sur des outil s auto mati sa nt la
générati on de flu x. Ces outil s di sposent de certa ines in fo rmati ons liées à la
descripti on sé mantique de services . Les concepts sé mantiques sont conte nu s
dan s des ontologies (web sémantique) qui sont des structures standardi sées
permettant leur interprétation [ 17] .
Nous re pre nons l' exempl e déc rit dans [ 1] et [ 18] . Il s'agit d' une age nce de voyage
utili sant les services d'achat de bill ets d'av ions et de réservati o n hôteliè re. Le pre mi er service
appartient à deux co mpagni es aéri e nn es et le deuxiè me à un e c haîne hôteliè re. U ne troisième
e ntre prise d'agence de voyages veut mettre e n pl ace un service Web d 'organi sati on de
formul es de voyages se lon une li ste de critères ou de préfé rences (vol avec réservati on
d ' hôtel). Au lieu de mettre en place un nouveau service, e ll e veut combiner et utili ser un
mécani sme de gesti on de préfé rences utili sant les se rvices des deux co mpagni es précédentes.
On parle d'agrégati on de services.
La fi gure 2.2 montre les services utili sés par l'age nce de voyage et les interve nant s
da ns le processus de réservation
17
Interaction
Service
Client Employé de l'agence
Dans cet exemple, le service d'agence de voyage utili se deux autres servi ces dans un
certain contexte relatif à la demande du c lie nt. Le co mportement des serv ices de base est
dicté par la requête éman ant du service agrégé.
Dans les prochaines section s (2.7 et 2.8) nous parl erons des deux approc hes de
composition existantes dans la section 2.9, nous ferons une comparaison entre les deux en
montrant les avantages et les inconvénients de chacune d 'ell e.
Dans cette approche, la description de servt ces repose esse nti ell ement sur l'aspect
syntaxi que [ 1] des messages en définissant les types de données éc hangés et les opérati ons
que le service web fournit pour l'accès à ces données. La locali sat ion des services est aussi
incluse dans le document WSDL d'un service web. L 'ense mbl e des opérations son t
regroupées dans des « porttypes » qui représentent l' équivalent d'une classe dans un langage
de programmation. La définition des messages consiste à spécifier ses différentes parties de
données (types) que les opérations reçoivent lors d'une requête ou envoient lors d'une
réponse. [6]. Les messages peuvent être co mparés aux paramètres d' une fo ncti on dans un
langage classique. WSDL indique dans la partie « binding » le protocole de communication
utilisé entre le client et le serveur. Dans la figure 2.4 nous indiquons les différentes parties
d'un document WSDL.
18
de données transmis?
Un processus BPEL4WS utili se WSDL pour la desc ripti on des messages et des
données. La desc ripti on des services est basée sur WSDL. Il est donc év ident que BPE L est
une abstracti on décri vant le comportement d' un service composé (co mpos ite). La fi gure 2 .4
montre la dépend ance de BPEL des autres stand ard s de services web.
19
BPEIAWS Comportement
' '
WSDL Interfaces
SOAP . Message
SCHEMAS Types
XML Données
Il est important de souli gner que BPEL prend en charge le traitement des excepti ons,
i.e., permet de faire des recou vrements d 'erreurs surve nant lors de l' exécuti on. L'exécution
en parallèle de services permet aussi de di sposer d' un moyen d'a méliorer les performances de
services composés. BPEL sépare les règles de gestion des processus des services utili sés et
par conséquent de remplacer fac ilement un service par un autre.
Nous reviendrons en détail sur les différents constructeurs de BPEL, dan s le chapitre 4,
car dans notre travail, BPEL a été choisi comme langage de composition.
En web sémantique, les pages du web sont considérées li ées par un ensemble
d' informati ons décrivant la sé mantique de ces liaisons dans un e sorte de base de données
globale [1]. En général cette description est un ensembl e d'asserti ons sur des ressources web
et de leurs propriétés. Le langage de desc ription est RDF (Resource Description Format) [30].
Une description « RDF » est un ensemble de triplets ayant chacun un suj et, un verbe et un
objet d' une phrase. Chaque é lément de la phrase est représenté par une URI (U niversa l
Resource Identifier). RDFS (Resource Description Format Schema) est utili sé pour définir les
schémas RDF qui permettent de modé liser les classes et les propriétés des ressources.
DAML-S (The DARPA Agent Markup Language Schema) est un autre stand ard utilisé pour
-l
1
20
co mpléter la description de services. Il utili se les ontologies pour exprimer plusieurs types de
relat ion ou de propriétés. DAML-S définit une classe pour la description de servi ce appelée
« Service» ayant les propriétés « prese nts, desc ribedBy et supports». Chaque propriété
utilise les classes « ServiceProfile, Servi ceModel et ServiceGroundin g ».
Avec les standards du wè b sémantique, il est possible d'avoir une descripti on assez
complète des services web et des processus utilisant ces services.
On remarque donc que dans ce type de systèmes, on utili se les tec hniques empruntées
aux systèmes à base de con naissances (Ce qui fait l'objet de chapitre 3 de ce trava il ). A
chaque étape du processus de générati on de plans de composition, il faut un choi x parmi
plusieurs possibilités (choix non-détermini ste). Les étapes subséquentes dépendent des choix
effectués lors des étapes précédentes et ainsi on arrive à construire un plan de composition de
manière progressive.
Nous allons ex plorer en profondeur cette tec hnique au chapitre 4 et nous donnerons
des illustrati ons par des exemples mais en utilisant un autre langage (Le langage de JES S)
La technologie des services web a offert un cadre de travail pour le développement très
intéressant en termes de standards (SOAP, WSDL, UDDI). Ces standards ont eu des
ex tensions incontestablement très riches pour justement supporter la composition de services
complexes. Dans les sections précédentes, nous avons mentionné quelques uns : BPEL4WS,
RDF/RDFS, DAML-S . Il en ex iste d' autres comme OWL_S, BPML WSCI.
21
Nous penso ns que la définition de standards est une étape nécessaire mai s non
suffi sante pour l' utili sation pratique de la co mposition de services dans le développement
d' applicati ons ou du logiciel en général.
Dans les deux approches développées au cours des dernières années, 1'accent a été mi s
sur ces stand ard s. Dans l'industrie, le problème de l'automatisati on de la co mposition n'est
pas ou peu abordé. L'approc he web sé mantique est beaucoup plus évoluée en ce se ns qu 'elle
a pri s en compte la sé mantique relative à la constructi on de services web complexes . Elle a
plus ou moins élaboré des stand ards plus robustes en mati ère de desc ripti on de services.
Certains outil s de la co mpositi on ont vu le jour. Ces outil s permettent de fa ire une pseudo-
automati sati on de la co mposition .
Nous co nstatons donc que malgré les tentati ves d'élaborati on de standards pour
supporter le développement de services à va leur ajoutée, il reste beaucoup de travail à faire
au niveau de la co mposition pour prendre en charge l' aspect « comportement » de servi ce.
Dans les deux approc hes, les informati ons sur le processus peuvent s'attacher à des
protocoles différents. Dans l'approche industri elle, le choix des ac ti ons à exécuter se fa it de
façon prédétermin ée avec les constructeurs « pick et switch ». Les acti vités sont exécutées
suite à des évènements qui surgisse nt. La nature des informati ons de desc ripti on et de
compos ition sont stri ctement syntax iques
En revanche dans l'approc he web sémantique, les choix des acti ons ne sont pas
prédéterminés. Les transitions entre les états sont basées sur des pré-conditions. La nécessité
de représenter des objecti fs à atteindre lors de la composition de mani ère ex plicite permet
d'avoir un e fl ex ibilité acc rue. La nature des in fo rmati ons est sémantique.
2.10 Conclusion
Dans ce chapitre nous avons analysé les tec hniques utilisées pour la composition de
services dans les deux approches et les caractéristi ques de chacune d'elles. Nous avons vu
qu'au niveau industriel, l' accent est mis sur la définition de standards et non sur
J'automat isation de la composition. Cependant dans J'approche web sémantique, on
s'i ntéresse à l'automatisation de la composition (complète ou partielle) et que les
22
Par aill e urs, les travaux déjà effectués co mmencent à donner des résultats pour une
se mi-auto mati sation de la composit ion.
Dans le c hapitre 4 , nous prése nterons notre approc he appe lée « approc he mi xte » e t
nou s définiron s les modè les de la co mpos iti o n que nous avons adoptés.
CHAPITRE III
3.1 Introduction
• Ces connaissances doivent être facil ement mod ifiables et indépendantes les
unes des autres
• Les mécani smes traitant ces connaissances sont aussi indépendants de ces
dern ières
Notre étude des systèmes à base de connaissances, nous a conduits à choisir JESS
comme outil de représentation et de traitement de la composition de services. Le choix de
24
JESS fac ilite l' intégrati on des différe nts modul es de notre systè me de compos iti on. Ce la
s'ex plique du fait que nous di sposons du code source (J ava) de JESS qui nous a été fourni par
« Sa ndi a Nati onal Labo ra tori es ». D 'autre part, beaucoup d 'outil s traita nt du XML so nt
égal eme nt di sponibl es e n Java.
Dans les proc haines secti ons, nous présentons dans un pre mi e r te mps les princ ipes de
base d ' un systè me à base de conn aissances et nous abordons les méca ni smes de
représentati on de conn aissances offe rt s par JESS ainsi que ses modes de raisonn e me nt.
On dés igne géné rale ment par le terme de SBC tout sys tè me qui permet de résoudre des
problè mes dans un domaine délimité (diagnosti c médica l, VLSI) pour leque l il ex iste des
experts, ayant une grande conn aissanc e du probl è me, pouvant Je résoudre effi cace me nt. Les
SBC tentent de simuler Je raisonne ment de ces experts humains dans des do maines
d' application où des algorithmes ne sont pas touj ours di sponibl es.
E n permettant d'automati ser des processus plus comp lexes que de simples routines de
calcul , les SBC ont introdu it l' informa tique dans des domaines où son utili sati on était réduite,
voire impossible, ou encore ont permi s de résoudre de façon plus simpl e des prob lè mes déjà
traités.
La résoluti on d' un problème par des moyens algorithmiques peut se traduire par le
schéma sui vant : Données + Algorithme = Programme
25
• Les SBC doivent être capables de don ner des ex plications concernant les
raisonnements qu'il s ont effectués;
• Les SBC sont spéciali sés dan s un domaine d'applicati on et non plus dans une
Un SBC est principale ment composé d' une base de connaissances (BC), représentant
1'expertise co ll ectée au sujet du domaine tra ité (par exe mpl e la compos iti on de services),
d'une base de faits (BF), ense mbl e de faits décrivant le probl ème préc is que l'on propose au
système de traiter et d ' un moteur d'inférences (MI) chargé d'app li quer les conn aissances
générales de la base de connaissances au cas particulier décrit dans la BF. Les interfaces sont
indispensabl es à une bonne communication homme-machine, l' une faci lite le dialogue avec
J'utilisateur au cours d ' une session et J' autre permet à l'expert du domaine de consulter ou
d'enrichir la BC du système. La figure 3.1 montre la structure d'un SBC.
26
BASE
DE EXPERT
REGLES
BASE
DE
FAITS
UTILISATEUR
La conception et la réalisation d' un SBC peut sui vre les étapes du schéma de la
figure 3.2.
3.2.3.1 Acquisition
3.2.3.3 Validation
Les générateurs de systèmes experts sont appelés à gérer des bases de conna issances de
plus en plus importantes tant sur le plan quantitatif que qualitatif, par conséquent ils sont
censés offrir des outil s assurant le regroupement des règles en plusieurs contextes spécialisés.
28
Exempl e de contexte :
Soit une base de règles spéc ia li sée dans le dépannage d' une vo iture, on distingue des
sous ensembles traitant des probl è mes é lectriques (contexte électrique) et d 'autres sous
e nsembl es pour des probl èmes méca niques (contexte mécanique) .
C'est da ns cette phase de va lid ati on que le contrôle de la co hére nce d' une base de
conn aissances s'effectue.
3.2.3.4 Exploitation
L 'ex plo itati on consiste à mettre e n œuvre via le moteu r d ' inférences une base de
co nnaissances validée; la communi cati on avec l' utili sateur est assurée par l' interface
utili sateur. L e moteur d ' inférences do it offrir plusieurs stratégies de contrôle :
• Chaînage avant
• C haînage mi xte
L ' interface utili sateur doit pe rmettre le di alogue e n : mode tex tuel class ique, mode
graphique statique ou dynamique.
JESS (J ava Expert S ystem She ll ) est un She ll de systè mes expe rts éc rit e nti ère ment en
Java. Son utili sati on a pri s de l' ampl eur depui s que lques années. Il peut être ex plo ité de deux
faço ns diffé re ntes :
• Pour développer des systè mes à base de conn aissances en formul ant l'experti se
d' un do ma ine donné sous forme de règles exprimées par des prédicats;
29
Dans le cadre de ce trava il , nous avons ex ploité son aspect re lat if aux systè mes à base
de conna issances.
Le mote ur de JESS utili se l'a lgorithme RETE (du latin qui sig nifi e réseau) qui est à la
base de l'a mé li orati on des performances dans le processus de déc lenc hement de règles da ns
les systè mes d 'ordre 1. Cet algorithme inte rvi e nt dans l'étape de filtrage des règles (choix de
la règle à utili ser parmi les règles candidates). JESS fut l'un des pre miers systè mes d' ordre
1(utili sant la logique des prédicats) à utili ser cet algorithme. Pour ce la il est considéré comme
Dans les prochaines sections, nous parl e rons des «artefact s» de JESS [5] utili sés da ns
ce travail. Ensuite, nous prése nton s les formali smes utili sés pour représenter les
connaissances.
filtra ge de JESS) afi n de pouvoir éc rire les règ les de mani è re à ce qu 'ell es soie nt exécutées
efficacement par JESS . Aussi, la structure de do nnées utili sée dan s RETE nous permet de
générer les pl a ns de composition de se rvices web.
Une impl é mentation sans RETE consiste à tester toutes les conditi o ns de toutes les
règles et ajoute r les conclusions des règles déclenchées à la mémoire de travail. Cette façon
de procéder est inefficace car le résultat des tests effectués sur les conditions des règles sont
toujours les mêmes et ne changent pas par rapport à l'itération précédente. La complexité
30
engendrée par ce type d ' implément ati on est O(RFAP) où R est le nombre de règ les, F le
nombre de faits dans la mémoire de travai l et P le nombre moyen de « pattern s» par règle.
Cec i nous permet de constater que la mé moire de travail est donc relati ve ment stable et
que la plupart du temps est passé à refaire les mê mes tests pour vérifi er si une règle est
déc lenchable.
C'est pourquoi plusieurs systèmes d' ordre 1 (JESS , OPSS et CLIPS) utili sent RETE
pour sauvegarde r le résultat des tests précédent s pour ne pas les refa ire à chaque cyc le. Et
ainsi la complex ité est réduite à O(RFP).
Dans RETE, on co nstruit un réseau dont chaque nœud représente un ou plusieurs tests
effec tués sur les conditions des règles. L 'ajout d'un ou plusieurs fa its est pro pagé à travers ce
réseau de nœuds. Les feui lles du réseau représentent les conditi ons instanciées des règles. On
les appelle les« activati ons »
Dans la figure 3.3, on représente un exemple de réseau RETE pour 2 règ les :
Reglet Regle2
Ils sont 1' équi valent des objets dans les langages ori entés objets. Les données sont
stockées dan s des slots (genre d'attributs). Voici un exempl e de fait non ordonné en JESS qui
définit une voiture de marque« ford », du modèle« focus »et so11ie l' année 2001:
Avant de pouvoir manipul er les faits non ordonn ées, il faut d'abord défi nir le gabarit
(genre de classe en java) avec la directive deftemplate. Le gabarit ou le moul e pour définir un
fait non ordonné pour une vo iture est Je su ivant :
(deftemplate voiture
(slot marque)
(slot modele)
Un slot en JESS est J'équivale nt d' un attribut d ' une classe en j ava ou en C++. Un fa it
non ordonné peut avoir plusieurs slots. U n slot conti e nt une seul e valeur. Si Je slot conti ent
plusieurs valeurs, il est appelé un multi -s lot.
Dans le cas des faits ordonnés, il n'est pas nécessa ire de définir des gabarits.
Ces derni ers sont générés auto matique me nt par JESS . Ces gabarits possède nt un seul
multi -slot. Le nom de ce slot est «_d ata » Les fa its ordonn és so nt des li stes dont le prem ier
élément peut ê tre considé ré comme une relati on. Par exempl e (Père a b) signifie que a est le
pè re de b.
• L 'aj out d ' un fait dans la mé mo ire de trava il se fa it par l'opérateur « assert ».
par exemple (assert (Père ab))
• La suppress ion d' un fait se fait par l'opérateur « retract ».ex : (retract (Père
ab)
Lorsqu'on veut effectuer une série d' insert ion de fa its dans la mé moire de trava il , il est
préférable d ' utili ser le constmcteur « deffacts ».En géné ral ce la se fait à l'initialisati on d ' une
sess ion. La commande « reset » perme t d ' in sérer tous les faits in diqués par « deffac ts » dans
la mé moire de travail.
Les règles son t des connaissances ayan t deux parties : les conditions et les conc lusions.
Une règle n'est exécutée que si sa partie « condition » est vérifiée. L'ordre dans lequel les
règles sont exécutées ne peut être déterminé à l'avance. C'est ce qui caractérise ce genre de
33
système. JESS permet donc d'avoir un comportement non détermini ste co ntrairement à un
programme classique.
L'exécuti on d' une règle par JESS se fait donc en essayant de trouver des faits dans la
mémoire de travail qui sati sfont sa parti e condition.
Dans l'exemple sui vant, on définit une règle permettant de déduire que X est grand
père de Z s' il exi ste une personne Y tell e que X est père de Y et qu 'en même temps Y est
père de Z. Notez l' utili sati on de la directi ve« assert » gui permet d'aj outer un nouveau fait à
la base de faits.
(detrule parenté
(PERE ?X ?Y)
(PERE ?Y ?Z)
=>
Il faut noter aussi que la partie conclusion utili se presque touj ours un appel de fonction
permettant de modifi er la base de faits. L'opérateur de relation ex istant entre les prédi cats de
la condition est implicitement un ET (AND). Il est également possible d' utili ser une
combinaison d'opérateurs AND, OR et NOT.
Il ex iste plusieurs autres opérateurs dans JESS ; pour plus d' informati ons veuill ez
consulter la documentation détaillée de JESS.
3.4 Conclusion
Dans ce chapitre, nous avons présenté les pnnc1pes des systèmes à base de
connaissances tout en mettant l'accent sur les aspects de JESS gui sont pertinents pour la
composition de services . Notre solution est basée sur l'exploitation des fonctionnalités de
34
JESS. Le choix de ce derni er comme outil est stratégique vu la nécess ité de di sposer d' un e
certaine fl ex ibilité au ni veau de l' intégrati on de la tec hnologie des systè mes à base de
connaissances avec les stand ards industri els relatifs aux services web. Cette intégrati on nous
a permi s de rasse mbl e r la pui ssance de WSDL (pour la desc ripti on de services) et le pouvo ir
déductif de JESS dans la génération des pl ans de co mpos iti on de services web. Nous avons
étudi é égale me nt les mécani smes offerts par JESS pour représente r le éléme nts permettant
de décrire les services web à savoir les règles et les faits.
Dans Je chap itre 4 , nous montrero ns co mment nous a ll ons déc rire les services web par
les mécani smes de JESS abordés dans ce c hapitre.
CHAPITRE IV
4.1 Introduction
Les deux approches possèdent des standards mais n'abordent pas la problématique de
la composition de services dans une même perspective. Car à notre sens, l'approche web
sémantique définit des standards pour représenter les informations liées aux contextes dans
lesquels les services web peuvent être combinés et assemblés dynamiquement pour construire
des services à valeur ajoutée. Par contre l' approc he industriell e élabore des standards pour
donner un support permettant de construire des processus manuellement.
Nous pensons que la définition des standards est une étape nécessaire mats non
suffisante pour répondre aux besoins de la composition dynamique de services.
Dans ce chapitre, nous allons présenter une approche « mixte » basée sur des standards
industriels et utilisant les techniques de composition dynamique inspirées de celles
appliquées dans l'approche web sémantique. Le fossé séparant les deux approches sera
rempli d'un certain nombre de modèles que nous définirons pour représenter les services.
36
Notre approche se base essenti ell eme nt sur l' utili sati on des règles modéli sant les
conn aissances de la compos iti on des servi ces we b . JESS, te l que décrit dans le chapitre 3, est
utili sé comme outil d 'exécuti on de règles pour la génération des flu x de compos iti on. Les
règles de JESS représentent l'aspect dynamique des services web. Dans les règles, nous
spéc ifi ons les c o nditi ons dans lesquell es les opérati ons de chaque service peuvent être
in voquées.
La compos iti o n de services nécess ite la re présentati o n des info rmati ons déc ri vant les
co ntex tes dans lesquels les services sont appe lés à coll aborer et à éc hanger des informati ons
afin de répondre à un ou plusieurs besoins spéc ifiques. L a nature évoluti ve de ces beso ins et
leur variété re nd la tache de définiti on de services très difficil e. Pire encore, la prise e n
compte des informati ons contextuell es pour co mbiner les servi ces et pre ndre en charge de
nou veaux besoins devient plus compliquée car les services n'étaient pas conçus, du mo in s à
leurs créatio ns, pour être utili sés ense mbl e.
La modé li sati on des informati o ns contex tuell es, re lati ve à la co mpos iti on de services,
est abordée différemment dans les approc hes de co mpositi on de services qui ex istent dans la
littérature et ne répondent pas nécessaire me nt au x ex igences et à la ri gueur des appli cati o ns
du mo nde rée l. A notre sens, les o bjectifs po ursui vis par les méth odes de co mpos iti o n
actue ll es ne sont pas les mê mes.
D' une part, l' approche indu strie ll e modé li se les serv1ces web sous une forme
exclusivement syntax ique et ne prend pas e n compte la sémantique li ée à l' utili sati on des
services. La définiti on de services uniqueme nt pa r leurs interfaces W SDL indique seule me nt
les opérati ons di sponibl es sur les diffé rents ports. WSDL n' indique pas l'ordre dans lequel
ces opérati ons devraient être appelées. Il faut aussi note r que les appe ls effectués par une
app lication clie nte à un même service pendant la même sess ion sont indépendants. Aucune
trace sur l' état du service entre deu x appe ls n'est gardée. La di fficul té est encore plu s
importante si o n veut utiliser un service web dans un processus d 'affaire pour lequel il n'a
pas été conçu. Un processus d'affaire faisant appel à plusieurs services web doit faire
collaborer les différents acteurs ou services de façon cohérente car chaque acteur peut
37
changer le flu x d'exécuti on ou le comporte me nt du processus par les informati ons reçues de
ces acte urs. De l' ense mbl e des servi ces mi s e n coll aboration peut résulte r un comporte ment
de processus qui aurait pu être différent si c haque service avait été utili sé séparément. Si par
exempl e, le co mporte ment anormal du processus n'est pas traité, on pourrait aboutir à une
situati on incohérente de l'état fin al des données.
Les mêmes probl è mes restent posés pour l'approc he web sé mantique. Néa nmoins, ell e
utilise des mécani smes de représentati on de la sé mantique li ée à la co mpos iti on beaucoup
plus ri ches que la mé th ode industri e ll e. Les onto logies et les systè mes à base de
conn aissances permette nt de pre ndre e n c ha rge certaines diffi cultés liées à la modéli sati on de
la compos iti on. La desc ripti on de services agrégés sous forme de buts à atteindre simplifie
énormé me nt le processus de compositi on ca r la transformati on de ces buts en fa its vérifiables
permet de savoir si un service agrégé est réa li sable à partir d' un ense mble de services donné.
L 'état actuel de la co mpos iti on des services web est caractéri sé par l'absence d 'outil s
de co mpos iti on dynamiques, particuli ère me nt pour la méthode industri ell e, pouvant être
utili sés pour des applicati ons du monde réel. L'établi ssement de standard s, au m veau
industri e l, est déj à une étape importante dans le do maine de la compos iti on. Les outils
ex istant, dans la sé mantique web, ne sont pas appro priés car ils ne s' intègrent pas dans les
environne ments de développement.
La modéli sation de la composition des services web est aussi un autre problème qu'i l
faut résoudre. L' intérêt de la modéli sati on de la co mpositi on est de pou voir gérer les
changeme nt s subi s par les processus de façon rapide et effi cace. Ces c hangements sont
38
fréque nts et nécess itent des outil s de conversion e ntre différe nts modèles afin de fac iliter la
co ll a borati on e ntre les di ffére nts ac teurs qui intervie nnent dans un processus. Il est important
de représenter la co mpos iti on par di ffére nts modèles car les acteurs ne considè re nt pas le
probl è me de la compos iti on sous un e mê me perspec tive. Diffé re nts concepts sont manipul és
et donc la représentati on de ces derniers en dépe nd . Il serait alors souh aitabl e de di sposer
d 'outil s perme ttant de passer automa tique ment d ' un modè le à l'autre se lon la nature de
l'ac teur qui intervi ent dans la modé li sati on de la compos iti on. La définiti on des processus,
étant co mplexe, nécessite plusieurs é tapes avant d 'arri ver à un résultat sati sfaisa nt.
Notre vision de la compos iti on a été abordée d ' un po int de vue pratique, c'est-à-dire
que nous avons conçu une app roc he pragmatique supportée par un systè me fac il e à utili ser et
pouva nt s' intégre r fac il e me nt dans un e nvironne me nt de développe ment.
L ' idée est de considérer la compos iti on co mme étant une soluti on à un probl è me
complexe pouvant être décomposé en plusieurs sous problè mes et ce processus de
décompos iti on peut s ' appliquer à chacun des sous problèmes jusqu 'à ce qu ' on arrive à un
ni veau de détail suffisa mment si mple pour trouver un serv ice pouvant prendre en charge le
39
sous problème en questi on. Les se rvi ces qui intervi enn ent dans la compos iti on ne sont pas
nécessa irement atomiques, i.e., donnant un simple résultat suite à un appel d 'opérati on. Ils
peuve nt , donc , eux même être co mposés d ' autres services.
La méth ode de compositi on utili sée dans l'approc he mi xte se base sur les principes
sui vants:
• Utilisation des standards industriels : Dès le début, nous avons cho isi de
nous conformer à l'utilisati on des standards industri els de dépl o ieme nt de se rvices
web car il serait inutil e de dé finir des fo rmats propri étaires auxq uels il fa ut
développer des outil s les supportant. Un tel déve loppement ex ige rait bea ucoup
d'effort s et de temps. La desc ripti o n de services web dans notre approc he se fait donc
en WSDL. L ' autre avantage est de pouvoir bé néfi cier des servi ces dépl oyés sur
Internet qui seront de plus e n plus nombre ux et utiles. La réutili sati on de
composantes sous forme de services justifi e ampl ement ce choix. La définiti on de la
compositi on par BPEL4WS est faite pour les mêmes raisons. Des outil s de
déploiement de servi ces agrégés so nt déj à di spo nibles . Nous en avons choisi ce lui
d ' IBM appelé BPWS4J (Business Process Web Services For Java).
S' il s'avère qu 'ell e n'est j ama is interpellée, sa présence dans la base de règles ne sera
pas nécessa ire. L 'autre avantage d' utili ser un systè me à base de conn aissa nces est de
pouvo ir di sposer d ' un deuxiè me modèle d 'exécuti on qui est surt out expl o ité lors de
la mi se au point des règles. On n'est donc pas li é au modè le final qui est BPEL4WS
pour le test d ' une base de conn aissances car le processus risque de devenir plus lent.
• Liaison entre les règles et les fichiers WSDL : Pour retrouver la desc ripti on
WSDL d' un service à partir d ' une règle de la base, il est ind ispensable d 'adopter un e
conventi on de no min ati on des règ les. Cette co nve nti on utili se les noms des f ichi ers,
des ports et des opérati ons des di ffé rentes desc ripti ons WSDL de serv ices. Les
informati ons retrou vées concernent les types de données éc hangées et les paramètres
de retour des opérati ons.
Le schéma de la fi gure 4.2 d onne une vue globale de l' approche mi xte .
---------+1 1
1
Approche Mixte+-- - - - - - - ,
1
L 'apport de notre approche réside essenti elle me nt dans la modéli sati on des aspects
dynamiques de la co mpos iti on. La pl ace dans laquell e nos modè les se situe nt par rapport à la
pile des standards montre que nous co mpl étons les ni veau x de descripti on de services et de
processus. Les règles de productions sont expl oitées comme un mode de représentati on de la
sémantique relative à la compos ition (Fi gure 4.3).
Les descriptions WSDL sont re li ées aux règles de telle sorte à pouvo ir accéde r au x
informati ons descriptives des se rvi ces (WSDL) à partir des règ les. Les règles déc le nc hées
lors de la compositi on nous pe rmette nt de générer les pl ans de co mpos iti on. Les pl ans de
compos iti on, à leur tour, vont être utili sés pour gé né re r le code BPEL4WS représe ntant les
servi ces compos ites.
Il faut aussi re marque r qu'il est poss ibl e d'ex ploiter UDDI pour mettre en pl ace un
modèle d ' invocation dynamique de services en utili sant les règles.
BPE~4WS[ Règles
SOAP WSDL 1 UDDI 1
1
XML&XSD
1 J
La modéli sati on de l' aspect dynamique de la compos iti on par les règles se fait par le
concepteur de la base des conna issances. Son rôle consiste à analyser le do maine d 'affa ires et
de choisir les servi ces qui s' y rapportent. L ' implé me ntati on du service co mposé se fait en
BPEL et l' exécuti on des règles est réali sée par JESS (Fi gure 4.4). Il s'agit alors de faire
l' intégration des règles et du la ngage d' exécuti on des processus. Le choix des services de
base à utili ser se fait lors de l'analyse. Ce qui donne plus de flexibilité au niveau de
42
l'évolution du servi ce composé qu i uti li se un ou plusieurs servi ces de base. Le change ment
d' un service de base n'affecte pas le service composé pourvu qu ' il soit remp lacé par un autre.
La compos ition suit un cycle composé d' un ensemb le d' étapes. Les fro nti ères entre les
étapes ne sont pas nécessairement délimitées car le cycle est itératif (Figure 4 .5). On procède
par raffinement success ifs jusqu'à ce gu' on arrive à un service composé réponda nt aux
critères de quali tés spéc ifiés. Chaque étape du cycle peut être supportée par des outi ls d'aide
à la composition. L' idéal serait de di sposer d' un env ironne ment qu i permet d'automati ser
co mp lètement la composition .
Règles Processus
abstrait
An alyse
Base de règl~s
.
"Y
.: Imp lémentation
Règles
..:.
Processus 1
--,
exécutable
1 1
1
L ~- Jess
- - -- - -----
BPWS4J
J 1
1
Intégration des règles et de BPEL
1
Figure 4.4 Approche de composition
Re-choi sir
Re-composer
pl ans est validée graphique ment pa r le développeur. Il peut aussi effec tuer des
simul ati ons sur les pl ans générés. Il peut modifi er les requêtes e n spécifi ant
diffé re ntes e ntrées/sorti es pour les services qu'il veut co mposer. Il faut
soul igner le fait que le développeur di spose touj ours de l'opti on de co mpl éte r
le pl an généré par le systè me ma nue ll e ment e n utili sant un service ex téri eur
no n modéli sé par le systè me. Cette opti on permet au développeur de partir
Le sc hé ma de la figure 4 .6 montre les di ffére nts cas d' utili sati on du systè me.
45
Construit les
règles de composition
Concepteur
Développeur
Utilisateur
Figure 4.6 Les diffé re nts cas d' utili sati on du système
L ' ana lyse d' un e requête de co mpos iti o n consiste à ex trai re les entrées et les sorti es de
service co mpos ite gue 1' on veut impl éme nte r. L ' interpré teur de co mmandes transforme ces
e ntrées e n un état initi al de la base de faits de JESS. Ces faits sont insérés par le compositeur
gui lance auss i l' exécuti on de JESS . A J'arrêt de JESS , le compositeur vérifie si la sortie,
transformé en un état final, est atteinte lors de 1'exécution . Dans le cas du succès, Je flu x de
composition est présenté sous forme graphique; après quoi la génération du code BPEL peut
être encl e nchée.
46
Le descripteur du service composite, peut être enregistré dans Je registre afin qu 'i l
puisse être utili sé par des utili sateurs potentiels.
Si la requête provient de la part d'un utili sateur voulant effectuer des rec herches sur le
registre afin de retrouver un service, le modul e d ' invocati on de services est appelé.
L'ensemble des descripteurs de se rvices sont stoc kés dans la base des reg istres. Lors de la
compos iti on, ces descripteurs y sont retrouvés pour ext raire les informati ons sur les types de
données et les noms des opérations pour générer des pl ans de co mpos iti on.
Dans la figure 4.7 sont indiqués les différen ts modul es qu 'o n vie nt de décrire. JI faut
rema rque r la présence de deux niveau x de services. Les servi ces composés que les
déve loppeurs ont générés et déployés pour être utili sés et les services de base qui so nt décrit
dan s la base de règles. Les services composés générés par les développeurs ne sont pas tous
déployés. Seuls ceux que Je concepteur considère pertine nts seront déployés. Tout
changement de service de base doit être contrôlé par Je concepteur car des serv ices composés
déjà dépl oyés peuve nt utili ser Je service de base en question . Sa suppress ion ne doit se faire
que si un autre service de base peut le re mplace r. Le contrôleur d' accès permet de gérer
J'auth entificati on des utili sateurs et de leur donn er J'accès unique ment aux services auxquels
il s ont droi t selon leurs profil s.
47
Interface Utilisateur
Invocation &
composition
Registre de
services
UDDI
Controleur d'accès
Découverte de
services
Déclaration Constitution
Services composites Compagnie
•• Services basiques
Nou s avons déj à présenté JESS au chapitre 3. Son rôle dans la composition de services
est primordial car il possède des caractéri stiques sui vantes:
vari ables. Nous all ons voir dan s la suite de ce chapitre co mment représenter les
opération s des services sous forme de règles et de prédi cats. Dans la versio n
actuell e, nous avons c ho isi de ne pas utili ser les foncti o ns et les négati ons dans
les règles. Cette derniè re poss ibilité pourrait être ex pl o itée pour introduire de
nou vell es foncti onnalités intéressantes dans le processus de co mpos iti on
parti culi èrement pour la mi se au point des bases de règles déc ri vant les
servtces.
• Facilité d'intégration et d'interaction: L ' intégrati o n des modè les que nous
avons é la bo rés dans JESS co nstitue un atout maj eur car il nous pe rmet de
construi re des pl ans de compos iti o n à partir des structures internes de JESS et
interviennent dans la co mpositi on. L 'ex tracti o n des informati ons re lati ves au x
types de données et au x paramètres des opé rati ons, a in si que les po rt s et les
dé pendance entre les appe ls, les in vocati o ns para ll è les et séquenti e lles seront
retrou vées d ans l' arbre d 'exéc uti o n de JESS. Il faut note r que les performances
de JESS dépendent de la structure des règles de compos it ion c'est po urquo i le
un atout majeur offert par JESS. Dans la modéli sati on de la compositi on, e n
plus des règles, il est possibl e de représe nter les entités de descripti on de
servi ces par les objets Java e t exploiter les concepts d' héritage et de surcharge
ou de sur-définiti on de foncti ons. Le formali sme obj et est intéressa nt pour la
représentation des connaissances liées à la compos iti on. Sa combin aison avec
les règles constitue un apport maj eur. Nous allons vo ir dans la suite de ce
chapitre comment exp loiter les obj ets.
L'intégration de JESS dans des applicati ons Java est une ca ractéri stique très
util e dans la mi se en pratique des idées avancées dans ce travail. Il est poss ible de créer
des règles dynamique me nt à partir d ' une classe Java e t de les exécuter. Cela est
particulièrement intéressant pour le concepteur de règl es qui maintie nt la base de
connaissances. L' écriture du modul e de génération automatique de règ les peut très bi en
être envisagée afin d'améli orer le processus de modéli sati on de la compositi on.
Notre modèle de composition se base sur la représentation des opérati ons d' un service
sous forme de règles. Dans la règle correspondant à une opérati on, on spéc ifie la sorti e
pouvant être déduite à partir d'une ou de plusieurs entrées. Un service est donc représe nté par
plusieurs règles; il ex iste autant de règles que le nombre d 'opérati ons d' un service donné .
50
Une règle possède un nom significatif qui permet de faire l'association entre le fi chi er
WSDL et la représentation sémantique pour extra ire les informations conce rn ant les
messages et les types de données échangés entre le client et le service.
Nom du po11
Nom de 1'opération
Service 1
Régie Le descripteur de
'
service WSDL
Portl
Opération Il
...___ _+---~ Opération 12
Port2
Opération21
Üpération22
4 . une foi s l'opérati on est locali sée, tous les messages et leurs types respec tifs
sont également retrouvés et an alysés.
Nous parton s d ' un exe mpl e [6) d' un servi ce web simple ayant une seule opérati on.
Nous all ons nous e n servir pour ex pliquer le modè le de co mpos ition du systè me. Le contenu
du fi chier WSDL est donné dans la fi gure 4 .9 . Il s'agit d' un service qui indique la va leur des
indices boursiers.
Un document WSDL est une suite de définiti ons. L'é lé ment « definiti ons» est la
rac ine de fi chier WSDL.
• Types, utili sés pour définir les types de données servant à décrire les messages
échangés;
• Messages, qui représentent une définition abstraite des données transmi ses. Un
message est constitué de plusieurs parties dont chacune est associée avec un
type donn é;
• PortType, qui est un ensembl e d' opérati ons abstraites; chaque opérati on
référence les messages d'entrées et le message de sorti e;
• Binding, spéc ifie le protocole et les spéc ifications des formats de données pour
les opérat ions et les messages d'un portType don né;
Dans l' exemple de la figure 4.9, J'élément « definitions» indique le nom du service
qui est « StockQuote ». La spécification des espaces de noms permet de différencier les
é léments et de référencer des spécifications externes comme SOAP, WSDL et des schémas
52
XML. L'attribut « targetNamespace »est un e co nvention qui permet de faire des références
au document WSDL (auto-reference). Dans l'exempl e, on a
targetNamespace="http://example .com/stockquote. wsdl".
Il faut noter que le documen t WSDL ne se trouve pas à cette adresse. Il s'agit
uniquement de spécifier une valeur unique différente des autres va leurs d'espaces de noms
utilisés dans le document.
<message name="GetlastTradePricelnput">
<part name="body" element="xsd1 :TradePriceRequest"/>
</message>
<message name="GetlastTradePriceOutput">
<part name="body" element="xsd1 :TradePrice"/>
</message>
Chacun des messages de cet exe mpl e contient une seul e partie. Dans le message de la
requête, cette partie représente le paramètre indiquant le nom de 1' indice boursier. Pour le
message de réponse, la partie représente la valeur de l'indice retournée par l'opérati on.
Les types des deux parties des deux messages sont défini s dan s la sec tion « types , et
sont référencés par l'attribut" element "·
La seul e opération du service est définie dans la section « PortType , . Elle possède un
message d'entrée et un message de sorti e. Le code sui vant montre la déc laration de la
méthode.
<portType name="StockQuotePortType">
<operation name="GetlastTradePrice">
<input message="tns:GetlastTradePricelnput"/>
<output message="tns:GetlastTradePriceOutput"/>
</operation>
53
<lportType>
<?xml version="1.0"?>
<definitions name="StockQuote"
targetNamespace="http://example.com/stockquote.wsdl"
xmlns:tns="http://example.com/stockquote.wsdl"
xmlns:xsd 1="http://example .com/stockquote.xsd"
xmlns:soap="http://schemas.xmlsoap .org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<schema targetNamespace="http ://example .com/stockquote.xsd"
xmlns="http ://www.w3.org/2000/ 10/XMLSchema">
<element name="TradePriceRequest"> ·
<complex Type>
<ali>
<element name="tickerSymbol" type="string"/>
</ali>
<lcomplexType>
</element>
<element name="TradePrice">
<complexType>
<ali>
<element name="price" type="float"/>
</ali>
<lcomplexType>
</element>
</schema>
</types>
<message name="GetlastTradePricelnput">
<part name="body" element="xsd1 :TradePriceRequest"/>
</message>
<message name="GetlastTradePriceOutput">
<part name="body" element="xsd1 :TradePrice"/>
</message>
<portType name="StockQuotePortType">
<operation name="GetlastT rade Priee">
<input message="tns:GetlastTradePricelnput"/>
<output message="tns:GetlastTradePriceOutput"/>
</operation>
</portType>
<binding name="StockQuoteSoapBinding" type="tns:StockOuotePortType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
54
<operation name="GetlastTradePrice">
<soap: operation soapAction=" http :/1ex am pie. com/G etlastT rade Priee"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
<lbinding>
<service name="StockQuoteService">
<documentation>My first service</documentation>
<port name="StockQuotePort" binding="tns:StockQuoteBinding">
<soap:address location="http://example.com/stockquote"/>
</port>
</service>
</definitions>
Figure 4.9 Le descripteur WSDL du service des taux boursiers
La descripti on d ' un serv ice par des règles, consiste d 'abord à définir un ensemble
d 'entités du monde rée l sur lesque lles les règles agisse nt e n mod ifi ant les différe nts attributs
des entités impliquées .
2. (lndiceBoursier ?X)
4. ===>
55
La ligne 1 indique le nom de la règle selon la conventi on que nous avons adopté dans
notre modèle. Après l' exécuti on de la règle, on peut retrouver toutes les informati ons
décri vant 1' opérati on dans le fi chier WSDL.
La ligne 2 indique un e condition devant être vérifi ée pour pouvo ir déclencher la règle.
Cette condition est vérifi ée si l'entité ?X est un indi ce boursier et possède la va leur vrai.
La ligne 3 indique la deuxième conditi on qui doit être vé rifiée pour déc lencher la règle.
Cette conditi on est vérifi ée si le nom de l' indice boursier est co nnu (possède donc la valeur
vrai)
La ligne 4 veut dire que si toutes les conditi ons sont vérifi ées, on peut déduire le fait de
la ligne 5. Dans l'exempl e il y a un seul fait mais on peut en avo ir plus.
La ligne 5 indique que la val eur de l'indice boursier ?X possède maintenant (après
l'exécution de la règle) la valeur vrai . Noter l'opérateur « assert » qui permet d' insérer le
nouveau fait dans la mémoire de travail.
La desc ripti on de servi ces par les règles est complétée par un modèle ori enté objet.
L'ensemble des objets correspondent à des entités du monde réel pour lequel on veut
appliquer la co mpositi on de servi ces.
Le seul objet de l'exempl e est l' « IndiceBoursier » ayant deux attributs : Nom et
Valeur
II est important de constater que dans une règle il n'est pas nécessaire de conn aître tous
les attributs des entités impliqués car se so nt les faits associés aux attributs et les relati ons qui
ex istent entre les entités qui changent l' état de la base de faits. Dans 1'exempl e précédent, on
a les fa its sui vants: Indi ceBoursier X, premi er fa it, qui signifie que tout objet X qui est un
indice boursier et dont on connaît le nom, deuxième fa it, on peut conn aître la valeur,
troisième fait.
Le système n'impose aucune restriction sur la définition des entités et les relations
entre les entités à partir desquell es on doit modéliser la sémantique relative à la composition.
56
Le concepteur est libre de définir ses propres e ntités et relation s li ées à la sé mantique de
composition des services qu ' il veut modé li ser. Le systè me offre donc un méc ani sme de
représentation de servi ces sous forme de règ les et d ' objets.
Il ex iste deux types d'entrées d'une opération d'un service. Les entrées portant sur les
conditions deva nt être spéc ifi ées sur les entités et les relati ons e ntre ces entités. Les entrées
po11ant sur les attributs ou les données de ces entités. Les mê mes types s'appliquent pour les
sorties des opérations d ' un service . Pour expliquer ce modèl e, pre nons l'exe mpl e de service
d ' annuaire de ya hoo. Il permet de retrouver l'adresse et le télé phone d' une pe rsonn e à partir
de son nom, prénom, vill e et état. Il e xi ste une seul e entité qui inte rvi ent dan s la desc ripti on
de la règle et qui est appelée X.
• Les e ntrées-condition s portant sur les entités : Personne(X) indique que X est
une entité Personne
Dans l'exempl e précédent, une seul e entité est impliquée dans la règle modéli sa nt le
service d' annuaire. D ans l' exe mpl e suivant, on va modé li ser un service d'e nvo i de courri e ls
où deux entités sont impliquées et une sorti e-condition est spéc ifi ée.
• Entités impliquées : X et Y
Ces deu x exemples montrent la pu issance d 'ex press ion des prédicats et de l' orie nté
obj et dans la représentati on de la sémantique de co mpos iti on de serv ices .
Les exe mples précédents montre nt que le problè me de la co mpos iti on de services peut
se décrire sous-forme d'acti ons représentant les opérati ons d' un service web do nné. Ces
acti ons prennent la forme de règles de producti on exprimées par des prédi cats. Les pré-
conditions des règles sont des conj oncti ons entre les conditions portant sur les entités et les
relati ons entre les entités d ' un e part ; et d 'autre part les fa its co nnu s portant sur un attribut ou
plusieurs attributs des différentes entités impliquées.
Le fait connu correspondant à un attribut, Attribut(X I,X2, ... Xm), est définis par
Conn u(Attribut,Xl ,X2, ... Xm). Et ain si le fait représentant une entrée d ' une opérati on de
service est Entrée(Xl ,X2, .... Xn). Da ns la deuxiè me notati on, il s'agit simple me nt d'u n
changement de variable (Attribut par X n).
Les post-conditions sont des conjonct ions des cond itions portant sur les entités et les
relat ions entre les entités et auss i entre les attri bu ts des sorti es. En d' autres termes, les mêmes
principes s'app liquent pour les post-condi tions des acti ons.
L'état initi al de la base de fa its est la conj oncti on entre tous les fa its des entrées
spéc ifiées pour le service composé que l'on veu t générer.
L'état final de la base de fait est la conjonction de tous les faits représentant la sortie du
service que l'on veut composer.
58
Dans ce modè le, nous n' avons pas utili sé la négation des faits ce qui a pour
conséquence de générer touj ours de nouveaux faits sans j amai s en supprimer. La gesti on de la
négati on peut rendre J' algorithme de composition complexe et par consequent la ge nerati on
des pl ans de compos ition sera difficil e .
Lorsqu 'on veut générer un pl an, le système lit les entrées et les sorti es que le
développeur a spéc ifié pour Je servi ce co mpos ite qu ' il veut développer. Il transforme, ensuite,
les entrées en faits initi aux qu'il insère dans la base de faits. Le système entame l'exécuti on
des règles en partant des faits initiaux. Le déclencheme nt des règles, en chaînage avant,
génère de nouveaux faits. Ces faits correspondent à des sorties des différentes opérati ons de
services représentées par la base des règles. L'ensembl e des règles déclenchées dépend des
faits initiaux et des faits intermédi aires qui sont insérés pendant l' exéc uti on. L 'arrêt de
J' exécuti on signifie qu ' il n'y a plus de règles pouvant être déclenchées. Pour savo ir si un pl an
correspond au x spécifications données par Je développeur, Je systè me vérifi e si la base de
faits conti ent les fait s qui représentent la sortie du servi ce compos ite.
Il faut noter que l'ordre d 'exécuti on des règ les n'est pas important car l'arbre
d'exécuti on permet de savoir l' enchaînement de ces règles. Les mêmes faits so nt déduits
indépendamment de 1'ordre de déclench ement des règles .
Dans le cas de succès, un pl an est généré à partir de l' arbre d 'exécuti on qui re prése nte
l'ensembl e des opérati ons des di fférents services impliquées. L ' analyse de J'arbre
d'exécuti on permet de remonter toute la chaîne des règles et de générer un pl an de
co mpos iti on. Ce plan peut être visuali sé sous fo rme graphique. Si le déve loppeur le dés ire, il
peut transformer le plan. Une fo is le plan graphique est visuali sé, la générati on du code B PEL
peut être lancée. L 'étape de générati on de code sera abordée dans les secti ons proc haines.
L'ensembl e de ce processus est résumé dans la figure 4. 1O.
Pour illustrer le processus de générati on de plan, nous allons modé liser 2 services de
base à partir desquels on effectuera une co mpositi on. Le premi er service permet de trou ver
59
( TrouverCoordonnes.pt1 .adresseTel
(Personne ?X) (Connu Prenom ?X) (Connu Nom ?X) (Connu ville ?X) (Connu Etat
?X)
===>
(assert (Connu adresse ?X)) (assert (Connu telephone)))
Règle 2:
( Trouverltinairaire.pt2.Chemin
(Connu ville ?X) (Connu Etat ?X) (Connu adresse ?X)
(Connu ville ?Y) (Connu Etat ?Y) (Connu adresse ?Y)
===>
(assert (Connu ltiniraire ?X ?Y)))
Supposons que l'on veut trouver le chemin entre le domicile d' une personne A et celui
d 'une personne B. On spécifie alors les faits suivants :
60
(Personne A)
(Connu Prenom A)
(Connu Nom A)
(Connu Ville A)
(Connu Etat A)
(Personne B)
(Connu Prenom B)
(Connu Nom B)
(Connu Ville B)
(Connu Etat B)
Le lancement du chaînage avant d éc lenche 2 fo is la règ le 1 ensuite la règle 2 qu i
permet de trouver le chemin entre les 2 domi ciles . L 'arbre d'exécuti on correspondant est
représenté dans la fi gure 4.11
(Connu Itiniraire A B)
L 'exe mple précéde nt montre les carac téri stiques sui vantes du modè le de composition
basé sur des règles :
• U ne règle peut être déclench ée plusieurs fois avec des données différentes .
Cela signifi e qu ' un e opération . d ' un service peut être exécutée plusieurs foi s
pour une mê me requête;
Il ex iste une différe nce entre la modé li sati on de services de base et celle des services
composés. Les services « basiques » sont en général une co llection d' opération s qui sont
appelées de mani ère synchrone ou asynchrone et se limite nt donc à un simpl e éc hange de
messages. L 'ordre d ' in vocation des opératio ns n'est pas important et se fa it selon les
sollicitation s de l'appli cation c li ente.
Par contre, les services composites so nt dotés d ' un comportement définis par le
séquence ment des messages éc ha ngés. L' interacti on obé it à la logique de l' app lication c liente
et l' ordre d 'appe l des opérations dev ie nt impo rta nt.
Considérons, par exempl e, une compagnie aéri enne qui veut publier un servi ce d 'ac hat
de billets d'av io n co mposé de tro is opérations : une opération de consultati on des offres, une
deu xième pour la réservati on du c hoix et une éve ntuelle tro isiè me pour le pa ie me nt. Dans la
descripti on W SDL du service, aucune informati o n n' interdit le fait de réserve r un vol qui
n 'ex iste pas ou de paye r un autre qui n'a pas été réservé. Toutes les opérati o ns sont au mê me
niveau et e ll es sont, tec hniquement , toutes invocables .
La modéli sation des services composés et des processus ne peut donc se faire
un iquement par WSDL. Il faut compl éter ce dernier par un autre modèle qui permet de
prendre en compte les contraintes de la composition. Cependant les modèles qui nous
intéressent dans le cadre de la composition sont ceux qui nous permettent de passer de l'arbre
62
d'exécution gé néré par JESS au code BPEL qui représente le service composé (Figure 4.12).
Le service composé peut donc être cons idéré comme un processus.
<process>
<lprocess>
Arbre Modè le
d'exécuti on int ermédiaire Code BPEL
Les modèles UML et l'extens ion de sa notation utili sent les diagrammes d'activités
pour déc rire une composition de services. Cela suppose que le modèle de départ soit le
di agramme d' activité UML dans leque l le concepteur du service co mposé modélise son
service manue ll ement. Or il s'agit dans notre cas de rendre cette tâc he de composition
automatique. Il faut donc trouver un mécani sme de transformation du modèle généré par
JES S vers le di agramme d'activité.
Pour illustrer la représentation des processus par UML, nous avons repris l'exe mple du
chapitre 2 auque l on a apporté des modifications pour illustrer certain s constructeurs de
BPEL. Le processus consiste à acheter des billets pour des employés d'une compagn ie en
spéc ifiant le nom de 1' empl oyé, sa destination, les dates du voyage ainsi que d'autres
informat ions. Le processus invoque un service qui permet de vérifier le statut de l'employé.
63
1 Request 2 Request
_ .. '' invoke (sync) »
C lient Recoit le statut du voyage de
6 Reply remployé
3 Reply
PortType
.....
« invoke (async) »
-- --
Demande le prix du billet
- à Americam A irl i ne.~
l
.....
·« invoke (async) »
Demande le prix du billet
à Delta Airl ines
PortType
Pri xAmeri can <= PrixDelta PrixAmerican > PrixDe lta 4.1 lnvoke
4.2 Cali
« assign >> <assign » )lt-
<< reply »
Retourner le mei ll eur prix ----
'-r-::5:-::.2:--:C~a-:-:
11:-'_Back
5. 1 Jn voke
Port Type
64
long chemin à parcourir avant d 'arri ver à des résultats sati sfai sant s. De ce fa it, des ou til s de
conception sont rarement utili sés de bout e n bout, de la modélisation à l'exécution .
La soluti on de composition que nous avons é laborée nous obli ge à prendre co mme
modèle de dép art l' arbre d 'exécuti on généré par JESS. Pour fai re le choix e ntre les deux
types de modèles précédents, il faut trouver un moyen de fai re le li en de l' un ou de l'autre de
ces modè les avec l'arbre d 'exécution . C'est pourquoi le c ho ix du modè le basé sur UML a été
vite écarté.
La géné rati o n d'un plan de compos iti on peut se décrire par un système de tran siti o n
d'états. Le systè me de composition passe d ' un état à l' autre lo rs de la gé né rati o n d ' un plan de
composition en partant d ' un état initial. Les différentes transiti ons sont provoquées par
J'exécution des règles qui représente nt les opérations des serv ices et qui correspondent à d es
action s. La modé li sati on de services sous forme de règ les nous permet justement de
bénéficier du modè le conceptuel utili sé d ans les systèmes de pl anificati o n. Dans notre cas,
Pour pouvoir génére r le code BPEL qui correspond à un serv ice co mposé généré par le
systè me, il est nécessaire d' établir un modè le conceptue l représentant les différents
opérateurs de BPEL qui lie ce dernier au plan de compos iti on généré par le systè me . Ce
modè le conceptuel nou s permettra de rattac her des routines sémantiques aux règles de
composit ion afin de construire le code BPEL relatif au service co mposé. Ce service est donc
déployé pour être utili sé
Le systè me de composition travaill e en réa lité avec deux modè les différents mai s qui
se complètent. Le premier est le modèle de p lanification dont les éléments de la compos iti o n
sont des opérateurs. Ces opérateurs son t les règ les qui opèrent sur la base de faits qui reflète à
chaque étape du processus de compositi on l'état dans leque l le système de composi ti o n est
rendu . Le deuxième est le modèle de composition dont les éléments sont des services
atomiques. Il indique les différentes opérations impliquées avec les paramètres de c haque
65
opération . L'ensemble des opérations des servi ces relatifs à une requête de co mpositi on sont
représentés par des activités en BPEL (Figure 4.14).
ass1gn throw
La représentati on des activités de BPEL par le modèle conceptuel que nous décrivons
dans cette section nous permettra de générer le code BPEL, qui représe nte le service
composé, à partir de ce modèle.
Services de base
impliqués dans la
compos ition
Le service composé pourrait alors être représenté par un processus BPEL qui va être
appelé de 1'extérieur comme tous les autres services existants (Figure 4.15).
66
Un processus défini en BPEL est une composition d'activités (Figure 4.16) dont le
modè le est un tuple (V, D, R) où :
Services
externes
o-p
ü-Q __
Figure 4.16 Représentation d'un processus BPEL par des activités
Le modèle de processus est donc un système de transition d'états car pour modéliser un
processus, il faut représenter toutes ses activités et 1' ordre d'exécution de ses activités en
67
utilisa nt des vari abl es et des règles. Dans les sec ti ons suivantes, nous all ons représenter les
différents types d'acti vités par des modèles formels.
On di stin gue se pt acti vités de base en BPEL qui ne peuvent comporter aucune autre
acti vité. Elles constituent les bl ocs de constructi on d'un processus et plus préc isément d' un
service composé dans notre cas. Chaque acti vité est translatée dans le modèle conceptuel
selon ses propres règles de transition . Nous avons élaboré un modèle basé sur les di agrammes
d'états pour représenter la sé mantique de co nstructi on de code BEPL liée à la compos iti on en
partant de l'arbre d'exécuti on généré par JESS.
Nous pouvons alors définir une acti vité dans un processus, qui est aussi un servtce
composé, comme un e règle de transition. Il fa it changer l' état du système en partant d' un état
initial «ac ti vité-début » vers un état fin al " activité-fin ». L'acti vité di spose d' une vari able
d'entrée " inVar >> et d' une vari able de sorti e '' outVar >> qui appartiennent à V et qui sont
impliquées dans la transition. La transition est étiqueté par un nom " nom Transition >>. Le
schéma de la figu re 4. 17 montre comment représenter un e acti vité dans le modèle conceptuel.
inVar, etatVar et outVar représentent les va ri ables d'états. nomTransition représe nte le
nom de l'acti on ou de la règle qui a provoqué la transiti on.
pre(inVar) ET etatV ar
N omTransitio
l
post(outVar) ET etatVar
Les noms affectés aux états e t transitions doivent être uniques. A chaque lancement
d ' une requête de compos ition de services, on peut gé nérer un numéro qui sera inclus dan s les
noms des états et des transitions afin de s'assurer de l'unicité des noms attribués.
Dans certains cas, la modéli sation du comportement interne d'une activité est
nécessaire si e lle comporte plusieurs états intermédiaires. Donc, une activ ité di sposant de
plusieurs états intermédiaires se représente par le passage d' un état de début vers un état de
fin en passant par plusieurs états inte rmédiaires (Fi gure 4. 18)
etat V a l état 1
..
N é tats
internes ~ etat Var = étatl
..
etat Var r étatN
TransitionN
post(outV ar) ET etatVar =fin
Dans cette sec tion nous allons modél iser les activités de base de BPEL. Toutes les
activités seront modélisées par les élé ments défini s dans la section précédente à savoir les
variables d'états, les acti ons et les transitions. Cependant, nous allons spéc ifier les
représentations de trois activités. Pour les autres activités, nous allons les donner en annexe
(Annexe A).
69
E ll e est utili sée pour recevoir des requêtes d 'exécution du processus (service
composé). La requête en question constitue le message d 'entrée dans le processus.
Lors de la réception d'un message SOAP, on vérifie le type du message pour savoir si
ce dernier correspond au type prédéfini dan s le processus. Si c'est le cas, on initi alise une
variab le messageRecu pour indiquer le fait qu 'on a reçu le message afin de déclencher une
tran sition. Le tabl eau 1.1 mo ntre les diffé re nts éléments de représentation de l' activité
Les règ les de transition pour l' in vocati on • (etat Var debut_invoke ET
--
synchrone ex i s t(inV ar))~ (etatVar = wait)
• (etatVar = wait) -7 (etatVar =
fin_ invoke ET ex ist(outV ar))
L 'envo i de messages entre le service co mposé et les services de base dépend de trois
paramètres :
L ' impl émentati on de ces modèles dans le cadre des services web se limite à
cert ain s d'entre eu x.
Les activités structurées indiquent l'ordre da ns leque l une coll ecti on d 'ac ti vités est
exécutée. Le flu x de contrôle du processus est décrit par la co mpos iti on des ac tivités de base
en acti vités structurées. On di stin gue les ac ti vités structurées sui vantes :
• Les c hoix non déterminés basés sur des événements externes est
fourni par « pick »
72
Les activités stmcturées sont modé li sées par la combinaison des règles de transiti on
qm expriment le comportement de chaque acti vi té imbriquée (ou inc lu se dans l' ac ti vité
st ructurée) et l'ordre d 'exécuti on de l'e nse mbl e des ac tivités imbriquées. Dans la suite de
cette section, nous allons décrire l'activité stmcturée « while »et les règles ex primant l'ordre
d' exécution . Les autres activités stmcturées seront décrites en annexe A.
L'activité« while »
Cette activité ré pète l' exécuti on d' une act ivité imbriquée qu 'on va des igne r par A. La
figure 4.19 montre le graphe qui la représe nte.
tin A
debu tA
La générati on d ' un processus BPEL se base sur l' arbre d 'exécution de JESS . La
structure de 1'arbre refl ète exacte ment le flu x d'exéc uti on du processus. Pour illustrer cette
correspondance, nous allons pa11ir de l' arbre d'exéc ution de la section 4.3.3 qui représente le
serv ice compos ite de la recherche d'itinéraire en tre deux adresses et co nstruire un arbre
géné ral représentant n' importe que l cas de compositi on.
- -- -- -- - - - - - -- - --
73
..
Tableau 4.3 Le modèle de représentation de l'actJVJté « whlle »
• Les nœuds de type ET qui représentent une conjonction d'une ou de plus ieurs
conditions qui ont été vérifiées et correspondent auss i aux opéra ti ons des
différe nts services impliqués.
Si on parcourt l'arbre du bas vers le haut, on constate qu ' il ex iste 2 ni veau x de nœud s
de type ET. La numérotation de ces ni veaux en partant du bas vers le haut nous donne le
niveau 0 suivi du niveau 1. L'ordre dans lequel les opérations sont invoq uées est l'ordre
inverse des ni veaux; c'est à dire que le niveau le plus faible (0) correspo nd à la dernière
opération qui doit être invoquée par le processus. Et ce lui le plus élevé représente la ou les
premières opérations qui doivent être in voquées. La figure 4.20 générali se le modèle.
74
Niveau N
Niveau 1
Niveau 0
Il faut noter que si le niveau 0 comporte plusieurs nœud s de type ET, cela veut dire que
L 'a lgorithme de géné ration de code peut se déc rire de la façon suivante :
courante
c. Définir les vari a bl es ayant pour types respectifs les types de messages
valeur
76
S. Si toutes les règles du ni veau courant ont été examinées et ell es sont au moins
en no mbre de deux, alors mettre les in vocati ons de ce ni veau dans une acti vité
dans la po1iée du l'instructi on « flow ». Ces in vocati ons peuvent s'effectuer en
parall èle
6. Passer au niveau i + 1
L 'algorithme précédent est récursif et refl ète la structure de l' arbre d 'exécuti on des
règles déc lenc hées lors de l' élaborati o n du pl a n de compos iti on.
La co mpos iti on de services peut conduire parfo is à des résultats incertains lors de la
générati on de pl a ns de compos iti on . Pou r comprendre co mme nt cela peut se produi re,
considérons une entité E ayant trois attributs a, b et c.
Supposons qu 'on a deux services S I et S2 aya nt res pecti ve ment les opérati ons 0 1 et
02 . Si :
alors cela peut nous conduire à des résu ltats incertains (Figure 4.21 ).
77
01 02
03
Si on considèreS 1 comme un service donnant l' adresse d' une personne à partir de son
nom et S2 comme un service donnant le téléphone d ' une personne à partir de so n adresse.
Supposons que plusieurs personnes habitent à la même adresse et possèdent des numéros de
té léphones différents. Si deu x personnes P 1 et P2 habitent la même adresse et aya nt chacu ne
un numéro, alors le service S3 retourne les deux numéros quand on lui demande celui de la
personn e Pl . La raison de ce la est que l'adresse ne permet pas de déterminer de façon unique
le numéro de téléphone ni le nom d'une perso nne.
4.7 Conclusion
expe1ts et de les intégrer dan s 1' infrastructure industri e ll e d' impl é me ntation des services web
pour réali ser un sys tè me de composition de services .
Nous avons utili sé un cycle de composition ité ratif pour répondre au x contraintes de
déve lo ppe ment d 'application s industri e ll es. L 'architec ture du systè me de co mpos iti on repose
sur un modèle ou vert qui permet de greffe r d 'autres outil s pouvant améli ore r la qualité des
services co mposés .
CHAPITRE V
5.1 Introduction
Le prototype réa li sé dan s le cadre de ce travail , nous a permi s de consolider nos idées
sur la mi se en pratique de l'approche mixte et de l'u tilité d'utili ser les standard s des servi ces
web.
Le prototype a été testé sur un ense mble de services web relevant du domaine de
di stribution d'énergie électrique (Hydro Québec). Ces se rvi ces sont utili sés pour re mettre e n
charge le réseau électrique après avoir subi un e panne quelconque, due à une défectu os ité,
d ' un ou plusieurs équipements. L es équipe ments sont nombreu x et variés et leur
comportement évolue au cours de te mps. Le ur fiabi lité dé pend de leur âge . Des déc isions
sont pri ses sur une base périodique pour leur re mpl acement ou leur réparation .
D'autres tests ont été effectués sur les exempl es présentés dans le chapitre 4. Nous
all ons présente r les pl ans sous forme g raphique gé nérés par ces exempl es .
Le prototype a été réali sé en utili sant Ec lipse comme environneme nt de déve loppement
et java (JDK 1.4) comme langage de programmation. Le déploiement des serv ices web sur
lesquel s nous avons ex périmenté le prototype s'est fait sur Axis. Nous avons utili sé son outil
de génération automatique de cli ents à partie des interfaces WSDL (WSDL2Java).
Les services composés seront déployés sur un outil d'IBM, BPWS4J (Business Process
Web Services for Java) qui est un eng in d' exécution de processus BPEL4WS . Cependant, la
80
phase de gé né rati on de code n'est pas te rmin ée, vue 1' ampleur de travai1 de programmati on
ex igé.
Le prototype est déve loppé sous fo rme d' une applicati on we b et sui vant le modèle
MVC (M odel View Controle r) voir fi gure 5. 1
Nous a vons utili sé JESS comme moteur d ' inte rprétati on de règ les de descripti on
sé mantique de servi ces, vo ir chapitre 3.
L 'ensemble de ces outil s ont été dépl oyés sur Tomcat 4. 1. La figure 5.2 montre
J' environne me nt tec hnologique sur lequel le compos iteur est construit.
Ax is [7] est un engin SOAP qui est offert par Apache en «open source». Il a d 'abord
ex isté sous Je nom d ' Apache SOAP. Il a gagné beaucoup d' intérêt auprès de la co mmun auté
des dé veloppeurs de servi ces web. Axi s2, qui est la nouve ll e version, a apporté beaucoup de
nou veautés en termes de déve loppement de servi ces web. Il possède de nombreux outil s
fac ilitant l' implé mentation de services web. Ses principales caractéristiques sont :
• Offre plusieurs modèles d 'éc hange de messages (Message Exc hange Pattern s)
• Supporte SOAP 1.1 et 1.2 et les protocoles HTIP, SMTP, JMS , TCP
En SOAP, les acteurs qui pre nnent part dans un e interacti on de service web sont
appe lés les nœuds SOAP. Il y a en gé néral un émetteur et un récepte ur. Chaque nœud SOAP
est éc rit dans un langage que lconque (J ava, C++ . . .) . Ax is prend en charge tous les aspects de
gesti on de messages et de sécurité. Le déve loppeur intervient dans la gesti on de la logique de
son applicati on qui se trouve avant l' envoi de message par le client et après la récepti on de
message par le récepteur. La fi gure 5.3 montre le modèle de traite ment des messages soap par
Ax is et les ni veaux d' intervent ion d' un déve loppeur.
82
lill lill
Récepteur
API Emetteur Récepteur de
Cli~nt
message
Développeur
Nous so mme parti s d' un ensembl e d 'applicati ons qu e nous avons transformé sous
forme de services web. Ces applicati ons étaient utili sées dans des contex tes différents et par
des acteurs différents. Il fall ait définir l' interface d' interacti on de ces services et identi fier un
sous ensemble de fonctionnalités de chaque application qui seront offertes sous forme de
services web. La partie interface graphique a été éliminée. Nous avons co nsidéré les
différents scenari os d ' utili sati on de chaque service afin d'établir une interface se lon laque ll e
ch aque servi ce devrait être exposé. La définiti on des interfaces d' interacti on d ' un se rvice web
consiste esse nti ellement à spéc ifier comment les requêtes sont reçues et comment les
ac heminer vers la couche de traitement. Dans la fi gu re 5.4, nous avons présenté les deux
couches d' un service web. L ' interface d' interacti on est la couche qui reçoit les requêtes et les
transmet vers la couche de traitement après avoir effec tué un certain prétraitement. La
formulation de la réponse est également assurée par l'interface avant d'être envoyée vers le
83
client. La couche de traitement implémente toute la logique des foncti onn alités offertes par le
service. li s'agit seul ement d' isoler le code de traitement de celui de l'interface graphique.
L' implémentation des différents services sous forme de couches permet de séparer les
responsabilités et de découpler les traitements des app lications dans lesquels il s sont
contenus.
1. Les services servant d'accès à des données qui so nt la plupart de temps lues
mais rarement mi ses à jour;
2. les services qui sont très sollicités par les utilisateurs en apportant des
changements fréquents à des données relatives à la maintenance des
équipements.
L' impl émentati on de services web peut se faire de deux façons différentes :
84
Dans le cas des servi ces de rem1 se en charge, nous avons adopté l'approc he
ascendante parce que nou s so mmes parti s d'applications ex istantes que nous avo ns
transformées en services web. En fait , nou s n'avons pas le choix car la partie
« traitement » des services existe déjà. Nous avons donc utili sé l'outil Java-to-WSDL
pour générer les interfaces WSDL.
Les services de remi se en charge que nous avons implémentés sont en nombre de 4 :
4. Le se rvice des schémas des stations: Il permet d'obtenir la confi guration des
équipeme nts dans une plusieurs stati ons sous forme graphique. Ces sc hémas
stations du réseau .
Connectivity Knowledge
Service Service
Le service de connect ivité permet d 'avoir pour chaque équipeme nt l' e nsemble des
équipements voi s ins auxque ls il est co nnecté. Nous donnon s ci-après un extrait du
descripteur WSDL montrant l' opération qui permet de récupérer la li ste des équipe me nts
voi sin s d'un équipement donné . Pour le desc ripteur détaillé veu ill ez consulter l'annexe B 1.
<wsdl:operation name="getConnectivite">
<wsdl:output message="impl:getConnectiviteResponse"
name="getConnectiviteResponse" 1>
</wsdl:operation>
Le service de disponibilité d' équipe me nts permet d'obte nir la li ste des équ ipements
non disponibles pour une remi se en charge du réseau . La desc ription WSDL de l'opération
d'accès à l'état d ' un équipement (disponib le ou no n) est donn é ci-après. La desc ription
detaillée du service est donnée dans l'annexe B2.
<lwsdl:operation>
D ans cette section , nous all ons donner la li ste des règles qui modéli sent la sémantique
de co mpos iti on de serv ices de rétabli ssemen t du réseau de distributi o n d'énergie.
(Network ?X)
87
=>
(Network ?X)
=>
(defrule KnowledgeService.KnowledgePort.getAIIKwEquipments
(Network ?X)
=>
(Network ?X)
88
=>
(defrule PlanningService.PianningPort.getNetworkPian
(Network ?X)
=>
(Network ?X)
89
(Station ?Y)
(Contains ?X ?Y)
=>
• « Station » est l' entité qui possède un e nse mbl e d' équipe me nts
• « Knowledge » est l'entité qm contient l'e nse mbl e des règ les de
gestion de la re mi se e n c harge d ' un réseau
• « Avai lability » est l' e ntité qui cont ient une li ste d' équipe men ts
indisponibles.
• « Con nectivity » est !;entité qui conti ent une li ste d 'équipements avec
leurs voisins respectifs. E ll e sert à propager le rétabli ssements des
équipements d'une station à l' autre
90
L 'ense mbl e des entités précéde ntes utili sent les différents obj ets représe ntant les types
d 'équipe ments. La figure 5.6 donne les différents types d' équipe ments
Figure 5.6 les différents objets d'équipements co nstitu ant les e ntités des règ les des
services web de remi se e n charge
Dans la secti on précédente, nous avons présenté les règ les représentant les serv1ces
web de remi se e n charge. Dans cette secti on, nous présentons le résultat d 'exécuti on de ces
règles.
Pour un réseau A dont on donne le no m, on veut trouver les in structi ons qui permettent
de rétablir le réseau à un mo ment donné. Le résultat est le graphe correspondant au plan de
composition (Figure 5.7)
91
SchemaServiœ.SchemaPortKnowledgeService .KnowledgConnectivityService.ConnecAvailibilityService.AvailibilityPort.getAIIAvEquipments
PlanningServlce.PianningPort.getNetworkPian_l
Figure 5.7 Le graphe de co mpos iti on des services de remi se en charge du réseau
Le service de rec herche d ' itinéraire entre 2 domicil es de 2 perso nnes (donné au
chapitre 4) est représenté par le graphe de la fi gure 5.8
92
\
drivlngDirections.PT2.op2_1
{1 Dooe
Figure 5.8 Le graphe de co mpos iti on des services de rec he rche d ' itin éraire
5.8 Conclusion
La géné rati on des graphes de co mpos iti on est une étape importante du processus de
compos ition de services. N ous avons montré par la réa li sati on de ce prototype qu ' il est
poss ible de réaliser un système de co mpos iti on utili sant un système à base de conn aissances
et les stand ard s des services web industriels.
,-
1
CHAPITRE VI
CONCLUSION
L'objec tif principal du travail présenté dan s ce mémoire est le déve loppe ment d' un
outil de composition. La so lution que nous avons élaborée met en œuvre les standards des
services web et les méca ni smes des systèmes à base de règles . L ' utili sation de WSDL comme
outil de description de services et so n enrichi sse ment par le modèle de règles a permis de
remédier à plu sieurs problèmes relatifs à la composition dynamique de services.
L'approche mixte regroupe plusieurs concepts qui ont été implé mentés grâce à
l' utili sation de JESS. Ce dernier a facilité l' ex ploitation de la structure d 'exécution des règles
pour l'extracti on des informations de gé né rati on de pl ans de composition. Cette structure est
utili sée aussi pour la gé né ration du code BPEL en faisa nt une tran sposition des règles
exécutées en termes d'invocations d 'opération s des services impliqués lors d' une requête de
composition d'un service.
L'analyse que nous avons effectuée sur les solutions existantes pour la composition de
serv ices nous a montré les aspects les plu s importants de la problématique de composition.
Ce qui nous permis de faire des choix appropriés pour atteindre l'objectif principal que
94
vouli ons atteindre da ns le cadre de ce trava il à savoir une approche de compos iti on
pragmatique.
Notre soluti on est caractéri sée p ar l'utili sati on de l' infrastructure de services web auss i
bie n au ni veau des sta nd ard s utili sés qu 'au ni veau des outil s de déve loppement. L 'apport de
JESS pour la modéli sati on de la compos iti on par des règles est incontestabl e. Son utili sati on
offre une fl ex ibilité accrue pour le concepteur des connaissances de la compositi on de
se rvices
Plusie urs idées de l'approc he mi xte peu ve nt être étendues pour consoli der le modè le de
co mpos ition :
• L ' utili sation d' un modè le d ' in vocati on dyna mique permettra de découpler les
application s cli entes des services. Ce modèle peut être impl émenté sous-forme
d ' un médi ateur e ntre les cli e nts et les services de tell e sorte que les
c hange ments apportés a ux services n'entraînent pas des modificati ons sur les
clie nts.
• L ' utili sati on de la logique fl oue au mveau des règles représentant les
opé rati ons des services peut a mé li orer la qualité des pl ans de compos iti on
générés. Ain si, le cho ix des règles à exécuter sera fait sur des critè res
qu alitatifs relati fs au do maine traité ou à la fi abilité des services modé li sés .
• L' utili sati on d' un ann ua ire offra nt un systè me de class ificati on de services
permettant de retrouve r ces derni ers plus fac il e ment aidera les util isateurs ou
les déve loppeurs dans leurs rec he rc hes. UDDI, à notre sens, n'est pas suffisant
car il ne prend pas co mpl èteme nt e n compte l'organi sati on sé ma ntique des
services. Les ontologies peuvent ê tre une bonne piste à ex pl orer.
• Le modèle de règles pour la représentation des opérations peut être enric hi afin
de prendre e n charge le traitement des exceptions et la gestion des services
transactionnels. Ceci peut par exemple se faire par l'association aux opérations
d'une règle traitant les exceptions et/ou les transactions.
APPENDICE A
Elle affecte de nouvell es données au x vari ables défini es dans le processus pend ant
l' exécuti on de ce dernie r.
Les vari ables d 'états inV ar,outV ar, etatVar = debut_ass ign,
fin_a ssign}
Elle permet de capter les cas d'excepti on ou d'erreurs afin d'entreprendre des acti ons
de recouvrement.
Elle suspend l' exécuti on du processus pour un e certa ine péri ode de te mps ou jusqu 'à
ce que un temps donné (date, heure) est atteint.
Les vari ables d 'états etatV ar= {debut_wait , fin _wa it}
Il faut noter que le temps n'est pas pris en considération dans ce modèle
97
Un e ac ti vité «sequence» peut comporter n ac ti vités de base dans sa portée qui vo nt être
exécutées dans un ordre séquenti el si les conditi ons d'exécuti ons so nt vérifi ées. Si on définit
1' ensemble des acti vités imbriquées par {Ai), on a alors le modèle sui va nt
fin An -7 fin_sequence
Cette activité choisit une branche parmi les n activités {A 1, ... ,An) et une autre
branche pour le cas otherwise correspond à l'activité An+l. Une activité Ai transforme l'état
etatAi en l'état finAi
Cette activité exécute toutes les activités de base se trouvant dans sa porté. On désigne
par {AI ,.. ,An) l' ense mble de ces activités. Chaque acti vité Ai possède une variable d' entrée
et une variable de sorti e inVari et outVari. Son modele est donné dans le tab leau sui vant :
Cette activité permet de bloquer l'exécution du processus jusqu 'à ce qu ' un message
arrive ou une alarme de dépassement de temps maximal est signalée. On est en prése nce d' un
cas d'i ndétermini sme car on ne sait pas à l'avance quelle est la proc haine branche à sui vre.
Les activités {AI,A2, .. . ,An} correspondent à ces branches. Son modèle est donné dans le
tableau suivant :
100
<schema targetNamespace="urn:recre"
xmlns="http://www.w3.org/2001/XMLSchema">
<complexContent>
<restriction base="soapenc:Array">
</restriction>
<lcomplexContent>
<lcomplexType>
<complexContent>
<restriction base="soapenc:Array">
</restriction >
<lcomplexContent>
<lcomplexType>
</schema>
<schema targetNamespace="http://xml.apache.org/xml-soap"
xmlns="http://www.w3.org/2001/XMLSchema">
<complexType name="Vector">
<sequence>
</sequence>
<lcomplexType>
</schema>
<schema targetNamespace="urn:recre.BeanService"
xmlns="http://www.w3.org/2001/XMLSchema">
<complexType name="EquipementBean">
<sequence>
103
</sequence>
<lcomplexType>
</schema>
<lwsdl :types>
<wsdl:message name="getConnectiviteResponse">
<Wsdl:part name="getConnectiviteReturn"
type="impl :ArrayOf_tns î _ EquipementBean" 1>
<lwsdl :message>
<lwsdl:message>
<lwsdl:operation>
<wsdl:operation name="getConnectivite">
<wsdl:input message="impl:getConnectiviteRequest"
name="getConnectiviteRequest" 1>
<lwsdl:operation>
<lwsdl:portType>
<wsdl:binding name="EquipementServiceSoapBinding"
type="impi :Chargement">
<Wsdl:input name="mainRequest">
<lwsdl:input>
<wsdl:output name="mainResponse">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="urn:recre" use="encoded" 1>
105
<lwsdl:output>
</wsdl:operation>
<wsdl:operation name="getConnectivite">
<wsdl:input name="getConnectiviteRequest">
<lwsdl:input>
<wsdl:output name="getConnectiviteResponse">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encodingl"
namespace="urn:recre" use="encoded" 1>
<lwsdl:output>
<lwsdl:operation>
</wsdl:binding>
<wsdl:service name="EquipementService">
<wsdl:port binding="impi:EquipementServiceSoapBinding"
name="EquipementService">
<lwsdl:port>
</wsdl :service>
106
<lwsdl:definitions>
<schema targetNamespace="urn:wsc.etat"
xmlns="http://www. w3.org/2001 /XMLSchema">
<complexType name="ArrayOf_soapenc_string">
<complexContent>
<restriction base="soapenc:Array">
</restriction>
<lcomplexContent>
</complexType>
107
<complexContent>
<restriction base="soapenc:Array">
</restriction>
<lcomplexContent>
<lcomplexType>
</schema>
<lwsdl:types>
<wsdl:message name="getEtatEqpResponse">
</wsdl :message>
<wsdl:message name="mainRequest">
<lwsdl:message>
<lwsdl:operation>
<lwsdl:portType>
<wsdl:operation name="main">
<wsdl:input name="mainRequest">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace=" http://etat" use="encoded" 1>
</wsdl:input>
<wsdl:output name="mainResponse">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="urn :wsc.etat" use="encoded" 1>
109
<lwsdl:output>
<lwsdl:operation>
<wsdl:operation name="getEtatEqp">
<lwsdl:input>
<wsdl:output name="getEtatEqpResponse">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="urn:wsc.etat" use="encoded" 1>
</wsdl:output>
<lwsdl:operation>
<lwsdl:binding>
<wsdl:service name="EtatService">
<lwsdl:port>
<lwsdl:service>
<lwsdl:definitions>
Bibliographie
[ 1] W eb Service Compositi on - Current So luti ons and Ope n Proble ms. Bi pl av Srivasta va
Jana Koe hl er 2004, http://www .zurich.ibm.co m/pdf/ebi zz/ic aps-ws. pdf
[2] Service-Ori e nted Composition in BPEL4WS Rani a Kh alaf, Nirmal Mukhi ,Sanjiva
W eerawa ra na 2003 ,
http ://ww w .uni zh .c h/home/mazzo!reports/www2003conf/ papers/P7 68/p 7 68-kha 1af. pdf
[3] we b services orc hestration Chris Peltz He wl ett Pac kard , Co . January 2003
[4] A De veloper Toolkit for W eb Service Compositi on . Shankar R .P onne kanti and Armando
Fox 2002, http ://www2002.org/CDROM/altern ate/7 86/
[5] Java Expert System Shell (Jess) . http ://herzberg.ca.sandi a .gov/j ess/.
[8] A surve y of middleware, di scovery & compositi on tec hnologies to aid in goal of
di stributed service composition in a pervas ive environme nt. JON ROBINSON, 2006,
http://www .cse.unsw. edu .au/- jyu/ieee-ic/UI_Integration.pdf
[9] Se mi-auto matic Composition of Web Se rvi ces usin g Se mantic Descripti ons, 2004,
http://www .mind swap.org/papers/compositi on.pdf
[Il] web services orchestration . Chri s Peltz He wlett Packard January 2003
[ 13] OASIS . UDDJ 3.0.2. spec ificati on http://uddi .org/pubs/udd i- v3.0.2-?004 10 19. htm
[14] Adaptative and Dynami c Service Compos iti on in eFlow . Fabio casati , Ski Ilni ck i, LiJie
Jin . HP marc h, 2000
[ 15] web services orchestration . Chris Peltz. HP, Co. January 2003
[ 17] web servi ce composition. Sateya Sanket Sahoo. University of Georgia 2004
[ 19] Adapting Go log for se mantique web serv ices. S. M ac llraith , T.Cao Sun
[32] desc ribe busin ess process actiVIties as web se rvi ces.
http://www. javaworld .com/ javaworld/j w- l 0-2005/ jw- 103 1-webse rvices- p2. html. Ash
parikh , vivek kondur 2005.
[33] Pl<engine: A System for Automated Service Compositi on and Process Enactment.
Harald Meyer, Hagen Overdick , andMathiasWeske, Dr.-Helmert-Strasse 2-3, 14482
Potsdam, Germany
[35 ] Future e-business solutions : To p Down or Bottom Up? Tec hno logical vs Business
Dri ve n Approach to e-Business. J yrki Haaj anen 2004
[40] Tools for Design of Compos ite We b Services. Rich ard Hull , Ji anwe n Su 2006
[42] Wh at is Wro ng With Web services discovery. Dieter Fense l, Uwe Ke ll er 2005
[45] UML Modelling of Automated Business Processes with a Mapping to BPEL4WS. Tracy
Gardner
] 12
[50] Imple mentin g Service Oriented Architecture with Apache Axis2 and We b Services. Paul
Fremantle 2006
[51] The Java Web Services Tutori al. Sun Mi c rosystems 2005
[52] A planner for composing services desc ribed in DAML-S. ln Work shop on Web se rvices
And Agent-based engineerin g, M . Sheshagiri, M. desJardin s, and T. Finin. 2003.
[53] Artificial Intelli gence & Software Engineering. Derek Parterid ge 199 1
[55] Web Services Composition (An Al-based Semantic Approach). Satya Sanket Sahoo
2004
[57] Sélection et Optimi sation pour la Composition de Services Web. Danie la Barreiro
Daniela Barreiro Claro. 2006
[59] Service Compositi on with Semantic Web Service.Mark Burstein , Christoph Bussler.
Proceeding 2005