Les annuaires de service de Web nous permet de localiser des fournisseurs des services de Web. Ils fournissent un endroit centralisé et Internet-accessible où les utilisateurs de service de Web (consommateurs) peuvent facilement localiser des services offerts par d'autres compagnies et organismes. Ils peuvent s'appeler en tant que « Yellow Pages » des services de Web où nous pouvons trouver une liste de services de Web et de leurs endroits. En utilisant ces annuaires nous pouvons rechercher et trouver n'importe quel service de Web basé sur le type de service que nous avons besoin.

La description, la découverte et l'intégration universelles (UDDI) est actuellement la norme de fait pour cataloguer et trouver des services de Web. L'organisation d'UDDI a créé un annuaire des services, etc. de l'api pour les compagnies participantes et des organismes fournissant des services de Web. Vous pouvez visiter le site Web d'UDDI pour rechercher des services de Web. Autrement, vous pouvez employer dispositif de référence de Web de s du studio .NET visuel 'pour rechercher ces annuaires.

La découverte de services de Web fournit les possibilités pour localiser des services de Web. C'est un processus de localiser les documents qui définissent un service spécifique. Ces possibilités sont décrites dans une manière standard en utilisant le langage de description de services de Web (WSDL) qui est spécifiquement conçu pour ceci. Le procédé de découverte permet à un utilisateur de service de Web de rechercher et localiser le document de WSDL. Les spécifications de DISCO (découverte) définissent l'existence des services de Web et aident à localiser le document du WSDL du service de Web. Les documents de DISCO sont XML basés et ont une prolongation de dossier de .vsdisco. Le document de découverte est un récipient pour deux éléments, indicateurs au document de WSDL et indicateurs à d'autres documents de découverte. Ces indicateurs sont sous la forme un URL.

Vous pouvez employer dispositif de référence de Web de s du studio .NET visuel le 'qui localise les services de Web employant automatiquement le procédé de découverte. Pour faire que vous devez écrire l'URL du document de découverte qui initialisera le procédé de découverte. Autrement, utiliser l'outil de la disco du cadre de .NET pour rechercher des dossiers de description de service de Web.

La description de service de Web est un document de XML qui permet à des possibilités de service de Web d'être décrites. En utilisant WSDL nous pouvons clairement définir les points d'entrée Web-accessibles en termes de messages de demande/réponse. En outre cette description inclut des informations sur les protocoles et les types de données soutenus traités par le service de Web. Asp .NET et la plateforme de .NET fournit l'appui pour la génération des documents de ce WSDL du service de Web une fois demandé.

La méthode standard d'agir l'un sur l'autre avec un service de Web est par l'utilisation d'une classe de procuration. Le studio visuel .NET et asp .NET fournissent des outils pour produire d'une classe de procuration de service de Web. La classe de procuration est semblable au service réel de Web mais ne contient pas toute pièce d'exécution. Avec le studio visuel .NET que nous pouvons produire de la classe de procuration des documents de WSDL avec lui est le dispositif de référence de Web pour localiser un service de Web que nous voulons appeler. Après localisation du document de WSDL nous pouvons produire de la classe de procuration à l'aide du bouton de référence d'ajouter.

Le format de fil de service de Web permettent à des services de Web d'échanger des données et des messages. Les formats de fil décrivent la méthode par laquelle des messages de demande/réponse de service de Web sont codés et transportés entre le service de Web et n'importe quel consommateur. Les trois formats de fil soutenus sont : HTTP-GET, HTTP-POST et HTTP-SOAP.

Le protocole de HTTP-GET code des demandes et des arguments d'opération de service de Web dans l'URL du service de Web. Ceci est codé en tant qu'élément de la corde d'URL et tous les arguments sont codés pendant que des paramètres de corde de question apposés à l'URL de base. L'URL indique le point d'entrée accessible de Web pour le service de Web qui est un dossier de .asmx.

Le protocole de HTTP-POST code des demandes d'opération de service de Web et les arguments dans la région de charge utile du HTTP-POST demandent comme paires de nom/valeur. HTTP-POST est semblable à HTTP-GET mais la différence est des paramètres de passages de HTTP-POST dans l'en-tête réel de demande de HTTP plutôt que comme corde de question apposée à l'URL.

HTTP-SOAP est le format de fil de défaut. Basé sur les spécifications de SAVON il soutient l'éventail de types de données simples et complexes. Des messages de demande et de réponse de service de Web sont codés dans le message de SAVON qui sont inclus dans le secteur de charge utile d'un message de HTTP-POST, messages de SAVON sont codés dans XML en utilisant le vocabulaire de SAVON défini dans les spécifications.

XML fournit une méthode norme-basée pour décrire des données. XML est employé intensivement dans le bâtiment et les services consumants de Web. XML a la capacité de décrire les données qui sont fortement interoperable parmi beaucoup de différents systèmes sur l'Internet. En utilisant les éléments de base de XML nous pouvons définir les types et les rapports de données simples et complexes. XML favorise la capacité des services de Web de communiquer leurs données efficacement et efficacement. C'est ce XML qui assure une interprétation cohérente et précise des données quand le service et le consommateur résident sur différentes plateformes.

Nous entendons beaucoup au sujet du SAVON de nos jours. Jetons un coup d'oeil quel SAVON est et pourquoi on le lie à .NET. Le protocole simple d'Access d'objet (SAVON) est un protocole léger pour l'échange d'information dans un environnement décentralisé et distribué. C'est un format industriellement compatible de message qui permet des communications message-basées pour des services de Web. C'est XML basé et se compose de trois parts, un enveloppement qui définit un cadre pour que décrire ce qui est dans un message et la façon le traite, un ensemble de règles de codage pour exprimer des exemples des types de données application-définis et une convention pour représenter les appels à distance de procédé (RPC). Les possibilités du SAVON pour fournir un modulaire empaquetant les mécanismes modèles et codants pour des données de codage dans des modules lui permettent d'être employé au-dessus des protocoles multiples avec une variété de différents modèles de programmation.

Il y a les parties facultatives des spécifications de SAVON et une part facultative définit à ce que ressemble un message de HTTP qui contient un message de SAVON. Cette attache de HTTP est importante car le HTTP est soutenu par presque tous les logiciels d'exploitation. L'attache de HTTP est appui facultatif, mais presque tout le de SAVON de réalisations il car c'est le seul protocole normalisé pour le SAVON. Pour cette raison, il y a une idée fausse commune que le SAVON exige le HTTP. Quelques réalisations des transports soutiennent de MSMQ, de MQ séries, smtp, ou TCP/IP, mais presque tous les services courants de Web de XML emploient le HTTP parce qu'il est omniprésent.

Une source importante de confusion en obtenant commencée par du SAVON est la différence entre les spécifications de SAVON et les nombreuses réalisations des spécifications de SAVON. La plupart des personnes qui utilisent le SAVON n'écrivent pas des messages de SAVON directement mais emploient une trousse à outils de SAVON pour créer et analyser les messages de SAVON. Ces trousses à outils traduisent généralement des appels de fonction d'un certain genre de langue à un message de SAVON. Par exemple, la trousse à outils 2.0 de SAVON de Microsoft traduit des appels de fonction de COM POUR SAVONNER et la trousse à outils d'Apache traduit des appels de fonction de JAVA POUR SAVONNER. Les types d'appels de fonction et les types de données des paramètres soutenus changent avec chaque exécution de SAVON, ainsi une fonction que les travaux avec une trousse à outils peuvent ne pas fonctionner avec des autres. Ce n'est pas une limitation de SAVON mais plutôt de l'exécution particulière que vous employez.

De loin le dispositif le plus contraignant du SAVON est qu'il a été mis en application sur beaucoup de différentes plateformes. Ceci signifie que du SAVON peut être utilisé pour lier les systèmes disparates dans et sans une organisation. Beaucoup de tentatives ont été faites dans le passé de proposer un protocole de transmissions commun qui pourrait être employé pour l'intégration de systèmes mais aucun de eux n'a eu l'adoption répandue que le SAVON a. C'est parce que le SAVON est beaucoup plus petit et plus simple pour mettre en application que plusieurs des protocoles précédents. Par exemple, le DCI et le CORBA ont pris des années à l'instrument. Le SAVON, cependant, peut employer des analyseurs existants de XML et des bibliothèques de HTTP pour effectuer la majeure partie du travail dur, ainsi une exécution de SAVON peut être accomplie dans une question des mois. C'est pourquoi il y a plus de 70 réalisations de SAVON disponibles. Le SAVON évidemment ne fait pas tout que le DCI ou les CORBA, mais le manque de complexité en échange des dispositifs est ce qui rend le SAVON si facilement disponible.

La description et l'intégration universelles de découverte est comme les « Yellow Pages » des services de Web. Comme avec des Yellow Pages traditionnels, nous pouvons rechercher une compagnie qui offre les services que nous avons besoin, eu connaissance du service offert et contactons la compagnie pour plus d'information. Nous pouvons également offrir un service de Web sans l'enregistrer dans UDDI.

Une entrée de répertoire d'UDDI est un dossier de XML qui décrit des affaires et les services qu'elle offre. Il y a trois parts à une entrée dans l'annuaire d'UDDI. Les « white pages » décrivent la compagnie offrant le service, comme, le nom, l'adresse, les contacts, etc. Les « Yellow Pages » incluent des catégories industrielles basées sur les taxonomies standard la classification industrielle standard. « Les pages vertes » décrivent l'interface au service dans assez de détail pour que quelqu'un écrive une application pour employer le service de Web. La manière que des services sont définis est par un document d'UDDI appelé un type modèle ou tModel. Dans beaucoup de cas, le tModel contient un dossier de WSDL qui décrit une interface de SAVON à un service de Web de XML, mais le tModel est assez flexible pour décrire presque n'importe quel genre de service.

L'annuaire d'UDDI inclut également plusieurs manières de rechercher les services que nous devons établir nos applications. Par exemple, nous pouvons rechercher des fournisseurs d'un service dans un endroit géographique indiqué ou des affaires d'un type indiqué. L'annuaire d'UDDI fournira alors l'information, des contacts, des liens, et des données techniques pour nous permettre d'évaluer quels services répondent à nos exigences.

UDDI nous permet de trouver des entreprises que nous pourrions vouloir pour obtenir des services de Web de. Si nous savons déjà avec qui nous voulons faire des affaires mais si nous ne savons pas quels services sont offert alors nous peut employer les les spécifications de W-Inspection qui nous permettent de passer en revue par une collection de services de Web de XML offerts sur un serveur spécifique à la trouvaille qui pourrait satisfaire vos besoins. Services de Web de XML