Le WSDL n’est pas “sémantique”. Surtout pas pour un programme qui ira le lire. Autrement dit, il faut déjà savoir ce qu’on cherche pour le trouver. Il faut avoir une implémentation du client déjà prête. On peut générer un client on the fly à partir du WSDL, mais comment savoir dans quelle ordre appellé les services, que passer en paramètre ? Ainsi, si on a un client, on a probablement déjà le WSDL. Alors comme source de WSDL inconnus, on oublie UDDI.

UDDI pourrais alors à trouver différentes implémentations du service ? Oui, mais ça ne peut marcher qu’a deux conditions qui ne sont pratiquement jamais réunies.

1. L’implémentation doit être standardisée
2. Le service doit être gratuit

Disons que le point 1 arrivera bien un jour, en commençant par des domaines spécialisés et soumis à des réglementations internationale (de l’industrie) comme la réservation de billets d’avion par exemple. D’où le “waiting” de mon résumé UDDI.

Le point 2 est là où tout s’effondre. Si le service n’est pas gratuit, il y aura une entente contractuelle entre les parties avant le premier appel SOAP. Que cette entente prenne la forme d’un contrat écrit, d’un courriel ou même d’un service web d’abonnement, on ne s’en sauve pas. Il y a une étape “contractuelle”. Le WSDL (et le endpoint) seront donnés lors de l’établissement du contrat. Pourquoi retourner dans UDDI pour me faire dire ce que je sais déjà ? Le service déménage ? 302 Moved.

UDDI pourra peut-être un jour être la solution au problème qu’il cherche/invente (j’appelle ça la solution “consultant”). Avoir un standard d’établissement de contrat avec un service, c’est la pierre d’achoppement de l’établissement d’un modèle distribué dynamique où UDDI aurait un rôle à jouer. Dans ce modèle, le client cherche les providers de contrats (le service pourrais être son propre provider de contrat), on établis un contrat et on appelle le service. Des standards comme WS-Trust pourrais jouer un rôle dans un tel scénario.

• WebSphere Application Server Community Edition (Geronimo)




• Eclipse 3.2




• Axis 1.4 (moving on to Axis 2.0 sometime, maybe)

Let’s see how that goes !