Académique Documents
Professionnel Documents
Culture Documents
1 Core
Ministre du Budget, des comptes publics et de la fonction publique Direction gnrale de la modernisation de ltat 64, alle de Bercy, tldoc 817 75572 Paris Cedex 12, France.
PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core
Audience
Ce document constitue une rfrence technique pour limplmentation du protocole PRESTO. Il est destin aux architectes, chefs de projets, dveloppeurs et plus gnralement tout public souhaitant avoir des informations concernant le support de PRESTO. Le public vis doit avoir des connaissances techniques sur les Web Services.
Prambule
Ce document nonce les concepts couverts par le profil PRESTO 2.0.1 Core. Il constitue une actualisation des spcifications PRESTO 2.0 dont la ncessit est apparue suite aux retours des tests dinteroprabilit mens entre les diffrentes implmentations . Les standards Web Services sur lesquels repose PRESTO sont lists dans le tableau dadoption suivant qui en prcise lvolution depuis PRESTO 1.0. Spcifications [W3C] SOAP [W3C] WSDL [W3C] WS-Addressing [W3C] XOP / MTOM [OASIS] WS-RM [OASIS] WS-Security PRESTO V1.0 1.2 1.1 2004 SUB 1.0 1.0 1.1 PRESTO V1.1 1.2 1.1 1.0 1.0 1.1 1.1 PRESTO V2.0 1.2 1.1 1.0 1.0 1.1 - Retir PRESTO V2.0.1 1.2 1.1 1.0 1.0 1.1 - Retir -
Remarque : La raison du retrait de WS-Security de PRESTO est que, bien quelles soient compatibles, les normes WS-ReliableMessaging et WS-Security ne garantissent pas linteroprabilit entre implmentations diffrentes. La scurisation de WS-ReliableMessaging se focalise plutt sur une association avec WS-SecureConversation qui se concrtise dans le profil Reliable Secure Profile (RSP) du WS-I. Ainsi, WS-Security est retir de PRESTO et devrait tre remplac par RSP dans une version ultrieure de PRESTO. Dans ltat actuel, la scurisation de PRESTO doit tre effectue grce HTTPS bien que sa couverture soit moindre (chiffrement point point, identification de lmetteur, id entification du rcepteur). Le protocole dchange PRESTO (PRotocole dchanges STandard et Ouvert) 2.0.1 est dfini par plusieurs niveaux de spcifications de Web Services :
Description Spcification du profil Web Services qui constitue le socle de base de PRESTO 2.0.1, essentiellement dfini par un ensemble de standards de Web Services. Spcification optionnelle qui traite de la non-altration accidentelle des donnes transmises et des acquittements. Spcification optionnelle qui traite les problmatiques de routage des messages PRESTO changs entre mandataires PRESTO ainsi que de lidentification des messages changs. Spcification optionnelle qui traite la problmatique de lenvoi des pices-jointes.
PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core Le profil PRESTO 2.0.1 Core constitue le socle de PRESTO 2.0.1, lensemble des extensions PRESTO requirent au pralable le support du profil PRESTO 2.0.1 Core.
PRESTO 2.0.1
Mcanisme dacquittement
PRESTO Core
Les dpendances des diffrentes spcifications PRESTO sont reprsentes dans le tableau suivant : Mcanisme dacquittement Routage & Corrlation
PRESTO Core PRESTO Core Mcanisme dacquittement Routage & Corrlation Pices-jointes * * * *
Pices-jointes
* * * * *
Notice
Copyright 2010 Ministre du Budget, des comptes publics et de la fonction publique, Direction gnrale de la modernisation de ltat, 64, alle de Bercy, tldoc 817, 75572 Paris Cedex 12, France. Toute personne est autorise copier, distri buer lidentique des copies des spcifications techniques du protocole PRESTO, mais les modifications ne sont pas autorises.
PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core
Sommaire
1. INTRODUCTION ....................................................................................................................................................... 6 1.1. OBJECTIF ET PRIMTRE ............................................................................................................................................ 6 1.2. RELATIONS AVEC LES PROFILS DU WS-I ..................................................................................................................... 7 2. CONVENTIONS DU DOCUMENT .......................................................................................................................... 8 2.1. CONVENTIONS DE NOTATION ..................................................................................................................................... 8 2.2. ESPACES DE NOMMAGE .............................................................................................................................................. 9 3. PATTERNS DCHANGES PRESTO .................................................................................................................... 10 3.1. ENVOI DE MESSAGE ONE-WAY ........................................................................................................................... 10 3.2. ECHANGE DE MESSAGE REQUTE-RPONSE ....................................................................................................... 11 3.3. ECHANGE DE MESSAGE AVEC UN TIERS (VIA UN AUTRE PROTOCOLE) .......................................................................... 13 3.4. ROUTAGE DE MESSAGE ............................................................................................................................................ 14 4. CONFORMIT AU PROFIL ................................................................................................................................... 15 4.1. EXIGENCES DE CONFORMIT .................................................................................................................................... 15 4.2. CIBLES DE CONFORMIT .......................................................................................................................................... 15 5. ENVELOPPE DES MESSAGES.............................................................................................................................. 16 5.1. ANATOMIE DES MESSAGES PRESTO ........................................................................................................................ 16 5.2. ENTTE SPCIFIQUE PRESTO ................................................................................................................................. 17 5.2.1. Entte References ................................................................................................................................ 17 5.2.2. Entte Attachments ............................................................................................................................. 18 5.2.3. Entte Acknowledgement ................................................................................................................... 18 5.2.4. Entte Routing ...................................................................................................................................... 18 5.3. UTILISATION DU STYLE DOCUMENT-LITERAL ............................................................................................................ 18 5.4. ENVELOPPE SOAP DANS UN MESSAGE HTTP RESPONSE ........................................................................................... 18 6. ADRESSAGE DES MESSAGES ............................................................................................................................. 19 6.1. EXPRESSION DES ADRESSES DE MANDATAIRE PRESTO ............................................................................................. 20 6.1.1. Prsence des blocs dentte ...................................................................................................................... 20 6.1.2. Envoi de message one-way ................................................................................................................ 20 6.1.3. Echange de message Requte-Rponse ........................................................................................... 21 7. LIVRAISON FIABLE ET QUALIT DE SERVICE ............................................................................................ 25 7.1. ENVOI DE MESSAGE ONE-WAY ........................................................................................................................... 25 7.1.1. Emetteur anonyme PRESTO ...................................................................................................................... 25 7.1.2. Emetteur adressable PRESTO ................................................................................................................... 26 7.2. ECHANGE DE MESSAGE REQUTE-RPONSE ....................................................................................................... 27 7.3. BLOC DENTTE DE SQUENCE .................................................................................................................................. 27 7.4. BLOC DENTTE DACQUITTEMENT DE SQUENCE ....................................................................................................... 28 7.4.1. Piggy-backing des acquittements de squence ...................................................................................... 28 7.4.2. Transport dacquittement dans une rponse HTTP dopration one -way .......................................... 29 7.5. COMPOSITION AVEC WS-ADDRESSING ..................................................................................................................... 29 7.6. GARANTIE DE LIVRAISON ET ORDONNANCEMENT ....................................................................................................... 30 8. GESTION DES PICES JOINTES ....................................................................................................................... 31
PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core 8.1. TRANSPORT DE DOCUMENTS BINAIRES ..................................................................................................................... 31 8.2. OPTIMISATION DU TRANSPORT DES DONNES BINAIRES ............................................................................................ 31 9. SCURIT ................................................................................................................................................................. 32 10. INTERFACE GNRIQUE PRESTO 2.0.1 CORE .......................................................................................... 33 10.1. OBJECTIFS ............................................................................................................................................................ 33 10.2. DESCRIPTION DU WSDL FOURNI ........................................................................................................................... 33 10.2.1. Namespaces ............................................................................................................................................... 33 10.2.2. Types de donnes ..................................................................................................................................... 34 10.2.3. Operations exposes ................................................................................................................................ 35 ANNEXE A RFRENCES ....................................................................................................................................... 36 ANNEXE B GLOSSAIRE .......................................................................................................................................... 37
PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core
1. Introduction
1.1. Objectif et primtre
Le PRotocole dEchanges STandard et Ouvert 2.0.1 (PRESTO) a pour objectif de fournir une couche gnrique et normalise pour les changes de messages informatiques de ladministration lectronique. PRESTO a t conu en tenant compte des contraintes et exigences collectes par la DGME auprs dadministrations, de collectivits et de partenaires de ladministration . PRESTO est base sur les spcifications de Services Web telles que SOAP, WS-Addressing, WSReliableMessaging et XOP/MTOM. Les mcanismes dcrits dans les diffrents documents qui composent ces spcifications fournissent donc la base pour supporter les patterns dchanges identifis pour PRESTO (voir la section Patterns dchanges PRESTO ). Ce guide PRESTO 2.0.1 Core fournit un profil normatif pour cet ensemble de spcifications de Services Web accompagnes de clarifications, amendements et restrictions afin de favoriser linteroprabilit. Le but de ce document est dtre lu en ac compagnement des documents dextensions PRESTO. Le protocole PRESTO est spcifi pour tre dans un premier temps implment par des mandataires PRESTO. La distinction introduite dans ce guide entre un mandataire metteur PRESTO et un mandataire rcepteur PRESTO est purement logique et a pour but de reflter leurs rles respectifs dans un change de message. Le premier est un service qui gnre et transmet un message via PRESTO au second. Par consquent, un mandataire rcepteur PRESTO est un service qui reoit et consomme des messages via le protocole PRESTO. Ainsi les mandataires PRESTO implmentent et exposent des points daccs PRESTO aux partenaires de ladministration lectronique et leur permet dinter-oprer avec tous les services qui parlent PRESTO. Un mandataire PRESTO peut remplir la fois les rles dmetteur et de rcepteur. Un mandataire peut tre un logiciel indpendant ou tre partie intgrante dune application. Le parcours dun message entre un mandataire metteur PRESTO et un mandataire rcepteur PRESTO peut inclure un ou plusieurs relais PRESTO. Les relais PRESTO ont pour but de fournir des services de routage ainsi que des services supplmentaires tels que la traabilit, larchivage Enfin, une application (source ou cible) peut galement implmenter et exposer directement un point daccs PRESTO. Une telle application est alors capable de parler directement PRESTO et ainsi dchanger avec des mandataires ou dautres applications galement PRESTO. Toutefois, par soucis de clart, ce guide utilise systmatiquement dans les changes les rles de mandataire PRESTO metteur et rcepteur quil soit intgr une application ou quil fasse lobjet dun module distinct.
PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core
PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core
2. Conventions du document
2.1. Conventions de notation
Les mots-cls DOIT ("MUST", "SHALL"), NE DOIT PAS ("MUST NOT", "SHALL NOT"), OBLIGATOIRE ("REQUIRED"), DEVRAIT ("SHOULD"), NE DEVRAIT PAS ("SHOULD NOT"), RECOMMAND ("RECOMMENDED"), PEUT ("MAY"), et OPTIONNEL ("OPTIONAL") utiliss dans ce document doivent tre interprts conformment la description du document RFC 2119 [RFC 2119]. Les URI despaces de nommage de la forme xxx-URI sont des URI dpendant dune application ou dun contexte ; elles sont conformes la RFC 2396 [RFC 2396]. Les constatations dexigences dans le profil sont prsentes de la manire suivante : RPnnn Texte de lexigence. O "nnn" est remplac par un numro unique au sein des exigences du profil, constituant de ce fait un identifiant unique dexigence. Les identifiants dexigence peuvent tre considrs comme associs un espace de no mmage, et ainsi tre compatibles avec les noms QNames issus de la spcification Namespaces in XML (http://www.w3.org/TR/REC-xml-names). Sil ny a pas de prfixe explicite sur un identifiant dexigence (p ar exemple R999 en opposition bp10:R999 ), ce dernier doit tre interprt comme appartenant lespace de nommage identifi par lURI de conformit du document en cours. Sil est qualifi, le prfixe doit tre interprt selon la correspondance des espaces de nommage, comme documente cidessous. Les identifiants dexigences spcifiques aux extensions PRESTO 2.0.1 seront prfixs de la manire suivante : RPYYnnn ou YY reprsente lidentifiant (numrique) de lextension : o o o Mcanisme dacquittement : 01 Routage & Corrlation : 02 Pices-jointes : 03
PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core
XML Namespace http://www.w3.org/2003/05/soap-envelope http://schemas.xmlsoap.org/wsdl http://schemas.xmlsoap.org/wsdl/soap urn:uddi-org:api_v3 http://www.w3.org/2001/XMLSchema http://www.w3.org/2005/08/addressing http://docs.oasis-open.org/ws-rx/wsrm/200702 http://schemas.xmlsoap.org/ws/2004/09/policy
Reference(s) SOAP 1.2 WSDL 1.1 SOAP UDDI 3.0 XML Schema WS-Addressing WS-ReliableMessaging WS-Policy
PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core
Ce pattern consiste en un envoi dun unique message selon les tapes suivantes : 1. Comme illustr ci-dessus, lapplication source invoque le mandataire metteur PRESTO. Lapplication source transfre la donne mtier (qui peut contenir un ou plusieurs documents binaires) ainsi que les identifiants de lapplication cible. 2. Le mandataire metteur PRESTO gnre un message PRESTO compos des donnes mtier XML (comprenant ventuellement des documents binaires) sous la forme dune charge utile opaque. Le mandataire alimente les lments dentte SOAP du message PRESTO et transmet le message au mandataire rcepteur PRESTO. 3. Le mandataire rcepteur PRESTO reoit le message PRESTO. 4. Le mandataire rcepteur PRESTO retourne un acquittement de rception au mandataire metteur (il sagit de lacquittement WS-RM). Lacquittement assure simplement que le message a bien t reu. 5. Le mandataire metteur PRESTO reoit lacquittement de rception. 6. Le mandataire rcepteur PRESTO extrait la donne mtier (comprenant des ventuels documents binaires) lintention de lapplication cible.
PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core
Ce pattern tend le pattern prcdent (envoi one-way ) en ajoutant un envoi de rponse synchrone : 7. Ainsi, la suite de ltape prcdente 6, lapplication transmet une donne mtier de rponse ainsi que lidentit de la requte son mandataire rcepteur PRESTO. 8. Le mandataire rcepteur PRESTO gnre un message PRESTO comprenant la donne mtier XML (NE pouvant PAS comporter de donne binaire) en tant que charge utile opaque. Le mandataire alimente les lments dentte SOAP du message PRESTO et transmet le message au mandataire metteur PRESTO. 9. Le mandataire metteur PRESTO reoit le message PRESTO. 10. Le mandataire metteur PRESTO retourne un acquittement de rception au mandataire rcepteur PRESTO. Lacquittement assure simplement que l e message a bien t reu. 11. Le mandataire rcepteur PRESTO reoit lacquittement de rception. 12. Le mandataire metteur PRESTO extrait la donne mtier (contenant les ventuels documents binaires) pour lapplication source. Cette tape donne fin la session dchange PRESTO. Les deux patterns dcrits prcdemment font ressortir que larchitecture de base dun mandataire PRESTO peut tre divise en deux parties principales : Une interface publique (boite blanche) utilise par les applications qui soumettent ou reoivent des donnes mtier, Une interface prive (boite noire) qui implmente un point daccs PRESTO en conformit avec les spcifications PRESTO et permet par consquent dinteragir avec nimporte quel autre mandataire PRESTO.
PRESTO exchange area
Sender Proxy Source Application Async Request Async Response/Ack Sync RequestResponse/Ack Sender Proxy (White-Box) Public Interface Sender Proxy (Black-Box) Private Implementation
Target Application
Linterface publique dun mandataire dcrit comment une application interagit avec le service, quelles oprations sont supportes, les protocoles et formats de messages que le service attend et enfin quelques informations non fonctionnelles attendues par le service comme par exemple le niveau de scurit appliquer lors de lenvoi. Il sagit du mandataire PRESTO vu par lapplication.
PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core Par exemple, pour une application source qui ne supporte que les services WS-I Basic Profile 1.0, le mandataire metteur PRESTO PEUT proposer cette application une interface qui sera invocable partir doprations simples Basic Profile 1.0.
PRESTO exchange area
Sender Proxy Sender Proxy Public Interface
Source Application
submit business data, receive transaction identifier submit transaction identifier submit transaction identifier, receive a response/acknowledgement (if available) submit transaction identifier, receive current status
GetMessage()
Submit business data synchronously Submit business data asynchronously Dispose of resources for a submission Poll for a response/ acknowledgement Get the status of a submission
Target Application
Les noms de mthodes prsents dans le schma prcdent ne sont donns qu titre dillustration. Linterface publique dun mandataire PRESTO est responsable des interactions avec les applications. Par contre limplmentation prive, derrire le point daccs PRESTO qui est expos de manire standard pour favoriser linteroprabilit, est responsable d u traitement des requtes, de lenvoi de rponses et des acquittements et doit assurer la validit des informations changes avec dautres composants PRESTO.
PRESTO exchange area
Sender Proxy Sender Proxy Private Implementation GetMessage() requestresponse/acknowledgement Request
SendMessage()
Target Application
Source Application
response/acknowledgement (source application supports a reply address) Dispose() Poll() GetStatus() In-Flight Store response/acknowledgement (no support for reply address)
PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core
Ce pattern consiste en un change de message contenant des donnes mtiers (pouvant contenir un ou plusieurs documents binaires) avec un tiers. Le tiers est un rseau dchange non PRESTO qui sappuie sur un autre protocole. Ce pattern nillustre que le cas dun envoi o le rseau tiers est la destination de lchange PRESTO. Ce pattern est compltement rversible et peut sappliquer pour le cas o le rseau tiers e st la source du message PRESTO. Un mandataire rcepteur PRESTO agit en tant que passerelle, transformant les messages au format PRESTO en messages au format spcifique au rseau tiers. Lacheminement du message au sein du rseau tiers ne concerne pas le protocole PRESTO et dpend des caractristiques propres du rseau en question. 1. Dune manire similaire aux patterns prcdents, lapplication source invoque le mandataire metteur PRESTO. Lapplication source transfre la donne mtier (qui peut contenir un ou plusieurs documents binaires) ainsi que les identifiants de lapplica tion cible. 2. Le mandataire metteur PRESTO gnre un message PRESTO compos de donnes mtier XML (comprenant ventuellement des documents binaires) sous la forme dune charge utile opaque. Le mandataire alimente les lments dentte SOAP du message PRESTO et transmet le message au mandataire rcepteur PRESTO. 3. Le mandataire rcepteur PRESTO reoit le message PRESTO. 4. Le mandataire rcepteur PRESTO retourne un acquittement de rception au mandataire metteur PRESTO. Lacquittement assure simplement que le message a bien t reu. 5. Le mandataire metteur PRESTO reoit lacquittement de rception. 6. Le mandataire rcepteur PRESTO extrait la donne mtier (contenant les ventuels documents binaires) pour lapplication source et gnre partir de rgles de transformation un message valide dans le format tiers. Les rgles de transformation dfinissent la logique de correspondance entre le format de message PRESTO et le format de message tiers et prend en compte ladressage et le routage dans le rseau tiers. Le protocole PRESTO ne couvre pas ces rgles. La dfinition de la correspondance entre les formats est la responsabilit de limplmentation spcifique du mandataire. Selon les exigences de ce pattern, le mandataire doit agir comme une passerelle entre deux protocoles, c'est--dire le protocole PRESTO et un protocole tiers. Ici le mandataire a donc au moins deux piles de protocole. Enfin le message tiers rsultant est rout vers lapplication cible au sein du rseau tiers. 7. Lapplication cible transmet sa rponse (donne mtier) au mandataire rcepteur PRESTO via le protocole tiers. 8. Le mandataire rcepteur PRESTO gnre un message PRESTO (par application des rgles de correspondance entre le format tiers et le format PRESTO) et finalement transmet le message au mandataire metteur PRESTO.
PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core 9. Le mandataire metteur PRESTO reoit le message PRESTO. 10. Le mandataire metteur PRESTO retourne un acquittement de rception au mandataire rcepteur. Lacquittement assure simplement que le message a bien t reu. 11. Le mandataire rcepteur PRESTO reoit lacquittement de rception. 12. Eventuellement, le mandataire metteur PRESTO extrait la donne mtier (et les ventuels documents binaires) pour lapplication source. Cette tape donne fin la session dchange PRESTO.
Le pattern de routage de message est un point dextension qui est trait dans lune des extensions du prsent profil. Ce pattern est donc trait plus en dtail dans la spcification ddie cette problmatique (cf. Guide pour le support de lextension PRESTO 2.0.1 Routage & Corrlation ).
PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core
4. Conformit au profil
4.1. Exigences de conformit
Les exigences font tat des critres de conformit au Profil. Elles rfrent typiquement une spcification existante et intgrent des rajustements, amplifications, interprtations et clarifications dans le but damliorer linteroprabilit. Toutes les exigences du profil sont considres comme normatives et celles des spcifications rfrences appartenant au cadre (voir le chapitre cadre de conformit ) doivent galement tre considres comme normatives. Quand les exigences du Profil et des spcifications rfrences se contredisent, les exigences du profil sont prioritaires pour la conformit au Profil.
PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core
Un seul lment racine DOIT tre prsent au sein de llment s12:Body. Lenvelopp e technique PRESTO permet nimporte quelle charge utile dtre imbrique dans le message SOAP PRESTO en tant que donne mtier. Si des mtadonnes mtier (mtadonnes associes aux donnes mtier telles que des documents binaires) sont exiges, ces mtadonnes mtier ne doivent pas tre considres comme une partie de lentte PRESTO mais comme une partie de la charge utile (corps de message opaque).
PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core La charge utile peut donc tre : Des donnes mtier, Une enveloppe constitue de mtadonnes et des donnes mtier.
Data Data
Llment dentte PRESTO dispose dun attribut indiquant la version de PRESTO utilise. Ici, il sagit de la version 2.0.1.
PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core
PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core
PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core
PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core Message :
<s12:Envelope xmlns:s12="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:presto="http://www.w3.org/2005/08/addressing"> <s12:Header> <wsa:Action s12:mustUnderstand="1">http://tempuri.org/ServicePortType/Foo</wsa:Action> <wsa:To s12:mustUnderstand="1">http://presto-receiver/inbox</wsa:To> <wsa:MessageID>uuid:aaaabbbb-cccc-dddd-eeee-ffffffffffff</wsa: MessageID> <presto:PRESTOHeader version="2.0.1"> <!enttes PRESTO --> </presto:PRESTOHeader> </s12:Header> <s12:Body> <! Charge utile OPAQUE pour PRESTO --> <ping xmlns="http://tempuri.org/">Hello</ping> </s12:Body> </s12:Envelope>
PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core Dans le contexte du Basic Profile du WS-I, la seule raison pour que la rponse dune requte HTTP soit vide est quil sagit dun envoi one-way. De toute manire, la spcification WSAddressing introduit llment dentte wsa:ReplyTo qui change la nature de lopration requte-rponse pour une mise en uvre sur http. Si un message de requte inclut un lment dentte wsa:ReplyTo qui ne contient pas lURI anonyme de WS -Addressing, alors le message de rponse est attendu ladresse indique dans llment wsa:ReplyTo et non dans la rponse HTTP. Comme la rponse nest pas transmise dans le message de rponse HTTP, la rponse HTTP sera du type 202 Accepted . Cela ne contredit pas les exigences du Basic Profile de WS-I, il sagit dun changement de comportement. RP009 Si une enveloppe correspondant un message wsdl:input contient un lment dentte wsa:ReplyTo contenant une valeur autre que lURI Anonyme de WS Addressing, alors le message de rponse HTTP PEUT avoir un code retour 202 Accepted et un contenu vide. Requte :
<s12:Envelope xmlns:s12="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:presto="http://www.w3.org/2005/08/addressing"> <s12:Header> <wsa:Action s12:mustUnderstand="1">http://tempuri.org/ServicePortType/Foo</wsa:Action> <wsa:To s12:mustUnderstand="1">http://presto-receiver/inbox</wsa:To> <wsa:MessageID>urn:uuid:bf121bf2-38b7-4910-b8a3-f8ca65437e33</wsa:MessageID> <presto:PRESTOHeader version="2.0.1"> <!enttes PRESTO --> </presto:PRESTOHeader> <wsa:ReplyTo> <wsa:Address>http://www.w3.org/2005/08/addressing/anonymous</wsa:Address> </a:ReplyTo> </s12:Header> <s12:Body> <! Charge utile OPAQUE pour PRESTO --> </s12:Body> </s12:Envelope>
Rponse :
<s12:Envelope xmlns:s12="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:presto="http://www.w3.org/2005/08/addressing"> <s12:Header> <wsa:Action s12:mustUnderstand="1">http://tempuri.org/ServicePortType/FooResponse</wsa:Action> <wsa:RelatesTo>urn:uuid:bf121bf2-38b7-4910-b8a3-f8ca65437e33</wsa:RelatesTo> <presto:PRESTOHeader version="2.0.1"> <!enttes PRESTO --> </presto:PRESTOHeader> </s12:Header> <s12:Body> <! Charge utile OPAQUE pour PRESTO --> </s12:Body> </s12:Envelope>
PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core Dans le contexte dune messagerie asynchrone, il est ncessaire que lenveloppe contienne des informations de corrlation suffisantes pour permettre au rcepteur dun message de rponse de corrler cette rponse avec le message de requte original. RP010 Nimporte quelle ENVELOPPE PEUT contenir un entte wsa:ReplyTo. RP011 Si, dans une description WSDL, une wsdl:operation est dcrite avec un lment wsdl:output, lENVELOPPE du message correspondant au wsdl:input de cette opration DOIT contenir un lment dentte wsa:ReplyTo. RP012 Si, dans une description WSDL, une wsdl:operation est dcrite avec un lment wsdl:output, lENVELOPPE du message correspondant au wsdl:output de cette opration DOIT contenir un lment dentte wsa:RelatesTo contenant la valeur wsa:MessageID du message dentre correspondant. Un MANDATAIRE_EMETTEUR qui met un message de requte dont une rponse doit tre remise ladresse spcifie dans llment dentte wsa:ReplyTo doit assurer que le destinataire du message comprend la smantique de lentte wsa:ReplyTo. RP013 Si une ENVELOPPE contient un lment dentte wsa:ReplyTo, ce dernier DOIT avoir un attribut s12:MustUnderstand avec la valeur '1'. 6.1.3.2 Emetteur PRESTO adressable Ce scnario PEUT tre propos par lmetteur PRESTO. Ce scnario met en uvre le pattern de communication asynchrone correspondant un envoi de message requte-rponse (comme prsent dans la section 3.2 Echange de message Requte-Rponse ) : un message est envoy par un mandataire metteur PRESTO un mandataire rcepteur PRESTO et enfin une rponse est retourne par le mandataire rcepteur PRESTO au mandataire metteur PRESTO. Par soucis de clart, nous avons omis les acquittements HTTP qui ne concernent pas directement le protocole PRESTO mais sont une consquence de la mise en uvre sur le transport HTTP. Le mandataire metteur PRESTO envoie un message PRESTO qui contient la charge utile. A titre dexemple, la charge utile peut tre une chane de caractre encode en UTF-8. Le mandataire rcepteur PRESTO retourne ensuite un message PRESTO, contenant une charge utile de rponse. A titre dexemple, la charge utile peut tre une chane de caractre de rponse encode en UTF-8. Requte :
<s12:Envelope xmlns:s12="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:presto="http://www.w3.org/2005/08/addressing"> <s12:Header> <wsa:Action s12:mustUnderstand="1">http://tempuri.org/ServicePortType/Foo</wsa:Action> <wsa:To s12:mustUnderstand="1">http://presto-receiver/inbox</wsa:To> <wsa:MessageID>urn:uuid:bf121bf2-38b7-4910-b8a3-f8ca65437e33</wsa:MessageID> <presto:PRESTOHeader version="2.0.1"> <!enttes PRESTO -->
PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core
</presto:PRESTOHeader> <wsa:ReplyTo s12:mustUnderstand="1"> <wsa:Address>http://presto-sender/inbox</wsa:Address> </wsa:ReplyTo> </s12:Header> <s12:Body> <! Charge utile OPAQUE pour PRESTO --> </s12:Body> </s12:Envelope>
Rponse :
<s12:Envelope xmlns:s12="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:presto="http://www.w3.org/2005/08/addressing"> <s12:Header> <wsa:To s12:mustUnderstand="1">http://presto-sender/inbox</wsa:To> <wsa:Action s12:mustUnderstand="1">http://tempuri.org/ServicePortType/FooResponse</wsa:Action> <wsa:RelatesTo>urn:uuid:bf121bf2-38b7-4910-b8a3-f8ca65437e33</wsa:RelatesTo> <presto:PRESTOHeader version="2.0.1"> <!enttes PRESTO --> </presto:PRESTOHeader> </s12:Header> <s12:Body> <! Charge utile OPAQUE pour PRESTO --> </s12:Body> </s12:Envelope>
PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core
PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core Le mandataire de rception PRESTO retourne des acquittements pour chaque message de squence reu. Tous les acquittements sont transports par les rponses HTTP. Chaque acquittement devra accuser rception des messages prcdents plus le message qui vient dtre envoy dans la requte HTTP lexception du cas o le rcepteur dcide de ne pas accepter le message. Un mandataire metteur PRESTO peut retransmettre certains messages si cela est considr comme appropri ou ncessaire. Une fois que le mandataire metteur PRESTO reoit un acquittement qui couvre lensemble des messages, il transmet un message CloseSequence au mandataire rcepteur PRESTO. La rponse HTTP de ce message doit tre un message CloseSequenceResponse. Suite la rception de ce message CloseSequenceResponse, le mandataire metteur PRESTO transmet un message TerminateSequence dont la rponse HTTP doit tre un message TerminateSequenceResponse. Les lments dadressage wsa:ReplyTo et wsrm:AcksTo DOIVENT tre tous anonymes.
PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core
RP014 Si une ENVELOPPE contient un lment dentte wsrm:Sequence, ce dernier DOIT avoir un attribut s12:MustUnderstand avec une valeur de '1'. Par exemple :
INCORRECT: <s12:Envelope xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core
xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200702" xmlns:wsa="http://www.w3.org/2005/08/addressing"> <s12:Header> <wsa:MessageID>http://example.com/guid/0baaf88d-483b-4ecf-a6d8-a7c2eb546817</wsa:MessageID> <wsa:To>http://example.org/service</wsa:To> <wsa:From>http://example.com/client/rm</wsa:From> <wsa:Action>http://example.org/service/credit</wsa:Action> <wsa:ReplyTo s12:mustUnderstand='1'> <wsa:Address>http://example.com/client</wsa:Address> </wsa:ReplyTo> <wsrm:Sequence> <wsrm:Identifier>http://example.org/guid/0baaf88d-483b-4ecf-a6d8-a7c2eb546817</wsrm:Identifier> <wsrm:MessageNumber>42</wsrm:MessageNumber> </wsrm:Sequence> </s12:Header> <s12:Body> <!- body contents OPAQUE to the PRESTO protocol --> </s12:Body> </s12:Envelope>
CORRECT: <s12:Envelope xmlns:s12="http://www.w3.org/2003/05/soap-envelope" xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200702" xmlns:wsa="http://www.w3.org/2005/08/addressing"> <s12:Header> <wsa:MessageID>http://example.com/guid/0baaf88d-483b-4ecf-a6d8-a7c2eb546817</wsa:MessageID> <wsa:To>http://example.org/service</wsa:To> <wsa:From>http://example.com/client/rm</wsa:From> <wsa:Action>http://example.org/service/credit</wsa:Action> <wsa:ReplyTo s12:mustUnderstand='1'> <wsa:Address>http://example.com/client</wsa:Address> </wsa:ReplyTo> <wsrm:Sequence s12:mustUnderstand='1'> <wsrm:Identifier>http://example.org/guid/0baaf88d-483b-4ecf-a6d8-a7c2eb546817</wsrm:Identifier> <wsrm:MessageNumber>42</wsrm:MessageNumber> </wsrm:Sequence> </s12:Header> <s12:Body> <!- body contents OPAQUE to the PRESTO protocol --> </s12:Body> </s12:Envelope>
PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core mandataire metteur PRESTO) dans des messages spars. Cette pratique est couramment appele piggy-backing des acquittements. RP015 Un lment dentte wsrm:SequenceAcknowledgement, pour chaque squence idoine, PEUT tre inclus dans nimporte quelle ENVELOPPE transmise au point de terminaison spcifi dans llment dentte wsrm:CreateSequence/wsrm:AcksTo.
PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core
RP019 Pour un change de messages dont le message dentre (la requte) et le message de sortie (la rponse) doivent tre transmis avec la fiabilit de WSReliableMessaging, lENVELOPPE du message dentre NE DOIT PAS tre lURI anonyme de WS-Addressing. Cette rgle ne concerne pas lchange de messages a travers des relais, pour lequel lutilisation dune URI anonyme assortie dune adresse logique est autorise (voir lextensi on PRESTO : Routage & Corrlation).
PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core
PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core
9. Scurit
La scurit tait prcdemment assure dans PRESTO 1.x grce WS-Security qui ne fait plus partie de PRESTO 2.0.1. En effet, bien quelles soient compatibles, les normes WS ReliableMessaging et WS-Security ne garantissent pas linteroprabilit entre implmentations diffrentes. En consquence, lorsquelle est ncessaire, la scurisation de PRESTO doit tr e effectue grce HTTPS (cf. RFC 2818 http over TLS) bien que sa couverture soit moindre. Elle se limite au chiffrement point point, lidentification du rcepteur par certificat et, ventuellement, lidentification de lmetteur par certificat. Le protocole PRESTO 2.0.1 ne propose donc pas de mcanisme de scurisation au niveau du contenu des messages, mais simplement un mcanisme situ au niveau du transport (SSL et TLS). En cas de transit par des relais PRESTO, la scurisation ne se fait donc que de point point et non de bout en bout (ce qui implique que chaque relais soit un partenaire de confiance). Concernant les certificats x509, cts serveur et client, pour la mise en uvre de HTTPS, il est not que leur processus de dlivrance doit tre ralis conformment aux exigences du Rfrentiel Gnral de Scurit (RGS) et doivent correspondre aux exigences du niveau de scurit cible requis (*, ** ou ***).
PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core
10.1. Objectifs
Lobjectif principal est de fournir aux partenaires le souhaitant, une interface conforme PRESTO 2.0.1 Core et directement utilisable pour couvrir les principaux patterns dchanges concernant lenvoi et la rception de formulaires avec pices-jointes. Lutilisation dune mme interface par plusieurs partenaires permet aussi de favoriser grandement linteroprabilit et par la mme occasion la simplicit dintgration entre deux partenaires. Nanmoins, cette interface gnrique tant limite au primtre denvoi de formulaires, ell e ne dispense pas chaque partenaire dexposer les oprations mtiers qui lui sont propres et de faire en sorte que celles-ci soient conformes au profil PRESTO 2.0.1.
10.2.1. Namespaces
Les target namespaces DGME utiliss dans le WSDL sont les suivants : Namespace
http://dgme.finances.gouv.fr/presto/services/proxyprestoservice
Description
Target namespace correspondant au service gnrique PRESTO 2.0.1 Target namespace correspondant aux types de donnes manipuls par le service
http://dgme.finances.gouv.fr/presto/types
PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core
http://dgme.finances.gouv.fr/presto/metadata
Description
Ce type reprsente un message fonctionnel PRESTO contenant les lments suivants : message de type String contenant le payload du formulaire chang attachment de type AttachmentType contenant la pice jointe attache au formulaire Ce type reprsente un message fonctionnel PRESTO de rponse, contenant un message de type String contenant le payload du formulaire chang. Ce type reprsente une pice jointe, il contient les lments suivants : fileName : Nom du fichier binaryData : Contenu du binaire
RequestDataType
ResponseDataType
AttachmentType
Acknowledgement
Ce type reprsente un acquittement fonctionnel, il contient les lments suivants : status : DONE ou ERROR code : code de lerreur message : message derreur
PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core
Pattern dchange
InOnly
Description
Cette opration consiste en lenvoi dun formulaire avec sa pice jointe associe. Cet envoi seffectue en mode asynchrone. Cette opration consiste en lenvoi dun formulaire avec sa pice jointe associe, ainsi que la rception dun message de rponse en retour, pouvant contenir un payload ainsi quun binaire. Cette opration permet au mandataire rcepteur de renvoyer un acquittement fonctionnel lors dun change asynchrone.
GetMessage
InOut
Acknowledge
InOnly
Source Application
Target Application
PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core
Annexe A Rfrences
[PRESTO-Ref] DGME, "A Technical Reference for the PRESTO Protocol", June 2006. [PRESTO-Proxy] DGME, "PRESTO Proxy Specifications", June 2006. [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997. [RFC 2396] T. Berners-Lee, et al, "Uniform Resource Identifier (URI): Generic Syntax", RFC 2396bis, W3C/MIT, July 2004. [SOAP 1.2] M. Gudgin et al, "SOAP Version 1.2 Part 1: Messaging Framework", June 2003. [UDDI] Ed. Luc Clement et al, "UDDI Version 3.0.2 API Specification", October 2004. [WSDL 1.1] Ed. Erik Christensen et al, "Web Service Description Language (WSDL) 1.1", March 2001. [WS-Addressing] D. Box et al, "Web Services Addressing (WS-Addressing)", August 2004. [WS-Policy] D. Box et al, "Web Services Policy Framework (WS-Policy)", September 2004 [WS-RM] Ruslan Bilorusets et al, "Web Services Reliable Messaging (WS-ReliableMessaging)", February 2005. [WS-RMPolicy] Stefan Batres et al, "Web Services Reliable Messaging Policy Assertion (WS-RM Policy)", February 2005. [XML Schema, Part 1] H. Thompson et al, "XML Schema Part 1: Structures", May 2001. [XML Schema, Part 2] P. Biron et al, "XML Schema Part 2: Datatypes", May 2001. [MTOM] Ed. Noah Mendelsohn et al, "SOAP Message Transfer Optimization Mechanism", July 2004. [XOP] Ed. Noah Mendelsohn et al, "XML-binary Optimized Packaging (XOP)", June 2004.
PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core
Annexe B Glossaire
Authentification L'authentification a pour but de vrifier l'identit dont une entit se rclame. Autorisation Lautorisation dsigne le processus visant contrler (accorder ou refuser) laccs une ressource en fonction des droits daccs possds par lu tilisateur. Canonisation La canonisation est le processus de conversion dun document XML dans un format commun. La canonisation est utilise avant de signer les documents et de contrler les signatures. Composition de protocoles La composition de protocoles est la capacit combiner des protocoles en garantissant leur cohrence technique et labsence deffets de bord induits. Dsrialisation La dsrialisation est le processus de construction dun XML Infoset partir dun flux doctets. Factory Une factory est un Web service qui peut crer une ressource partir de sa reprsentation en XML. Intermdiaire SOAP Un intermdiaire SOAP est un nud SOAP qui nest ni lmetteur, ni le destinataire du message SOAP. Mandataire PRESTO Un mandataire PRESTO est un service. Mandataire metteur PRESTO Un mandataire metteur PRESTO est un service permettant de gnrer un message conforme aux spcifications du protocole PRESTO et capable de lenvoyer un mandataire rcepteur PRESTO. Ce message peut tre envoy travers dun ou plusieurs relais PRESTO.
PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core Mandataire rcepteur PRESTO Un mandataire rcepteur PRESTO est un service capable de recevoir des messages conformes aux spcifications du protocole PRESTO. Message Un message est une unit complte de donnes prte tre envoye ou rceptionne par un service. Dans ce document, un message contient toujours une enveloppe SOAP et peut comporter des parties MIME additionnelles tel que spcifi dans MTOM ainsi que des en-ttes spcifique au protocole de transport. Pattern dchange Un pattern dchange est un modle utilis pour les changes de messages entre des mandataires PRESTO. Relais PRESTO Un relais PRESTO est un intermdiaire SOAP situ sur la route entre un mandataire metteur et un mandataire rcepteur. Ressource Une ressource est une entit adressable via un endpoint rfrence. Cette entit peut fournir une reprsentation XML. Route Une route est lensemble des nuds SOAP entre le mandataire metteur PRESTO initial et le mandataire destinataire PRESTO final et par lesquels transitent les messages PRESTO. Srialisation C'est le procd consistant coder un objet depuis le format machine vers le format rseau dans un format transparent, pour restitution l'arrive dans un format machine potentiellement diffrent. Service Composant applicatif interagissant avec dautres services via des messages. Service Web Composant applicatif accessible via un rseau, par l'entremise d'une interface standard, qui peut interagir dynamiquement avec d'autres applications en utilisant des protocoles de communication bass sur le XML, et cela indpendamment du systme d'exploitation et des langages de programmation utiliss.