1. Services Web avec J2EE et .NET Conception et implmentations
Libero Maesano Christian Bernard Xavier Galles Le
2.
3. CHEZ LE MME DITEUR Ouvrages sur XML A. MICHARD. XML :
langage et applications. N9206, 2e dition 2000, 400 pages. D.
HUNTER, et coll. Initiation XML. N9248, 2000, 850 pages. K.
WILLIAMS et al. XML et les bases de donnes. N9282, 2001, 1 100
pages. F. BERQU, S. FREZEFOND, L. SORRIAUX. Java-XML et Oracle.
E-Commerce EAI Portails dentreprise Applications mobiles. N9149,
2001, 650 pages + 2 CD-Rom. D. CARLSON. Modlisation dapplications
XML avec UML. N9297, 2002, 324 pages. Ouvrages Java ou .NET P.
HARRISON, I. MC FARLAND. Tomcat par la pratique. N11270, 2003, 560
pages. J. GOODWILL. Jakarta Struts. N11231, 2003, 354 pages. E.
ROMAN, S. AMBLER, T. JEWELL. EJB fondamental. N11088, 2002, 626
pages. K. AVEDAL, et coll. JSP professionnel. Avec sept tudes de
cas combinant JavaServer Pages, JDBC, JNDI, EJB, XML, XSLT et WML.
N9247, 2001, 950 pages. S. ALLAMARAJU et al. Programmation J2EE.
Conteneurs J2EE, servlets, JSP et EJB. N9260, 2001, 1 260 pages. G.
LEBLANC. C# et .NET. N11066, mai 2002, 800 pages. D. APPLEMAN. De
VB6 VB.NET. N11037, mars 2002, 500 pages. T. PETILLON. Cahier du
programmeur ASP.NET. Infrastructure Web dune PME avec ASP.NET.
N11210, 2003, 200 pages. E. PUYBARET. Cahier du programmeur JAVA.
Premires applications professionnelles en Java. N11272, 2003, 240
pages. O. DAHAN, P. TOTH. Delphi 7 Studio N11143, 2003, 816
pages.
4.
5. DITIONS EYROLLES 61, bd Saint-Germain 75240 Paris Cedex 05
www.editions-eyrolles.com Le code de la proprit intellectuelle du
1er juillet 1992 interdit en effet expressment la photocopie usage
collectif sans autorisation des ayants droit. Or, cette pratique
sest gnralise notamment dans les tablissements denseignement,
provoquant une baisse brutale des achats de livres, au point que la
possibilit mme pour les auteurs de crer des uvres nouvelles et de
les faire diter correctement est aujourdhui menace. En application
de la loi du 11 mars 1957, il est interdit de reproduire
intgralement ou partiellement le prsent ouvrage, sur quelque
support que ce soit, sans autorisation de lditeur ou du Centre
Franais dExploitation du Droit de Copie, 20, rue des
Grands-Augustins, 75006 Paris. Groupe Eyrolles, 2003, ISBN :
2-212-11067-7
6. Mise en page : TyPAO Dpt lgal : septembre 2003 N dditeur :
6890 Imprim en France
7. Isabella et Ariele-Paolo Catherine et Guillaume
Florence
8. Remerciements Nous avons eu, au cours de la rdaction de cet
ouvrage, des changes fructueux avec Florian Doyon, Guillaume
Dauvergne et Lionel Roche : leurs avis techniques pointus, toujours
accompagns dencouragements sympathiques, nous ont t bien utiles.
videmment, la responsabilit du contenu de louvrage, et des erreurs
ventuelles que lon pourra y trouver, incombe uniquement aux auteurs
! Les discussions amicales avec rik Bukk sur les applications
possibles de la technologie et son impact sur les systmes
dinformation nous ont permis de bncier de sa comptence et de son
exprience pour conforter ou adapter notre point de vue. Claude
Amenc a ds le dbut encourag moralement notre projet et uvr pour le
dveloppement des services Web lorsque la signication du terme tait
encore inconnue de la plupart des dcideurs. Muriel Shan Sei Fan,
des ditions Eyrolles, a t un diteur (devrait-on dire ditrice ?)
enthousiaste et volontaire. Elle nous a soutenus sans faille tout
au long de la tche, qui sest nalement rvle dune ampleur suprieure
aux prvisions. En plus du professionnalisme, toute lquipe
dEyrolles, et notamment Muriel, Anne Garcia et Sophie Hincelin, a
fait preuve de beaucoup de gentillesse et de patience avec des
auteurs pas toujours lheure. Enn, nos familles ont support
stoquement les soires, dimanches et vacances que nous avons passs
sur les claviers : cet ouvrage leur est ddi. Christian Bernard
Xavier Legalles Libero Maesano
27. Avant-propos Quel est lobjectif de louvrage ? La premire
ambition de cet ouvrage est de fournir au lecteur une prsentation
approfondie des technologies de services Web et de leurs
implmentations en J2EE et .Net. Louvrage couvre les technologies de
base (SOAP, WSDL, UDDI), les technologies dinfrastructure (lchange
able, la scurit, les transactions) et la gestion des processus
mtier. La prsentation est la fois thorique et pratique. Dun ct, les
spcications sont expliques et commentes en dtail. Lide est dessayer
de faire comprendre la logique architecturale qui lie lensemble,
mais aussi les raisons des diffrents choix techniques effectus par
les auteurs des spcications : ces choix sont parfois de lordre du
dtail mais ils ont des consquences importantes sur la mise en uvre
des services Web. Dun autre ct, louvrage prsente la mise en uvre
des technologies de services Web dans diffrents langages de
programmation (essentiellement Java et C#, mais aussi Visual Basic,
Ecmascript, Jscript et Flash) et sur diffrentes plates-formes et
outils (essentiellement J2EE et .Net, mais aussi Internet Explorer,
Mozilla, Ofce XP, Flash). La prsentation est toujours agrmente
dexemples et la dernire partie de louvrage dcrit une tude de cas,
au contenu fonctionnel intuitif, dcline en plusieurs variantes en
termes darchitecture technique et dimplmentation, qui dmontrent les
diffrentes facettes et usages des technologies de services Web.
Tous les logiciels des exemples et de ltude de cas sont excutables
et les codes source sont disponibles en tlchargement libre sur le
site des ditions Eyrolles (http://www.editions-eyrolles.com).
Louvrage ne prsente pas systmatiquement, pour chaque brique de la
technologie des services Web, plusieurs implmentations concurrentes
disponibles (J2EE, .Net, autre plate-forme). Cependant, maintenir
une position de neutralit en traitant des plates-formes
dimplmentation a t une de nos principales proccupations et nous
avons essay de garder, dans la mesure du possible, un quilibre
entre les implmentations sur les diffrentes plates-formes. Par
exemple, pour linterface programmatique UDDI, cest limplmentation
en Java qui est prsente, tandis que limplmentation de la scurit est
prsente essentiellement en .Net (C#). Lavantage (et lobjectif)
essentiel des technologies de services Web tant linteroprabilit,
nous lavons dmontr dans maints cas par la mise en uvre de plusieurs
exemples et de variantes de ltude de cas sur des plates-formes
mixtes. Linteroprabilit empiriquement vriable est aussi une
dmonstration concrte du dcouplage entre une architecture de
services Web et son implmentation logicielle, cette dernire tant
banalise et interchangeable.
28. XXII Services Web La deuxime ambition de cet ouvrage est de
prsenter concrtement les technologies de services Web comme le
support dlection du modle mergent de larchitecture oriente
services. Nous sommes convaincus que les technologies des services
Web vont devenir un vecteur de changement et dautomation des
processus mtier intra et interentreprises. Elles vont aussi changer
les pratiques et le positionnement des professionnels de
linformatique, lintrieur des organisations et sur le march. Nous ne
nous hasardons pas traiter les consquences socio-conomiques de
ladoption de la technologie qui fait lobjet de cet ouvrage. En
revanche, nous essayons de montrer, par la pratique, larchitecture
oriente services comme un nouveau paradigme qui implique un
changement dapproche de la part des informaticiens : changement
dans la relation avec les utilisateurs mais aussi changement dans
la manire de penser, concevoir, dvelopper, dployer et exploiter les
logiciels et les systmes rpartis. Pour mettre en vidence le nouveau
paradigme, la premire partie de louvrage est consacre une
prsentation circonstancie du modle de larchitecture oriente
services. La deuxime partie prsente les technologies de base (SOAP,
WSDL, UDDI). La troisime partie expose les diffrentes plates-formes
dimplmentation (J2EE, .Net, autre). La quatrime partie approfondit
les spcications et les implmentations des technologies
dinfrastructure (abilit de lchange, scurit, gestion des
transactions) ainsi que la mise en uvre des processus mtier par des
langages de scnario (BPEL). La cinquime partie prsente ltude de cas
(un service dagence de voyages implment par agrgation de diffrents
services de rservation), dclin en plusieurs variantes : dune
architecture quasi-statique la mise en uvre en processus mtier
BPEL, en passant par des architectures dynamiques avec UDDI. Une
description plus dtaille du contenu de louvrage, chapitre par
chapitre, est donne au chapitre 1. qui sadresse cet ouvrage ? Cet
ouvrage sadresse : aux dveloppeurs dapplications, et plus
particulirement ceux qui utilisent les environnements J2EE et .Net
; aux architectes des systmes dinformation, qui souhaitent
comprendre les concepts cls de larchitecture oriente services (AOS)
et de sa mise en uvre ; aux dcideurs, consultants, chefs de projets
et spcialistes de lintgration, qui ont besoin dtendre leur capacit
dintervention vers lurbanisation du SI de lentreprise et la prise
en charge de services valeur ajoute ; aux tudiants des coles
dingnieurs et universitaires, qui recherchent une rfrence sur ce
type darchitectures.
29. 1 Introduction La premire difcult laquelle on se heurte
lorsquon aborde le vaste sujet des technologies de services Web est
dordre terminologique. Un exemple, dsormais bien connu, du dsordre
terminologique est le vrai faux acronyme SOAP, qui signierait
Simple Object Access Protocol , alors quil dsigne un protocole
dchange entre applications rparties o il nest nulle part question
daccder des objets . Le dbat a nalement t tranch par le W3C, qui a
dautorit supprim la forme dveloppe du terme SOAP , dont il a
simplement fait un nom propre. Les difcults commencent, vrai dire,
avec le terme mme de service Web (Web service) : George Colony,
fondateur et CEO de Forrester Research Inc., dans sa confrence du
10 mars 2003 au ICT World Forum
(http://idg.net/ic_1211529_9677_1-5041.html) dit propos des
services Web quil nest absolument pas question de services ni de
Web , mais que la dnomination la plus approprie serait celle de
middleware Internet qui permet de connecter les applications des
entreprises celles de leurs clients et partenaires. Il est vrai que
le terme de service est galvaud, que le terme Web voque les sites
Web, et que les deux termes juxtaposs font penser des services pour
le public et les professionnels, pourvus par des sites Web, ce qui
est droutant par rapport au concept de services Web. Tous ceux qui,
comme les auteurs, ont anim des confrences et des prsentations sur
le sujet peuvent tmoigner de la difcult articuler les messages les
plus simples en raison de lusage dtourn de ces termes. Par exemple,
il faut rappeler sans cesse le fait que cette technologie prside
lchange direct des applications entre elles sans la participation
ni lintermdiation des utilisateurs. Cela dit, mme si la proposition
de George Colony a lavantage dtre claire, nous ne sommes pas
entirement daccords avec lui sur deux points : Le terme de
middleware doit tre mani avec prcaution, car il voque le dploiement
dans une architecture rpartie dun ensemble de composants
technologiques cohrents, lments du mme produit. Or, il ny a pas de
produit dployer, mais plutt des spcications de langages de
description (comme WSDL) et de protocoles dinteraction (comme SOAP)
que chacun peut
30. 2 Services Web implmenter, dans son environnement
technique, par des composants logiciels standards ou bien spciques,
propritaires ou bien ouverts. Cest la conformit aux spcications de
ces composants qui permet linteroprabilit des applications,
objectif primaire de la technologie des services Web, et le
middleware en question, autant quon puisse lappeler ainsi, est donc
mis en uvre par linteraction dynamique de composants dorigines
diverses et dimplmentations htrognes. linverse, le terme de service
, bien que souvent employ dans des acceptions plus prcises, reste
pertinent et important. Lutilisation de ce terme permet de
rattacher la technologie des services Web larchitecture oriente
services. Larchitecture oriente services est un concept et une
approche de mise en uvre des architectures rparties centre sur la
notion de relation de service entre applications et sur la
formalisation de cette relation dans un contrat. Larchitecture
oriente services est en principe un concept indpendant de la
technologie des services Web, mais cette dernire reprsente dsormais
son plus important moyen dimplmentation et fournit la base
technologique pour sa diffusion sur une chelle jamais exprimente
auparavant. Le langage WSDL (Web Services Description Language) en
est la technologie pivot qui reprsente le noyau extensible dun
langage de formalisation de contrats de service entre applications.
Ces prcisions faites, en conformit avec un usage dsormais assez
rpandu, nous continuerons appeler les technologies prsentes dans
cet ouvrage, technologies de services Web en sachant que le terme
va rapidement se banaliser comme un nom propre (si ce nest pas dj
fait). Par ailleurs, nous utiliserons aussi le terme de service Web
pour dsigner une application qui joue le rle de prestataire dans
une relation de service et est mise en uvre sur la base de la
technologie des services Web. Cet ouvrage tente de prsenter un
panorama large et organis de ces technologies et de leurs
implmentations en J2EE et .Net, tout en offrant un
approfondissement des problmes fondamentaux poss par leur
dploiement et leur volution, avec la cl des exemples dapplication
et une tude de cas dont limplmentation est dcline en plusieurs
variantes. Louvrage, outre cette introduction et une conclusion est
organis en vingt-cinq chapitres regroups en cinq parties. La
premire partie (chapitres 2, 3 et 4) traite de larchitecture
oriente services. La deuxime partie (chapitres 5, 6, 7, 8, 9, 10,
11 et 12), aprs un rappel des technologies Internet et XML,
introduit les technologies cls SOAP, WSDL et UDDI. La troisime
partie (chapitres 13, 14, 15, 16 et 17) prsente les plates-formes
dimplmentation J2EE et .Net, ainsi que les composants disponibles
sur le poste de travail et traite les problmes dinteroprabilit. La
quatrime partie (chapitres 18, 19, 20 et 21) introduit les
technologies dinfrastructure qui garantissent lchange able, la
gestion de la scurit et la gestion des transactions, ainsi que la
gestion des processus mtier. La cinquime et dernire partie
(chapitres 22, 23, 24, 25 et 26) dcline une tude de cas en
plusieurs architectures conguration statique et dynamique, sur
plate-forme Java et .Net, ainsi que lapplication du langage de
scnarios de processus mtier BPEL. Nous pensons que la matire traite
est sufsante pour donner au lecteur une vision la fois large et
approfondie de larchitecture oriente services et de la technologie
des services Web. Par ailleurs, le dveloppement de la technologie
des services Web avance grands pas et touche des domaines et des
sujets qui ne sont pas traits dans cet ouvrage pour des questions
despace et dunit duvre. Le chapitre de conclusion voque les axes
centraux de consolidation et de dveloppement futur des services
Web, et quelques ides dexploration sur des sujets non traits.
31. Introduction 3 Larchitecture oriente services Nous avons
pris le parti de considrer que la dclinaison du concept
darchitecture oriente services (chapitres 2, 3 et 4) tait le
meilleur moyen pour introduire le cadre conceptuel et la
terminologie utilis dans la suite de louvrage. La technologie des
services Web est donc prsente comme le moyen dimplmentation des
architectures orientes services. La premire partie fournit la cl de
lecture qui permet de comprendre la position et le rle fonctionnel
des diffrents modules technologiques prsents dans la deuxime et la
quatrime partie, ainsi que des implmentations prsentes en troisime
partie. Le chapitre 2 introduit le concept darchitecture oriente
services. Il introduit la relation de service et les rles de
clients et de prestataires jous par les applications participantes.
Il est important de noter que nous avons choisi le terme
prestataire pour marquer une diffrence avec la terminologie des
architectures client/serveur, qui ne sont quune forme spcique et
limite des architectures client/prestataire. Il introduit galement
la notion de contrat, lequel formalise les engagements du
prestataire et ventuellement du client dans la ralisation de la
prestation de services. Un contrat est un document organis en
plusieurs parties, dont les plus importantes sont : la description
des fonctions du service ; la description de linterface du service
; la description de la qualit du service. Le chapitre 2 prsente les
fonctions et linterface dans le contrat de service. Il faut bien
noter la diffrence entre les fonctions et linterface du service :
la description des fonctions est une description abstraite de la
prestation de services, tandis que linterface est une description
des mcanismes et des protocoles de communication avec le
prestataire de services. Naturellement, la comprhension du lien
entre linterface et les fonctions dun service est capitale. Le
problme de la formalisation de ce lien na pas encore de solution
satisfaisante aujourdhui, tout au moins lchelle o ce problme est
pos par la diffusion des technologies des services Web. Si la
description fonctionnelle est abstraite et indpendante de
limplmentation du prestataire, la description de linterface stend
jusquaux dtails concrets comme les protocoles de transport des
messages et les adresses des ports de rception. Le chapitre 3
traite de la qualit de service, cest--dire de lensemble des
proprits oprationnelles (non fonctionnelles) dun service :
performance, accessibilit, abilit, disponibilit, continuit, scurit,
exactitude, prcision La formalisation et la prise en charge
explicite dengagements de qualit de service est de faon gnrale
encore insufsamment, voire pas du tout, traite dans le cadre des
technologies des services Web. La qualit de service va prendre une
importance croissante avec la diffusion darchitectures orientes
services de plus en plus larges et dynamiques. Les engagements de
qualit de service vont constituer un facteur de diffrentiation
importante entre les prestataires fournissant le mme service du
point de vue fonctionnel. Le chapitre 3 se termine par une
discussion des relations entre le contrat de service et la mise en
uvre concrte des applications clientes et prestataires agissant en
conformit avec le contrat. Il tablit notamment la relation entre
les diffrentes parties du contrat et les langages et protocoles des
technologies de services Web. Par ailleurs, lors de la prsentation
(dans les chapitres 2, 3 et 4) de chaque lment du contrat, quil
soit fonctionnel, dinterface ou oprationnel, louvrage renvoie
32. 4 Services Web systmatiquement la technologie de services
Web cense dcrire formellement lengagement contractuel ou bien le
mettre en uvre. Le chapitre 4 traite des architectures orientes
services conguration dynamique. Pour introduire le sujet, il
prsente tout dabord deux gures de la dmarche de conception et de
mise en uvre de larchitecture oriente services : lagrgation de
services ; la dissmination de services. Lagrgation est la
ralisation dun service qui intgre, pour raliser sa prestation, les
rsultats des prestations dautres services. La dissmination est,
linverse, la mise en uvre sous forme de services modulaires des
fonctions dune application monolithique. La conception dune
architecture oriente services est en gnral le rsultat de la
combinaison de ces deux dmarches. Laspect dynamique de la
conguration de larchitecture nest ni secondaire ni accessoire, mais
bien au cur mme du concept darchitecture oriente services (ce qui
nempche pas par ailleurs de mettre en uvre des architectures
orientes services totalement statiques). Dans une architecture
dynamique, les services qui la composent, les applications
prestataires qui interviennent, ainsi quun certain nombre de
proprits oprationnelles des prestations de services ne sont pas
dnis avant sa mise en place, mais sont composs, congurs, tablis,
voire ngocis, au moment de lexcution. Ce processus peut tre itratif
: il est possible de recongurer une architecture dynamique la vole
lors de son fonctionnement normal, ou bien loccasion dun
dysfonctionnement. Avec les technologies de services Web
disponibles actuellement, on peut notamment tablir des
architectures dans lesquelles les applications participantes
peuvent choisir dynamiquement les services abstraits quelles
consomment, les prestataires de ces services, les ports daccs de
ces prestataires. Ltude de cas prsent dans la cinquime partie
articule la mme application rpartie en plusieurs scnarios
darchitectures doues de niveaux diffrents de capacit de conguration
dynamique. Les technologies des services Web La deuxime partie
(chapitres 5, 6, 7, 8, 9, 10, 11 et 12), aprs un rappel des bases
et des fondements (les protocoles Internet et le langage XML)
prsente les trois technologies cls des services Web : SOAP, WSDL et
UDDI. Il est vident que, sans Internet, lensemble des technologies
de services Web ne serait encore quun autre standard de middleware,
un nouveau concurrent de DCOM ou de CORBA. linverse, certains
fournisseurs qui ont un parc important de produits propritaires
installs prtendent que, sur des rseaux locaux ou propritaires, il
est possible de dployer des architectures de services Web qui
nutilisent pas de protocoles de communication Internet, mais des
middlewares patrimoniaux. Cette mouvance dnit un service Web comme
une application dont linterface est dcrite par un document WSDL,
indpendamment de la technologie de middleware utilise pour
interagir avec elle. En revanche, le dploiement de ces mmes
architectures sur Internet impose lutilisation de protocoles
Internet et notamment dHTTP, qui se dtache aujourdhui comme le
premier protocole de transport pour la communication avec les
services Web. Le chapitre 5 rappelle les fondamentaux des
concepts
33. Introduction 5 et protocoles Internet (URI et URL, HTTP,
SMTP, MIME, SSL, TLS) ainsi que le modle de rfrence en sept couches
OSI de lInternational Standard Organisation. Le chapitre 6 est un
rappel indispensable de ce que sont XML et les technologies
connexes comme XML Namespaces, Xlink, Xpath, XML Base, XML Schema
et DOM. Les technologies XML constituent une vritable fondation
pour les technologies de services Web : XML est la base du format
de message SOAP et du langage de description WSDL. XML Namespaces
et XML Schema sont particulirement utilises par les services Web.
XML Namespaces est loutil de gestion des versions et permet de grer
sans conit lassemblage et lextension de technologies et
dapplications dorigines diffrentes. Quant XML Schema, il est spci
demble comme seul outil de dnition de formats XML dans les services
Web. Les DTD nont pas cours dans le monde des services Web : il est
mme explicitement interdit, par exemple, de vhiculer une DTD comme
partie dun message SOAP. Ces rappels sont faits avec le simple
objectif dpargner au lecteur, qui a dj une certaine familiarit avec
la matire, la ncessit de quitter louvrage pour un rappel rapide ou
un renseignement ponctuel et ne remplacent en aucun cas les
ouvrages spcialiss sur le sujet. SOAP, qui est lobjet des chapitres
7, 8 et 9, va invitablement devenir le protocole dchange utilis
pour communiquer avec les services Web, bien quen principe il ne
soit pas le seul protocole admis. Le chapitre 7 introduit les
fondamentaux du protocole (le format de message, le message
derreur, le style dchange message sens unique ) et prsente en outre
rapidement la problmatique des chanes dacheminement (routing) : en
fait, SOAP est basiquement conu pour permettre dinterposer entre
lexpditeur et le destinataire une chane dintermdiaires qui sont,
potentiellement, des fournisseurs de services annexes comme la
scurit et la non-rpudiation. Lutilisation dune chane dacheminement
reste une possibilit qui peut tre mise en uvre comme une extension
propritaire du protocole SOAP (cest loption choisie par Microsoft
avec la spcication WS-Routing) en attendant une spcication du
mcanisme qui puisse aspirer au statut de standard. La dmarche mise
en uvre pour les chanes dacheminement est typique de lapproche
courante du dveloppement des spcications des technologies de
services Web : les spcications de base (SOAP, WSDL) contiennent un
mcanisme standard dextension ; les promoteurs dune technologie de
niveau suprieur (par exemple la abilit des changes, la scurit, les
transactions) utilisent les mcanismes standards dextension pour
proposer des spcications : dans cette phase, on peut assister la
parution de plusieurs propositions concurrentes ; un acteur
institutionnel (W3C, OASIS) est saisi de la tche de btir une norme
unie sur la base dune ou plusieurs propositions concurrentes. La
troisime tape nest videmment pas automatique, mais rsulte des
ngociations conduites en coulisses entre les acteurs technologiques
majeurs. Le chapitre 8 prsente le sujet trs controvers du codage
des donnes dans un message SOAP. Le sujet est complexe pour
plusieurs raisons que nous analysons en dtail dans ce chapitre :
les principaux langages de programmations manipulent des structures
de donnes partages et circulaires (par exemple des graphes dobjets)
;
34. 6 Services Web pour pouvoir transfrer ces structures, il
faut un mcanisme pour les srialiser dans un fragment XML, partie
dun message SOAP ; la reprsentation linaire de ces structures ne
peut pas tre dnie par lutilisation standard dXML Schema. La
spcication SOAP 1.1 propose un mcanisme de codage dont le rsultat
peut tre valid par un analyseur syntaxique XML standard mais
demande la mise en uvre dun mcanisme spcique capable de
reconstruire la structure partage ou circulaire en mmoire. La
discussion dans la communaut est trs vive : lorganisme de
validation dinteroprabilit des implmentations des technologies des
services Web (WS-I) interdit, pour cause de dfaut dinteroprabilit,
lutilisation du mcanisme de srialisation (dit style de codage SOAP)
car il nest pas mis en uvre de faon homogne, et dans la spcication
SOAP 1.2 (qui nest pas encore adopte comme recommandation par le
W3C) la mise en uvre du style de codage est considre comme
optionnelle. Le codage permettant la srialisation/dsrialisation de
structures partages ou circulaires est cependant ncessaire pour
coller aux applications patrimoniales des interfaces de services
Web sans modier leurs API (Application Programming Interface), car
ces dernires prsentent parfois des invocations de mthodes et des
procdures vhiculant par valeur des structures de ce type. Le
chapitre 8 prsente par ailleurs la spcication contenue dans la note
W3C SOAP Messages with Attachments qui permet dinclure dans la mme
requte ou rponse HTTP un message SOAP et des objets binaires
(images, documents pdf, documents Word) considrs comme des pices
jointes, tout en permettant de rfrencer ces pices de lintrieur du
message. Nous ne prsentons pas la spcication concurrente (DIME)
dorigine Microsoft, qui est postrieure mais semble rester conne
dans le monde Microsoft. Le chapitre 9 dcrit plus en dtail les
styles dchange propres au protocole SOAP. En fait, SOAP propose
deux styles dchange : le message sens unique et la requte/rponse.
Le deuxime style ne peut tre mis en uvre que sur un protocole de
transport bidirectionnel comme HTTP, savoir sur un protocole de
transport qui se charge lui-mme de la corrlation entre la requte et
la rponse. La corrlation entre messages transfrs par des protocoles
unidirectionnels (comme SMTP) peut bien entendu tre ralise, mais
via des extensions, savoir lutilisation didentiants de messages
contenus dans len-tte. Le chapitre 9 dcrit la liaison SOAP/HTTP,
cest--dire lensemble des rgles quil faut respecter pour transfrer
correctement des messages SOAP via le protocole HTTP. La
prsentation de la liaison permet galement dintroduire la
problmatique de lasynchronisme dans lenvoi et le traitement des
messages. Le style dchange requte/rponse en SOAP se dcline en deux
variantes : le style document et le style rpc. Dans le style
document, la requte et la rponse SOAP nont pas une structure
diffrente de celle dun message SOAP standard. En style rpc, la
requte et la rponse ont une structure particulire qui permet
dutiliser le message et le protocole SOAP pour srialiser lappel et
le retour dappel de procdure distante. Le style rpc est notamment
indispensable pour exposer comme interface de service Web lAPI dune
application patrimoniale avec un minimum deffort. Le chapitre 10
prsente WSDL (Web Services Description Language). WSDL est loutil
pivot de la technologie des services Web car il permet vritablement
de donner une description dun service Web indpendante de sa
technologie dimplmentation. Les traits principaux du langage sont
prsents via
35. Introduction 7 lexemple dun des services Web les plus
populaires : laccs programmatique par SOAP au moteur de recherche
Google (http://www.google.com/apis). Un document WSDL joue le rle
dembryon de contrat de service et reprsente donc le document de
rfrence pour les quipes ct client et ct prestataire . Il joue en
outre un rle technique pivot car il peut tre : gnr automatiquement
partir dune application par des outils souvent intgrs aux
environnements de dveloppement ; dans ce cas, la formalisation du
service drive directement de la concep