Exporter (0) Imprimer
Développer tout

Découvrir et décrire un service Web en utilisant UDDI, 1ère partie

Cliquez ici pour télécharger l'exemple - AtYourService10032001.exe.

Karsten Januszewski
Microsoft Corporation

Afficher et télécharger le code source de cet article Lien non MSDN France Site en anglais

Introduction

Jusqu'à présent, la rubrique At Your Service a expliqué comment construire un service Web, depuis les documents de conception initiale jusqu'au développement final, en passant par les aspects commerciaux. La prochaine étape logique consiste à examiner comment diffuser ce service Web de façon à ce que les clients intéressés puissent le découvrir facilement et l'intégrer à leurs applications. Il existe un mécanisme qui répond à ces exigences : UDDI (Universal Description Discovery and Integration), initiative industrielle visant à soutenir la diffusion des services Web sur plusieurs technologies et plates-formes.

Les auteurs de la rubrique At Your Service m'ont gentiment offert la possibilité de rédiger une rubrique spéciale présentant UDDI et les étapes de la procédure d'inscription. J'examinerai en premier lieu les implications d'UDDI d'un point de vue technologique et commercial. J'analyserai ensuite la relation entre UDDI et le langage WSDL (Web Services Description Language). Enfin, je décrirai les étapes de l'enregistrement sur UDDI et expliquerai les points à considérer si l'on veut exploiter tout son potentiel. La rubrique suivante (2ème partie) servira à décrire les étapes suivies par l'équipe de At Your Service pour tirer pleinement parti d'UDDI.

UDDI : un registre mondial des services Web

UDDI est un registre public conçu pour héberger des informations sur les entreprises et leurs services de façon structurée. Au travers d'UDDI, il est possible de publier et de découvrir des informations sur une entreprise et ses services Web. Ces données peuvent être classifiées à l'aide de taxinomies standard. Ces informations peuvent donc être recherchées par catégories. Enfin et surtout, UDDI contient des informations sur les interfaces techniques des services d'une entreprise. Grâce à un jeu d'API XML basées sur SOAP, il est possible d'interagir avec UDDI au moment de la conception et de l'exécution pour découvrir des données techniques, de sorte que ces services peuvent être invoqués et utilisés. De cette façon, UDDI sert d'infrastructure à un paysage logiciel reposant sur des services Web.

Pourquoi UDDI ? Pourquoi aurait-on besoin d'un tel registre ? Alors que nous progressons vers un paysage de milliers (voire de millions) de services Web, des difficultés surgissent :

  • Comment les services Web sont-ils découverts ?
  • Comment cette information est-elle catégorisée de façon pertinente ?
  • Quelles sont les implications pour la localisation ?
  • Quelles sont les implications pour les technologies propriétaires ? Comment garantir l'interopérabilité du mécanisme de découverte ?
  • Comment interagir avec un tel mécanisme de découverte lors de l'exécution une fois que mon application est dépendante d'un service Web ?

C'est en réponse à ces difficultés que UDDI est né. Un certain nombre d'entreprises, notamment Microsoft, IBM, Sun, Oracle, Compaq, Hewlett Packard, Intel, SAP et plus de 300 autres (la liste complète des participants est consultable à l'adresse suivante : UDDI: Community Lien non Microsoft Site en anglais se sont réunies pour développer une spécification basée sur des technologies standard non propriétaires afin de surmonter ces difficultés. Le résultat (lancé pour la première fois en version bêta en décembre 2000 et produit en mai 2001) fut un registre commercial mondial hébergé par plusieurs nœuds opérateurs dans lesquels les utilisateurs peuvent (gratuitement) rechercher et publier.

Avec une telle infrastructure de services Web en place, il est possible de mener des recherches cohérentes et fiables sur les données des services Web, dans un environnement universel complètement exempt de l'influence des vendeurs. On peut mener des recherches précises par catégorie, en utilisant des systèmes de taxinomie et d'identification extensibles. L'exécution d'UDDI peut être incorporée aux applications. Par conséquent, un environnement logiciel de services Web peut s'épanouir.

Comment cela fonctionne-t-il ?

Les informations UDDI sont hébergées par des nœuds opérateurs, entreprises qui se sont engagées à mettre en place un nœud public conforme aux spécifications énoncées par le consortium UDDI.org. Il existe aujourd'hui deux nœuds publics conformes aux spécifications de la version 1 d'UDDI : l'un est hébergé par Microsoft et l'autre par IBM. Hewlett Packard s'est engagé à héberger un nœud conforme aux spécifications de la version 2. Les opérateurs hôte doivent répliquer les données entre eux au travers d'un canal sécurisé, fournissant une redondance de l'ensemble du nuage UDDI. Les données peuvent être publiées sur un nœud puis, après réplication, peuvent être diffusées sur un autre nœud. Aujourd'hui, il y a réplication toutes les 24 heures. Dans le futur, lorsque davantage d'applications dépendront des données UDDI, les intervalles entre réplications seront plus courts.

Il est intéressant de remarquer qu'il n'existe aucune exigence propriétaire au-delà du fait que l'opérateur hôte implémente effectivement son nœud. Ce nœud doit simplement être conforme aux spécifications UDDI. Le nœud Microsoft (http://uddi.microsoft.com/default.aspx Lien non MSDN France Site en anglais), par exemple, a été entièrement écrit en C# et s'exécute en production sur le .NET Beta 2 Common Language Runtime. La base de code tire parti de la prise en charge SOAP native et de la sérialisation offerte par les classes du système .NET. En arrière plan, le nœud opérateur Microsoft utilise Microsoft® SQL Server 2000 pour stocker les données. Inutile de préciser que le nœud IBM utilise des technologies pour gérer son nœud ! Néanmoins, les deux nœuds se comportent de façon identique, parce qu'ils sont conformes au même ensemble d'appels API XML basés sur SOAP. Les outils clients peuvent interopérer avec les nœuds sans difficulté. Ainsi, le nuage public UDDI constitue un premier exemple de la façon dont le modèle de Services Web fonctionne avec des environnements hétérogènes.

Pour comprendre le projet UDDI, il faut ensuite examiner les données stockées dans UDDI et la façon dont elles sont structurées. UDDI est relativement léger. Il est conçu comme un registre et non comme un espace de stockage. La distinction est subtile mais essentielle. Un registre dirige les utilisateurs vers les ressources, alors qu'un espace de stockage contient véritablement les informations. Considérons par exemple le registre Microsoft® Windows® : il contient des paramètres et une configuration de base, mais, en fin de compte, il guide l'application vers une ressource ou un fichier binaire. En recherchant un composant COM par son ID de programme, on aboutit à une ID de classe, ce qui permet de trouver l'emplacement du fichier binaire.

UDDI se comporte de façon similaire : à l'instar du registre Windows, il utilise des GUID (Globally Unique IDentifiers) pour réaliser des recherches et déterminer l'emplacement des ressources. Les requêtes UDDI aboutissent en fin de compte à une interface (un fichier .WSDL, .XSD, .DTD, etc.) ou à une implémentation (un fichier .ASMX ou .ASP) située sur un autre serveur. UDDI peut ainsi répondre aux questions suivantes :

  • "Quelles sont les interfaces de services Web publiées qui sont basées sur WSDL et établies pour une industrie donnée ?"
  • "Quelles entreprises ont écrit une implémentation autour de l'une de ces interfaces ?"
  • "Quels services Web, classés selon certains critères, sont disponibles aujourd'hui ?"
  • "Quels services Web offre une entreprise donnée ?"
  • "Qui faut-il contacter pour utiliser les services Web d'une entreprise donnée ?"
  • "Quels sont les détails d'implémentation d'un service Web donné ?"

WSDL et UDDI

WSDL est aujourd'hui prédominant dans la pile de protocoles pour services Web. Pour cette raison, il est important de comprendre comment UDDI et WSDL fonctionnent ensemble et comment la notion d'interface et d'implémentation fait partie de chaque protocole. WSDL et UDDI ont été conçus pour établir une claire distinction entre les métadonnées abstraites et les implémentations concrètes. Pour comprendre les implications de cette division, il est essentiel de comprendre WSDL et UDDI.

Par exemple, WSDL fait une distinction claire entre les messages et les ports. Les messages, syntaxe et sémantique indispensables à un service Web, sont toujours abstraits. Les ports, adresse réseau à laquelle le service Web peut être invoqué, sont toujours concrets. Il n'est pas obligatoire de fournir des informations sur le port dans un fichier WSDL. Un WSDL peut contenir exclusivement des informations abstraites sur l'interface et ne fournir aucune donnée d'implémentation concrète. Un tel fichier WSDL est considéré valide. De cette façon, les fichiers WSDL sont séparés des implémentations.

L'une des implications les plus intéressantes de ceci, c'est qu'il peut exister plusieurs implémentations d'une même interface WSDL. Cette conception permet à plusieurs systèmes d'écrire des implémentations de la même interface, ce qui garantit que les systèmes pourront communiquer entre eux. Si trois entreprises différentes ont implémenté le même fichier WSDL et qu'un logiciel client a créé le code proxy/stub à partir de cette interface WSDL, alors le logiciel client peut communiquer avec les trois implémentations avec la même base de code en changeant simplement de point d'accès.

Avec son concept de tModel, UDDI établit une distinction similaire entre abstraction and implémentation. La structure tModel (abréviation de "Technology Model") représente les empreintes digitales, les interfaces et les types de description techniques des métadonnées. Les modèles de liaison, corollaires des tModels, constituent l'implémentation concrète d'un ou plusieurs tModels. Au sein d'un modèle de liaison, on peut enregistrer le point d'accès d'une implémentation donnée d'un tModel. Tout comme le schéma de WSDL permet de séparer interface et implémentation, UDDI fournit un mécanisme similaire, les tModels pouvant être publiés séparément des modèles de liaison qui les référencent. Par exemple, imaginons qu'un organisme de normalisation ou un groupe industriel publie l'interface réglementaire d'une industrie donnée  plusieurs entreprises pourraient ensuite écrire des implémentations de cette interface. Chacune des implémentations de ces entreprises référenceraient alors ce même tModel. Les fichiers WSDL sont des exemples parfaits d'un tModel UDDI.

Enregistrement sur UDDI

Publier sur UDDI est une procédure simple. La première étape est de déterminer des informations de base sur la façon de modéliser votre entreprise et ses services dans UDDI. Une fois ces informations déterminées, l'étape suivante consiste à procéder à l'enregistrement, ce qui peut être fait soit via une interface utilisateur sur le Web ou par programmation. L'étape finale consiste à tester votre entrée pour s'assurer qu'elle a été correctement enregistrée et qu'elle apparaît comme prévu dans les différents types de recherches et d'outils.

Étape 1 : Créez votre entrée UDDI

Étant donné le modèle de données décrit plus haut, il faut réunir certaines données essentielles avant d'établir une entrée UDDI.

  1. Déterminez les tModels (fichiers WSDL) utilisés par les implémentations de votre service Web.

    Tout comme un composant COM, votre service Web a été développé soit à partir d'une interface existante, soit à partir d'une interface que vous avez vous-même créée. Dans le cas d'un service Web basé sur un WSDL existant, vous devez savoir si ce fichier WSDL a été enregistré dans UDDI. S'il l'a été, notez son nom et la tModelKey, qui est le GUID généré par UDDI lors de l'enregistrement de ce fichier WSDL.

    En revanche, si votre service Web est basé sur un fichier WSDL qui n'a pas été enregistré dans UDDI, vous devrez vous préparer à créer un nouveau tModel pour représenter cette interface. Ce tModel devra avoir un nom en format URI (Uniform Resource Identifiers), c'est-à-dire de type NomEntreprise-com:ExempleServiceWeb-interface:v1, et devra pointer vers l'emplacement de votre fichier WSDL.

    Si votre service Web est un service Microsoft® Visual Studio® .NET, vous pouvez générer une description WSDL à l'aide d'une chaîne de requête à partir du fichier .ASMX (c'est-à-dire <http://www.nomentreprise.com/ExempleServiceWeb.asmx?wsdl>). Néanmoins, le fichier WSDL généré par Visual Studio .NET est étroitement lié au point d'accès utilisé pour invoquer ce service Web, ce qui peut ne pas être approprié si l'interface de votre service Web a plusieurs implémentations. Si vous n'envisagez pas d'associer à votre fichier WSDL plusieurs implémentations, ce n'est pas un problème.

  2. Déterminez le nom de votre entreprise et une brève description de l'entreprise en plusieurs langues (si nécessaire) ainsi que les principaux contacts pertinents pour les services Web de votre entreprise.

    UDDI prend en charge l'espace de noms xml:lang, ce qui permet à une entreprise de fournir une description en plusieurs langues. UDDI permet également d'établir une liste de contacts avec adresse de courrier électronique, téléphone et adresse postale. Cette liste de contacts permet de déterminer les personnes les plus aptes à répondre aux questions relatives aux services Web de l'entreprise. Par exemple, si quelqu'un veut commencer à utiliser votre service Web et doit entrer en contact avec un responsable des relations commerciales, quelle est la personne la plus indiquée ? Existe-t-il un contact technique pouvant répondre aux questions relatives à l'utilisation de vos services Web ? Cette personne devra également apparaître dans la liste.

  3. Déterminez les catégories et les identifications correspondant à votre entreprise.

    Parcourez les taxinomies prises en charge par UDDI dans le nœud UDDI de Microsoft (http://uddi.microsoft.com/default.aspx Lien non Microsoft Site en anglais). Les taxinomies actuellement prises en charge sont les suivantes : NAICS (North American Industry Classification System), UNSPSC (Universal Standard Products and Services Codes), ISO 3166, SIC (Standard Industry Classification) et la Classification géographique GeoWeb. Choisissez les catégories qui représentent le mieux votre entreprise.

  4. Déterminez les services Web que votre entreprise proposera via UDDI.

    Ensuite, déterminez les services Web que votre entreprise souhaite enregistrer dans le nœud UDDI public. Existe-t-il plusieurs points d'accès pour ce service ? Existent-ils d'autres paramètres ou informations que doivent connaître les clients utilisateurs de ce service Web ?

    Il est important de comprendre que le fait d'enregistrer un service Web dans UDDI ne signifie pas que tout le monde y aura accès. Les entrées dans le registre UDDI peuvent être accompagnées de mesures de sécurité, d'autorisation et d'authentification. Il ne suffit pas que quelqu'un connaisse l'existence de votre service Web pour qu'il puisse l'invoquer. Il se peut très bien que les entreprises communiquent hors bande avant que l'accès au service Web ne soit autorisé.

  5. Déterminez les catégories correspondant à vos services.

    À l'instar des entreprises, les services Web peuvent entrer dans des catégories. Une entreprise peut être classifiée dans la catégorie d'activités NAICS: Software Publisher (51121) (Éditeurs de logiciels), mais son service Web de réservation de chambres d'hôtels peut entrer dans la catégorie de services NAICS: Hotels and Motels (72111) (Hôtels et motels).

Étape 2 : Enregistrez votre adhésion UDDI

Une fois terminé l'exercice de modélisation, il faut enregistrer votre entreprise. Vous devrez obtenir un compte auprès d'un registre UDDI, ce qui ne peut pas être fait par programmation, comme l'acceptation des conditions d'utilisation. Le nœud de Microsoft utilise Passport pour l'authentification. Vous devrez donc en acquérir un (http://www.passport.com/Consumer/default.asp Lien non Microsoft Site en anglais) pour procéder à l'enregistrement.

Il existe à ce point deux options possibles : soit vous utilisez l'interface Web utilisateur fournie par le nœud Microsoft, soit vous vous enregistrez par programmation en émettant les appels API SOAP vers le nœud. Si vous n'envisagez pas de modifier votre entrée ou si votre entrée est relativement simple, l'interface Web utilisateur est suffisante. En revanche, si vous envisagez de faire des mises à jour fréquentes ou si votre entrée est plus complexe, il est préférable de traiter la procédure d'enregistrement par script en utilisant le SDK de Microsoft UDDI. De plus, l'interface utilisateur Microsoft n'est pas localisée pour d'autres langues. Donc si vous souhaitez utiliser cette fonction de l'API UDDI, vous devez vous enregistrer par programmation.

Remarque    Vous pouvez vous entraîner dans un environnement sandbox à l'adresse suivante : http://test.uddi.microsoft.com/default.aspx Lien non Microsoft Site en anglais, qui est la réplique du nœud de production. C'est un bon moyen de se familiariser avec la procédure avant de passer à l'élaboration.
Utilisation de l'interface Web utilisateur de Microsoft

L'utilisation de l'interface Web utilisateur de Microsoft est relativement intuitive. Commencez par accéder à la page d'administration (https://uddi.microsoft.com/register.aspx Lien non MSDN France Site en anglais). Après vous être connecté, vous accédez aux options d'enregistrement des tModels et des entreprises. Vous trouverez ci-dessous quelques points à connaître pour faciliter votre progression :

  1. Assurez-vous d'enregistrer votre fichier WSDL en tant que tModel avant d'enregistrer le service. Le tModel vous sera demandé plus tard dans la procédure.
  2. Lorsque vous enregistrez un document WSDL en tant que tModel, classez ce tModel à l'aide de la taxinomie des types UDDI. Votre WSDL doit au moins être classifié dans la catégorie "Specification for a Web Service" (Spécifications pour service Web, wsdlSpec).

    Ce mode de classification garantit que le tModel est classé selon le document de meilleure pratique intitulé "Using WSDL in a UDDI registry". Parce que les tModels peuvent contenir des références à des documents autres que des fichiers WSDL, il est important de fournir une classification à votre tModel. Certains outils (comme Visual Studio .NET) utilisent ces classifications pour réduire le nombre de requêtes réalisées.

  3. Après avoir enregistré votre interface WSDL en tant que tModel, vous devrez ajouter une entreprise avec les informations de contact et de classification appropriées. Vous pouvez ajouter autant de classifications que vous le jugez utile.
  4. Continuez en ajoutant les services Web que vous souhaitez exposer via UDDI. Parce qu'un service peut avoir plusieurs implémentations, vous devrez ajouter une liaison pour chaque service ajouté. Vous devrez fournir pour chaque liaison le point d'accès du service Web, c'est-à-dire <http://www.nomentreprise.com/ExempleServiceWeb.asmx>.
  5. Chaque liaison a besoin de créer une référence aux interfaces qu'elle prend en charge. L'interface Microsoft les appelle comme des "signatures de spécification". Une signature de spécification est le tModel qui contient l'interface WSDL. L'interface Microsoft propose un écran qui vous permet de rechercher votre tModel à partir de son URN. Ce tModel sera soit celui que vous avez enregistré à l'étape 1, soit le tModel d'un fichier WSDL enregistré par quelqu'un d'autre.
  6. Enfin, vous avez la possibilité d'indiquer l'emplacement http d'un document de résumé au sujet de cette instance particulière de votre service Web, ainsi que tout paramètre d'instance pertinent.
Enregistrement par programmation avec le SDK .NET UDDI de Microsoft

Il est également possible de procéder à l'enregistrement par programmation. L'utilisation du SDK UDDI de Microsoft est très aisée. Vous devez obtenir un compte UDDI par l'interface Web, mais une fois cette tâche terminée, le reste de la procédure peut être réalisée au moyen d'un script. Tout d'abord, téléchargez le SDK UDDI à l'adresse suivante : http://www.microsoft.com/downloads/release.asp?ReleaseID=30880 Lien non MSDN France Site en anglais et installez-le. Puis créez une nouvelle application console C# à l'aide de Visual Studio .NET. Ajoutez une référence à la dll du SDK UDDI Microsoft, qui s'installe par défaut dans C:\Program Files\Microsoft UDDI SDK\VS7\Microsoft.Uddi.Sdk.dll. Puis ajoutez des références à des espaces de nom au début de votre code :

using Microsoft.Uddi;
using Microsoft.Uddi.Binding;
using Microsoft.Uddi.Business;
using Microsoft.Uddi.Service;
using Microsoft.Uddi.ServiceType;

Ajoutez le code suivant à la fonction static void Main (string[] args) :

//Il est recommandé d'exécuter au départ ce programme 
//sur le registre de test à l'adresse suivante : 
//https://test.uddi.microsoft.com/publish
Publish.Url = "https://uddi.microsoft.com/publish";
Publish.User = "votre compte ici";
Publish.Password = "************";

Ceci établira l'authentification de votre compte. Ensuite, ajoutez le code suivant pour publier vos fichiers WSDL en tant que tModel :

//Créez le tModel
SaveTModel stm = new SaveTModel();
stm.TModels.Add();
stm.TModels[0].Name = "Insérez l'URN ici";
stm.TModels[0].Descriptions.Add("fr","Insérez ici la description");
stm.TModels[0].OverviewDoc.OverviewURL = "Insérez ici l'URL du WSDL";
//La ligne suivante est nécessaire à la bonne classification de votre tModel
stm.TModels[0].CategoryBag.Add 
( "uddi-org:types",
"wsdlSpec",
"uuid:c1acf26d-9672-4404-9d70-39b756e62ab4" );

string sTModelKey = "";

//Envoyez à UDDI
try
{
 TModelDetail tmd = stm.Send();
 sTModelKey = tmd.TModels[0].TModelKey;   
}
catch (UddiException ue)
{
 Console.WriteLine ( ue.Message );
 return;
}
catch (Exception e)
{
 Console.WriteLine ( e.Message );
 return;
}

Dès que l'enregistrement est réussi, UDDI génère un nouveau tModelKey unique, que vous utiliserez ultérieurement pour la liaison de votre service Web. Ensuite, créez l'entrée de votre entreprise :

//Créez l'entreprise (Business)
SaveBusiness sb = new SaveBusiness();
sb.BusinessEntities.Add();
sb.BusinessEntities[0].Name = "Insérez ici le nom de l'entreprise";
sb.BusinessEntities[0].Descriptions.Add("fr","Insérez ici la description");

//Créez le service de l'entreprise (BusinessService)
sb.BusinessEntities[0].BusinessServices.Add();
sb.BusinessEntities[0].BusinessServices[0].Name = "Insérez ici le nom du service";
sb.BusinessEntities[0].BusinessServices[0].Descriptions.
Add("fr","Insérez ici la description du service");

//Créez le modèle de liaison (BindingTemplate)
sb.BusinessEntities[0].BusinessServices[0].BindingTemplates.Add();
sb.BusinessEntities[0].BusinessServices[0].BindingTemplates[0].
Description.Add("fr","Insérez ici la description de la liaison");
sb.BusinessEntities[0].BusinessServices[0].BindingTemplates[0].
AccessPoint.Text = "Insérez ici le point d'accès";
sb.BusinessEntities[0].BusinessServices[0].BindingTemplates[0].
AccessPoint.URLType = Microsoft.Uddi.Api.URLTypeEnum.Http;

//Créez les informations d'instance tModel (tModelInstanceInfo)
sb.BusinessEntities[0].BusinessServices[0].BindingTemplates[0].
TModelInstanceDetail.TModelInstanceInfos.Add();
sb.BusinessEntities[0].BusinessServices[0].BindingTemplates[0].
TModelInstanceDetail.TModelInstanceInfos[0].Descriptions.
Add("fr","Insérez la description ici");
//Utilisez la même chaîne tModelKey que précédemment
sb.BusinessEntities[0].BusinessServices[0].BindingTemplates[0].
TModelInstanceDetail.TModelInstanceInfos[0].TModelKey = sTModelKey;

//Envoyez à UDDI
try
{
 BusinessDetail bd = sb.Send();
 //show xml
 Console.WriteLine ( bd );
}
catch (UddiException ue)
{
 Console.WriteLine ( ue.Message );
 return;
}
catch (Exception e)
{
 Console.WriteLine ( e.Message );
 return;
}

Lorsque vous arrivez à ce point, votre définition WSDL et les informations sur l'entreprise ont été enregistrées sur UDDI. En passant la clé appropriée, vous pouvez toujours modifier ces entrées ultérieurement.

Étape 3 : Recherchez votre entrée dans UDDI

Une fois que votre entrée est enregistrée dans UDDI, il est recommandé de procéder à trois vérifications. Tout d'abord, à l'aide de l'interface utilisateur Web de Microsoft, recherchez votre entreprise à partir de son nom et des classifications pour voir si elle apparaît dans la liste des résultats. Ensuite, ouvrez Visual Studio .NET et assurez-vous qu'elle apparaît dans la boîte de dialogue "Add Web Reference". Si elle n'apparaît pas, il est probable que votre tModel n'a pas été classé correctement à l'aide de la taxinomie uddi-org:types expliquée plus haut. Vous devriez être capable d'ajouter le service Web à votre projet et de générer le code proxy basé sur le fichier WSDL. Enfin, après 24 heures, votre entrée aura été répliquée sur le nœud IBM, sur lequel vous pouvez faire des recherches à partir de leur interface à l'adresse suivante  : https://uddi.ibm.com/ubr/find Lien non Microsoft Site en anglais.

Conclusion

UDDI et WSDL sont des spécifications complémentaires qui aident à activer un paysage logiciel sur les services Web. WSDL offre une méthode formelle et exempte de l'influence des vendeurs de définir des services Web de façon à ce que la nouvelle génération d'appels de procédures à distance puissent être réalisée. UDDI offre une vaste infrastructure standardisée qui permet de décrire et de découvrir des services Web. En associant ces deux normes, un écosystème de services Web peut s'épanouir.

La rubrique de la semaine prochaine explorera l'expérience de l'équipe de At Your Service de la conception et de l'enregistrement des services de favoris Lien non MSDN France Site en anglais dans UDDI.



Dernière mise à jour le mardi 8 janvier 2002



Pour en savoir plus
Microsoft réalise une enquête en ligne pour recueillir votre opinion sur le site Web de MSDN. Si vous choisissez d’y participer, cette enquête en ligne vous sera présentée lorsque vous quitterez le site Web de MSDN.

Si vous souhaitez y participer,
Afficher:
© 2014 Microsoft