Aujourd’hui, les services web se sont impos´es en tant que standard de facto dans le domaine du g´enie-logiciel. Mais malgr´e les avanc´es spectaculaires r´ealis´ees par cette technologie, certaines difficult´es et d´efis demeurent r´esiduels. Cette section comporte une discussion qui passe en revue certaines questions inh´erentes `a cette technologie, et qui constituent actuellement des th´ematiques de recherche tr`es actives.
2.7.1
La prolif´eration des standards
Le principe fondateur de la technologie des services web est la standardisation qui est la pierre angulaire de toute l’architecture SOA. Cette standardisation est exi- g´ee `a diff´erents niveaux de la couche protocolaire de la figure 2.1. Pour garantir le contrˆole de ces normes, les organismes internationaux et consortiums (W3C, OMG, OASIS,. . . ) ont pour mission de valider et de contrˆoler l’´evolution des diff´erentes normes propos´ees. N´eanmoins, la prolif´eration grandissante de ces standards risque de compromettre le principe lui mˆeme, et d’engendrer, par l`a mˆeme, l’effet inverse de ce qui est vis´e par la normalisation. L’exemple le plus frappant est celui des normes de s´ecurit´e pour lesquelles, au moins, une dizaine de standards est propos´ee ; d´esi- gn´ees par l’acronyme WS-*, tels que : WS-Security [70], WS-Privacy [71], WS-Trust [72], WS-Secureconversation [73], WS-Policy[74], WS-Federation [75], . . . . Cependant, ces protocoles n’arrivent pas `a s’imposer vue l’absence de consensus de la part des diff´erents acteurs.
Le constat pr´ec´edent est aussi valable dans le contexte de la composition des ser- vices web, o`u il est observ´e qu’une panoplie de langages de composition est propos´ee, par exemple : WSFL [76], WSCI [77], WSCL [78], BPEL [54], . . . .
CHAPITRE 2. LES SERVICES WEB ET LES PROTOCOLES DE SERVICES
2.7.2
Les services web s´emantiques
La tendance des services web s´emantique [32] a stimul´e beaucoup d’engouement chez les chercheurs et les industriels pour la d´ecouverte, la s´election et l’invocation de services publi´es, sur la base de crit`eres s´emantiques. Certains travaux envisagent mˆeme la composition automatique bas´ee sur la s´emantique [79, 80, 81]. L’objectif vis´e par les environnements des services web s´emantiques est de permettre la prise en charge des besoins sp´ecifiques des utilisateurs par des ordinateurs au lieu des humains. Ils projettent d’automatiser d’une mani`ere transparente, une grande vari´et´e des processus m´etiers sur le web, le plus rapidement et le plus efficacement possible [33]. Toutefois, les services fond´es sur la s´emantique ne sont gu`ere adopt´es ni utilis´es concr`etement. Comme il y a peu d’exemples r´eels qui d´emontrent les possibilit´es et les avantages de ces services. En outre, il y a un manque de cadres de cr´eation de services et de plates- formes techniques ad´equates qui sont capables de guider et de promouvoir l’ing´enierie simple, flexible, rapide et unifi´ee des services fond´es sur la s´emantique. En r´ealit´e, les plates-formes actuelles des services web s´emantiques ne prennent pas vraiment en charge la construction des services web s´emantiques ”intelligents et auto-composables” et elles demeurent limit´ees `a de simples annotations s´emantiques des services web ou `
a des int´egrations et des utilisations rudimentaires de quelques concepts associ´es `a des ontologies [82].
2.7.3
Le gestion des contraintes fonctionnelles et non fonc-
tionnelles
Bien que beaucoup de standards ont ´emerg´es durant la derni`ere d´ecennie pour la sp´ecification des techniques permettant la prise en compte des diff´erents phases du cycle de vie des services web, la majorit´es des approches propos´ees se focalise en grande partie sur les contraintes fonctionnelles des services web (publication, d´ecouverte, s´e- lection, interaction, . . . ). Par contre, les contraintes non fonctionnelles, telles que les param`etres de qualit´e des services QoS [83, 84, 85] (performance, cout, fiabilit´e,. . . ), ou la s´ecurit´e et l’administration des services, n’ont pas b´en´efici´e de tout l’int´erˆet qu’elles revˆetent. En effet, bien que ce type de contraintes exprime les garanties et les conditions auxquelles le client doit se confirmer durant les diff´erentes phases du processus d’interaction avec le service d´esir´e (d´ecouverte, s´election, invocation, com- position), peu de standards ont ´et´e propos´es pour leur prise en charge, et mˆeme ceux propos´es n’ont pas encore atteint un niveau de maturit´e qui les rend op´erationnels de fa¸con effective.
A titre d’illustration, il est constat´e une absence de mod`eles standards pour la sp´ecification des m´etriques de qualit´e de service, et mˆeme ceux qui sont en cours de gestation ne sont pas encore support´es par la structure actuelle du registre UDDI. Comme cons´equence directe, une grande partie des travaux de recherche autours de cette probl´ematique [86,87,88, 89] convergent vers des propositions de remaniements et des extensions de cet annuaire afin de permettre la prise en compte des contraintes non fonctionnelles.
CHAPITRE 2. LES SERVICES WEB ET LES PROTOCOLES DE SERVICES
2.7.4
La repr´esentation des protocoles et les transformations
de mod`eles
Au niveau conceptuel, diff´erents mod`eles dot´es de niveaux d’expressivit´e vari´es ont ´et´e propos´es dans la litt´erature pour repr´esenter les protocoles des services web. Certains sont formels [10,11,52,65], alors que d’autres sont plutˆot graphiques. Dans cette sph`ere, certaines approches proposent mˆeme des techniques de r´etro-engineering pour rehausser le niveau d’abstraction, en transformant des programmes ´ecrit dans des langages sp´ecifiques vers des mod`eles plus abstraits [90, 91]. Vue la diff´erence du niveau d’expressivit´e des diff´erents mod`eles propos´es, et pour tenir compte des besoins sp´ecifiques des utilisateurs qui se sont familiaris´es avec une cat´egorie donn´ee de mo- d`eles, toute une panoplie de techniques de transformation entre les diff´erents mod`eles (d’un mod`ele source vers un autre mod`ele cible) a ´et´e propos´ee dans la litt´erature de recherche et des outils de passage inter-mod`eles ont ´et´e ´elabor´es (voir par exemples [92, 93, 94] ).
Nous estimons que les mod`eles formels (e.g : automates, r´eseaux de Petri ) restent les plus ad´equats pour une repr´esentation efficace des protocoles des services web, puisqu’ils sont dot´es d’une assise th´eorique solide. En plus, ils peuvent ˆetre soumis `a des techniques de v´erification de mod`eles (model-checking) [95].
2.7.5
Evolution, adaptation et flexibilit´e des services web
Dans les environnements service web, les applications et les syst`emes d’informations peuvent ˆetre construits en int´egrant diff´erents services h´et´erog`enes provenant de divers fournisseurs. Cependant, comme les services utilis´es sont assujettis aux changements qui sont dˆus `a l’´evolution des lois et r´eglementations, la gestion de l’´evolution des services et l’analyse de l’impact du changement sont des questions d’actualit´e qui ont fait l’objet de travaux de recherche tr`es intenses. Ainsi, pour faire face `a cet enjeu qui caract´erise les syst`emes logiciels plusieurs approches ont ´et´e propos´ees, et chacune se focalise sur un aspect particulier du probl`eme, entre autres : l’actualisation de l’interface du service, les changements dans les param`etres non fonctionnels et l’´evolution du comportement des protocoles du service [96, 97, 98]. Cette derni`ere question sera abord´ee en d´etails dans les prochains chapitres (Chap. 3 et 4).