Web Services:
faut-il tenter l'aventure ?
Par le JDNet
Solutions (Benchmark Group)
URL : http://www.journaldunet.com/solutions/0207/020711_webservices.shtml
Jeudi 11 juillet 2002
Objet d'intérêt particulièrement
vif dans les entreprises, figurant parmi les sujets de prédilection
des analystes ces derniers mois, les Web Services semblent maintenant
avoir dépassé le stade de l'effet d'annonce pour se
positionner comme notion d'avenir. Pour autant, la perception de
celle-ci reste particulièrement floue, et deux questions
restent en suspens pour les directions informatiques, au delà
des interrogations techniques: d'une part, est-ce bien nécessaire
? d'autre part: est-ce le bon moment ?
Direction générale ou direction informatique ?
Avant d'apporter des éléments de réponse à
ces deux questions, il est sans doute nécessaire de distinguer,
dans ces fameux Web Services, ce qui est de l'ordre du service et
ce qui est de l'ordre de l'applicatif logiciel. Car c'est là
que le bât blesse, finalement: il serait une erreur de présenter
les Web Services comme des services - soient, en tant que tels,
des éléments de l'offre d'une entreprise dont il n'appartient
pas à la direction informatique de décider de les
fournir aux clients. Présenter les Web Services comme une
méthodologie nouvelle pour délivrer du service est
déjà plus proche de la réalité, mais
trompeur, car nous parlons ici de service applicatif, donc de logiciel.
Jean-Marie Chauvet, dans son livre: "Services Web avec SOAP,
WSDL, UDDI, ebXML", insiste sur l'idée de "logiciel
considéré comme service"... preuve qu'il s'agit
bien d'abord de logiciel, et donc, en dernière analyse, de
choix effectués par la direction informatique (dois-je ou
non délivrer du service par tel moyen technique, ou par tel
autre ?). Ensuite, seulement, viendra l'examen des nouveaux services
que le chantier des Web Services offrira l'opportunité de
lancer.
Trois chantiers
Déployer
un Web Service, c'est rendre accessible, via le réseau
Internet, une fonctionnalité (ou éventuellement un groupe
de fontionnalités) d'une application quelle qu'elle soit (client-serveur,
bâtie avec un serveur d'application
). Pour cela, trois chantiers
sont nécessaires:
- le chantier de la "publication", sous un format standardisé
(WSDL, soit du XML), des services (fonctionnalités) que peut
rendre l'application;
- le chantier de l'accès à distance au service applicatif,
effectué dans le cadre des Web Services grâce au protocole
SOAP, qui combine XML pour la description des messages entre l'application
qui joue le rôle de client (invoquant le service) et l'application
qui joue le rôle de serveur (dont une portion du code est
exécutée à distance, délivrant le service),
et (notamment) le protocole HTTP. Les messages XML sont deux types:
un message contenant les paramètres d'invocation du service,
un message contenant les données en sortie après exécution
à distance du service (soit de la portion de code correspondante
- ou procédure). Ce chantier, très concrètement,
consiste au développement d'une API (Application Programming
Interface) tirant profit de WSDL et de SOAP;
- le chantier, enfin, du référencement des Web services
déployés, au sein d'un annuaire comme UDDI par exemple.
Ces trois chantiers correspondent à l'utilisation des Web
Services comme vecteur de collaboration inter-entreprise, mais dans
la pratique, le deuxième de ces chantiers risque fort de
concentrer la majorité des efforts de déploiement
autour des Web Services, car il répond, à lui seul,
à la problématique la plus demandée (pour l'instant
du moins) par les entreprises: l'intégration inter-applicative,
dans l'entreprise elle-même (et non avec ses fournisseurs
ou partenaires).
Combiner interopérabilité interne et externe
La
question qui se pose est donc, dans un premier temps: pourquoi "remplacer"
mon modèle "traditionnel" d'intégration à base de composants
(ces briques logicielles qui transportent sur les réseaux la logique
applicative) par un modèle d'intégration à base de
"services". Deux réponses à cela. La première
repose sur les atouts technologiques des web services: l'intégration
apparaît moins "lourde", non véritablement
en termes de développement, mais surtout en terme d'infrastructure
(les Web Services utilisent les protocoles internet pour le routage
inter-applicatif).
Deuxième réponse: l'intégration basée
sur les Web Services à l'avantage d'être complémentaire
de l'intégration basée sur un modèle "objet",
dans le sens ou la première n'implique pas l'abandon de la
seconde.
En conséquence, le problème est ramené à
la question de savoir si l'intégration basée sur les
Web Services va permettre à l'entreprise d'aller plus loin
que l'intégration elle-même. Si la réponse est
oui (que l'entreprise ait ou n'ait pas déjà un middleware
d'intégration) alors le choix des Web Services est, de notre
point de vue, véritablement judicieux.
En effet, outre que les principales briques technologiques des Web
Services sont aujourd'hui arrivée à maturité
(et notamment SOAP) - et même s'il existe une incertitude
quant au modèle de sécurité associé
-, ces briques possèdent également l'avantage de constituer
des standards ouverts. Cela signifie, pour ne prendre que quelques
exemples:
- que l'on peut envisager d'utiliser des logiciels libres pour déployer
des Web Services,
- que les Web Services combinent à la fois la variété
d'utilisation en interne (par nature, étant un moyen général
de décrire une ou des fonctionnalités d'une application,
ils ne sont pas limités à telle ou telle catégorie
de fonction, mais peuvent répondre à n'importe quel
besoin applicatif - Intranet, Extranet, Internet) et la variété
d'utilisation sur des projets impliquant des partenaires (les standards
ouverts favorisant la diffusion de la technologie).
En d'autres termes, les Web Services offrent une plus grande probablité
de passage réussi de l'intégration intra-entreprise
d'aujourd'hui à l'intégration inter-entreprise de
demain. Quant à savoir si le chantier des Web Services doit
être mené à bien dès à présent,
malgré l'investissement moyen évalué, selon
Benchmark Group à partir de projets actuellement en cours
ou déjà menés à terme en France, à
environ 100 000 euros, malgré l'adoption moins massive que
prévu d'une technologie comme XML, malgré la nécessité,
à terme, de modéliser des procédures métier
impliquant plusieurs Web Services... on
peut avancer que l'alternative technologique la plus souvent citée,
en matière spécifiquement d'intégration B2B,
apparaît avant tout comme une solution transitionnelle, puisqu'il
s'agit... d'ebXML. On en revient toujours au mêmes fondements.
[Jérôme Morlon, JDNet]
Pour tout problème de consultation, écrivez au Webmaster
Copyrights
et reproductions . Données
personnelles
Copyright 2006 Benchmark Group - 69-71 avenue Pierre Grenier
92517 Boulogne Billancourt Cedex, FRANCE
|
|
|