Introduction
Dans la plupart des cas, la raison de créer un service Web est de proposer un service (gratuit ou payant) pouvant être utilisé par des applications Web ou logiciels par un maximum de personnes. Ce service étant normalisé et standardisé.
Naturellement ce genre de services ne peut fonctionner sur la toile uniquement si les utilisateurs demandeurs de tels services peuvent les retrouver si ce n'est pas le cas, les heures abominables passées à taper des lignes de code n'auront servi a rien.
Les entreprises veulent être sûres que leurs services seront publiés de telle façon que n'importe qui intéressé par de tels services puisse les retrouver facilement ainsi que tous les agents Web et autres "spiders" sur la toile. Elles exigent donc une certaine qualité de service à cet égard.
Nous expliquerons donc, dans ce sujet, les principes fondamentaux pour faire en sorte que cela soit possible et comment enregistrer un service Web sur un annuaire UDDI pour qu'il soit accessible à tous.
UDDI signifie Universal Description, Discovery and Integration. Comme son nom l'indique, le but principal de ce projet est de proposer un standard pour la description des services Web et de permettre à n'importe qui de pouvoir retrouver le contenu et l'intérêt de tels services sur le net pour faciliter le développement d'applications multi niveaux. UDDI fonctionne donc comme une sorte de moteur de recherche dédié aux services Web, cependant le but principal de ce projet était de créer un standard pouvant être manipulé informatiquement.
1. L’histoire d'UDDI
1.1. Creation du standard UDDI
Le standard UDDI a été proposé par Microsoft, IBM et Ariba en septembre 2000. Plutôt que de soumettre ce projet à des organismes de standardisation tels que WC3 ou IETF, ces trois compagnies ont préféré créer le projet UDDI, aussi connu sous le nom de UDDI community ( http://www.uddi.org ) pour planifier et avoir la main sur la création de ce standard. Selon eux le projet UDDI était "une initiative commune visant à promouvoir le développement de logiciels basés sur une architecture multi niveaux grâce aux nouveaux outils Internet dans le but de créer de nouveaux secteurs d'activités et de nouveaux type de besoins standardisés". Les acteurs de ce projet prévoient actuellement de le soumettre aux organismes de standardisations lorsque la troisième version sera terminée.
Site dédié au projet et à la communauté UDDI
1.2. Evolution d'UDDI
La communauté autour d'UDDI a rapidement grandi. Regroupant à la base seulement trois compagnies, elle en regroupe aujourd'hui beaucoup d'autres et principalement des "mammouths" de l'industrie informatique comme Sun, HP et SAP.
Lorsque la seconde mouture d'UDDI fut terminée (v2.0), la communauté regroupait plusieurs centaines d'entreprises participantes dépassant de loin les simples sociétés spécialisées dans le secteur informatique. Pour en apprendre davantage à ce sujet n'hésitez pas à jeter un oeil par ici http://www.uddi.org/community.html.
1.3. Antécédent à UDDI
Avant de rejoindre le projet UDDI, beaucoup d'entreprises offraient des services similaires mais toutes étaient propriétaires et se basaient sur leurs technologies propres. Par exemple Microsoft BizTalk server permettait aux utilisateurs de rechercher, télécharger et publier leur projet XML. Hewlet-Packard disposait de son E-Service Village proposant des fonctions similaires mais qui ont depuis été remplacés par UDDI.
Beaucoup de ces services existent toujours cependant, aujourd'hui, la plupart des acteurs de ce marché considèrent UDDI comme le standard en matière d’annuaire d’enregistrement de services.
1.4. Fonctionnement d'UDDI
UDDI est avant tout dédié au B2B (business to business) électronique. Les principaux acteurs de ce secteur soutenant ce projet ont fait en sorte qu'UDDI devienne le modèle d'annuaire standard et dominant des services électroniques sur le net. Si l'on prévoit de publier ses services Web sur la toile, il est important de connaître le fonctionnement de ce nouveau standard et la façon d'en tirer profit au maximum.
UDDI est :
Un standard dédié à l'enregistrer de services (payant ou gratuit) d'une compagnie.
Prévu pour fonctionner avec les standards de W3C et IETF comme XML, HTTP, DNS et SOAP.
Régit par la communauté UDDI.
Gratuit (même s'il pourrait devenir payant un jour).
Ces différents points sont essentiels. UDDI fonctionnant sur des standards connu et reconnu, n'importe quelle entité est libre d'implémenter son propre modèle d'annuaire d'enregistrement de service Web tant qu'il respecte les principes de la communauté. Ainsi quelques grosses compagnies comme IBM ou Microsoft proposent leurs propres systèmes d'enregistrements UDDI qui sont complément gratuit pour le moment.
2. Pourquoi avoir créé UDDI ?
Nous avons déjà parlé de l'importance d'avoir un annuaire référençant les services Web et les publiant pour permettre à n'importe qui de les retrouver facilement. Mais pourquoi UDDI a t il su s'imposer comme la référence en la matière ? Nous allons répondre a cette question en examinant de plus près les objectifs du ce standard.
2.1. Un standard multi plateforme
UDDI définit une structure pour l'enregistrement de services. Cette structure peut très facilement être implémenté sur n'importe quelle plate-forme (que ce soit NT, Linux, Unix, etc.). Microsoft, par exemple, a construit son annuaire en se basant sur le framework .NET alors qu'IBM a utilisé ses technologies propriétaires pour construire le sien. Peu importe donc la façon dont on va développer ces annuaires, l'essentiel étant de respecter la structure définit par UDDI.
Nous étudierons cette structure dans le chapitre 3.
2.2. Une liberté d'innovation totale
Comme nous l'avons vu, UDDI se base sur des standards mondiaux comme HTTP, XML, SOAP mais le standard UDDI lui-même est totalement open source et gratuit. Il n'y a aucune contrainte de licence pour implémenter et développer de nouvelles fonctionnalités se basant sur UDDI. Tout comme il n'est pas nécessaire de payer pour créer son propre annuaire d'enregistrement avec UDDI.
2.3. Un support mondial
UDDI n'est pas seulement supporté par les acteurs majeurs de l'industrie comme Microsoft, IBM, Oracle et HP mais aussi par des centaines de compagnie tierce. Ce support est, en outre, réalisé par une variété importante de compagnie comme Boeing ou KPGM Consulting. Comme le dit si bien la communauté UDDI sur son site (http://www.uddi.org), UDDI "peut être utilisé par n'importe quel compagnie, pour n'importe quel type de service, peut importe sa taille et sa localisation".
Il est cependant intéressent de voir que la majorité des acteurs de cette communauté sont des sociétés se basant sur des technologies américaine. Quoiqu'il en soit l'importance de ces sociétés dans le développement d'UDDI a permit à ce projet de s'imposer par rapport à ses concurrents.
3. Annuaire d'enregistrement de service UDDI
3.1. Principe de fonctionnement
Un annuaire d'enregistrement de service est une implémentation du standard UDDI. Cette instance est en fait une entité disponible sur le net avec laquelle n'importe quel navigateur ou message XML peuvent interagir. Comme nous l'avons dit plus tôt il existe pour le moment trois annuaires d'enregistrement majeurs aussi appelé "nœuds d'enregistrements" :
Le premier est hébergé par Microsoft.
Le second par IBM.
Le troisième (plus récent) par HP.
Ces trois leaders proposent tous un système d'enregistrement gratuit mais il faudra, par exemple, disposer d'un passeport .NET ou d'un compte utilisateur chez IBM pour enregistrer son service.
Interface de référencement UDDI de Microsoft
Chacun de ces nœuds a accepté d'adhérer à la stratégie de qualité de service (QoS) définit par les membres du comité directeur de la communauté UDDI. Cela veut dire qu'ils s'engagent notamment à certifier que chaque enregistrement de service est répliqué entre les nœuds à intervalle régulier (toutes les 24h). Cette réplication est faite via un canal sécurisé. Au final chaque noeud possède une réplique complète de l'ensemble des services Web disponibles sur les annuaires. Plus le nombre de nœuds augmentera et avec eux le nombre d'enregistrement, et plus la fréquence des réplications augmentera elle aussi.
Chaque hébergeur de noeud doit se conformer au standard UDDI mais comme nous l'avons vu il est cependant libre de la façon dont il va développer son propre annuaire; ainsi IBM a développé le sien en Java, pendant que Microsoft développait son propre annuaire en C# se basant sur le framework .NET et SQL Server 2000 pour stocker les enregistrements. D'ailleurs une version de l'annuaire d'enregistrement Microsoft est disponible gratuitement sur le site de Microsoft consacré à UDDI (http://uddi.microsoft.com) pour toutes personnes intéressé par la configuration de son propre annuaire d'enregistrement ou pour tester celui-ci. Il n'y a aucun problème de compatibilité entre les différents nœuds puisqu'ils sont tous conforme au même WSDL (Web Service Définition Language) et se comportent donc de la même manière. Les envois entre les noeuds sont sous la forme de fichier XML ce qui veut dire que la technologie utilisé par l'annuaire derrière importe peu.
L'annuaire d'enregistrement est en fait lui même un service Web. Il est possible de télécharger une édition de ce service, incluant des exemples de codes sur la MSDN : http://msdn.microsoft.com
Techniquement, UDDI se comporte comme un DNS orienté services. Alors qu'un DNS permet de trouver l'adresse IP d'un serveur a partir d'un hostname, l'annuaire UDDI permet de trouver un service Web grâce au nom de la compagnie ou de la catégorie dans laquelle se situe son service. Les catégories peuvent être définit en fonction du domaine d'activité de la société ou de son emplacement. L'annuaire est en fait essentiellement une base de données dans laquelle on va pouvoir trouver une description et un lien vers l'interface du service Web correspondant à notre recherche (ex : WSDL ou XSD) et son implémentation ( ex : les fichiers asmx).
En plus de cet agenda de production Microsoft propose également un annuaire de test qui peut être utilisé pour debugguer des programmes conforme au standard UDDI sans corrompre le fichier initial. L'annuaire de test se trouve à http://test.uddi.microsoft.com/default.aspx.
3.2. Contenu d'un enregistrement conforme UDDI
Chaque enregistrement dans un annuaire au standard UDDI contient certaines informations à propos de la société ayant effectué cet enregistrement et à propos du service Web proposé. L'annuaire UDDI va stocker ces données de manière structurée (grâce à XML). Les informations sur le service sont stockées dans 5 entités de données (tables) relationnelles (pour UDDI v2.0). Chaque table est associée aux autres. Nous allons étudier chacune d'elle plus en détails :
1 businessEntity
Cette table fournit un identifiant unique, un nom de service (ou business name), une description courte et des informations sur les personnes à contacter, une liste de catégories identifiant la société et une URL pointant sur une page décrivant la société.
2 businessService
Chaque société peut avoir un ou plusieurs services Web associés. Un businessService contient la description du service, une liste des catégories auquel appartient le service Web, une liste de pointeur vers les références et les informations du service Web. Le businessService est en quelque sorte la représentation logique du service.
3 bindingTemplate
Un service Web peut avoir un plusieurs bindingTemplate. Il contient les informations techniques a propos du service comme sa localisation (ou point d'accès) sous la forme d'une URL. La table businessService représente le service Web logiquement alors que la table bindingTemplate le représente physiquement.
4 publisherAssertion
Cette table contient des informations sur les enregistrements des relations entre les différentes businessEntity. En effet la plupart des "grosses" sociétés ne peuvent pas être représenté par une seule entrée dans la table businessEntity car elles peuvent avoir un grand nombre de secteurs d'activités différents (par exemple Vivendi, AOL, etc.). Dans ce cas il est normal qu'une société puisse avoir plusieurs entrées dans la table BusinessEntity pour cibler plus efficacement leurs différents domaines d'activités et ainsi les recenser de façon optimale. La table publisherAssertion a été conçue dans ce but.
5 tModel
Il est souvent difficile de comprendre réellement l'intérêt de cette table qui parait en général assez flou puisqu'elle contient des meta données (donnés sur les données). Il s'agit en fait d'un document source pour déterminer la compatibilité du service. C'est une sorte de classe "abstraite". Une sorte de récipient sur la façon de construire un service Web, de le définir (par WSDL) et sur les méthodes de développement du service Web sans pour autant porter sur son implémentation et son contenu propre. Elle reste très importante dans le monde des services Web et d'UDDI mais nous n'entrerons pas dans les détails de celle-ci, car elle dépasse la portée de ce document.
Voici le modèle du standard UDDI et les relations entre les différentes tables que nous venons de voir :
Relation entre les 5 entités UDDI
Ce diagramme montre les relations (un à plusieurs) entre la table businessEntity, la table businessService et la table bindingTemplate. Une relation similaire existe entre les tables bindingTemplate et tModel puisqu'un tModel peut avoir plusieurs bindingTemplates associés.
Pour en apprendre davantage à propos de ce modèle et notamment l'entité tModel n'hésitez pas à consulter l'aide en ligne de Microsoft http://msdn.microsoft.com.ainsi que la documentation officielle sur la structure des données UDDI sur le site http://www.uddi.org.
3.3. Tri par catégorie
La possibilité de structurer les données sous forme de catégories était l'un des objectifs fondamental lors du développement d'UDDI. C'est aussi l'un des points faibles du modèle. En effet, contrairement à un moteur de recherche c'est la société qui définit à quelle catégorie son service Web appartient lorsqu'elle enregistre celui-ci, mais l'un des gros inconvénients du modèle est que ce système ne prend pas en compte la sous catégorisation. Prenons un exemple simple : une société parisienne va par exemple pouvoir choisir la catégorie "France" pour référencer son service. Lorsqu'un client potentiel recherchera les service Web français il trouvera alors sans problème notre service, cependant s'il cherche les services Web européens grâce à la catégorie "Europe", notre service n'apparaîtra pas car le modèle ne prend pas en compte justement les sous catégories ce qui réduit évidement grandement l'intérêt des catégories. Il est cependant possible de définir plusieurs catégories par service. Alors pourquoi avoir fait un tel oubli ?
Il est tout simplement volontaire. Les concepteurs du modèle UDDI ont voulu donner aux développeurs d'annuaires d'enregistrements le maximum de flexibilité. Leur but n'a jamais été de proposer des options avancées de recherche simplement un modèle de référencement des données. Ils préfèrent laisser cette tache aux développeurs eux-mêmes. Puisque les annuaires UDDI sont prévu pour grandir rapidement et contenir des millions d'enregistrements (et donc énormément de catégories), cela parait logique d'avoir voulu laisser aux développeurs d'annuaire le soin de créer eux-mêmes leurs propres systèmes de recherche.
3.4. Accéder à un enregistrement
Le moyen le plus simple d'accéder à un enregistrement est d'utiliser un navigateur Internet pour se connecter sur l'un des principaux annuaires existants cité précédemment. L'annuaire d'enregistrement UDDI de Microsoft est disponible ici http://uddi.microsoft.com. Celui d'IBM peut se trouver ici http://www-3.ibm.com/services/uddi. Il est également possible d'accéder à un service Web depuis certains logiciel notamment Visual Studio .NET qui propose en fait un mini browser pour se faire.
Ces deux sites comprennent une implémentation totale du standard UDDI et effectuent exactement les mêmes tâches. Il n'y aucun intérêt à enregistrer votre service Web sur l'un et sur l'autre puisque nous avons vu que les bases contenant les enregistrements étaient répliqués très régulièrement.
4. Découverte de l'annuaire UDDI de Microsoft
4.1. Principes de base de l'enregistrement
Note : Nous utiliserons pour cette étude de cas, l'annuaire de test de Microsoft disponible à l'adresse suivante : http://test.uddi.microsoft.com
La première étape lorsque vous voulez enregistrer votre service Web sur l'annuaire d'enregistrement est de disposer d'un passeport .NET. Si vous n'en avez pas encore n'hésitez pas à en créer un, une option vous sera proposé en cliquant sur "register" dans le menu de gauche. Une fois cette formalité terminée vous allez arriver sur une page ressemblant à la figure 4.1 ci-dessous :
4.1 Enregistrement de votre secteur d'activité
4.2. Informations importantes
C'est à ce niveau que vous allez devoir les détails sur votre société (name, phone number, business, address, city, country, etc.). Une fois que vous aurez soumis ces informations, cliquez sur "Publish", vous allez pouvoir utiliser le menu qui vous ai proposé pour compléter certaines tâches : contacts, identificateur unique (DUNS number), classification, services, tModels.
La figure 4.2 vous présente l'interface prévue à cet effet :
4.2 Description d'un contact
- Contacts
Chaque société doit disposer d'un contact. Les informations de ce contact sont utilisées par d'autres sociétés voulant entrer en contact avec vous. Vous aurez à préciser le nom, le numéro de téléphone, l'adresse et le mail de ce contact. Attention cependant ces informations sont évidement rendu publique et beaucoup de personne prise les annuaire UDDI pour créer des listes d'email. Ne vous étonnez donc pas de recevoir dans les jours qui suivent de nombreux mails inintéressant vous saurez d'ou ils proviennent !
- Identifiers
Les identifiers sont des numéros uniques pour votre activité. Le système UDDI vous permet de rentrer vous même votre identifier si vous ne voulez pas en créer un.
- Categories
Les catégories permettent de réaliser un tri en fonction de différents critères sur votre entité que ce soit par le domaine d'activité ou par le lieu géographique. Il est donc important d'être certain d'avoir choisi la bonne catégorie. UDDI permet non seulement de définir votre société en fonction de certains critères mais cela est également valable pour chaque service Web que vous proposerez.
- Services
C'est ici que vous allez mettre en place les services Web que vous proposez en incluant le WSDL (Web Service Description Language) de votre service et le lien vers votre fichier asmx. Les services peuvent ensuite être trié et associer avec des tModels.
4.3 Ajout d'un service Web
- tModels
Vous pouvez associer plusieurs modèles avec votre société ou l'un de vos services Web.
4.4 Ajout d'un tModels
Bien qu'il soit important de remplir chacun de ces champs pour identifier clairement votre société et les services qu'elle propose, ce n'est cependant pas obligatoire surtout si vous souhaitez simplement tester votre service Web dans un premier temps comme c'est le cas ici.
Cependant si vous voulez que l'on retrouve facilement les services que vous proposez il est important de prendre le temps nécessaire pour remplir toutes les informations proposées notamment en ce qui concerne les catégories.
Nous ne rentrerons pas dans tous les détails ici quand aux informations nécessaires. Si vous avez suivi ce document convenablement cela ne devrait pas vous poser de problèmes, puisque vous connaissez à présent le fonctionnement du modèle UDDI. Pour en apprendre davantage n'hésitez pas à consulter l'aide disponible sur le site de la msdn ainsi que le support technique disponible sur le site consacré à UDDI de Microsoft.
Conclusion
L'arrivée des connexions permanentes à prix avantageux que ce soit pour les entreprises ou les particuliers et l'ouverture des sociétés aux technologies Internet ont permis l'essor des services Web. Ce type de service est de plus en plus prisé que ce soit dans les applications Web ou les applications standard. Ce nouveau domaine d'activité fondamentalement orienté B2B nécessitait une standardisation quant à la diffusion et au référencement sur le Web des services Web.
UDDI a donc été conçu dans ce but. La simplicité du modèle, son efficacité et l'ouverture qu'il propose aux développeurs lui ont permis de s'imposer comme le standard en matière d'annuaire d'enregistrements des services Web. Il ne faut pas non plus oublier qu'il a été conçu à la base par deux des principaux acteurs de ce secteur d'activité : Microsoft et IBM. Fort de leur expérience, de leurs relations et de la qualité de leurs services, beaucoup de compagnies ont pris le train en marche en intégrant la communauté UDDI.
Les deux principaux noeuds d'enregistrements existant proposés par Microsoft et IBM permettent de référencer gratuitement et facilement les services Web d'une entreprise. Le principe de réplication des bases des annuaires UDDI entre les nœuds et la catégorisation assure à la société que son service sera accessible à tout le monde, et cela peut importe l'annuaire qui sera utilisé pour faire la recherche, avec un simple navigateur.
Ces annuaires devraient se répandre de plus en plus sur le net comme les moteurs de recherche à leur époque, puisque les services Web ne cessent de se développer. La communauté UDDI n'hésite pas à affirmer que l'annuaire global devrait contenir plusieurs millions d'enregistrement d'ici l'année prochaine. Le modèle étant prévu à cet effet il devrait évoluer avec les besoins grandissant mais sans changer ses principes fondamentaux.
Toutes les informations sur l'évolution d'UDDI sont disponibles sur le site de la communauté http://www.uddi.org/news.html.