Vous êtes sur la page 1sur 38

Protocole PRESTO Guide pour le support de PRESTO 2.0.

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.

Version : 2.0.1 - Valide Date : 26/01/2011 Rsum :


PRESTO (Protocole dEchange STandard et Ouvert) pose les bases dun protocole dchange de messages informatiques entre applications pour servir les besoins de ladmini stration lectronique. Il cible les principaux cas dusage envisags en matire dchanges de donnes entre des applications ayant des domaines de rattachement diffrents : ministres, tablissements publics, collectivits locales, certains partenaires privs. Il se veut agnostique en regard des problmatiques lies aux fonctions mtier. Aussi, il dfinit les principes dchanges entre applications partenaires sans se soucier de la nature des donnes mtier manipules et vhicules et, de ce fait, il ne lgifre pas sur la nature fonctionnelle des documents changs. Les spcifications du protocole dchanges PRESTO 2.0.1 sont constitues dun profil Web Services PRESTO 2.0.1 Core (ensemble de standards de Services Web) accompagn dun ensemble dextensions optionnelles permettant de rpondre des problmatiques particulires telles que lenvoi de pices jointes, le routage de messages, la corrlation des changes Le profil PRESTO 2.0.1 Core objet du prsent document, constitue le socle de base du protocole PRESTO : il regroupe un ensemble de spcifications de Services Web, prcises, amendes ou restreintes afin de favoriser linteroprabilit. Le support de ce profil nimplique aucun besoin dimplmentation autre que ceux induits par les standards sur lesquels il repose (SOAP, WS-Addressing, WS-ReliableMessaging).

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 :

Identification PRESTO Core Mcanisme dacquittement Routage & Corrlation Pices-jointes

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.

Version : 2.0.1 - Valide Page 2 / 38

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

Gestion de lentte de routage

Gestion des picesjointes

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.

Version : 2.0.1 - Valide Page 3 / 38

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

Version : 2.0.1 - Valide Page 4 / 38

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

Version : 2.0.1 - Valide Page 5 / 38

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.

Version : 2.0.1 - Valide Page 6 / 38

PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core

1.2. Relations avec les profils du WS-I


En raison de la diversit des plateformes et technologies de ladministration lectronique, il est important de sassurer que les diffrentes implmentations de Services Web PRESTO soient interoprables, quelle que soit la technologie retenue pour limplmentation. Lutilisation des profils WS-I dfinit une base de standards auxquels les implmentations doivent adhrer. Plus particulirement, le Basic Profile spcifie un ensemble minimum de spcifications que les services Web doivent supporter pour garantir linteroprabilit travers diffrentes plateformes. La version finale actuelle du Basic Profile (BP), c'est--dire la version 1.1 (http://www.ws-i.org/Profiles/BasicProfile-1.1.html galement rfrenc par la norme ISO/IEC 29361:2008), intgre SOAP 1.1 (bien que SOAP 1.2 soit une recommandation W3C depuis 2003), XML 1.0 et HTTP 1.1 pour la messagerie et le format des messages, WSDL 1.1 et XML Schema 1.0 pour la description des services et enfin UDDI v2 pour la dcouverte et la publication. La version initiale du protocole PRESTO est base sur les spcifications de Services Web SOAP 1.2 [SOAP 1.2], WS-Addressing [WS-Addressing], MTOM [MTOM], WS-ReliableMessaging [WSReliableMessaging]. Ces spcifications ne sont pas prises en compte dans le Basic Profile 1.1, toutefois la plupart des exigences identifies font apparatre la ncessit de les considrer. Par exemples les exigences concernant SOAP 1.1 sont prises en compte dans SOAP 1.2. Le protocole PRESTO se rfre autant que possible au Basic Profile 1.1 et tend se rapprocher, de part ses caractristiques, du Basic Profile 1.2 (non officiellement valid ce jour). Aussi, certaines exigences PRESTO cites dans ce document seront probablement amenes disparatre, dans le futur, au bnfice du Basic Profile 1.2 ou 2.0 et du Reliable Secure Profile 1.0 rcemment finaliss ; la version finale de ces profils conclut les travaux du WS-I sur linteroprabilit des services Web initis en 2002. Le protocole PRESTO pourrait alors simplement reprendre les exigences de ces profils WS-I et nen tre quun cas dusage. Concernant la scurit, elle tait prcdemment assure dans PRESTO 1.x grce WSSecurity mais lutilisation de cette norme a t retire ds PRESTO 2.0. La raison de ce retrait 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, identification du rcepteur). 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. 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).

Version : 2.0.1 - Valide Page 7 / 38

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

Version : 2.0.1 - Valide Page 8 / 38

PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core

2.2. Espaces de nommage


Cette spcification utilise un certain nombre de prfixes despaces de nommage. Les URI correspondantes sont listes plus bas. Le choix dun prfixe despace de nommage est arbitraire et na pas de sens smantique. Les URI despace de nommage de la forme gnrale some-URI reprsentent des URI dpendant dune application ou dun contexte comme dfini dans la RFC 2396 [RFC 2396].

Prefix s12 wsdl soap uddi xs wsa wsrm wsp

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

Version : 2.0.1 - Valide Page 9 / 38

PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core

3. Patterns dchanges PRESTO


Cette section dcrit les scenarii dchanges de messages caractristiques du protocole PRESTO bass sur le retour dexprience collect par la DGME. Larchitecture et limplmentation du MANDATAIRE ne sont pas dtailles dans les prsentes spcifications. Toutefois, ce guide fournit quelques considrati ons darchitecture et quelques directions pour limplmentation de mandataires quand cela est jug opportun. Cela pourra aider la comprhension des mcanismes PRESTO. Les sections suivantes dcrivent les quatre patterns dchanges de messages PRESTO (Message Exchange Patterns MEP) actuellement supports par cette version du protocole PRESTO.

3.1. Envoi de message one-way


PRESTO exchange area
Source Application Sender Proxy Receiver Proxy Target Application

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.

Version : 2.0.1 - Valide Page 10 / 38

PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core

3.2. Echange de message Requte-Rponse


PRESTO exchange area
Source Application Sender Proxy Receiver Proxy Target Application

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

PRESTO Protocol Endpoint

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.

Version : 2.0.1 - Valide Page 11 / 38

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

SendMessage() Dispose() Poll() GetStatus()

Sender Proxy Private Implementation

submit business data, receive response/acknowledgement

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

PRESTO Protocol Endpoint

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

Sender Proxy Public Interface

SendMessage()

PRESTO Protocol Endpoint

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)

Version : 2.0.1 - Valide Page 12 / 38

PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core

3.3. Echange de message avec un tiers (via un autre protocole)


PRESTO Exchange Area
Source Application PRESTO Sender Proxy

Third Party Protocol


Target Application

PRESTO Receiver Proxy

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.

Version : 2.0.1 - Valide Page 13 / 38

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.

3.4. Routage de message


PRESTO exchange area
Source Application Sender Proxy Relay Receiver Proxy Target Application

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 ).

Version : 2.0.1 - Valide Page 14 / 38

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.

4.2. Cibles de conformit


Les cibles de conformit identifient quels artfacts (par exemple, message SOAP, description WSDL, donne de registre UDDI) ou quels partis (par exemple un moteur SOAP, un utilisateur final) font lobjet de lexigence. Cela permet de dfinir la conformit dans diffrents contextes, dassurer labsence dambigut dans linterprtation de lapplication des exigences. Cela permet galement de tester la conformit des artfacts (par exemple les messages SOAP ou les descriptions WSDL) et du comportement des diffrents partis dun service Web (par exemple les clients et les instances de service). Les cibles de conformit des exigences sont des artfacts physiques dans la mesure du possible afin de permettre les tests et dcarter les ambiguts. Les cibles dexigences suivantes sont utilises dans le Profil : MESSAGE lments du protocole transports au sein dune enveloppe (e.g., SOAP/HTTP messages). ENVELOPPE la srialisation de llment s12:Envelope et de son contenu. DESCRIPTION description des types, messages, interfaces, protocoles, formats de messages et points daccs rseau associs avec les services Web (par exemple une description WSDL). MANDATAIRE_EMETTEUR lment logiciel qui gnre un message en fonction du protocole associ et qui met le message vers un mandataire rcepteur selon un chemin denvoi pouvant mettre en jeu un ou plusieurs relais. MANDATAIRE_RECEPTEUR lment logiciel qui reoit un message en fonction du protocole associ. RELAI lment logiciel pouvant intervenir dans le chemin dun envoi vers un mandataire rcepteur.

Version : 2.0.1 - Valide Page 15 / 38

PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core

5. Enveloppe des messages


5.1. Anatomie des messages PRESTO
Le format des messages PRESTO est XML, qui est le format de facto pour les communications entre applications. XML fournit une structure dfinie qui donne un sens aux donnes. Le Profil rend obligatoire le respect de la recommandation XML du W3C dans sa version 1.1. Cette spcification XML se trouve ladresse http://www.w3.org/XML. Le format d enveloppe pour les messages permet de positionner des mtadonnes ct de la charge utile. Le message PRESTO utilise le format SOAP en tant quenveloppe pour encapsuler les mtadonnes et la charge utile. Ce Profil rend obligatoire lutilisation de SOAP dans la version 1.2 [ SOAP 1.2]. Cette section du profil incorpore les spcifications suivantes par rfrence, et dfini leurs points dextensions : SOAP 1.2 (W3C Recommendation 24 June 2003) [SOAP 1.2] Le message SOAP PRESTO contient dans ses enttes les mtadonnes techniques qui concernent ladressage et la fiabilit. Ces sujets sont couverts respectivement dans les chapitres suivants de ce document. Les donnes mtier sont OPAQUES pour le protocole PRESTO. Ce qui signifie que les donnes prsentes dans le corps du message ne sont pas utilises pour assurer les services du profil PRESTO (adressage, fiabilit du message, etc.).

Envelope PRESTO Header Opaque Body

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).

Version : 2.0.1 - Valide Page 16 / 38

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.

Envelope PRESTO Header Opaque Body

Envelope PRESTO Header Opaque Body


Envelope MetaData

Data Data

5.2. Entte spcifique PRESTO


Le protocole PRESTO impose la prsence, dans lentte SOAP de chaque message, dun entte spcifique portant des informations ncessaires ou complmentaires concernant ce message. Cet lment dentte comporte quatre parties : un lment References , obligatoire, comportant les informations didentification du message un lment Attachments , facultatif, comportant des informations sur les pices jointes ventuelles du message un lment Acknowledgement , facultatif, permettant deffectuer des demandes dacquittement un lment Routing , facultatif, comportant des informations sur le routage du message entre lmetteur et le(s) destinataire(s).

Llment dentte PRESTO dispose dun attribut indiquant la version de PRESTO utilise. Ici, il sagit de la version 2.0.1.

5.2.1. Entte References


Cet lment comporte quatre sous lments destines identifier un message et le placer dans un contexte des fins de corrlation. Seul llment messageId est obligatoire, du fait de la ncessit pour chaque message PRESTO de disposer dun identifiant unique. Llment References est dcrit en dtail dans la spcification PRESTO 2.0.1 Routage & Corrlation .

Version : 2.0.1 - Valide Page 17 / 38

PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core

5.2.2. Entte Attachments


Cet lment est dcrit en dtail dans la spcification PRESTO 2.0.1 Pices jointes .

5.2.3. Entte Acknowledgement


Cet lment est dcrit en dtail dans la spcification PRESTO 2.0.1 Acquittements .

5.2.4. Entte Routing


Cet lment est dcrit en dtail dans la spcification PRESTO 2.0.1 Routage & Corrlation .

5.3. Utilisation du style Document-Literal


Le Basic Profile du WS-I dfinit les termes document-literal et rpc-literal (http://wsi.org/Profiles/BasicProfile-1.1-2004-08-24.html#WSDLMSGS) sappliquant sur les styles dcriture autoriss pour les WSDL. Ce Profil limite le choix du style dcriture WSDL autoris par lexigence R2705 (http://ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html#R2705) au style document-literal . RP001 Un wsdl:port dans une DESCRIPTION DOIT utiliser un binding "document-literal".

5.4. Enveloppe SOAP dans un message HTTP Response


Les exigences du Basic Profile R2714 et R2750 indiquent que la rponse un message oneway doit inclure un code de rponse HTTP 2xx sans enveloppe SOAP et que lmetteur du flux doit ignorer toute envelope ventuellement retourne. Toutefois, des spcifications telles que WS-ReliableMessaging peuvent causer la gnration de messages SOAP qui ne sont pas considrs comme des rponses applicatives, mais qui doivent tre transmis lmetteur du message HTTP. En effet, si llment de rfrence wsrm:AcksTo a la valeur URI anonyme , alors le destinataire doit retourner des messages dacquittement de squence la source dans le message de rponse HTTP. Pour cette raison, PRESTO redfinit les R2714 et R2750 du Basic Profile 1.1 du WS-I. RP002 Un MESSAGE de Rponse HTTP correspondant une opration WSDL one-way PEUT contenir une enveloppe SOAP dans son corps de message.

Version : 2.0.1 - Valide Page 18 / 38

PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core

6. Adressage des messages


Le protocole PRESTO rend obligatoire lutilisation de WS -ReliableMessaging qui sappuie sur WS-Addressing. Pour cette raison ce chapitre nest fourni qu titre dillustration sur lutilisation des enttes dadressage. Afin de rpondre aux patterns dchange de messages correspondant aux cas dutilisation PRESTO, une solution dadressage est ncessaire. La localisation dun mandataire rcepteur PRESTO peut tre dtermine lexcution par une requte vers un annuaire UDDI. Cela permet de respecter un des principes dune architecture oriente service : la transparence de la localisation. Ladresse retourne par la requ te reprsente la localisation physique du mandataire destinataire PRESTO. Cela peut prendre la forme dune URL HTTP, si le protocole de transport utilis pour PRESTO est HTTP (transport par dfaut de PRESTO). Un message SOAP PRESTO contient des donnes mtier et des enttes SOAP contenant ladresse du point daccs devant recevoir et traiter les donnes mtier. Ce point daccs est ladresse dun mandataire rcepteur PRESTO dont la responsabilit est de transmettre la donne une application. En plus de ladresse du point daccs, un ensemble de proprits peuvent tre ajoutes afin de dcrire soit lapplication cible, soit nimporte quel autre paramtre technique ou applicatif permettant de dterminer lapplication cible . Cette section dcrit lutilisation de la spcification de services Web WS-Addressing [WSAddressing] dont lutilisation est OBLIGATOIRE pour PRESTO. Avec WS-Addressing le destinataire du message (le point daccs) est identifi par llment wsa:To et lopration excuter au sein du mandataire est identifie par llment wsa:Action. Llment wsa:From identifie la source du message et llment wsa:ReplyTo identifie qui transmettre les rponses. Enfin, llment wsa:FaultTo identifie le destinataire des erreurs. La spcification WS-Addressing stipule quun lment wsa:ReferenceParameters peut -tre associ chacun des lments didentification dun point daccs. Or, certaines implmentations ne peuvent pas accder simplement ces lments. Aussi, le profil PRESTO 2.0.1 nutilise pas ces lments. Dautre part, llment wsa:MessageID identifie de manire unique un message SOAP. Cependant, un message PRESTO peut, sil est volumineux, tre compos de plusieurs enveloppes SOAP disposant didentifiants diffrents, potentiellement gnrs par WSReliableMessaging. Pour identifier un message PRESTO, la spcification PRESTO 2.0.1 spcifie donc un champ dans ses propres en-ttes pour identifier un message PRESTO, que tous les segments dune squence WS-ReliableMessaging reprendront. Se rfrer la spcification Routage & Corrlation pour une description des champs didentification dun message. RP003 Pour des raisons dinteroprabilit, llment wsa:ReferenceParameters NE DOIT PAS tre utilis pour identifier un point daccs. RP004 Llment wsa:MessageID NE DOIT PAS tre utilis pou r identifier un message PRESTO.

Version : 2.0.1 - Valide Page 19 / 38

PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core

6.1. Expression des adresses de mandataire PRESTO


6.1.1. Prsence des blocs dentte
RP005 Une ENVELOPPE DOIT contenir exactement un entte wsa:To. RP006 Une ENVELOPPE DOIT contenir exactement un entte wsa:MessageID. RP007 Une ENVELOPPE DOIT contenir exactement un entte wsa:Action . RP008 Une ENVELOPPE DOIT contenir exactement un entte PRESTOHeader. Il DOIT comporter au minimum un identifiant de message (lment PRESTOHeader / References / messageId). Par exemple :
CORRECT: <s12:Envelope xmlns:s12="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://dgme.finances.gouv.fr/presto/metadata" xmlns:presto="http://www.w3.org/2005/08/addressing"> <s12:Header> <wsa:To>http://example.com/service</wsa:To> <wsa:ReplyTo s12:mustUnderstand="1"> <wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous </wsa:Address> </wsa:ReplyTo> <wsa:MessageID>uuid:aaaabbbb-cccc-dddd-eeee-ffffffffffff</wsa:MessageID> <wsa:Action> http://example.com/service/tbd </wsa:Action> <presto:PRESTOHeader version="2.0.1"> <presto :References> <presto:messageId>ID_MESSAGE</presto:messageId> </presto :References> </presto:PRESTOHeader> </s12:Header> <s12:Body> <!- body content OPAQUE to the PRESTO protocol --> </s12:Body> </s12:Envelope>

6.1.2. Envoi de message one-way


Ce scnario met en uvre le pattern denvoi de message one-way (comme dfini dans la section 3.1 Envoi de message one-way ) : un message est envoy dun mandataire metteur PRESTO vers un mandataire rcepteur PRESTO. 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 une rponse HTTP 202. Cette rponse nest pas une exigence du protocole PRESTO mais une simple consquence de la mise en uvre via HTTP.

Version : 2.0.1 - Valide Page 20 / 38

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>

Rponse HTTP : HTTP 202 Accepted

6.1.3. Echange de message Requte-Rponse


6.1.3.1 Emetteur PRESTO anonyme Ce scnario est le cas nominal et DOIT tre applicable par un metteur 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. WS-Addressing dfinit une URI anonyme pour les points daccs qui ne peuvent avoir une URI stable et rsolvable : http://www.w3.org/2005/08/addressing/anonymous. Cest le cas ici pour les points daccs de rponse. Par consquent, le champ wsa:ReplyTo contient cette constante anonyme, ce qui implique le renvoi dune rponse synchrone par le destinataire. Ainsi, les requtes dont le point daccs de rponse, dorigine ou derreur, contient cette adresse DOIVENT proposer un mcanisme de renvoi des rponses ou fautes (par exemple le renvoi de la rponse dans la mme connexion). Ce mcanisme peut tre un simple protocole de requte/rponse (par exemple HTTP GET ou POST pour la version actuelle de PRESTO). 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.

Version : 2.0.1 - Valide Page 21 / 38

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>

Version : 2.0.1 - Valide Page 22 / 38

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 -->

Version : 2.0.1 - Valide Page 23 / 38

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>

Version : 2.0.1 - Valide Page 24 / 38

PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core

7. Livraison fiable et qualit de service


Cette section dcrit lutilisation de la spcification WS-ReliableMessaging [WSReliableMessaging] au sein du protocole PRESTO pour assurer la fiabilit et la livraison ordonne des messages. Un mandataire metteur PRESTO remet un message un mandataire rcepteur PRESTO. Le mandataire rcepteur accuse rception en retournant un message au mandataire metteur. Le chemin de routage est dtermin par les diffrents messages utiliss par le standard WSReliableMessaging, comme par exemple CreateSequence, CloseSequence, SequenceAcknowledgement, et TerminateSequence. Au niveau du protocole, le mandataire metteur PRESTO, (c'est--dire la source ReliableMessaging), transmet avant un envoi de messages CreateSequence au mandataire destinataire PRESTO (c'est--dire la destination ReliableMessaging). La destination cre un identifiant de squence et retourne un message CreateSequenceResponse. Ensuite lmetteur procde lenvoi du ou des messages, chacun identifi par un numro incrment. Ensuite la destination rpond avec un message SequenceAcknowledgement qui contient le dtail des messages reus. Si certains manquent, la source renvoie les messages avec une demande daccus de rception. Aprs lacquittement de tous les messages, la source transmet un message CloseSequence, en attente dune rponse CloseSequenceResponse de la part du mandataire rcepteur. Enfin, la source transmet un message TerminateSequence en attente dune rponse TerminateSequenceResponse de la part du mandataire rcepteur . Les squences doivent tre conformes au cas gnral de la spcification WS-RM Section Appendix C. Message Examples . Les cas dutilisations suivants prsentent le m canisme dchange de WS-ReliableMessaging dans le cadre des patterns supports par PRESTO (voir la section 3 Patterns dchanges PRESTO ).

7.1. Envoi de message one-way


7.1.1. Emetteur anonyme PRESTO
Ce scnario met en uvre la forme la plus simple des patterns dchange. Il reprend le pattern PRESTO synchrone, envoi de message one-way (comme dfini dans la section 3.1 Envoi de message one-way ) pour envoyer un message dun mandataire metteur PRESTO vers un mandataire rcepteur PRESTO. Le mandataire metteur PRESTO et le mandataire rcepteur PRESTO tablissent une squence fiable partir dun change simple de messages CreateSequence/CreateSequenceResponse (CS/CSR). Le message CreateSequenceResponse est renvoy dans la rponse HTTP de la requte HTTP du message CreateSequence. Le mandataire metteur PRESTO envoie, dans notre exemple, un unique message PRESTO contenant la charge utile. A titre lillustration, la charge utile peut tre simplement une chane de caractre encode UTF-8. La diffrence entre les messages est la valeur de llment dentte wsrm:MessageNumber et ventuellement la charge utile du message qui est opaque pour le protocole PRESTO.

Version : 2.0.1 - Valide Page 25 / 38

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.

7.1.2. Emetteur adressable PRESTO


Ce scnario met en uvre la seconde forme simple des patterns dchange. Il reprend le pattern synchrone dcrit prcdemment. Le mandataire metteur PRESTO et le mandataire rcepteur PRESTO tablissent une squence fiable de la mme manire que pour un metteur anonyme, mise part que le message CreateSequenceResponse est renvoy dans un second canal HTTP canal de retour . Toutes les rponses HTTP (transport actuellement retenu pour PRESTO) la fois pour lmetteur PRESTO et pour le rcepteur PRESTO sont 202 Accepted. Les acquittements HTTP ont t omis car ils ne sont pas une particularit du protocole PRESTO mais simplement une consquence de la mise en uvre de PRESTO sur le transport HTTTP. Lchange effectu est strictement identique lchange synchrone dcrit prcdemment. Une fois que le mandataire metteur PRESTO reoit un acquittement qu i couvre lensemble des messages, il transmet un message CloseSequence au mandataire rcepteur PRESTO. La rponse HTTP de ce message doit tre 202 Accepted. Le mandataire rcepteur PRESTO transmet ensuite au mandataire metteur un message CloseSequenceResponse. La rponse HTTP de ce message doit galement tre 202 Accepted. Ensuite, le mandataire metteur transmet un message TerminateSequence au mandataire rcepteur PRESTO. La rponse HTTP de ce message doit tre 202 Accepted. Le mandataire rcepteur PRESTO transmet ensuite au mandataire metteur un message TerminateSequenceResponse. La rponse HTTP de ce message doit galement tre 202 Accepted. Les lments dadressage wsa:ReplyTo et wsrm:AcksTo EPRs NE DOIVENT PAS tre anonymes et doivent pouvoir tre joignables par le mandataire rcepteur PRESTO. Le mandataire rcepteur PRESTO doit envoyer ses messages sur des canaux HTTP distincts.

Version : 2.0.1 - Valide Page 26 / 38

PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core

7.2. Echange de message Requte-Rponse


Ce scnario met en uvre une forme plus complexe dchange qui ncessite une squence duplex pour supporter un pattern de messagerie requte-rponse . (Comme dfini dans la section 3.2 Echange de message Requte-Rponse ) : un message est transmis partir dun mandataire metteur PRESTO vers un mandataire rcepteur PRESTO et ensuite une rponse est transmise en retour partir du rcepteur PRESTO vers lmetteur PRESTO . Le mandataire metteur PRESTO doit tre adressable et joignable par le mandataire rcepteur PRESTO. Le mandataire metteur PRESTO envoie les messages au mandataire rcepteur PRESTO et attend des rponses en retour. Le mandataire metteur PRESTO et le mandataire rcepteur PRESTO tablissent une squence fiable duplex avec un change de messages CS/CSR, comprenant les lments wsrm:Offer et wsrm:Accept. Le mcanisme Offer/Accept est utilis pour tablir deux squences corrles rciproques qui forment une session (voir la spcification WS-ReliableMessaging). Le mandataire metteur PRESTO envoie, dans notre exemple, un unique message PRESTO contenant la charge utile. A titre lillustration, la charge utile peut tre simplement une chane de caractre encode UTF-8. La rponse HTTP est toujours 202 Accepted. Les acquittements HTTP ont t omis car ils ne sont pas une particularit du protocole PRESTO mais simplement une consquence de la mise en uvre de PRESTO sur le transport HTTP. Quand les requtes sont traites, le mandataire rcepteur PRESTO rpond. Le mandataire metteur PRESTO attend une rponse du mandataire avant dmettre une nouvelle requte. Pour lacquittement des messages, le mandataire metteur PRESTO et le mandataire rcepteur PRESTO peuvent envoyer les acquittements seuls ou via un piggy-backing (placement des acquittements en en-tte dautres messages envoys en mme temps). Une fois que tous les messages ont t changs et acquitts, lmetteur envoie un message CloseSequence puis un message TerminateSequence au mandataire rcepteur PRESTO et considre que la squence est termine. A ce point, un mandataire rcepteur PRESTO fera typiquement la mme chose : envoi dun message TerminateSequence pour la squence une fois que tous les messages sont reus.

7.3. Bloc dentte de squence


Quand un message est envoy de manire fiable, avec WS-ReliableMessaging, il est impratif que le destinataire puisse traiter correctement llment dentte wsrm:Sequence.

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"

Version : 2.0.1 - Valide Page 27 / 38

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>

7.4. Bloc dentte dacquittement de squence


7.4.1. Piggy-backing des acquittements de squence
Quand une enveloppe SOAP est transmise la mme adresse que celle prcise par un lment dentte wsrm:CreateSequence/wsrm:AcksTo, alors la destination (par exemple un mandataire rcepteur PRESTO) peut ajouter un acquittement de squence dans lentte SOAP (pour chaque squence idoine) au lieu de les transmettre la source (par exemple un

Version : 2.0.1 - Valide Page 28 / 38

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.

7.4.2. Transport dacquittement dans une rponse HTTP dopration one-way


Les exigences du Basic Profile R2714 (http://ws-i.org/Profiles/BasicProfile-1.1-2004-0824.html#R2714) et R2750 (http://ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html#R2750) sont en conflit avec la possibilit de transmettre des acquittements de squence dans les messages de rponse HTTP pour les envois one-way avec fiabilit. En effet, les intituls de ces exigences sont les suivants : R2714 : For one-way operations, an INSTANCE MUST NOT return a HTTP response that contains an envelope. Specifically, the HTTP response entity-body must be empty R2750 : A CONSUMER MUST ignore an envelope carried in a HTTP response message in a one-way operation. Or cette exigence est susceptible dtre courante pour les cas dutilisations o la source de lchange fiable est situe derrire un firewall, ce Profil redfini les exigences du Basic Profile R2714 et R2750. RP016 Un MESSAGE correspondant la rponse dun message de type one-way PEUT contenir une enveloppe SOAP avec un lment dentte wsrm:SequenceAcknowledgement et aucun lment dans le s12:Body. RP017 Un CONSOMMATEUR qui spcifie lURI Anonyme de WS-Addressing comme adresse de llment dentte wsrm:CreateSequence/wsrm:AcksTo DOIT pouvoir recevoir et traiter des messages rponses HTTP contenant une enveloppe SOAP pour des oprations one-way.

7.5. Composition avec WS-Addressing


RP018 Quand lURI Anonyme de WS-Addressing est utilise dans llment dentte wsrm:AcksTo dune enveloppe wsrm:CreateSequence, tous les messa ges dacquittement de la squence DOIVENT tre renvoys dans le flux de rponse de la connexion HTTP utilis pour la rception des messages contenant llment dentte wsrm:Sequence. La capacit de retenter lenvoi de messages est un lment cl de WS -ReliableMessaging. Pour cela, il est ncessaire que lmetteur dun message puisse tablir une connexion avec le destinataire. Ainsi, lutilisation dune URI anonyme dans llment dentte wsa:ReplyTo de la requte enfreint cette rgle car lmetteur de la r ponse ne peux initier une connexion en retour pour supporter ReliableMessaging.

Version : 2.0.1 - Valide Page 29 / 38

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).

7.6. Garantie de livraison et ordonnancement


Afin dassurer une qualit de service maximum pendant les changes de documents, lassurance ExactlyOnce (i.e. exactement une fois) est exige. Lassurance InOrder (i.e. dans lordre) est galement exige. Cette exigence permet de sassurer que le payload arrive en dernier dans une squence WS -RM. En effet, dans le cas de transport dune pice-jointe volumineuse (voir lextension PRESTO : Pices-jointes), celle-ci est transporte par morceau dans de multiples segments WS-RM et le dernier segment WS-RM transmis comprend, en plus du dernier morceau de pice-jointe, le payload. Ainsi, on peut facilement dtecter le dernier message dune squence : cest celui qui contient le payload. (Cette exigence a t ajoute du fait que toutes les implmentations de WS-RM ne permettent pas facilement de connatre le dernier message). Note : dans le cas o le message transmettre nest compos que de pices jointes sans payload particulier, un payload minimal devra tre insr. RP020 Lassurance de livraison des MESSAGES DOIT tre ExactlyOnce InOrder.

Version : 2.0.1 - Valide Page 30 / 38

PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core

8. Gestion des pices jointes


Pour lenvoi de documents binaires de gros volume (potentiellement plusieurs M o) au sein de la charge utile, le protocole PRESTO rend obligatoire lutilisation de deux spcifications du W3C : XML-binary Optimized Packaging [XOP] et SOAP Message Transmission Optimization Mechanism [MTOM]. MTOM avec XOP permet lenvoi de contenu binaire en dehors de lenveloppe SOAP (en tant que pice jointe MIME) et sans encodage Base64. Au lieu de la donne encode en Base64 dans le document Infoset XML, un lment spcifique XOP donne un lien vers un contenu optimis dans le message MIME. Le rsultat (aprs la srialisation de linfoset) est connu en tant que package XOP et comprend le document XML (XOP Document) et le contenu extrait en parties MIME. MTOM dcrit comment optimiser la transmission du message SOAP (en particulier lenveloppe) et est lie la spcification XOP qui dcrit limplmentation de loptimisation. Le mandataire metteur PRESTO se charge de ces oprations. Le mandataire rcepteur PRESTO qui reoit le message SOAP est responsable de la reconstruction du message en replaant les contenus optimiss sous la forme Base64, bien que cela ne soit pas obligatoire.

8.1. Transport de documents binaires


Afin de respecter linfoset XML, les documents binaires doivent tre inclus dans le document XML sous la forme dun lment binaire base 64. Le contenu binaire de llment XML peut tre dcrit en utilisant un attribut xmime:ContentType comme dfini dans la note du W3C Describing Media Content of Binary Data in XML (http://www.w3.org/TR/xml-media-types/). RP021 Un document binaire DOIT tre encod en base 64 puis inclus dans le message.

8.2. Optimisation du transport des donnes binaires


Lutilisation de lencodage base 64 augmente la taille des documents. Lutilisation du mcanisme doptimisation MTOM/XOP facilit le transport des documents en slectionnant et en optimisant les lments binaires de la donne XML. Les lments encods en base 64 doivent tre dans une forme canonique du type de donnes XML xs:base64Binary. RP022 Pour tre optimiss, les caractres de tous les lments binaires du MESSAGE doivent tre dans une forme canonique du type de donne XML xs:base64Binary.

Version : 2.0.1 - Valide Page 31 / 38

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 ***).

Version : 2.0.1 - Valide Page 32 / 38

PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core

10. Interface gnrique PRESTO 2.0.1 Core


Une interface gnrique de mandataire est fournie en complment de la spcification du profil PRESTO 2.0.1. Cette interface se prsente sous la forme dun fichier WSDL directement utilisable par les partenaires pour limplmentation de leurs mandataires compatibles PRESTO 2.0.1 (en adoptant une approche Top Down ). Il sagit donc de linterface Boite noire expose aux autres mandataires PRESTO et non pas de linterface Boite blanche (tel que dcrit dans le paragraphe 3.2). Cette interface gnrique est fournie titre dexemple et ne constitue pas une spcification de PRESTO 2.0.1. En particulier, les mthodes GetMessage et SendMessage dcrites dans cette interface ne sont pas imposes par la spcification PRESTO 2.0.1.

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. Description du WSDL fourni


Nom du fichier : presto.wsdl Il est accompagn des fichiers wsd0.wsdl, xsd0.xsd, xsd1.xsd, xsd2.xsd et Location.xsd.

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

Version : 2.0.1 - Valide Page 33 / 38

PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core

http://dgme.finances.gouv.fr/presto/metadata

Target namespace correspondant aux types de donnes des enttes PRESTO

10.2.2. Types de donnes


Les types de donnes manipuls par le service sont les suivants : Type Schma XSD
<complexType name="DataType"> <sequence> <element name="message" type="xs:string"/> <element name="attachment" nillable="true" type="s:AttachmentType"/> </sequence> </complexType> <complexType name="DataType"> <sequence> <element name="message" type="xs:string"/> </sequence> </complexType> <complexType name="AttachmentType"> <sequence> <element name="fileName" type="xsd:string"/> <element name="binaryData" type="xmime:base64Binary" xmime:expectedContentTypes="*/*"/> </sequence> </complexType> <complexType name="Acknowledgement"> <sequence> <element name="status" type="string"/> <element name="code" type="string"/> <element name="message" type="string"/> </sequence> </complexType>

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

Version : 2.0.1 - Valide Page 34 / 38

PRotocole dEchanges Standard et Ouvert Guide pour le support de PRESTO 2.0.1 Core

10.2.3. Operations exposes


Les oprations exposes par le service sont les suivantes : Type
SendMessage

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

PRESTO exchange area


Sender Proxy Sender Proxy Private Implementation

PRESTO Protocol Endpoint

Sender Proxy Public Interface

Source Application

GetMessage() SendMessage() Acknowledge()

requestresponse Request Request

Target Application

Version : 2.0.1 - Valide Page 35 / 38

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.

Version : 2.0.1 - Valide Page 36 / 38

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.

Version : 2.0.1 - Valide Page 37 / 38

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.

Version : 2.0.1 - Valide Page 38 / 38

Vous aimerez peut-être aussi