Synthèse des standards des Web Services

Règles pour favoriser l’interopérabilité entre les parseurs SOAP, par exemple dans le domaine de la gestion des Faults, de l’encodage (choix du mode ‘Document-Litreral’), de la représentation des tableaux…

Le Basic Profile 1.0 ne fournit pas de règles sur le niveau d’usage des types étendus des schémas XML, ce qui est souvent une cause des problèmes d’interopérabilité. Il faut donc compléter le Basic Profile par des meilleures pratiques d’usage des schémas XML pour la définition des messages SOAP (généralement on évite l’utilisation des types dont l’interprétation par les implémentations est divergente : choice, enumeration…).

Le Basic Profile 1.0 intègre, sous la forme de notations, les spécificités pour WSDL 2.0 et SOAP 1.2 (au départ le Basic Profile est écrit pour WSDL 1.1 et SOAP 1.1).

www.ws-i.org

Etat : Final Specification.

Langage (Schema XML) pour la définition de processus formé par l’enchaînement de endpoints Web services.

Xpath est utilisé pour exprimer les conditions d’enchaînements entre les étapes du processus. Une étape est nommée ‘activité’ (ce qui est conforme au vocable UML).

On définit deux niveau de représentation du processus : sa partie abstraite qui est vue par tous les participants du processus, et une partie concrète (‘processus exécutable’) pour chaque participant qui définit le comportement du point de vue d’un participant.

La partie abstraite est définit dans un fichier WSDL. Le processus est donc exposé comme un Web service.

www.oasis-open.org/committees
/wsbpel/charter.php

Etat : V1.1 Mars 2003 Public Draft.

WS-TMX (Transaction Management)

WS-CTX (Context)

WS-Addressing

REST : Representational State Transfer.

Ce n’est pas un standard mais un principe d’architecture. REST n’est pas spécifique au Web service et il parfois positionné comme un concurrent possible de SOAP.

Le Web HTTP respecte les principes de l’architecture REST notamment en imposant l’usage de quatre opérations de base pour accéder aux ressources (uniform interface) : Get, Put, Post, Delete qui fonctionnent en stateless (sans état entre deux sollicitations).

http://www.ics.uci.edu/~fielding
/pubs/dissertation/top.htm

Etat : Final Specification.

SOAP est l’enveloppe pour le transport des endpoints web service.

SOAP 1.2 permet l’usage du mode de communication GET, ce qui est intéressant pour les stratégies de gestion de cache et de sécurité (une opération GET n’est censée faire qu’une consultation sur le serveur). La version précédente de SOAP ne permet que le mode POST (bien que WSDL 1.1 prévoyait déjà le mode GET).

http://www.w3.org/TR/20...0-20030624/

Etat : Recommendation Juin 2003.

Gestion de l’acheminement de bout en bout des messages au dessus des protocoles de communication (donc fonctionne en HTTP).

http://dev2dev.bea.com
/technologies/webservices/
WS-Acknowledgement-0_9.jsp

Etat : Février 2003.
Semble abandonné au profit de WS-ReliableMessaging.

Spécification qui permet de décrire des SLA dans un schéma XML afin qu’une introspection et un traitement automatique puissent être exécutées.
Un ensemble d’opérations d’introspection et de manipulation des schémas SLA sont spécifiées (createAgreement, agreementState…)

http://www.gridforum.org/Meetings/GGF11/
Documents/draft-ggf-graap-agreement.pdf

Etat : Draft Mai 2004

Représentation de la référence à un endpoint par l’introduction d’un nouveau élément plus détaillé que ce que propose WSDL 1.1. Il s’agit donc d’étendre la description des portTypes et Binding tout en restant compatible avec WSDL.

Un endpoint référence se compose notamment des éléments suivants :

• Son adresse sous la forme d’une URI.
• Des ‘policies’ (exprimée en WS-Policy) qui décrivent le comportement du endpoint.

Décrit également la façon dont un endpoint peut véhiculer la référence à un autre endpoint : Message Information Header. Ceci est par exemple utile pour standardiser les principes du mode de communication par CallBack.

Ce standard est très important car il permet aux implémentations d’introspecter un endpoint pour déterminer son nom, ses propriétés… Par exemple, les standards pour la gestion des événements (WS-Eventing, WS-Distributed Management) s’appuient sur WS-Addressing.

Etat : Evaluation only Mars 2004.

Spécification pour déclarer de manière standard le endpoint de réponse dans le header de l’émetteur (en cas de mode de communication par CallBack).

http://dev2dev.bea.com/technologies/
webservices/WS-CallBack-0_9.jsp

Etat : Février 2003.
Semble abandonné au profit de WS-Addressing.

WS-MessageDelivery

WS-Addressing

WS-TXM (WS-Transaction Management) -> WS-Atomic Transaction (AT)

Nommé aussi WS-TXM ACID model.

Gestion des transactions courtes.

Description des mécanismes de préparation et de validation des transactions (1 phase commit pour un seul participant, 2 phases commit si plusieurs participants).

Un portType spécifique décrit les opérations ‘prepare’, ‘onePhaseCommit’, ‘RollBackMessage’, ‘CommitMessage’…

http://www.arjuna.com
/li...ws_caf_1-0/WS-TXM.pdf

Etat : Draft Version 1.0 Juillet 2003.

WS-CF (Coordination Framework)

WS-CTX (Context)

Gestion des transactions longues.

Mise en place des mécanismes de compensation des transactions afin de défaire des transactions réalisées dans une stratégie d’implémentation optimiste.

Un portType spécifique permet de décrire les opérations de compensation.

http://www.arjuna.com/library/specs/
ws_caf_1-0/WS-TXM.pdf

Etat : Draft Version 1.0 Juillet 2003.

WS-CF (Coordination Framework)

WS-CTX (Context)

Framework pour la gestion de contexte et de transaction qui se compose de trois spécifications : WS-CF (Coordination Framework), WS-CTX (Context) et WS-TXM (Transaction Management).

http://www.oasis-open.org/committees/
ws-caf/charter.php

Pas de spécification à ce jour hormis les mises à jour des contributions de départ : WS-Context, WS-CF, WS-TXM.

WS-CF (Coordination Framework)

WS-CTX (Context)

WS-TXM (Transaction Management)

Gestion de contexte suivant un principe qui consiste à faire transiter le contexte dans le header SOAP. Le contexte est partagé par plusieurs endpoints.

Les endpoints qui doivent partager le contexte s’enregistrent au sein d’une même activité. La référence à cette activité (donc au contexte) transite dans le header SOAP.

http://www.arjuna.com/li...caf_1-0/WS-CTX.pdf

Etat : Draft Version 1.0 Juillet 2003.

Décrit un service de coordination qui permet à un endpoint de s’enregistrer comme participant à une conversation. Le coordinateur assure des fonctions transverses pour l’ensemble des endpoints enregistrés comme par exemple l’envoi d’un message.

http://www.arjuna.c...caf_1-0/WS-CF.pdf

Etat : Draft Version 1.0 Juillet 2003.

Représentation (langage XML) des processus collaboratifs d’un point de vue ‘observateur central’ de l’exécution des processus entre les acteurs.

http://www.w3.org/T...-10-20040427/

Etat : Working Draft Avril 2004.

WSDL 2.0

(intègre le MEP : Message Exchange Pattern)

Représentation du contrat du web service avec une partie abstraite et une partie concrète (protocole, encodage…).
WSDL 2.0 remplace les termes portType et port respectivement par Interface et endpoint. Il est possible de faire des héritages d’interface, ce qui est notamment utile pour l’ajout des opérations de management des web services (WS-Distributed Management).

WSDL 2.0 introduit une formalisation des types d’échange de messages grâce au Message Exchange Pattern (MEP).
Avec le MEP, il est possible, par exemple, de fournir une adresse différente de endpoint pour l’envoi de la réponse : l’émetteur n’est pas celui qui doit recevoir la réponse. C’est par exemple le cas lorsque l’on déploie un modèle de « call-back ». A ce titre, le standard WS-Message Delivery propose de rationaliser ce type de pattern.

http://www.w3.org/TR/wsdl20/ (core langage) - http://www.w3.org/TR/wsdl20-patterns/ (Message Exchange Pattern) - http://www.w3.org/TR/wsdl12-bindings/ (binding)

Etat : Working Draft Mars 2004 (core langage et Message Exchange Pattern) – Working Draft Juin 2003 (binding).

WS-Distributed Management (WS-DM)

(WS-Manageability)

Définition de l’architecture et des opérations pour le management des endpoints : identification, state, dépendance entre les ressources managées (relationship)…

(WS-Manageability est une spécification initiale soumise à l’OASIS comme contribution de départ à WS-DM –

Auteurs : IBM, Talking Blocks, Computer Associates).

Etat : Version 1.0 Septembre 2003 – Soumission à l’OASIS.

Permet de procéder à une interrogation « multicast » afin de découvrir une série de endpoints qui répondent aux critères d’interrogation. A l’origine l’idée est de permettre à des ressources matérielles de s'identifier mutuellement sur un réseau.

Une interrogation correspond à une sonde (‘probe’) définie en XML et qui contient des conditions de recherche comme par exemple : le message de réponse du endpoint doit contenir un paramètre d’un certain type.

Un cas d’utilisation indiqué dans la spécification concerne la recherche de endpoints spécialisés dans l’impression.

Compatible avec SOAP 1.1 et SOAP 1.2.

Nécessite l’usage d’un protocole multi-cast (UDP).

http://msdn.microsoft.com/library/default.asp
?url=/library/en-us/
dnglobspec/html/ws-discovery.asp

Etat : Février 2004 draft.

WS-Addressing

WS-Policy

Définition des mécanismes de gestion par événements (abonnement, notification) plus précisément dans un contexte d’exécution asynchrone. Supporte à la fois SOAP 1.1 et SOAP 1.2.

http://ftpna2.bea.com/pub/
downloads/WS-Eventing.pdf

Etat : Janvier 2004.

Partage d’information de sécurité entre plusieurs ressources (permet notamment l’implémentation du mode SSO).
Etend la spécification WS-Trust.

http://www-106.ibm.com/developerworks/
webservices/library/ws-fed/

Etat : Initial public draft Juillet 2003.

Représentation d’un web service afin de permettre sa découverte par un consommateur (c'est-à-dire localiser son WSDL).

Exemple :

http://www-106.ibm.com/developerworks/
webservices/library/ws-wsilspec.html

Etat : Draft 2001.

Définit un mécanisme pour déclarer des ID dans les messages SOAP (dans l’idée d’identifier de manière standard des endpoints comme le propose WS-Addressing).

http://dev2dev.bea.com/technologies/
webservices/WS-MessageData-0_9.jsp

Etat : Février 2003.
Semble abandonné au profit de WS-Addressing

Représentation des références aux endpoints avec d’autres apports comme la standardisation du pattern « call-back ».

http://www.w3.org/Submission/2004/
SUBM-ws-messagedelivery-20040426/

Etat : Avril 2004 – Publication de la proposition de soumission par les auteurs (Sun, Oracle, Arjuna…).

WS-Metadata Exchange

(GetPolicy
GetWSDL
GetSchema)

Standardisation des opérations pour la récupération de la policy d’un endpoint mais aussi son WSDL et son schéma de données (GetPolicy, GetWSDL, GetSchema).

http://msdn.microsoft.com/library/default.asp?
url=/library/en-us/dnglobspec/html/ws-metadataexchange.asp

Etat : public draft release Mars 2004.

WS-Notification

(WS-BaseNotification
WS-BrokeredNotification
WS-Topics)

Définition des mécanismes de gestion par événements (abonnement, notification) plus précisément dans un contexte d’exécution asynchrone.

Issu du mouvement GRID (fortement promu par IBM) à la différence de WS-Eventing promu par Microsoft.

Exemple :

ftp://www6.software.ibm.com/software
/developer/library/
ws-notification/WS-BaseN.pdf (WS-BaseNotification) - ftp://www6.software.ibm.com/software
/developer/library/
ws-notification/WS-BrokeredN.pdf (WS-BrokeredNotification) - ftp://www6.software.ibm.com/software
/developer/library/
ws-notification/WS-Topics.pdf (WS-Topics)

Etat : pas de spécification publique à ce jour hormis les contributions de départ : Mars 2004 version 1.0 initial draft release.

Grammaire pour déclarer les règles de comportement affectées à un endpoint.

Exemple :

Dans cet exemple on montre comment WS-Policy complète les assertions de WS-Security en précisant que ‘exactement une’ assertion de sécurité est attendue et obligatoire.

http://www-106.ibm.com/developerworks
/library/ws-polfram/

Etat : Mai 2003 draft.

Permet le ‘provisioning’ de ressources comme la gestion des comptes des utilisateurs et la propagation dans un environnement distribué.

En cours de soumission à l’OASIS. Contribution pour le travail sur SPML.

http://xml.coverpages.org/
ni2003-10-07-a.html

Etat : Octobre 2003 Version 0.7 draft.

Lien vers le langage XML SPML (Service Provisioning Markup Langage) : http://www.oasis-open.org/committees/download.php/
3032/cs-pstc-core-1.0.pdf

Etat : Juin 2003 version 1.0 candidate for Committee Specification.

SPML : OASIS

WS-ReliableMessaging de l’OASIS

(Reprend WS-Reliability)

Acheminement de bout en bout des messages SOAP (au dessus du protocole de communication utilisé, donc notamment HTTP).

Prend en compte la contribution initiale de WS-Reliability publiée en Janvier 2003 par Fujitsu, Hitachi, Oracle, NEC, Sonic Software et Sun Microsystems.

Lien vers WS-Reliability :
http://xml.fujitsu.com/jp/concept/WS-ReliabilityV1.0.pdf

Etat de WS-Reliability : version 1.0 janvier 2003 draft. Proposé à l’OASIS en Avril 2003.

Acheminement de bout en bout des messages SOAP (au dessus du protocole de communication utilisé, donc notamment HTTP).

http://msdn.microsoft.com/webservices
/understanding/
specs/default.aspx?pull=/library/en-us/dnglobspec/html/ws-reliablemessaging.asp

Etat : Mars 2004, draft.

WS-RF (Resource Framework)

(WS-ResourceProperties
WS-ResourceLifetime)

Représentation et accès à des ressources ‘stateful’ dans un contexte distribué.
Met en œuvre une gestion de contexte selon un principe qui consiste à faire transiter dans le header SOAP une référence endpoint (WS-Addressing) vers une stateful ressource.

Une WS-Resource est définie comme une association entre un endpoint et une stateful ressource identifiée par un endpoint référence (au sens de WS-Addressing). La WS-Resource est gérée (création, lecture, suppression), dispose de propriétés et d’un cycle de vie.

Lien vers WS-ResourceProperties :
http://www-106.ibm.com/
developerworks/library/
ws-resource/ws-resourceproperties.pdf

Etat WS-ResourceProperties : Mars 2003 version 1.1 draft.

Lien vers WS-ResourceLifetime :
http://www-106.ibm.com/
developerworks/library/
ws-resource/ws-resourcelifetime.pdf

Etat WS-ResourceLifetime : Mars 2004 version 1.1 draft.

Lien vers WS-RF :
http://www-106.ibm.com/developerworks/
library/ws-resource/ws-wsrf.pdf

Etat WS-RF : Mars 2004 version 1.0 draft.

Appel en cascade de web services.

Lien : http://msdn.microsoft.com
/library/default.asp?
url=/library/en-us/dnglobspec
/html/ws-routing.asp

Etat : octobre 2001, draft.

Remplacé par WS-Addressing : http://msdn.microsoft.com/library/
default.asp?url=/library/en-us/dnwebsrv/html/wsroutetowsadd.asp

Représentation et gestion des web services interactif (interface homme-machine).

http://www.oasis-open.org/
committees/download.php/3343/
oasis-200304-wsrp-specification-1.0.pdf

Etat : standard approuvé Août 2003.

Partage de contexte de sécurité. Ce standard étend WS-Security qui se ‘limite’ à la définition de la sécurité dans le cadre d’un échange de message (dans le header SOAP). WS-SecureConversation permet de définir des assertions de sécurité partagées entre plusieurs messages.

ftp://www6.software.ibm.com/software/
developer/library/ws-secureconversation.pdf

Etat : Mai 2004 version 1.1 draft.

WS-Security

WS-Trust

WS-Security

[Web Service Security (WSS)]

Mise en place des informations de sécurité de base dans les headers SOAP (authentification, chiffrement).

L’OASIS s’appuie sur la contribution d’origine WS-Security de Microsoft, IBM, Verisign.

Lien vers la contribution d’origine WS-Security :
http://www-106.ibm.com/
developerworks/library/ws-secure/

Etat de la contribution d’origine WS-Security : avril 2002 version 1.0 draft.

Lien vers WS-Security SOAP message security 1.0 :
http://docs.oasis-open.org/wss/2004/01/
oasis-200401-wss-soap-
message-security-1.0.pdf

Etat WS-Security SOAP message security 1.0: technical committee document Mars 2004.

Lien vers WS-Security User name token Profile 1.0 :
http://docs.oasis-open.org/wss/2004/01/
oasis-200401-wss-
username-token-profile-1.0.pdf

Etat WS- Security User name token Profile 1.0: technical committee document Mars 2004.

Echange de token de sécurité (extension de WS-Security). Permet à un endpoint de s’assurer de l’identification des autres endpoints avec lesquels il communique.

ftp://www6.software.ibm.com
/software/developer0/
library/ws-trust.pdf

Etat : Version 1.1 Mai 2004 draft.

Référentiel pour le référencement des web services (et potentiellement d’autres ressources sous conditions de créer les taxonomies – c'est-à-dire les tModels – adéquats).

http://uddi.org/pubs/uddi_v3.htm

Etat : Version 3.0.1 Octobre 2003 Committee specification.

Lien vers les règles de mapping WSDL / UDDI :
http://www.oasis-open.org/
committees/uddi-spec/doc/tn/
uddi-spec-tc-tn-wsdl-v200-20031104.htm

Etat : updated periodically.