API d'interrogation (Inquiry) du registre UDDI version 3

L'API Inquiry met à disposition quatre formes de requête qui obéissent à des conventions largement adoptées et répondant aux besoins des logiciels traditionnellement utilisés dans les registres.

Les quatre formes de requête possibles sont les suivantes :
  • Le modèle navigation (browse)
  • Le modèle analyse (drilldown)
  • Le modèle appel (invocation)
  • Les fonctions de l'API Inquiry

Schéma d'exploration du registre UDDI

Les logiciels utilisés pour explorer et examiner des données doivent intégrer des fonctions de navigation, en particulier lorsque ces données ont une structure hiérarchisée. Le modèle de recherche et de navigation (appelé browse pattern dans la spécification de l'API UDDI) s'appuie sur la démarche suivante : exécution d'une recherche dans un lot d'informations globales, localisation d'ensembles de résultats généraux, puis sélection de données plus spécifiques pour les modèles d'exploration en aval.

La spécification de l'API UDDI implémente ce modèle de recherche et de navigation au moyen des appels d'API find_xx. Ces appels permettent de disposer des fonctions de recherche assurées par l'API fournit. A chacun de ces appels correspondent des messages récapitulatifs renvoyant un aperçu des informations enregistrées qui sont associées au type de message d'interrogation (inquiry) et aux critères de recherche indiqués dans l'interrogation.

A titre d'exemple, vous pourrez exécuter une séquence de recherche et de navigation afin de déterminer si une entité commerciale de votre connaissance dispose d'informations enregistrées. Vous commencerez cette séquence par un appel à la fonction "find_business", en lui passant éventuellement les premiers caractères du nom de l'entité. Vous obtiendrez en retour une liste nommée businessList. Ce résultat consiste en informations générales - avec clés, noms et descriptions - dérivées des informations enregistrées des entités commerciales (businessEntity) et correspondant au fragment de nom que vous avez indiqué comme critère. Si l'entité que vous recherchez figure dans cette liste, vous pouvez utiliser l'appel d'API find_service pour explorer les informations businessService correspondantes et rechercher des modèles techniques spécifiques tels que les achats ou les expéditions. De la même façon, si vous connaissez l'empreinte digitale technique, la signature tModel, d'une interface logicielle particulière et que vous souhaitez savoir si l'entité commerciale recherchée fournit un service web prenant en charge cette interface, vous pouvez utiliser le message d'interrogation find_binding.

Schéma d'exploration en aval du registre UDDI

Lorsque vous disposez d'une clé correspondant à l'un des quatre principaux types de données gérés par un registre UDDI, vous pouvez utiliser cette clé pour accéder à la "fiche descriptive" complète et détaillée d'une instance de données spécifique. Les types de données UDDI sont businessEntity, businessService, bindingTemplate et tModel. Vous pouvez accéder aux informations complètes et enregistrées de l'une de ces structures en passant un type de clé approprié à l'un des appels d'API get_xx.

Toujours dans l'exemple de la section précédente, l'un des éléments de données renvoyés par tous les appels find_x est une clé. Concernant l'entité commerciale qui vous intéresse, la valeur de la businessKey renvoyée dans le contenu d'un structure businessList peut être passée comme argument dans le message get_businessDetail. En cas de succès de cet appel, le résultat sera un message businessDetail contenant la fiche descriptive complète de l'entité dont la valeur de clé a été passée en argument. Ces informations constitueront une structure businessEntity complète.

Schéma d'appel du registre UDDI

Pour qu'une application puisse tirer parti d'un service web distant, enregistré dans le registre UDDI par une autre société ou entité commerciale, vous devez la préparer à exploiter les informations que le registre contient sur le service à appeler.

Les données bindingTemplate obtenues du registre UDDI représentent les détails spécifiques d'une instance d'un type d'interface donné, notamment l'endroit où un programme commence à interagir avec le service. L'application appelante mémorise ces informations en cache et les utilise pour contacter le service à l'adresse enregistrée chaque fois qu'elle a besoin de communiquer avec l'instance de service.

Dans les technologies de procédures à distance - qui ont rencontré un grand succès -, des outils automatisent les tâches liées à la mise en cache (ou codage en dur) des informations de localisation. Toutefois, des problèmes se posent dès lors qu'un service à distance se déplace sans que les appelants en soient informés. De nombreuses raisons peuvent justifier ce déplacement - entre autres exemples : mise à niveau de serveur, reprise après incident, acquisition de service ou changement de nom commercial.

En cas d'échec d'un appel utilisant des informations mémorisées en cache précédemment obtenues d'un registre UDDI, la conduite à suivre est d'interroger à nouveau le registre pour obtenir une structure bindingTemplate à jour. Si les données renvoyées diffèrent des données mémorisées en cache, l'appel du service peut être automatiquement retenté avec les informations réactualisées. Si la nouvelle tentative réussit, les nouvelles informations remplacent celles qui étaient mémorisées.

En adoptant ce modèle avec des services web, une société utilisant un registre UDDI peut automatiquement reprendre ses transactions avec un grand nombre de partenaires commerciaux sans coûts de communication et de coordination inutiles. Par exemple, si une société a basculé son activité sur un site de reprise à la suite d'un sinistre sur son site principal, la plupart des appels émanant de ses partenaires échoueront lorsque ceux-ci tenteront de recourir à des services sur le site sinistré. Cependant, si cette société a pris soin de mettre à jour son registre UDDI avec la nouvelle adresse des services, ses partenaires (pour autant qu'ils utilisent le modèle d'appel exposé plus haut) pourront automatiquement renouer le contact avec les services déplacés sans avoir à accomplir de tâches administratives.


Icône indiquant le type de rubrique Rubrique de concept



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwsu_inquiry_api
Nom du fichier : cwsu_inquiry_api.html