Type Message Opération Type du Port Partie Concrète Liens Services et Ports
133
Les messages: balise <message>
C’est dans cette partie que la description des messages est faite. Selon leur complexité, les messages sont décomposés en une ou plusieurs parties (<Part>). Chaque partie est associée à un type à l’aide d’un attribut «type».
Les opérations: balise <opération>
Sont définies par la balaise <opération> et peuvent être de différentes natures:
• Opération unidirectionnelle (One-Way): Le récepteur final du service reçoit un message mais ne renvoie jamais de réponse.
• Requête/Réponse: On communique en mode question/réponse synchrone.
• Sollicitation/Réponse: Idem que l’opération requête/Réponse ; hormis que les éléments en entrée et les éléments en sorite sont inversés.
• Notification: Le récepteur final envoi un message mais sans attendre de réponse de la part du client.
La première et la dernière opération impliquent un seul message et sont asynchrones, contrairement aux deux autres qui impliquent deux messages et sont synchrones. Les types de port: balise <PortType>
Les types de port sont utilisés pour définir les traitements offerts par un service Web. Un type de port est un ensemble de messages regroupés en opération qui représentent une unité d’action pour le service décrit. Un type de port peut comporter plusieurs opérations.
A noter que les quatre balises précédentes forment la partie abstraite du service. Elle est considérée abstraite pour les raisons suivantes: il n’est y a pas de lien (Binding) concret, ni un codage spécifique à ces constructions, non plus une définition d’un service qui implémente un ensemble de PortType.
Les liens: balise <Binding>
Une liaison permet de spécifier les propriétés du protocole utilisé et le format des messages. Un PortType peut supporter plusieurs protocoles.
Les ports (ou EndPoint): balise <Port>
Un port spécifie l’adresse d’une liaison. Un port combine les interfaces ‘Binding’ et les adresses réseau (spécifiées par un URI) à laquelle l’implémentation du PortType est accessible. Un port ne peut pas indiquer plus d’une adresse et ne peut définir d’autres informations de liaison.
Les services: balise <Service>
C’est un groupement logique de ports et constitue la liste des services mis à disposition par le service Web. C’est ce point qui va permettre de rechercher via l’UDDI les services offerts.
Une fois tous ces constructeurs sont ajoutés à WSDL, la définition de l’interface du service devient plus concrète. Avec l’information de lien («Binding»), l’utilisateur
134
connaît le protocole à utiliser, la structure des messages XML pour interagir avec le système et le résultat attendu en contactant le service.
Avec l’information du port, l’utilisateur connaît l’adresse réseau et à quelle fonctionnalité de port elle est implémentée. Finalement avec la définition de service, l’utilisateur connaît tous les ports qui sont implémentés pour un groupe.
Le fichier WSDL est ensuite publié dans un annuaire UDDI par le fournisseur et récupéré par le client lorsque celui-ci décide d’invoquer le service Web.
c/ Exemple d’une interface WSDL
Voici un exemple détaillé d’un document WSDL concernant un service qui permet de commander des produits (Figure A4)
< ?xml version="1.0"? > <definitions name= "Procurement"
TargetNamespace= "http://example.com/procurement/definitions" xmlns: tns="http://example.com/procurement/definitions" xmlns: xs="http://www.w3.org/2001:XMLSchema" xmlns: soap="http://schema.xmlsoap.org/wsdl/soap/" xmlns ="http://schema.xmlsoap.org/wsdl/" > r r Partie abstraite Messages Opération et PortType Partie Concrète Lien (Binding ) Nom deservice Port et services Localisation du service </definitions>
Figure A4: Description WSDL d’un service pour la commande de produits <message name= "OrderMsg">
<Part name="ProductName " type= "xs:string"/> <Part name="quantity" type="xs: integer"/> </message>
<portType name= "procurementPortType"> <operation name="OrderGoods"> <input message = "orderMsg"/> </operation>
</portType>
<binding name ="ProcurementSoapBinding" type="tns: procurementPortType"> <soap: Binding style ="document"
Transport="http://schema.xmlsoap.org/soap/htpp/"> <operation name ="orderGoods">
<soap: operation soapAction="http://example.com/orderGoods"/> <input>
<soap: body use ="literal1" /> </input>
<output>
<soap: body use ="literal1" /> </output>
</operation> </binding>
<service name ="ProcurementService">
<Port name ="ProcurementPort" binding = "tns: ProcurementSoapBinding"> < soap: address location = "http:// example.com/procurement "/> </port>
135
ANNEXE 3: Structure, description et API du registre UDDI
Les spécifications UDDI définissent le modèle d’information, c'est-à-dire les structures de données UDDI et les API que l’opérateur de l’annuaire est censé fournir aux utilisateurs de l’annuaire.
a/ Structure des données UDDI
Dans l’annuaire UDDI, les descriptions des services contiennent quatre types d’informations: informations métier, information de service, information de lien, et information sur les
spécifications du service décrit par plusieurs entités.
• Business Entity: Décrit l’organisation qui fournit le service Web. Contient la liste des noms d’entreprises, adresse et autres informations sur le fournisseur.
• Business Service: Décrit un groupe de services Web offerts par une Business Entity. Un Business Service correspondra à un type de service mais proposé à différentes adresses, dans de multiples versions et à travers différentes technologies. Une entrée de Business Service n’est rattachée qu’à une seule business entity.
• Business Template: Décrit l’information technique pour utiliser un service Web particulier. Il définit essentiellement l’adresse à laquelle le service est valable ainsi qu’un certain nombre d’informations telles que la référence du document (appelé
tModel) décrivant l’interface du service Web ou autres propriétés du service. Il définit
également comment les paramètres d’opération doivent être configurés et les valeurs par défaut pour ces paramètres. Une entrée du Business Service peut inclure de multiples éléments Business Template, mais une Business Template n’est rattachée qu’à une seule Business Service.
• tModel "Technical Model ": C’est un conteneur générique pour n’importe quel type d’informations. Il peut par exemple représenter une interface de service WSDL, une classification ou un protocole d’interaction; il peut aussi décrire la sémantique d’une opération.
b/ Les API de l’enregistrement UDDI
Les annuaires UDDI ont trois types principaux d’utilisateurs exploitants les API: - Les fournisseurs de services qui publient les services Web.
- Les clients ou demandeurs qui recherchent les services Web. - D’autres utilisateurs qui ont besoin d’échanger des informations.
Ces utilisateurs d’annuaires (clients de l’UDDI) peuvent utiliser six types d’API:
• API d’Interrogation: Cette API inclut:
- Les opérations permettant de trouver des entrées dans l’annuaire qui correspondent aux critères de recherches et donnent une vue d’ensemble des informations au sujet de cette entrée.
136
Cette API, utilisée par le navigateur UDDI, permet au développeur de trouver les informations nécessaires.
• API de Publication: Cette API permet au fournisseur d’ajouter, modifier ou supprimer des entrées dans l’annuaire.
• API de sécurité: Elle permet aux utilisateurs d’obtenir des authentifications qui seront utilisées dans les communications futures avec l’annuaire.
• API de propriété de transfert: Autorise les annuaires à transférer les droits des structures d’un fournisseur à un autre.
• API d’Abonnement à l’UDDI: Permet de gérer les abonnements à un enregistrement (ajout, modification, suppression).
• API de Réplication: Permet la réplication entre deux annuaires.
Les annuaires UDDI maintiennent différents points d’accès (URIs) pour les demandeurs, les fournisseurs et les autres annuaires.