WS-I : Web services (non)Interoperability

Vous avez sans doute déjà entendu parle de WS-I. Voici un extrait de leur page about:

WS-I is an open industry organization chartered to promote Web services interoperability across platforms, operating systems and programming languages. The organization’s diverse community of Web services leaders helps customers to develop interoperable Web services by providing guidance, recommended practices and supporting resources. All companies interested in promoting Web services interoperability are encouraged to join the effort.

WS-I regroupe tous les mammouths de la profession, de Microsoft à IBM en passant par Oracle, SAP, Intel,… La préoccupation principale de WS-I est l’intéropérabilité, on ne peut que saluer une telle initiative. Elle part d’un constant simple: bien que les web services soient basés sur des spécifications ouvertes du W3C SOAP, WSDL, XML,… Il n’est pas rare que deux implémentations de ces spécifications n’arrivent pas à intéropérer à 100%. D’où WS-I basic profile une spécification dont le but est décrit dans l’abstract de la spec:

This document defines the WS-I Basic Profile 1.0, consisting of a set of non-proprietary Web services specifications, along with clarifications and amendments to those specifications which promote interoperability.

Le point central est donc bien l’intéropérabilité, dont même notre ministre de la culture connait l’importance depuis les débats du projet de loi DADVSI.

Poursuivons la lecture de la spécification WS-I basic profile… Section 1.1 Guiding Principles:

No guarantee of interoperability

It is impossible to completely guarantee the interoperability of a particular service. However, the Profile does address the most common problems that implementation experience has revealed to date.

Un doute immense m’envahit, pourtant non, le sénat français n’est pas membre de WS-I! Tout ça pour ça, s’était trop beau, en fait ce n’est que du flan. Le but de l’initiative est de garantir l’intéropérobérabilité des web services et la spec démarre par: pas de garantie de l’intéropérabilité??? “Il est impossible de complètement garantir l’intéropérabilité” C’est impossible où les membres de WS-I ne veulent pas?

babel.jpgA quand remonte la dernière fois où vous n’avez pas réussir à faire communiquer entre elles 2 cartes réseaux de marque différentes? Pour peu que les constructeurs ne fassent pas n’importe quoi, l’ethernet n’est-il pas un standard qui garanti l’intéropérabilité de la couche physique?

A quand remonte la dernière fois où vous n’avez pas réussi à pinger un mac depuis un PC? Pour peu que les éditeurs y mettent un peu du leur, TCP/IP n’est-il pas un standard qui garanti l’intéropérabilité de la couche transport?

A quand remonte la dernière fois où vous n’avez pas réussi à lire avec différents parseurs un même document xml correctement formé? XML n’est-il pas un standard qui garantie l’intéropérabilité des documents?

Lisez cet article de Tim Berners-Lee: The Stack of Specifications, vous y retrouverez toutes ces spécifications ainsi que les liens vers les documents de référence, aucun ne contient les mots “No guarantee of interoperability”, bien au contraire.
Pourquoi les implémentations des web services n’adopteraient pas ce principe simple à la base de l’intéropérabilité:

In general, an implementation must be conservative in its sending behavior, and liberal in its receiving behavior. That is, it must be careful to send well-formed datagrams, but must accept any datagram that it can interpret (e.g., not object to technical errors where the meaning is still clear).

Lentement mais surement l’intéropérabilité s’est imposé à notre industrie en partant des couches les plus bases. A chaque couche des protocoles basés sur des principes simples, robustes et transparents ce sont imposés. Il nous reste à conquérir la couche applicative. Quand je vois ce qui est écrit dans une spec comme WS-I basic profile j’ai du mal à croire que ce soit un jour les web services qui garantissent l’intéropérabilité au niveau de la couche applicative.

Comment font-ils?

Depuis 2, 3 ans google a recruté tout ce que le monde java compte comme star.

Depuis 2 ans google nous épate régulièrement avec des applis client riche en ajax incroyable (Google mail, calendar, maps, notebook,…)

Mais comment font-ils pour coder ces merveilles?

La réponse vient d’être dévoilée aujourd’hui: Google Web Toolkit

Google code l’interface de ses applis web en java puis utilise un compilateur pour générer du javascript de l’AJAX… Il fallait oser, ils l’ont fait et comme ils disent: “We’re biased, but we think it works pretty darn well”
Développer en javascript est très penible, c’est quasiment impossible à débugguer, alors que yahoo débug en affichant des messages dans un div, google peut se servir de toute la puissance d’un débugguer java…
Derrière ça vous mettez le google cluster, le google file system et mapreduce… Ils peuvent donner ce toolkit en open source, ils ont encore de la marge avant que la concurrence ne les rattrape.

Scrat le DSI

Une métaphore qui m’a fait mourir de rire hier ? une présentation…

Imaginez un instant que Scrat, l’écureuil de Ice Age, soit DSI.

Sa direction métier (le Mammouth) lui demande d’urgence d’installer une nouvelle application (le gland). Scrat doit forcer pour installer cette nouvelle application dans son système d’information monolithique (la banquise) Je vous laisse découvrir ce qu’il se passe ensuite dans la vidéo ci-dessous…

Une autre, toujours Scrat en DSI, cette fois ci sa mission est d’ajouter une nouvelle fonctionnalité dans un silo applicatif…