Voir
aussi: Les
briques métier et d'orchestration
La construction de l'édifice destiné à
supporter les Web Services se poursuit. En quelques mois,
les travaux relatifs à la mise au point de cette
interface universelle de publication et d'intégration
de composants ont beaucoup progressés. C'est notamment
ce que met en valeur cette seconde édition de notre
panorama.
Les évolutions en question ? Elles concernent
principalement la gestion de la sécurité
des échanges, la garantie de l'intégrité
des messages SOAP en particulier. Mais également
les projets liés à l'affichage des services
Web, champ dont les diverses spécifications sont en cours
de consolidation (voir le second
volet).
Des
obstacles à surmonter
Malgré tout,
force est de constater que des divergences existent encore
entre éditeurs. Une difficulté qui est notamment
mise en valeur par les doublons existants au chapitre
des nombreuses propositions présentées ici
(WS-ReliableMessaging/WS-Reliability, etc.).
Dernièrement, un nouvel épisode est venu
encore renforcé cette impression: le W3C a décidé
de se lancer (en mai 2002) dans un projet de standardisation
touchant à l'orchestration des Web Services (nom
de code: BPEL4WS)... Et ceci alors que l'OASIS planchait
déjà depuis longtemps sur cette question
(avec WSCI). Un état de fait qui, rappelons le,
avait provoqué une levée de boucliers général
de la part des analystes (voir l'article).
Forte heureusement, les récentes déclarations
des deux groupements, mettant en avant leur volonté
de collaboration (autour des architectures de services
Web), pourrait contribuer à dépasser cet
obstacle...
Un
édifice qui reste inachevé
Le tableau ci-dessous tente de faire le point sur les
technologies établies ou en cours de définition.
Nous les avons découpé en deux groupes :
les couches fondamentales et les protocoles relatifs à
la sécurité et à la gestion des transactions.
Les couches fondamentales
sont au nombre de trois et répondent chacune à
une question:
Découverte: comment identifier et localiser
les Web Services ?
Description:
comment exposer les fonctions des Web Services ?
Echange:
comment échanger les messages entre les Web Services
?
|
Les
couches de base
|
| Découverte |
UDDI
(2.0) (OASIS) |
Annuaire
mondial indexant notamment les Web Services publiquement
mis à disposition par les entreprises, et
les références techniques de ces derniers. Objectif:
permettre à terme aux services Web de s'invoquer
dynamiquement. Projet initié par Microsoft. |
| WS-Inspection
(Microsoft) |
Issus des projets ADS (IBM) et DISCO, WS-Inspection
se charge d'agréger les pointeurs vers les Web Services
qu'une entreprise souhaite exposer. A la différence
d'UDDI, il ne permet pas de rechercher des services
dont on ne connaîtrait pas les coordonnées. |
| XRI
(OASIS) |
Ce
mécanisme (Extensible Resource Identifier) qui repose
sur le standard URI (pour Uniform Resource Identifier)
vise à proposer une solution équivalente à celle
des noms de domaines (URL) pour retrouver un service
Web.
Projet soutenu par Microsoft, Sun et IBM. |
Description
|
WSDL
(W3C) |
Consolidation
de NASSL (Ariba), SCL (Microsoft)
et SDL (IBM), Web Services Description Language
1.1 est un format d'invocation des méthodes
et des paramètres d'un composants distants. |
Echange
|
SOAP
(1.2) (W3C) |
Protocole
gérant l'échanges d'informations. Il utilise XML
pour formater ses messages et http pour les véhiculer.
Dans sa version 1.2, il s'étend au support d'autres
protocoles que HTTP (TCP, UDP, etc.) tout en étant
capable d'intégrer des fichiers attachés (par le
biais de SOAP Attachment et DIME). |
| WS-Addressing
(Microsoft ) |
WS-Addressing,
projet dessiné par IBM, Microsoft
et BEA, permettrait de véhiculer des messages
SOAP de manière bi-directionnelle, que ce soit en
mode synchrone ou asynchrone, le tout indépendamment
de la couche de transport. |
Quant
à la sécurité et la gestion
de l'intégrité (message et transaction),
nous avons choisi de les dissocier car elles interviennent
en fait à tous les étages des couches
de base des Web Services. Dans les deux cas, transaction
et sécurité, deux protocoles sont en concurrence.
|
Transaction/Sécurité
|
|
Gestion
de l'intégrité des messages
|
WS-Reliability
(Sun) |
Cette
spécification standardise le dispositif mis en uvre
entre deux Web Services en vue de garantir la réception
des messages transmis (par le biais d'accusés de
réception notamment). Projet initié par Sonic
Software et Sun. |
| WS-Acknowledgment
(BEA) |
Avancée
par BEA System, l'objectif de cette proposition
semble comparable à celle de WS-Reliability.
|
| WS-ReliableMessaging
(Microsoft) |
Très
proche de WS-Acknowledgment (y compris en termes
de vocabulaire), WS-ReliableMessaging a été
défini conjointement par IBM, Microsoft,
BEA et TIBCO. |
| Gestion
de l'intégrité des transactions |
WS-Transaction
(OASIS) |
Reposant sur WS-Coordination (IBM), WS-Transaction
vise
à garantir l'intégrité de transactions exécutées
via les Web Services. Il devrait
être prochainement être soumis par Microsoft
à un organisme de standardisation.
Projet initié par Microsoft. |
| BTP
(OASIS) |
Initié
par BEA, Business Transaction Protocol gère
l'intégrité des transactions longues
et complexes. Il est comparable à WS-Transaction. |
| WSCL
(W3C) |
Web Services Conversation Language (WSCL) qui a
été soumis au W3C par HP a pour but de préciser
les règles d'invocation d'un Web Services et a le
statut de Note. |
Sécurité
|
SAML
(OASIS) |
Protocole
couvrant les problématiques d'authentifications
et d'habilitations des transactions SOAP. Projet
soutenu par IBM et Microsoft. La |
| XACML
(OASIS) |
Access
Control Markup Language définit un schéma
pour décrire les politiques de droits d'accès
à des objets XML. Projet initié par
Entrust et soutenu par IBM. |
| WS-
Security (W3C) |
Soumis
par Microsoft, IBM et Verisign,
WS-Security couvre l'authentification, la gestion
de l'intégrité et le cryptage des échanges. Il précise
en outre la manière de décrire les droits et les
conditions d'utilisation associés à un Web Services.
Il se décline en nombreuses sous-spécifications
(WS-Trust, WS-Secure, WS-Policy, WS-Privacy,
WS-Federation et WS-Authorization). |
| XrML
(OASIS) |
Proposé par l'éditeur américain
ContentGard, eXtensible rights Markup Language
aborde les conditions d'utilisation (ou droits numériques)
associées au contenu d'un service Web. |
Voir
aussi: Les
briques métier et d'orchestration
|
[