Architecture du Système d Information sur l Eau Spécifications techniques Partie 1 Services Version 1.1

(1)

Spécifications techniques Partie 1 – Services

Version 1.1

Titre Architecture du Système d’Information sur l’eau – Spécifications techniques – Partie 1 – Services

Créateur Système d’Information sur l’Eau / SANDRE

Sujet Services web ; interopérabilité ; rss ; géoservices ; protocole.

Description Décrit les caractéristiques techniques à respecter pour le développement de services web de manière à garantir l’interopérabilité des services entre les partenaires du SIE.

Editeur Ministère de l’Ecologie et du Développement Durable

Contributeur Pierre Lagarde, René Lalement, François-xavier Prunayre, Société SILOGIC, Sylvain Grellet

Date / Création Date / Modification Date / Validation

2005/12/07 2008/05/30 2008/06/04

Type Text

Format OpenDocument ; PDF

Identifiant http://ftp.sandre.eaufrance.fr/public/sandre/francais/asie/ASIE_Specifica tionsTechniquesPartieI_v1.1

Langue Fr

Relation / est remplacé par Relation / remplace Relation / référence

Couverture France

Droits © SANDRE

Version 1.1

(2)

Création du document en version 2005-1

Evolutions Document Version 2005-1 Version 2008 – 1.1

P15, l'expression régulière ((-?[0-9]{4})-([0-9]{2})-([0-9]{2})T([0-9]{2}):([0-9]{2}):([0-9]

{2})(\.[0-9]*)?(Z|[+\-][0-9]{4}|[+\-][0-9]{2}:[0-9]{2})?)? Devient :

((-?[0-9]{4})-([0-9]{2})-([0-9]{2})T([0-9]{2}):([0-9]{2}):([0-9]{2})(.[0-9]*)?(Z|[+\-][0-9]{4}|

[+\-][0-9]{2}:[0-9]{2})?)?

1. CONTEXTE ET OBJECTIFS DU DOCUMENT...5

2. LES COMPOSANTES TECHNIQUES DE L’ARCHITECTURE...6

2.1 LESCHÉMADEPRINCIPEDEL’ARCHITECTURETECHNIQUE...6

2.2 LESCOMPOSANTESTECHNIQUES ...7

2.3 INSTANCESDENORMALISATION...7

2.3.1 IETF - Internet Engineering Task Force ...7

2.3.2 W3C - World Wide Web Consortium...7

2.3.3 OASIS - Organization for the Advancement of Structured Information Standards ...8

2.3.4 WS-I - Web Services Interoperability Organization ...8

2.3.5 OGC - Open Geospatial Consortium ...8

3. SPECIFICATIONS TECHNIQUES ASIE (NORMATIVE)...9

3.1 PÉRIMÈTRED’APPLICATIONDESRÈGLESD’INTEROPÉRABILITÉ...9

3.2 ORGANISATIONETNOTATIONDESRÈGLESD’INTEROPÉRABILITÉ...9

3.3 PROTOCOLED’ÉCHANGES...10

3.4 L’ÉCHANGEDESMESSAGESENMODESYNCHRONE...10

3.4.1 Mécanisme d’échange des messages sur HTTP...10

3.4.2 Type de paramètres échangeables...13

3.4.3 La description d’un service...15

3.4.4 La gestion des versions pour les services...17

3.4.5 La gestion des erreurs...19

3.4.6 Problème des timeout...21

3.5 ECHANGEDESMESSAGESENMODEASYNCHRONE...22

3.5.1 Mécanisme général...22

3.5.2 Description des services asynchrones...24

3.5.3 Accessibilité des services...26

3.6 ECHANGEDESDONNÉESVOLUMINEUSES...26

3.6.1 La compression des données...26

3.6.2 Transmission des données attachées en SOAP...27

3.7 L’ÉCHANGEDEDONNÉESGÉOGRAPHIQUES...27

3.7.1 Approche REST exclusivement...28

3.7.2 Transmission de données sous forme d’images ...28

3.7.3 Transmission de données sous forme vectorielle...29

3.7.4 Gestion des services transactionnels spatialisés...29

3.7.5 Gestion des styles de représentation des données spatialisées...30

3.7.6 Filtrage des données spatialisées...31

3.7.7 Sauvegarde de carte...32

3.7.8 Système de projection...32

3.8 L’ÉCHANGEDEDONNÉESDEMANIÈRESÉCURISÉE...32

3.8.1 Rappel des objectifs...32

3.8.2 Intégrité des données ...33

(3)

3.8.3 Authentification...33

3.9 O^RGANISER^ET^FÉDÉRER^LASYNDICATIONDECONTENUS...34

3.9.1 Utilisation des flux rss...34

3.9.2 Contenu et métadonnées du fil RSS ...34

3.9.3 Décrire un fichier partagé...35

3.9.4 Le référencement des fils RSS...37

4. ANNEXE I : IMPLEMENTATIONS DES SPECIFICATIONS (INFORMATIVE)...39

4.1 P^RINCIPES...39

4.2 OUTILSPOURLESSERVICESENMODE REST...39

4.3 O^UTILS^POUR^LES^SERVICES^EN^MODE SOAP...39

4.3.1 .NET...39

4.3.2 JAVA...39

4.3.3 PHP...39

4.4 O^UTILS^POUR^LES^SERVICES^DE^DONNÉESVOLUMINEUSES...40

4.4.1 .NET...40

4.4.2 JAVA...40

4.4.3 PHP...41

4.5 O^UTILS^POUR^LES^FILS RSS...41

4.5.1 Lecteurs de fils RSS...41

4.5.2 Outils pour la génération de fils...41

4.6 OUTILSPOURLESSERVICESSPATIALISÉS...44

4.6.1 Outils Serveurs...44

4.6.2 Outils Clients...47

4.6.3 Liens...50

4.6.4 Conclusion...50

5. ANNEXE II : CAS D’UTILISATION DES SPECIFICATIONS TECHNIQUES (INFORMATIVE)...51

5.1 CAS I : SYNDICATION DE CONTENUS...51

5.1.1 Les acteurs concernés...51

5.1.2 Description du cas d’utilisation...52

5.2 SPÉCIFICATIONSUTILISÉESPOURTRAITERLECASD’UTILISATION...53

5.3 CAS II : RECHERCHE DE LOTS DE DONNEES...54

5.3.3 Spécifications utilisées...57

5.4 CAS III : APPELÀUNENSEMBLEDEDONNÉESAUFORMAT XML-SANDRECOMPRESSÉES...57

5.5 SPÉCIFICATIONSUTILISÉES...59

5.6 CAS IV : SERVICESCARTOGRAPHIQUES...59

5.6.3 Spécifications utilisées...60

5.7 CAS V : ENVOI D’UNE DONNEE VIA UN SERVICE SECURISE...60

5.8 SPÉCIFICATIONSUTILISÉES...61

6. ANNEXE III (INFORMATIVE) : ANALYSE SUR LES FLUX RSS...62

(4)

Le document « Spécifications techniques de l’architecture SIE – Partie 1 : Services » est décomposé en trois parties et trois annexes :

La partie I présente les objectifs du document.

La deuxième partie du document reprend les principes de l’architecture ASIE pour en dégager les grandes composantes utiles à une compréhension générale des spécifications techniques. Les principales instances de normalisation y sont aussi rapidement présentées.

La troisième partie est le chapitre normalisé décrivant les spécifications techniques.

L’annexe I (Informative) propose des implémentations techniques respectant les spécifications techniques. Cette partie est uniquement informative.

L’annexe II (Informative) présente des cas d’utilisation des spécifications.

L’annexe III (Informative) est un résumé sur les standards RSS.

Les termes DOIT, NE DOIT PAS, DEVRAIT, NE DEVRAIT PAS, PEUT, OBLIGATOIRE, RECOMMANDE, OPTIONNEL ont un sens précis. Ils correspondent à la traduction française de la norme RFC2119 (RFC2119) des termes respectifs MUST, MUST NOT, SHOULD, SHOULD NOT, MAY, REQUIRED, RECOMMENDED et OPTIONAL.

(5)

1. CONTEXTE ET OBJECTIFS DU DOCUMENT

Le Système d’Information sur l’Eau (SIE) fédère un ensemble de partenaires coopérant dans le domaine de l’information environnementale publique dans le domaine de l’eau, à travers un ensemble de projets qui sont coordonnés par la Direction de l’eau. Le SIE a parmi ses objectifs de construire une architecture de banques de données et de portails de services permettant la satisfaction des besoins des utilisateurs des données sur l’eau.

Dès 1993, le RNDE a défini des recommandations d’architecture fondées sur la capacité des partenaires à échanger des données entre eux et sur l’élaboration d’un référentiel commun. Les nouvelles obligations (convention d’Århus, directive cadre sur l’eau) ont conduit les partenaires à évoluer à partir de cette base vers une architecture de système d’information fondée sur la fourniture de services. Cette évolution porte sur la période 2004-2006 :

•Une étude sur l’interopérabilité a été conduite en 2004 afin de déterminer les technologies d’interopérabilité adaptées aux besoins du SIE, de réaliser un prototype utilisant ces technologies (SOAP, WMS, LDAP), et de tester leur implantation chez un nombre restreint de partenaires.

•Un groupe de travail « Architecture » a été créé en décembre 2004 avec les partenaires du SIE afin de piloter la définition et la mise en œuvre de sa nouvelle architecture.

•Un Livre vert¹ a été publié en janvier 2005, sur les bases de l’étude précédente, pour présenter les enjeux et les contraintes de l’architecture du SIE et les lignes directrices de l’architecture envisagée : une architecture distribuée fondée sur le Web constituée de services à faible couplage ;

•Le cadre général de l’architecture du SIE (ASIE) est élaboré dans la continuité du livre vert : Ce document de référence définit les objectifs et les principes d’architecture du SIE.

Le passage des principes conceptuels à une mise en œuvre opérationnelle se heurte souvent à des problèmes techniques, notamment dans des configurations très hétérogènes. La définition de spécifications techniques complètes et précises garantissant l’interopérabilité a donc été l’objectif prioritaire du groupe Architecture SIE. Le Sandre a été chargé avec l’appui d’une société informatique d’établir les spécifications techniques de l’architecture du SIE. Ce travail a abouti à la première version de ce présent document.

Ce document est la version 1 des spécifications techniques du SIE. Elle ne couvre qu’une partie du domaine couvert par l’architecture du SIE. Certains sujets (notamment les métadonnées, annuaire, sécurité) ne sont pas abordés ou sont traités de façon simplifiée. De plus, en raison des problèmes d’interopérabilité entre les solutions technologiques, il n’a pas toujours été possible d’utiliser les normes définis par les instances de normalisation ; dans ce cas, des solutions proches (mais interopérables) ont été privilégiés dans l’attente d’un déploiement à une échelle suffisante des derniers standards du W3C, OASIS ou de l’OGC.

Les spécifications techniques évolueront dans le temps afin de couvrir un périmètre technique plus vaste ou pour prendre en compte de nouveaux standards (ou déploiement). Néanmoins, les évolutions seront limitées et planifiées sur quelques années de manière à éviter les problèmes de compatibilité entre les déploiements des différentes versions des spécifications par les partenaires.

1 Cf. http://www.ecologie.gouv.fr/IMG/pdf/ArchSIE_LivreVert2005_Final.pdf.

(6)

2. LES COMPOSANTES TECHNIQUES DE L’ARCHITECTURE

2.1 Le schéma de principe de l’architecture technique

Le cadre général de l’architecture décrit les principes de l’architecture. En simplifiant pour une vision technique, le schéma peut se résumer aux rôles suivants :

•Un fournisseur de services web qui expose des services et des données. Généralement, le fournisseur publie des données sur l’eau (mode descendant). Quelquefois il propose d’intégrer des données (mode ascendant).

•Un consommateur de services web qui utilise des services exposés. Généralement, il recherche des données, puis les récupère et les traite. Il peut aussi s’agir de transmettre un jeu de données pour réaliser un traitement métier particulier (calcul d’un indice de qualité par exemple), ou d’agréger un jeu de données élémentaires pour diffuser ce nouveau service de données élaborées, etc.

•Une infrastructure commune qui assure le rôle de « référentiel d’entreprise » du SIE. Cette infrastructure commune ne doit pas être comprise comme un orchestrateur de services, mais plutôt une mutualisation de services communs à tous les échanges fournisseur / consommateur : annuaire des intervenants, catalogues de métadonnées de données et de services, référentiels communs.

•Un management général de l’infrastructure , où est notamment traité les aspects relatifs à la sécurité, les performances et la supervision.

Le schéma ci-après illustre le principe :

Fournisseur de services

Consommateur de services

Annuaire Métadonnées de données

Métadonnées de services

Référentiels

Infrastructure commune

Sécurité Management

Performances

(7)

2.2 Les composantes techniques

Sur le schéma précédent, il est possible d’analyser différentes catégories de composantes techniques :

1. Les spécifications techniques pour les « services web » entre fournisseur et consommateur de services : canaux de communication, infrastructure des services (REST, SOAP), représentation de l’information (XML-Sandre, HTML, GML,…)

2. Les spécifications techniques de l’infrastructure en distinguant :

•L’annuaire : définition d’un annuaire mutualisé

•Les métadonnées de données et de services

•Les référentiels

3. Les spécifications du management

•La modélisation générale de l’infrastructure de services (comment modéliser et maintenir cette infrastructure, la publication et description des services ?)

•La gestion du déploiement

•La gestion de la sécurité

•La supervision de l’infrastructure générale et le suivi des performances.

Ce document Partie 1 porte uniquement sur les spécifications techniques relatives aux services.

2.3 Instances de normalisation

Le présent document s’appuie très largement sur des normes internationales ouvertes et libres. Ces normes sont généralement élaborées par l’une des instances suivantes.

2.3.1IETF - Internet Engineering Task Force

Littéralement traduit de l'anglais en « Mission d'ingénierie d'Internet », l’IETF est un groupe informel, international, ouvert à tout individu, qui participent à l'élaboration de standards pour Internet. L'IETF rédige les Request for comments (RFC), nom donné aux documents de spécification à la base d'Internet.

www.ietf.org

2.3.2W3C - World Wide Web Consortium

Organisme de promotion du web créé en 1994 sous l'impulsion de Tim Berners Lee. Son principal objectif est la mise au point de recommandations et de protocoles ouverts et libres, dans un souci d'interopérabilité maximale. Il est géré conjointement par le MIT aux É-U, l’European Research Consortium for Informatics and Mathematics (ERCIM) en France et l'université Keio au Japon. Le W3C n'émet pas des normes, mais des recommandations.

www.w3c.org

(8)

2.3.3OASIS - Organization for the Advancement of Structured Information Standards

Consortium à but non lucratif qui dirige le développement, la convergence ainsi que l’adoption des standards de l’e-commerce. Il comprend plus de 600 membres (entreprises et individus) dans une centaine de pays

www.oasis-open.org

2.3.4WS-I - Web Services Interoperability Organization

Association née en 2002 sous l'impulsion de Microsoft, d'IBM et de BEA Systems, dont la vocation est de veiller à l'interopérabilité des services Web. Le WS-I définit des profils d'utilisation des normes d'interopérabilité.

www.ws-i.org

2.3.5OGC - Open Geospatial Consortium

L'Open Geospatial Consortium (OGC) est une organisation internationale dédiée au développement de systèmes d’informations géographiques inter-communicables et inter-opérables. Les spécifications techniques OGC qu'elle publie définissent des interfaces de systèmes inter opérables.

www.opengeospatial.org

(9)

3. SPECIFICATIONS TECHNIQUES ASIE (NORMATIVE)

3.1 Périmètre d’application des règles d’interopérabilité

Le schéma ci-dessous décrit sous forme de couches l’ensemble des aspects (protocoles, normes, conventions) où l’interopérabilité doit être vérifiée.

3.2 Organisation et notation des règles d’interopérabilité.

Dans les chapitres suivants, il est présenté un ensemble de règles d’interopérabilité que chaque couche du schéma précédent devra respecter pour garantir l’interopérabilité des services SIE.

Les règles sont identifiées par la notation suivante :

ASIE-[NUMERO DE LA REGLE]. [REGLE A RESPECTER]

Les termes DOIT, NE DOIT PAS, DEVRAIT, NE DEVRAIT PAS, PEUT, OBLIGATOIRE, RECOMMANDE, OPTIONNEL ont un sens précis. Ils correspondent à la traduction française de la norme RFC2119 (RFC2119).

Les règles sont généralement accompagnées de textes permettant une meilleure compréhension de l’exigence spécifiée par le SIE ou d’expliciter les choix relatifs à la règle.

(10)

L’analyse débute des couches protocoles pour se finaliser sur la définition de services.

3.3 Protocole d’échanges

Cette partie décrit les protocoles qu’ils peuvent être utilisées pour l’échange d’informations dans le cadre du SIE.

ASIE-1. Tous les échanges de message DOIVENT s’effectuer en utilisant le protocole TCP/IP.

ASIE-2. Tous les mécanismes de services DOIVENT s’effectuer en utilisant le protocole HTTP Version 1.1 [RFC 2616]

Il est à noter que cette règle est toujours applicable lorsqu’une couche de sécurité SSL est ajoutée au protocole HTTP (HTTPS).

Pour le partage de fichiers, il est possible d’utiliser le protocole FTP (en complément ou à la place d’une transmission par HTTP). Ce dernier est réservé uniquement à cet usage et ne sera pas exploité pour l’échange de services WEB.

ASIE-3. Le partage de fichiers PEUT s’effectuer par le protocole FTP (RFC 959²)

Dans ce cas, tous les fichiers partagés DOIVENT être décrits par un flux RSS selon les spécifications décrites dans la spécification 3.9.3.

3.4 L’échange des messages en mode synchrone

3.4.1Mécanisme d’échange des messages sur HTTP

Comme décrit dans le cadre général de l’architecture du SIE, deux mécanismes sont autorisés pour la mise en œuvre d’échanges sur HTTP : le protocole SOAP ou l’approche REST.

3.4.1.1 Présentation du style REST

Le style REST (REpresentational State Transfer) est un style d’architecture répartie hypermédia proposé par Roy T. Fielding dans sa thèse « Architectural Styles and the Design of Network-based Software Architectures » (2000). Ce style a été conçu pour décrire (rétrospectivement) l’architecture du Web, mettant en exergue le caractère sans état du protocole HTTP, et considérant que les interactions entre un client et un serveur web ont la forme d’un changement d’état dû au transfert au client de la représentation de la ressource qu’il a requise. Ce style repose sur les notions de ressource, qui s’applique autant aux pages web qu’aux services web, d’URI (Uniform Resource Identifier) et de représentation. Le principe de ce changement d’état est le suivant :

2 www.faqs.org/rfcs/rfc959.html

(11)

•à partir d’un état d’information initial, le client requiert une ressource web qu’il référence en utilisant une URI connue dans cet état ;

•le Web répond à cette requête en retournant au client une représentation de cette ressource, ce qui place le client dans un nouvel état d’information.

La représentation d’une ressource (qui est transférée du serveur au client) a une nature d’hypermédia, c’est-à-dire contient des URI d’autres ressources. Le client, recevant cette représentation, est donc placé dans un nouvel état qui lui permet de construire et d’utiliser de nouvelles URI pour requérir les ressources qu’elles désignent, etc. Le client change ainsi d’état en « naviguant », mais le serveur n’a pas d’état : la requête doit contenir toute l’information nécessaire à sa compréhension par le serveur (qui oublie les requêtes précédentes). En réalité, le client n’interroge pas un « serveur web », mais le

« Web » : le protocole HTTP (avec le service de noms de domaines de l’Internet) a la capacité d’une part de relayer la requête à travers des « proxys » (mandataires de sécurité), d’autre part d’utiliser des caches pour optimiser l’efficacité du réseau. Toutes les ressources sont accessibles à travers une interface générique, l’une des méthodes GET, POST, PUT ou DELETE du protocole HTTP :

•GET est utilisée pour obtenir une représentation d’une ressource, sans causer d’effet de bord ; dans le cas d’un service, ceci permet d’obtenir ses propriétés ou le résultat de l’exécution d’un processus ;

•POST est utilisée pour modifier ou créer une représentation d’une ressource, sous la forme d’un contenu XML de la requête ; dans le cas d’un service, ceci permet de transmettre au serveur le contexte de création d’un processus (ses paramètres d’exécution) ;

•PUT est utilisée pour créer une représentation d’une ressource ;

•DELETE est utilisée pour supprimer une représentation d’une ressource.

Aucune contrainte n’est imposée au contenu XML des messages POST ou PUT, dès lors qu’il est interprétable par la ressource requise par la requête, contrairement à SOAP, qui impose la syntaxe SOAP.

3.4.1.2 Présentation du protocole SOAP

A la différence de REST, SOAP (Simple Object Access Protocol), est un protocole ; il est destiné à l’échange d’information structurée dans un environnement réparti. Proposé par Microsoft, SOAP est une spécification du W3C depuis 2003. SOAP transporte l’information au moyen d’une encapsulation XML normalisée, conçue pour être indépendante de tout modèle de programmation et d’implémentation. D’une manière simplifiée, le protocole SOAP permet d’échanger des données (XML selon une sémantique donnée ou d’autres formats de données) d’un point (émetteur) à un autre point (récepteur) en les encapsulant dans un message contenant :

•une enveloppe ;

•un en-tête qui contient des informations spécifiques aux services SOAP et permet notamment de véhiculer des informations liées aux transactions, au routage ou à la sécurité (la plupart des spécifications WS-Agreement, WS-Addressing, WS-Eventing, …, s’appuient sur cet en-tête pour

« compléter » le protocole SOAP) ;

•un corps contenant toutes les informations sur l’appel distant (paramètres, données XML, …) ;

•éventuellement, des attachements qui permettent de véhiculer des données hors du corps, comme un fichier compressé ou des images.

Le message est ensuite échangé dans un quelconque protocole d’interaction (HTTP dans le cas de la présente spécification) conformément à une liaison entre la spécification de SOAP et son implémentation sur l’un de ces protocoles. Le protocole SOAP est complété par le langage WSDL

(12)

(Web Service Description Langage), dialecte XML dédié à la description de tous les éléments nécessaires pour interagir avec un service web.

3.4.1.3 Spécifications REST

Dans le cadre de l’architecture SIE, les règles suivantes s’appliquent :

ASIE-4. Le choix de l’utilisation de la méthode HTTP GET ou POST pour implémenter un service web REST synchrone DEVRAIT suivre les recommandations du W3C disponibles à l’URL suivante : http://www.w3.org/2001/tag/doc/whenToUseGet.htm Dans le cadre des échanges en mode synchrone en mode REST, le choix de la méthode HTTP GET ou HTTP POST est souvent posé. En reprenant le document du W3C, il est conseillé de respecter les règles suivantes.

On utilise GET si :

•L’interaction est une requête sure (i.e. si c’est une opération sans risque telle qu’une requête, une opération de lecture ou une recherche).

On utilise POST si :

•L’interaction est une commande.

•L’interaction change l’état de la ressource de manière perceptible pour l’utilisateur (e.g. la souscription à un service).

•L’utilisateur doit être jugé responsable des résultats de l’interaction.

Dans la plupart des services REST à déployer dans le cadre du SIE, il sera privilégié la méthode HTTP GET

Les avantages d’utiliser GET sont :

•Simple à développer, à tester avec un navigateur web par exemple

•Tous les paramètres sont de type « string » et ont un format nom = valeur

•Compatible avec les caches HTTP, Proxy HTTP

•URI enregistrable dans l’historique d’un navigateur

•URI enregistrable comme « favoris » (bookmark)

Les inconvénients sont :

•Limite de la longueur des URI (256 caractères maximum d’après W3C³)

•Tous les paramètres sont visibles directement dans l’URI

•Les URIs ainsi que des paramètres doivent être encodés en ASCII

•Les paramètres ne sont pas structurés : format nom=valeur

•Les paramètres ne sont pas typés : type « string »

3 http://www.w3.org/2001/tag/doc/whenToUseGet.htm

(13)

ASIE-5. L’implémentation d’un service REST DOIT utiliser l’une ou l’autre des deux méthodes GET ou POST mais pas les deux (le choix de la méthode est exclusif)

3.4.1.4 Mécanisme SOAP

ASIE-6. L’implémentation d’un service SOAP DOIT être compatible avec le Basic Profile 1.1 du WS-I.

En corollaire, seule la méthode HTTP POST est utilisable pour l’implémentation du service web SOAP synchrone.

La spécification à utiliser dans le cadre des échanges synchrones de type SOAP est le Basic Profile 1.1 du WS-I disponible à l’url suivante :

http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html

Le Basic Profile 1.1 est un ensemble de recommandations pour garantir l’interopérabilité des web services qui utilisent les technologies suivantes :

•SOAP 1.1

•WSDL 1.1

•UDDI 2.0

•XML Schema 1.0

•XML 1.0 (Second Edition)

•HTTP 1.1

•SSL v3

En plus du Basic Profile 1.1 le WS-I met en oeuvre le Simple SOAP binding Profile 1.0 qui définit liaison des messages SOAP avec HTTP POST.

UDDI 2.0 n'est pas traité dans la version 1 des spécifications ASIE.

3.4.2Type de paramètres échangeables

3.4.2.1 Mécanisme REST

ASIE-7. Pour les échanges de type REST qui mettent en œuvre la méthode GET, tous les paramètres DOIVENT être de type String.

On PEUT envisager d’utiliser la technologie XML pour passer des paramètres en HTTP GET (un ensemble de balises XML est un paramètre de type String). Néanmoins, cette solution DEVRA veiller à être de taille très limitée et on portera une attention toute particulière au problème de longueur des URI.

(14)

ASIE-8. Pour les échanges de type REST qui mettent en œuvre la méthode POST, les types de paramètres PEUVENT être ceux définis dans la norme XML Schema 1.0

ASIE-9. Toutes les requêtes de type REST DOIVENT contenir en plus des paramètres spécifiques à l’opération les paramètres OBLIGATOIRES suivants :

- Service : contient le nom du service

- Request : contient le nom de l’opération à exécuter - Version : la version du service souhaitée

Cette règle permet de respecter les spécifications de l’OGC sur les services cartographiques.

3.4.2.2 Mécanisme SOAP

Une fois le mode d’échange de message SOAP choisi, il faut encore définir quels types de données peuvent être transmis dans les messages SOAP. Le Basic Profile 1.1 spécifie que tous les types disponibles dans les XML Schema peuvent être utilisés.

Dans un souci d’interopérabilité pour des environnements qui ne sont pas encore compatibles avec le Basic Profile 1.1 du WS-I, on restreint la liste des types utilisables à un sous-ensemble exposé dans la règle suivante.

ASIE-10. Les types utilisables pour les échanges synchrones de type SOAP DOIVENT être : - les types de base : string, boolean, byte, short, int, long, float, double - les tableaux des types de base

- les structures composées des types de base et des tableaux de type de base - les tableaux des structures composées

De même, le type « DateTime » doit être manipulé avec attention dans le cadre du développement de services interopérables. Les types date, dateTime, time ne doivent pas être utilisés dans les structures échangées afin d’assurer l’interopérabilité entre les 3 langages étudiés dans le cadre de l’étude courante.

En effet, avec le framework .NET 1.1 on rencontre les 2 problèmes suivants :

•Le type System.DateTime ne prend pas en compte le TimeZone et considère donc que la date est exprimée dans la locale courante.

•Le type System.DateTime ne peut prendre la valeur null. Ce problème sera corrigé avec le framework .NET 2.0 qui introduit les types Nullables.

Enfin dans le monde PHP, il n’existe pas de type représentant le type date, dateTime et time. Tout doit être géré à partir d’une chaîne de caractères.

(15)

ASIE-11. Un paramètre de type dateTime DOIT être transmis sous la forme d’une string au format ISO 8601 (cf. http://www.w3.org/TR/NOTE-datetime).

Exemple : 2005-09-29T18:01:05

Voici ci-dessous la définition d’un type dateTime compatible avec la spécification technique 3.4.2.2 et qui permet de valider le format de la chaîne de caractères transmise.

<xs:element name="dateTime">

<xs:simpleType>

<xs:restriction base="xs:string">

<xs:pattern value="((-?[0-9]{4})-([0-9]{2})-([0-9]{2})T([0-9]{2}):([0-9]

{2}):([0-9]{2})(.[0-9]*)?(Z|[+\-][0-9]{4}|[+\-][0-9]{2}:[0-9]{2})?)?"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

3.4.3La description d’un service

3.4.3.1 Documentation générale

Tout service mis en œuvre dans le cadre de l’architecture du SIE doit posséder une documentation suffisante pour que les partenaires extérieurs puissent disposer des modalités d’accès au service (nom, paramètre d’appel).

ASIE-12. Dans le cadre du développement de services web de type SOAP et de type REST, une description textuelle DOIT être fournie pour documenter les services.

3.4.3.2 Description d’un service REST

WSDL 1.1 supporte la définition de services WEB utilisant HTTP GET et POST. Néanmoins, il n’existe pas d’outils pour exploiter directement un fichier WSDL pour le REST. L’approche REST s’appuie plutôt sur des développements spécifiques à partir d’une documentation papier.

Notons aussi qu’une tentative de description spécifique pour le protocole REST a été envisagé en 20002 : WRDL (Web Resource Definition Language) mais que l’initiative a été abandonnée.

En conclusion, seule une description textuelle DOIT être fournie (Cf. 3.4.3.1).

3.4.3.3 Description d’un service SOAP

Le WS-I précise que la description des services s’effectue via le standard WSDL. Ce standard est repris pour la description des services SOAP du SIE

ASIE-13. Les contrats des services web de type SOAP DOIVENT être décrits dans un fichier WSDL.

(16)

La spécification WSDL 1.1 autorise le découpage d’un fichier WSDL. Le Framework .NET 1.1 et les implémentations SOAP de PHP (Nusoap, PEAR::SOAP et extension Soap de PHP5) n’autorisent pas le découpage du fichier WSDL.

ASIE-14. Le fichier WSDL NE DOIT PAS être découpé. La balise wsdl:import NE DOIT PAS être utilisée.

Le fichier WSDL peut utiliser différentes méthodes afin de décrire un service web. L’article “Which style of WSDL should I use?”⁴ explique les différentes approches possibles ainsi que leurs limitations.

Pour des raisons d’interopérabilité avec le framework .NET 1.1 les services développés devront suivrent les spécifications techniques ci-dessous :

ASIE-15. Pour les échanges synchrones de type SOAP, les opérations décrites dans le WSDL DOIVENT être de type Document/Literal Wrapped.

ASIE-16. Pour les échanges synchrones de type SOAP, la surcharge des opérations DOIT être interdite car incompatible avec le type Document/Literal Wrapped.

Les conventions de nommage suivantes DOIVENT être suivies :

ASIE-17. Les éléments message d’entrée et de sortie d’une opération synchrone DOIVENT contenir un seul élément part. L’élément part DOIT posséder un attribut name ayant pour valeur "parameters", et un attribut element faisant référence à un élément du schéma.

ASIE-18. L’élément référencé par le part d’un message d’entrée DOIT porter le nom de l’opération pour laquelle le message est utilisé.

ASIE-19. L’élément référencé par le part d’un message de sortie DOIT porter le nom de l’opération pour laquelle le message est utilisé concaténé avec "Response".

Voici un exemple qui illustre ces conventions de nommage :

<types>

<xs:element name="getDateTime">

<xs:complexType/>

</xs:element>

<xs:element name="getDateTimeResponse">

<xs:complexType>

<xs:sequence>

<xs:element minOccurs="1" maxOccurs="1" name="date"

type="tns:dateTime"/>

</xs:sequence>

</xs:complexType>

4 http://www-128.ibm.com/developerworks/library/ws-whichwsdl/

(17)

</xs:element>

</types>

<message name="getDateTimeSoapIn">

<part name="parameters" element="tns:getDateTime"/>

</message>

<message name="getDateTimeSoapOut">

<part name="parameters" element="tns:getDateTimeResponse"/>

</message>

<portType name="Service1Soap">

<operation name="getDateTime">

<input message="tns:getDateTimeSoapIn"/>

<output message="tns:getDateTimeSoapOut"/>

</operation>

</portType>

3.4.4La gestion des versions pour les services

Lors de la mise en place d’une architecture de type SOA on doit porter une attention toute particulière au problème de version des services qui sont déployés. L’anti-pattern DLL Hell⁵ illustre bien ce problème.

En effet, par définition dans le cadre d’une architecture de services, les applications clientes utilisent des services. Or ces services peuvent évoluer au fil du temps. On souhaite permettre aux applications existantes de continuer à fonctionner avec une version donnée d’un service tout en s’autorisant à déployer une nouvelle version du service. Pour ce faire on définit une stratégie de gestion des versions pour les services développés.

Un exemple d’architecture de type SOA en production peut être trouvé chez Amazon.com. On peut s’inspirer des best practices qu’ils ont pu mettre en œuvre sur le web service commercial : Amazon E- Commerce Service⁶. Amazon a mis en œuvre un mécanisme de gestion de versions pour l’ensemble des services REST et SOAP qu’ils exposent. L’article décrivant ce mécanisme peut être trouvé à l’url suivante :

http://www.amazon.com/gp/aws/sdk/main.html?

s=AWSEcommerceService&v=2005-03-23&p=ApiReference/ServiceVersioningArticle

3.4.4.1 Version pour les services REST

ASIE-20. L’URI permettant d’accéder à un service de type REST qui met en œuvre la méthode GET DOIT référencer la version du service dans un paramètre obligatoire nommé version.. Elle DOIT avoir la forme suivante : http://HostName/Path/ ServiceID?

service=<Service >&request=<méthode>&version=<N°

version>&[<paramètre=valeur>]*

5 L’anti pattern DLL illustre le problème de la gestion des versions d’une même DLL dans un environnement Windows. Le manque de normalisation dans la gestion des versions, des nomenclatures et des localisations sur le système de fichiers a conduit à l’impossibilité d’installer deux versions différentes d’une même DLL sur un poste Windows. Cf. http://en.wikipedia.org/wiki/DLL_hell.

6http://www.amazon.com/gp/browse.html/104-4389826-0068740?

%5Fencoding=UTF8&node=3435361

(18)

3.4.4.2 Version pour les services SOAP

ASIE-21. Le targetNamespace du fichier WSDL d’un service SOAP DOIT avoir le format suivant : targetNamespace=’’http://HostName/Path/ServiceID/<N°version majeure>-<N°version mineure>/’’.

Le champ « HostName » DEVRAIT être le nom de l’hôte hébergeant le service web de type SOAP décrit dans le contrat WSDL

.

Le champ « serviceID » est un identifiant du service qui peut prendre différentes valeurs telles que :

•Service1

•Domaine1/Service2

•etc…

ASIE-22. La version d’un service SOAP DOIT être égale au numéro <N°version majeure>-<N

°version mineure> spécifié à la fin du targetNamespace de son contrat WSDL.

Le choix d’utilisation d’une version particulière d’un service par un client se fait en choisissant le fichier WSDL décrivant le service dans la version voulue.

Le contrat WSDL d’un service SOAP pour une version donnée DOIT être accessible à l’URL suivante : http://HostName/ServiceID/<N°vers. majeure>-<N°vers . mineure>/NomFichier.wsdl

L’implémentation d’une nouvelle version d’un même service web se fait simplement en implémentant un nouveau service web. Grâce à cette stratégie, plusieurs versions d’un même service peuvent cohabiter sur un même serveur dès lors que tous les web services sont déployés. Afin de faciliter la maintenance des différentes versions des services déployés les développeurs doivent respecter la spécification technique suivante :

ASIE-23. L’attribut location de l’élément soap:address DOIT inclure la version dans l’URI du service web.

Exemple :

<service name="Service1">

<port name="Service1Soap" binding="tns:Service1Soap">

<soap:address location="http://serveur.domaine.fr/WebService1/Service1_1-1.asmx" />

</port>

</service>

ASIE-24. Un client SOAP DOIT utiliser le contrat WSDL pour savoir quelle adresse utiliser pour accéder au service demandé pour une version donnée.

Que le développement des proxies SOAP client soit dynamique ou statique, l’adresse doit être récupérée depuis le fichier WSDL dans la version choisie.

(19)

3.4.5La gestion des erreurs

L’écriture de services Web ne peut se faire sans prendre en compte la gestion des erreurs qui peuvent avoir diverses origines telles que réseaux ou applicatives.

3.4.5.1 Description d’une erreur

Dans un souci d’interopérabilité, le W3C⁷ recommande des règles de bonnes pratiques pour la gestion des erreurs dans le cadre des architectures Web :

•Une erreur doit être suffisamment explicite et significative. Ceci doit être considéré à deux niveaux : au niveau applicatif (machine) et au niveau utilisateur (humain). Les codes d’erreurs permettent en effet aux applications clientes d’effectuer un traitement adapté, alors que les messages d’erreur permettent de présenter à l’utilisateur une explication claire.

•Pour éviter tout problème de format et donc d’interprétation erronées, le contenu d’une erreur doit être formatée en XML.

D’autre part, un mécanisme de gestion d’erreur a été mis en œuvre pour le service Web commercial Amazon E-Commerce Service (ECS). Il est décrit dans l’article suivant :

http://www.amazon.com/gp/aws/sdk/main.html/103-2433248-6902223?

s=AWSEcommerceService&v=2005-03-23&p=PgHandlingErrorCodesArticle

La gestion des erreurs de ECS distingue deux types d’erreur : les erreurs de syntaxe des requêtes et les erreurs d’exécution de la requête. Chaque erreur est composée d’un code unique et d’un message explicatif. Si une requête génère plus d’une erreur, toutes les erreurs sont retournées dans la réponse.

ASIE-25. La gestion des erreurs applicatives lors de l’implémentation d’un service web DOIT respecter les recommandations suivantes :

- Une erreur DOIT contenir un code qui l’identifie.

- Une erreur DOIT contenir un message explicatif clair.

- Une erreur DOIT contenir une évaluation de sévérité Une erreur DOIT être formatée au format XML.

Le schéma XML des erreurs transmises est décrit à partir la balise « Erreur » du schéma XML-Sandre:msg (http://xml.sandre.eaufrance.fr/msg/1/ ) :

La description de la balise Erreur du schéma XML-SANDRE msg est reprise ci-après :

<xs:complexType name="Erreur">

<xs:sequence>

<xs:element name="CdErreur" type="sa_msg:CdErreur"/>

<xs:element name="LocationErreur" type="sa_msg:LocationErreur" minOccurs="0"/>

<xs:element name="DescriptifErreur" type="sa_msg:DescriptifErreur" minOccurs="0"/>

</xs:sequence>

<xs:attribute name="SeveriteErreur" use="optional">

<xs:simpleType>

7 http://www.w3.org/TR/webarch/#error-handling

(20)

<xs:restriction base="xs:string">

<xs:enumeration value="Warning"/>

<xs:enumeration value="Error"/>

</xs:restriction>

</xs:simpleType>

</xs:attribute>

</xs:complexType>

<xs:complexType name="CdErreur">

<xs:simpleContent>

<xs:extension base="cct:CodeType"/>

</xs:simpleContent>

</xs:complexType>

<xs:complexType name="DescriptifErreur">

<xs:simpleContent>

<xs:extension base="cct:TextType"/>

</xs:simpleContent>

</xs:complexType>

<xs:complexType name="LocationErreur">

<xs:simpleContent>

<xs:extension base="cct:TextType"/>

</xs:simpleContent>

</xs:complexType>

Le code Erreur s’appuie par défaut sur la liste des codes erreurs définies par le Sandre pour chaque service.

Voici l’exemple d’un message d’erreur respectant ces recommandations :

<?xml version="1.0" encoding="UTF-8" ?>

<erreur SeveriteErreur="Warning">

<CdErreur listAgencyID="SANDRE">150</CdErreur>

<DescriptionErreur>Le paramètre fourni n’est pas une date</DescriptionErreur>

</erreur>

3.4.5.2 Erreur pour un service REST

A l’inverse de SOAP, les services de type REST n’intègrent pas de convention précise concernant la gestion des erreurs et la façon de les retourner aux applications clientes. Cependant, REST s’appuyant intégralement sur le protocole HTTP, la gestion des erreurs au niveau service inclut donc la gestion des erreurs au niveau HTTP.

La spécification du protocole HTTP 1.1 (RFC 2616⁸) introduit deux catégories d’erreur :

•les erreurs clientes (codes 4xx) sont utilisées lorsque le problème provient de la requête du client

•les erreurs serveurs (codes 5xx) sont utilisées lorsque le serveur sait que le problème vient de lui ou qu’il est incapable de traiter la requête.

Dans tout les cas, la norme offre la possibilité (et même préconise) de fournir un contenu descriptif de l’erreur. Ce contenu peut être utilisé pour introduire une sémantique applicative. Les erreurs de type applicative pourront être par exemple retournées au sein de réponse HTTP « 404 Not Found ».

Remarque : Internet Explorer présente une page spécifique pour les erreurs 404, ce qui empêche la visualisation du message XML de l’erreur. Pour contourner ce problème, il faut désactiver l’option

8 http://www.w3.org/Protocols/rfc2616/rfc2616.html

(21)

« Afficher des messages d’erreur HTTP simplifiés » dans les options avancées du navigateur (menu Outils Options Internet…, onglet Avancé).

ASIE-26. L’erreur selon le scénario XML décrit par la règle 3.4.5.1 DOIT être retournée dans une réponse HTTP de type 4xx (Par exemple, le code 404).

3.4.5.3 Erreur pour un service SOAP

Dans le cas des échanges synchrones de type SOAP, le protocole inclut le mécanisme de gestion d’erreur aux travers des éléments « SOAP Fault ».

Le Basic Profile 1.1 apporte un certain nombre de règles à suivre cadrant l’utilisation des SOAP Faults, disponibles à l’adresse suivante :

http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html#SOAPFAULT

Afin de pouvoir exploiter les différentes exceptions générées par le client et/ou le serveur de manière interopérable, il faut utiliser la propriété detail de l’objet SoapFault. En effet, une exception Java n’a aucun sens sur une plateforme .NET ou PHP. De ce fait, il est indispensable d’utiliser le schéma 3.4.5.1 pour transmettre les erreurs.

ASIE-27. La gestion des erreurs pour les services SOAP DOIT être compatible avec les recommandations du Basic Profile 1.1 du WS-I.

ASIE-28. Les informations sur les erreurs DOIVENT être transmises dans la propriété detail de l’objet SOAPFault selon le scénario XML décrit par la règle 3.4.5.1.

3.4.6Problème des timeout

Il est difficile de définir une règle à ce niveau. Chacune des interfaces réseau traversées par une requête SOAP ou REST définit son propre timeout. Quel délai d’attente peut on supporter lors d’un échange synchrone ?

ASIE-29. Tout traitement long pouvant entraîner un problème de « timeout » pour le client HTTP DEVRAIT mettre en œuvre un mécanisme d’échange asynchrone.

(22)

3.5 Echange des messages en mode asynchrone

3.5.1Mécanisme général

La technologie SOAP ne permet pas de gérer de manière standard les échanges asynchrones dans son modèle d’échange de messages. Le W3C et l’OASIS proposent les 2 spécifications suivantes afin de traiter, entre autres, la problématique des échanges asynchrones de manière standard :

•WS-Addressing⁹ (W3C) : La spécification WS-Addressing du W3C définie de manière standard les structures de données à échanger afin de traiter des messages dans des échanges business- to-business (B2B).

•WS-Reliable Messaging¹⁰ (OASIS) : La spécification WS-RM de l’OASIS traite le problème de l’envoi fiable de messages. Cette spécification gère, entre autre, les problèmes de time-out pouvant survenir sur le serveur avant de recevoir l’accusé de réception.

Diverses implémentations de framework d’échange de messages asynchrones basées sur l’interprétation des WS-* intermédiaire existent pour Java et .NET. Il s’agit d’implémentations propriétaires qui ne sont pas interopérables.

Pour résoudre la problématique des échanges de messages asynchrones, le WS-I propose dans ces scénarios d’usage¹¹ le scénario appelé « Basic Callback ». L’échange asynchrone est en fait réalisé grâce à deux messages de type requête/réponse synchrones :

1. L’application invoque un service initial synchrone sur le serveur qui lui retourne immédiatement un acquittement de réception.

2. Le serveur effectue un traitement.

3. Le serveur envoie le résultat du traitement en invoquant un service synchrone sur l’application callback.

4. L’application callback retourne un acquittement de réception au serveur.

La paire de messages requête/réponse doit être reliée par un mécanisme de corrélation, typiquement un identifiant, valide uniquement pour la transaction et qui est fourni par le client. De même, le client doit aussi fournir l’URL (forcément du http pointant vers un service SOAP) de son service callback, invoqué par le serveur.

Le scénario Basic callback reprend des termes et principes (Application Callback, acknowledgement

…) spécifiés dans la norme WS-Adressing.

La définition du service Web asynchrone et du callback peut être décrite dans un seul fichier WSDL, ou bien dans deux WSDL séparés. Dans les deux cas, deux portTypes doivent être définis : un pour le serveur et un pour le client. Un port (de la section service) contenant une « address location » valide pourra être défini pour la partie serveur. Par contre, le WSDL client contient un port avec une adresse non significative puisque cette adresse est donnée par le client lors de l’appel au service asynchrone.

Le diagramme ci-après illustre le principe de fonctionnement d’un appel asynchrone respectant les règles décrites ci-dessus :

9 http://www.w3.org/Submission/ws-addressing/

10 http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrm

11 http://www.ws-

i.org/SampleApplications/SupplyChainManagement/2003-12/UsageScenarios-1.01.pdf

(23)

Application Application callback Serveur

Res : Ack

Requêtes en attente

La requête associée au correlationID est mise en attente de résultat

Res : Ack

1Vérification que le correlationID correspond bien à une requête en attente

2Suppression de la requête (en attente) satisfaite 3Traitement du résultat de la requête

Req : invoque service asynchrone [correlationID, callbackLocation]

Req : notifie résultat [correlationID]

Application Application callback Serveur

Res : Ack

Res : Ack Res : Ack

Req : invoque service asynchrone [correlationID, callbackLocation]

Req : notifie résultat [correlationID]

Une application invoque un service asynchrone sur un serveur en lui transmettant deux paramètres :

•CorrelationID qui permet d’identifier la requête en cours entre l’application et le serveur,

•CallbackLocation qui indique au serveur sur quelle URL il doit transmettre le résultat de la requête

Le serveur retourne à l’application :

•un accusé de réception si tous les paramètres attendus sont corrects (Res : ack)

•une erreur si les paramètres de la requête sont erronés (par exemple).

L’application met la requête associée au correlationID dans une liste en attente du résultat.

Le serveur lance le traitement de la requête. Lorsqu’il a terminé, il invoque un service de l’application Callback pour notifier son résultat en lui passant l’identifiant (correlationID) de la requête traitée.

L’application Callback vérifie que le correlationID correspond bien à une requête en attente, et en fonction des contrôles applicatifs, la supprime ou non de la liste et répond au serveur en lui adressant un accusé de réception ou une erreur.

Si tous les contrôles sont positifs, l’application callback traite les résultats de la requête asynchrone Afin d’assurer le contrôle des messages arrivant sur le service de callback de l’application, une liste de requêtes en attente de résultat doit être mise en place. Cela va permettre de s’assurer d’une part que le message reçu est bien le résultat d’une requête émise, et d’autre part qu’une requête finit toujours par obtenir un résultat.

(24)

Ces contrôles sont du domaine de l’applicatif, de même que les erreurs qu’ils pourront générer et la façon de les traiter. Par exemple, si l’on reçoit un message avec un correlationID inconnu deux attitudes pourraient être envisagée : rejeter le message ou bien provoquer une erreur sur l’application.

ASIE-30. Pour les échanges asynchrones, on DOIT utiliser la technologie SOAP en mettant en oeuvre le mécanisme décrit dans les scénarios d’usage du WS-Idisponible à

l’adresse http://www.ws-i.org/SampleApplications/SupplyChainManagement/2003-12/

UsageScenarios-1.01.pdf.

Ce protocole d’échanges asynchrone spécifique au SIE s’appuie largement sur les principes des standards actuels.

Afin de respecter les principes du WS-I, les règles suivantes devront être respectées :

ASIE-31. Les informations relatives à l’asynchronisme (correlationID et callbackLocation) DOIVENT être transmises dans le header SOAP.

3.5.2Description des services asynchrones

ASIE-32. Le WSDL décrivant le service Web asynchrone du serveur DOIT définir l’élément MessageHeader suivant :

<xs:element name="MessageHeader">

<xs:complexType>

<xs:sequence>

<xs:element minOccurs="1" maxOccurs="1" name="conversationID" type="xs:string"/

>

<xs:element minOccurs="1" maxOccurs="1" name="callbackLocation"

type="xs:string"/>

</xs:sequence>

</xs:complexType>

</xs:element>

ASIE-33. La définition du message entrant du service Web asynchrone DOIT contenir deux parts : le part permettant de référencer l’élément de l’opération tel que défini dans 3.4.3.3 et 3.4.3.3, et le part correspondant au header du message référençant le MessageHeader définit dans 3.5.2.

L’exemple suivant illustre cette règle. On définit le message d’entrée de l’opération startLongOperation :

<message name="startLongOperationSoapIn">

<part name="parameters" element="tns:startLongOperation"/>

<part name="SendHeader" element="tns:MessageHeader"/>

</message>

(25)

ASIE-34. Dans la section binding, l’input de l’opération asynchrone DOIT spécifier que le part parameters est transmis dans le SOAP body, et que le part référençant le

MessageHeader est transmis dans le SOAP header.

L’exemple suivant illustre cette règle. On définit le binding SOAP de l’opération startLongOperation :

<operation name="startLongOperation">

<soap:operation soapAction="startLongOperation" style="document"/>

<input>

<soap:body parts="parameters" use="literal"/>

<soap:header message="tns:startLongOperationSoapIn" part="SendHeader" use="literal"/

>

</input>

<output>

<soap:body use="literal"/>

</output>

</operation>

ASIE-35. Le WSDL décrivant le service callback DOIT définir l’élément MessageHeader suivant :

<xs:element name="MessageHeader">

<xs:complexType>

<xs:sequence>

<xs:element minOccurs="1" maxOccurs="1" name="conversationID" type="xs:string"/>

</xs:sequence>

</xs:complexType>

</xs:element>

ASIE-36. La définition du message entrant du service callback DOIT contenir deux parts : le part permettant de référencer l’élément de l’opération tel que défini dans 3.4.3.3 et 3.4.3.3, et le part correspondant au header du message référençant le

MessageHeader définit dans 3.5.2.

L’exemple suivant illustre cette règle. On définit le message d’entrée de l’opération de callback notifyResultLongOperation :

<message name="notifyResultLongOperationSoapIn">

<part name="parameters" element="tns:notifyResultLongOperation"/>

<part name="ReceiveHeader" element="tns:MessageHeader"/>

</message>

ASIE-37. Dans la section binding, l’input de l’opération callback DOIT spécifier que le part parameters est transmis dans le SOAP body, et que le part référençant le

MessageHeader est transmis dans le SOAP header.

L’exemple suivant illustre cette règle. On définit le binding SOAP de l’opération de callback notifyResultLongOperation :

<operation name="notifyResultLongOperation">

<soap:operation soapAction="notifyResultLongOperation" style="document"/>

(26)

<input>

<soap:body parts="parameters" use="literal"/>

<soap:header message="tns:notifyResultLongOperationSoapIn" part="ReceiveHeader"

use="literal"/>

</input>

<output>

<soap:body use="literal"/>

</output>

</operation>

3.5.3Accessibilité des services

ASIE-38. Le service Web SOAP asynchrone exposé par le serveur DOIT être accessible par l’application et le service Web callback de l’application DOIT être accessible par le serveur.

Le client transmet dans le header du message SOAP l’endpoint (URL HTTP) sur lequel le serveur doit lui répondre (CallBack Location). La règle signale que le serveur doit être capable d’atteindre l’URL transmis par le client ce qui n’est pas forcément le cas. Le client et le serveur doivent être dotés chacun d’un serveur HTTP. La communication entre ces 2 serveurs doit pouvoir se faire dans les 2 sens (entrant/sortant).

3.6 Echange des données volumineuses

L’échange de données volumineuses entraîne deux types d’opérations complémentaires aux règles précédentes :

1. la compression des données avant leur transmission,

2. la transmission de données binaires (compressés) par un service SOAP.

3.6.1La compression des données

Il est souhaitable d’utiliser des mécanismes de compression de données afin de réduire le volume transféré lors des échanges de fichiers volumineux.

ASIE-39. La compression des données avec le format standard GZip v.4.3 (RFC 1952) DOIT être obligatoire lors des échanges de fichiers volumineux en SOAP et en REST.

Les données transmises dans le cadre d’échanges de type SOAP doivent être de type XML ( Texte). La transmission de fichiers binaires POURRAIT être réalisée selon l’une des 2 approches suivantes :

•SOAP avec attachement : le fichier binaire est transmis en binaire à l’extérieur du message SOAP.

•Encodage en texte dans le corps du message SOAP le fichier binaire doit être encodé en texte.

(27)

Dans la version 1 des spécifications, seul l’encodage en texte dans le corps du message SOAP DOIT être utilisé.

Le format d’encodage utilisé est le format Base64 décrit dans le RFC 2045.

ASIE-40. L’envoi de données volumineuses avec la technologie SOAP DOIT utiliser l’encodage Base64 après la compression du fichier à transmettre. La chaîne encodée est ensuite envoyée dans le message SOAP retourné.

ASIE-41. Dans le cas de la technologie SOAP, le content-type sous forme d’un MIME du fichier avant compression DOIT être envoyé en tant que paramètre de retour du service.

3.6.2Transmission des données attachées en SOAP

Le WS-I vient de finaliser le Attachment Profile 1.0¹². Or, les implémentations actuelles de la spécification SOAP with Attachment (SwA) ne respectent pas ce cadre d'interopérabilité.

Par exemple, l’implémentation de SwA pour le langage .NET est WSE (Web Services Enhancements) 2.0. Microsoft impose d’utiliser DIME pour effectuer cet échange alors que Java a choisi MIME. Cette implémentation demande d’implémenter une partie de la spécification WS-Security pour pouvoir invoquer un Web Service avec WSE.

Il est préconisé de ne pas utiliser la technologie « SOAP with Attachment » à cause des problèmes d’interopérabilité.

ASIE-42. La technologie « SOAP with attachment » NE DOIT PAS être utilisée pour l’implémentation des services renvoyant des données volumineuses.

3.7 L’échange de données géographiques

L’information environnementale est généralement une information géographique. Il est donc indispensable de disposer des moyens techniques pour échanger des données spatialisées. Comme le précise le cadre général de l’architecture SIE, les spécifications s’appuient sur les préconisations de la directive européenne INSPIRE sur la diffusion et l’échange de l’information géographique.

Les spécifications techniques sur les services géographiques sont définies par l’OGC. Aujourd'hui, 16 spécifications sont adoptées par le consortium. Les spécifications SIE Version 1 se focalisent sur les moyens de diffuser des cartes sous forme d'image (Web Map Service ou WMS), de diffuser les données vectorielles elles-mêmes (Web Feature Service ou WFS), de filtrer (Filter Encoding ou FE), modifier les styles (Style Layer Descriptor ou SLD), sauver un contexte de carte (Web Map Context ou WMC).

12 http://www.ws-i.org/Profiles/AttachmentsProfile-1.0.html

(28)

3.7.1Approche REST exclusivement

ASIE-43. Tous les services concernant les données géographiques DOIVENT se faire au moins sur le mode REST - GET

Le protocole Soap n'est pas mentionné dans la spécification WMS 1.1.1 ni WMS 1.3.Une proposition de modification (WMS Change Request: Support for WSDL & SOAP (WMS-WSDL) 0.1.0 04-050r1 2005-04-22 )¹³ a pour but d'ajouter une description WSDL à l'interface WMS dans sa version 1.3.1.

3.7.2Transmission de données sous forme d’images

ASIE-44. Pour la diffusion d’informations cartographiques sous forme d’images, les serveurs cartographiques DOIVENT au minimum implémenter la spécification WMS

ASIE-45. Les services cartographiques mis en place sur les serveurs DOIVENT répondre à la spécification WMS 1.1.1

Cette spécification (ISO 19128) définit une interface (au sens de protocole) pour la représentation de données géographiques hétérogènes. Cette spécification concerne l'un des services décrits par l'OGC Web Services ou OWS.

Elle spécifie la façon dont une application cliente doit lancer une requête vers un serveur et la façon dont le serveur retourne la réponse au client. La carte ici est une représentation visuelle des données (une image au format PNG, GIF, JPEG...) mais pas les données elles mêmes (objets vectoriels avec leurs attributs).

La version 1.1.1 de la spécification¹⁴ propose trois opérations (GetCapabilities, GetMap, GetFeatureInfo), permettant respectivement d'obtenir les capacités du serveur à délivrer les cartes (liste des couches, formats, systèmes de projections acceptés... au format XML), obtenir une carte, obtenir des informations complémentaires sur les objets situés en un point (X, Y).

Exemple :

http://wms.jpl.nasa.gov/wms.cgi?

version=1.1.0&layers=global_mosaic&request=GetMap&format=image/png&bbox=1,42,2,43&srs=EP SG:4326&width=800&height=800&styles=pseudo

http://ogc2.brgm.fr/brgm/map/BRGM_WMS_GEOL1M?

version=1.1.1&request=getMap&format=image/png&srs=epsg:4326&width=600&height=600&bbox=0, 41,2,43&layers=CAR_GEO1M_SCAN6

Un outil client qui souhaite superposer des images issues de serveurs WMS multiples ne peut le faire qu'à la condition de disposer d'images dont les zones qui ne contiennent pas d'objets géographiques

13 WMS-WSDL : http://portal.opengeospatial.org/files/?artifact_id=9541

14 WMS 1.1.1 : http://portal.opengeospatial.org/files/?artifact_id=1081&version=1&format=pdf