Comment WSDL 1.1 définit les services Web et comment créer des modèles dans langage Java pour vérifier et transformer les documents WSDL
Série de contenu :
À propos de cette série d'articles
Services Web - fonction importante Technologies Java™ dans l'informatique d'entreprise. Dans cette série d'articles, Denis Sosnovskiy, consultant en XML et services Web, présente les cadres et technologies de base qui sont précieux pour les développeurs Java utilisant les services Web. Suivez les articles de la série pour vous tenir au courant des derniers développements dans ce domaine et savoir les appliquer dans vos propres projets.
Les services Web pour les applications d'entreprise reposent fortement sur l'utilisation de définitions de service. Les définitions de service décrivent l'accord de base entre un fournisseur de services et tout client potentiel, détaillant les types de fonctions fournies par le service et les messages au sein de chaque fonction. Les fournisseurs et les consommateurs sont libres de choisir comment ils mettent en œuvre leurs objets d'échange, dans la mesure où les messages réels qu'ils envoient sont conformes à la définition du service. L'utilisation d'une définition de service pour décrire la manière dont les messages XML sont échangés est ce qui différencie les services Web des technologies de programmation distribuée antérieures.
Diverses méthodes ont été proposées pour définir les services Web, mais WSDL 1.1 reste l'approche la plus largement utilisée. WSDL 1.1 présente certains inconvénients, notamment une structure trop complexe qui le rend difficile à lire pour les non-initiés. Il souffre également d'un manque de définition formelle faisant autorité, ce qui a conduit à des "raffinements" cohérents qui comblent certaines des lacunes du document de spécification original. Par conséquent, les piles de services Web tentent de gérer les documents WSDL 1.1 de la manière la plus flexible possible. Cette flexibilité peut ajouter à la confusion quant à la compréhension de WSDL 1.1, car les développeurs voient une grande variété de structures WSDL sans aucune indication de l'approche qui est préférable.
Dans cet article, nous allons vous montrer comment analyser des documents WSDL 1.1 et vous guider à travers les premières parties d'un modèle Java pour valider les documents WSDL et les convertir au format standard.
Analyse WSDL 1.1
Espaces de noms utilisés
Cet article utilise :
- le préfixe wsdl pour représenter l'espace de noms WSDL 1.1 http://schemas.xmlsoap.org/wsdl/ ;
- le préfixe soap pour l'espace de noms http://schemas.xmlsoap.org/wsdl/soap/ utilisé par l'extension SOAP 1.1 pour WSDL 1.1
- le préfixe xs pour l'espace de noms http://www.w3.org/2001/XMLSchema utilisé pour les définitions de schéma XML.
La révision WSDL 1.1, publiée début 2001, est techniquement remplacée par les directives W3C WSDL 2.0 publiées en 2007. WSDL 2.0 offre une structure plus claire que WSDL 1.1, ainsi qu'une plus grande flexibilité. Mais WSDL 2.0 souffre d'un problème de poule et d'œuf : WSDL 2.0 n'est pas largement utilisé car il n'est pas largement pris en charge, et parce qu'il n'est pas largement utilisé, les développeurs de piles de services Web sont peu incités à le prendre en charge. Malgré tous ses défauts, WSDL 1.1 est assez bon pour la plupart des usages.
La spécification WSDL 1.1 d'origine était inexacte en termes de nombre de fonctionnalités qu'elle utilisait. Étant donné que WSDL se concentrait sur les définitions de service SOAP, il incluait également la prise en charge des fonctionnalités SOAP (telles que l'encodage rpc) qui ont ensuite été dépréciées. L'organisation d'interopérabilité des services Web (WS-I) a abordé ces problèmes dans le profil de base (BP), qui fournit les meilleures pratiques pour les services Web utilisant SOAP et WSDL. BP 1.0 a été approuvé en 2004 et BP 1.1 a été publié en 2006. Cet article se concentre sur WSDL 1.1 basé sur les directives WS-I BP et n'aborde pas les fonctionnalités héritées de facto telles que l'encodage rpc pour SOAP.
La structure des documents XML est supposée être définie par des définitions de schéma XML. La spécification WSDL 1.1 d'origine comprenait une description de schéma, mais le schéma ne correspond pas aux descriptions textuelles à plusieurs égards. Cela a été corrigé plus tard dans une version modifiée du schéma, mais le document WSDL 1.1 n'a pas été modifié pour refléter ce changement. L'équipe BP WS-I a ensuite décidé d'apporter encore plus de modifications au schéma WSDL et a créé ce qui est salué comme un guide des meilleures pratiques pour ce schéma glissant. Les documents écrits pour une version du schéma ne sont généralement pas compatibles avec les autres versions (malgré l'utilisation du même espace de noms), mais heureusement, la plupart des outils de services Web ignorent fondamentalement le schéma et acceptent tout ce qui semble raisonnable. (Voir les liens vers de nombreux schémas WSDL dans la section).
Même la version WS-I BP du schéma WSDL 1.1 n'est pas très utile pour garantir la conformité avec la spécification du document WSDL 1.1. Le schéma ne reflète pas toutes les limitations de BP WS-I, notamment en ce qui concerne la commande des composants. De plus, XML Schema est incapable de gérer de nombreux types de contraintes facilement définies dans les documents (comme des attributs alternatifs ou des éléments supplémentaires requis à partir d'un schéma distinct). Par conséquent, la validation d'un document WSDL 1.1 par rapport à la spécification WSDL 1.1 (telle que modifiée par BP WS-I) implique bien plus qu'une simple validation de schéma XML. Nous reviendrons sur ce sujet dans cet article. Mais d'abord, examinons la structure des descriptions de service WSDL 1.1.
Description des composants
Les documents WSDL 1.1 utilisent un élément racine fixe avec un nom pratique
Il y a aussi un élément
Une description complète d'un service nécessite généralement au moins un élément de chacun de ces types, à l'exception de
Le listing 1 montre un exemple de description de service WSDL divisée en deux documents WSDL, de sorte que les composants de description d'interface se trouvent dans le fichier BookServerInterface.wsdl et les composants d'implémentation se trouvent dans le fichier BookServerImpl.wsdl. La liste 1 montre BookServerInterface.wsdl.
Liste 1. BookServerInterface.wsdl
Le listing 2 montre BookServerImpl.wsdl. Élément
Liste 2. BookServerImpl.wsdl
En plus des définitions d'éléments (et d'attributs) dans l'espace de noms WSDL 1.1, WSDL 1.1 définit également des éléments supplémentaires. Ils sont destinés à remplir des cellules spécifiques dans les descriptions de service WSDL 1.1 pour transmettre des informations supplémentaires requises pour un type de service spécifique. Les seuls éléments WSDL 1.1 supplémentaires qui sont encore largement utilisés sont les liaisons pour SOAP 1.1 (elles sont présentées dans, dans les éléments
Détails des composants
Élément
Étant donné qu'un élément
En plus de
Figure 1. Relations entre les composants WSDL
Messages représentés par des éléments
Les éléments
WSDL 1.1 définit plusieurs modèles d'interaction entre un client et un fournisseur de services, représentés par diverses séquences d'enfants
Chaque élément
À bien des égards
Comparer SOAP 1.1 et 1.2
SOAP 1.1 a été largement utilisé pour les services Web depuis la publication de la spécification en 2000. SOAP 1.2 a été développé avec un support plus large de l'industrie via le W3C et publié en tant que norme officielle du W3C en 2007. SOAP 1.2 est mieux documenté et plus propre que SOAP 1.1, certains des aspects laids de 1.1 étant supprimés chirurgicalement. Malgré cette structure raffinée, il y a peu de différence pratique entre les deux pour la plupart des services Web. La caractéristique la plus importante de SOAP 1.2 est probablement qu'il s'agit du seul moyen officiellement pris en charge d'exploiter la prise en charge étendue des pièces jointes SOAP pour l'empaquetage optimisé binaire XML (XOP) et le mécanisme d'optimisation de la transmission des messages SOAP (MTOM). En boucle Services Web Java J'ai utilisé SOAP 1.1 jusqu'à présent car certaines piles plus anciennes ne prennent pas en charge SOAP 1.2, mais pour développer de nouveaux services Web, 1.2 est probablement le meilleur choix.
Les éléments
Éléments enfants
Les extensions définies par WSDL entrent en jeu dans
A l'intérieur de chaque enfant
Le dernier composant de la description du service WSDL est l'élément
Travailler avec WSDL
Sans surprise, avec toutes les variations de schéma et de règle pour les documents WSDL 1.1, de nombreux documents ne suivent pas les meilleures pratiques BP WS-I. La prise en charge par toutes les piles de services Web de nombreuses déviations des meilleures pratiques a contribué à perpétuer l'utilisation de constructions obsolètes ou incorrectes, entraînant la propagation de mauvaises pratiques dans l'ensemble de l'industrie. Et je ne suis certainement pas à l'abri de cette infection - en regardant les documents WSDL que j'ai fournis comme exemples de code pour cette série, j'ai été surpris de constater qu'aucun d'entre eux n'est complètement correct.
Alors quand j'ai décidé d'écrire cet article, j'ai pensé qu'il serait bon d'inclure un outil avec lequel vous pouvez valider les documents WSDL pour les meilleures pratiques. Il semblerait que ce ne soit qu'une étape à partir d'ici pour transformer les documents WSDL dans la forme correcte, à condition que le WSDL d'origine soit exempt d'erreurs. Mais le travail s'est avéré être bien plus que ce que j'avais prévu à l'origine, et j'inclurai des informations complètes sur ce modèle dans les deux prochains articles de cette série.
Pour travailler avec des documents WSDL en langage Java, il existe de nombreux différents modèles, y compris le langage de description de services Web largement utilisé pour Java Toolkit (WSDL4J), qui est l'implémentation de référence JSR 110 (voir la section). Aucun de ces modèles ne correspond à ce que j'allais faire, en raison du double énoncé du problème : premièrement, lire des documents WSDL sous n'importe quelle forme semi-raisonnable et signaler les erreurs et les écarts par rapport aux meilleures pratiques, et deuxièmement, écrire des WSDL sans erreur. documents reformatés sous une forme conforme aux directives pratiques. WSDL4J, par exemple, ne préserve pas l'ordre des éléments d'entrée afin que les problèmes d'ordre puissent être signalés, et il ne traite pas les définitions de schéma, il ne peut donc pas être utilisé directement pour valider les références des éléments.
Modèle WSDL
Validation et vérification
Dans cet article, j'utilise le terme vérification pour désigner la validation d'un document WSDL, car le terme alternatif est validation, couramment utilisé pour les documents XML, signifie valider les documents par rapport à une définition de schéma.
J'ai déjà partiellement implémenté le modèle WSDL à utiliser avec la liaison de données JiBX dans le cadre d'un projet JiBX / WS. Ce modèle est uniquement destiné à la sortie et comprend un nombre relativement faible de classes qui, dans certains cas, combinent des données à partir d'éléments de structure XML WSDL imbriqués (
Une autre option consiste à générer du code à partir du schéma WS-I BP pour WSDL 1.1. Voyant cela, j'ai réalisé que le simple fait d'utiliser les classes générées conduirait directement à la confusion, car le schéma comprend des types redondants ainsi que des constructions maladroites qui sont utilisées pour représenter divers modèles de messagerie (dont certains ont ensuite été interdits par le BP WS-I texte) ...
J'ai donc fini par écrire les classes à la main, bien que le résultat soit à peu près le même que si je commençais avec le code généré à partir du schéma et que je réduisais simplement les duplications et la complexité inutiles. La liaison de données JiBX maintient plusieurs liaisons aux mêmes classes, j'ai donc pu créer une liaison d'entrée pour gérer la gamme complète d'options autorisées par n'importe quelle version de WSDL 1.1, bien que la configuration de la liaison de sortie pour la sortie WSDL ne soit qu'une bonne pratique forme.
Le listing 3 montre la partie de la classe Definitions correspondant à l'élément racine.
Listing 3. La classe Definitions (partiellement)
Les définitions de classe publique étendent ElementBase (/ ** Répertorie les éléments enfants dans l'ordre attendu. * / static enum AddState (invalide, imports, types, message, portType, binding, service); / ** Liste des noms d'attributs autorisés. * / public static final StringArray s_allowedAttributes = new StringArray (new String ("name", "targetNamespace")); / ** Valide le contexte utilisé. * / Private ValidationContextL'organisation des données enfants dans montre comment le modèle prend en charge à la fois l'entrée et la sortie génériques selon recommandations pratiques... Au lieu d'une seule liste d'enfants de tous les types, des listes distinctes sont utilisées pour chaque type. La liaison d'entrée JiBX traite les enfants comme un ensemble non ordonné, appelant spécifique à de ce genreéléments set-méthode chaque fois que l'enfant n'est pas à sa place. Au lieu de remplacer l'une des valeurs précédentes, le setter ajoute l'instance à la liste typée, comme vous pouvez le voir à partir du setter addMessage () utilisé pour les éléments enfants.
Des attributs et éléments supplémentaires sont autorisés dans tous les éléments WSDL (généralement tous les attributs ou éléments qui n'utilisent pas l'espace de noms WSDL 1.1). Des exemples de ces éléments supplémentaires sont les configurations WS-Policy intégrées dans les documents WSDL des articles précédents de cette série, ainsi que des liens vers les politiques réelles. Il est préférable que ces éléments supplémentaires précèdent tous les éléments enfants de l'espace de noms WSDL 1.1, et c'est ainsi qu'ils sont traités dans la liaison de sortie. La liaison d'entrée gère des éléments et des attributs supplémentaires à l'aide du code de classe de base des classes d'éléments WSDL non affichées et permet aux éléments de suivre dans n'importe quel ordre (générant un avertissement s'ils suivent un élément de l'espace de noms WSDL 1.1).
Le modèle gère les éléments connus en utilisant des liaisons distinctes pour chaque espace de noms supplémentaire, chacun avec son propre ensemble de classes. Je couvrirai la gestion de ces éléments supplémentaires plus en détail dans la prochaine version. Services Web Java, où le code source sera présenté plus en détail.
Vérification du modèle
Une vérification de base des données WSDL est effectuée car les objets de désassemblage correspondant aux éléments sont ajoutés à la structure arborescente du document WSDL, comme indiqué dans le code addMessage() à la fin. Ce code utilise la méthode checkAdd() pour vérifier l'ordre des enfants et la méthode addName() pour vérifier qu'un nom valide est fourni (le texte correspond au type de schéma NCName et la valeur est unique dans le type d'élément) et mappe le nom à un objet. Mais ce n'est qu'une vérification des informations les plus élémentaires pour un seul élément ; un code de vérification supplémentaire est requis pour vérifier les autres propriétés de chaque élément et les relations entre les éléments.
JiBX vous permet d'appeler des gestionnaires d'extensions personnalisés dans le cadre du processus de regroupement et de désorganisation. Le modèle WSDL utilise l'un de ces gestionnaires supplémentaires, la méthode post-set, pour exécuter la logique de vérification. La méthode post-set est appelée une fois la désorganisation de l'objet associé terminée, c'est donc souvent un bon moyen d'effectuer des vérifications de type sur la vérification d'objet. Dans le cas de la validation WSDL, l'approche la plus simple consiste à effectuer toutes les vérifications d'objets à partir d'une seule méthode post-définie pour l'élément racine
Autres ajouts
Cet article décrit les bases de la structure et de l'utilisation de WSDL et fournit une introduction au modèle de données Java pour WSDL afin de prendre en charge la vérification des documents WSDL et de les transformer en un formulaire de meilleures pratiques.
Le prochain article poursuivra ce sujet en examinant les problèmes courants lors de l'écriture d'assertions WS-Policy et WS-SecurityPolicy. Il détaillera également le modèle WSDL et le processus de vérification, y compris l'extension du modèle pour inclure les assertions WS-Policy / WS-SecurityPolicy intégrées dans WSDL.
Une fois, ils m'ont confié la tâche de démarrer le développement de services Web et m'ont donné un échantillon du projet le plus simple sans aucune explication. Le projet, bien sûr, n'a pas démarré. Ce qu'est le printemps et comment il fonctionne, je n'en avais aucune idée non plus. Je n'ai pas non plus pu trouver d'articles adéquats sur le développement de services Web à l'aide de Spring, que ce soit en russe ou en anglais. Je devais le découvrir moi-même, il s'est avéré que ce n'était pas si effrayant.
Et tout récemment, j'ai décidé de voir quelles nouvelles fonctionnalités ont été ajoutées à Spring depuis lors et de mettre à jour les anciens services, ce qui m'a incité à écrire cet article.
Cet article est un guide pour développer un service Web de base basé sur SOAP à l'aide de Spring-WS.
Et donc, nous allons écrire un service simple qui accepte un nom d'utilisateur et envoie un message d'accueil et l'heure actuelle sur le serveur.
De quoi avons nous besoin?
- IDE. J'utilise Eclipse.
Préparation au travail
Créez un nouveau projet d'application Web. Dans Eclipse, c'est : "Fichier => Nouveau => Projet Web dynamique".J'ai nommé le projet : HelloService.
Ensuite, copiez les bibliothèques de Spring, XMLBean, wsdl4j, commons-logging dans le répertoire du projet WEB-INF/lib.
Si vous le souhaitez, vous pouvez les ajouter aux bibliothèques du serveur, afin de ne pas les traîner avec chaque application.
Création d'un schéma WSDL
Essentiellement, un schéma WSDL est destiné à décrire un service.Nous, bien sûr, ne le créerons pas manuellement. Le schéma sera généré automatiquement par les outils Spring, mais nous en reparlerons plus tard.
Définition des données d'entrée et de sortie
Des données d'entrée:- Nom de la chaîne.
- Salutation de chaîne ;
- Heure l'heure actuelle.
Créer une description des données d'entrée et de sortie
Dans le répertoire WEB-INF, créez le fichier HelloService.xsd. Ce fichier sera nécessaire pour générer le schéma WSDL et créer les classes Java correspondantes.Texte du fichier :
Attribut targetNamespace- espace de noms utilisé. Ceux. tous les objets créés seront situés dans le package org.example.helloService.
Les éléments Demande de service et ServiceRéponse décrire les données d'entrée et de sortie (requête / réponse), respectivement.
Les attributs minSurvient et maxSurvient déterminer le nombre de répétitions d'un composant donné dans un élément. Si ces paramètres ne sont pas spécifiés, ils sont alors considérés par défaut comme égaux à 1. Pour un composant optionnel, vous devez spécifier minOccurs = 0. Avec un nombre illimité de composants : maxOccurs = unbounded.
Vous pouvez en savoir plus sur les schémas XML.
Créer des JavaBeans
Sur la base du schéma créé, nous allons créer des classes Java. Pour ce faire, créez un fichier build.xml :Paramètre WS_HOME doit pointer vers le répertoire où se trouve XMLBeans.
BonjourService.xsd- chemin vers le schéma créé.
lib \ helloservice.jar- la librairie java en cours de création.
Ensuite, lancez Ant-build (j'espère que vous l'avez déjà installé).
Dans Eclipse, vous pouvez l'exécuter comme ceci : RMB sur le fichier build.xml => Run As => Ant Build.
Si via la ligne de commande :
ant -buildfile build.xml
Eh bien, nous attendons l'achèvement de la construction. Après cela, nous pouvons vérifier dans le répertoire du projet WEB-INF\lib la présence de la bibliothèque correspondante (helloservice.jar).
Mise en œuvre des services
Créer une interface et une classe de service
Interface de service : HelloService.java :paquet org.example; importer java.util.Calendar ; interface publique HelloService (chaîne publique getHello (nom de la chaîne) lève une exception ; calendrier public getCurrentTime ();)
Implémentation du service : HelloServiceImpl.java :
paquet org.example; importer java.util.Calendar ; importer org.springframework.stereotype.Service ; @Service La classe publique HelloServiceImpl implémente HelloService (la chaîne publique getHello (nom de la chaîne) lève une exception (retourne "Bonjour" + nom + "!";) Calendrier public getCurrentTime () (retourne Calendar.getInstance ();))
Ce code, je pense, n'a pas besoin de commentaires. La seule chose que les personnes qui n'ont jamais rencontré Spring peuvent se poser des questions est l'annotation @ Service, mais j'en parlerai un peu plus tard.
Point de terminaison
Endpoint est une classe qui sera responsable du traitement des requêtes entrantes (une sorte de point d'entrée).Créez le fichier HelloServiceEndpoint.java :
paquet org.example; importer org.springframework.beans.factory.annotation.Autowired ; importer org.springframework.ws.server.endpoint.annotation.Endpoint ; importer org.springframework.ws.server.endpoint.annotation.PayloadRoot ; importer org.example.helloService.ServiceRequestDocument ; importer org.example.helloService.ServiceRequestDocument.ServiceRequest ; importer org.example.helloService.ServiceResponseDocument ; importer org.example.helloService.ServiceResponseDocument.ServiceResponse ; @Endpoint public class HelloServiceEndpoint (private static final String namespaceUri = "http://www.example.org/HelloService"; private HelloService helloService; @Autowired public void HelloService (HelloService helloService) (this.helloService = helloService;) (@PayloadRoot localPart = "ServiceRequest", namespace = namespaceUri) public ServiceResponseDocument getService (ServiceRequestDocument request) lève une exception (ServiceRequestDocument reqDoc = request ; ServiceRequest req = reqDoc.getServiceRequest (); ServiceResponseDocument = respaDoc = ServiceResponse. ); String helloMessage = testNewService.getHello (userName); Calendar currentTime = testNewService.getCurrentTime (); resp.setHello (helloMessage); resp.setCurrent); return )
Qu'est-ce qui a été fait ici?
annotation @Endpoint détermine simplement que cette classe traitera les demandes entrantes.
espace de nomsUri- le même espace de noms qui a été spécifié lors de la création du schéma xml.
Revenons un peu en arrière et rappelons-nous l'annotation. @ Service... Si vous n'entrez pas dans les détails, afin de ne pas surcharger le lecteur d'informations inutiles, alors cette annotation indique à Spring "de créer l'objet approprié. Et l'annotation @Autowired sert à l'injection (substitution automatique) de l'objet correspondant. Bien sûr, lors de la construction applications simples cela n'a aucun sens d'utiliser ces annotations, mais j'ai décidé de ne pas les exclure toutes dans cet exemple.
Sinon, encore une fois, tout devrait être clair. Veuillez noter que ServiceRequest, ServiceResponse, etc. - ce sont exactement les classes qui ont été créées sur la base de notre schéma xml.
Configuration du service de printemps
La fin approche donc déjà.Créez le fichier service-ws-servlet.xml.
sws : basé sur les annotations- dit simplement que les annotations sont utilisées dans ce projet.
MAIS contexte : analyse des composants indique le package dans lequel rechercher les annotations, tout en recherchant également dans les sous-packages.
Les deux prochains bacs seront toujours inchangés. Leur essence réside dans la réception et la conversion d'une requête de Xml en un objet Java et sa reconversion ultérieure.
sws : wsdl dynamique responsable de la génération automatique d'un document WSDL basé sur le schéma Xml généré.
lieu indique le chemin d'accès au schéma.
emplacementUri- l'adresse (relative au conteneur) à laquelle le schéma WSDL sera disponible.
Dans mon cas, WSDL est disponible à l'adresse suivante :
localhost / HelloService / HelloService.wsdl
Descripteur de déploiement
Et enfin, la dernière chose.Modifiez ou créez le fichier web.xml dans le répertoire WEB-INF.
Je ne décrirai plus ce dossier, la plupart devraient déjà le savoir. Pour les projets simples, cela ne devrait essentiellement pas changer. Il convient de noter seulement que le nom du servlet (nom-servlet) doit correspondre au nom du fichier de configuration Spring du service. service-ws-servlet.xml.
Contrôle fonctionnel
Le tout premier signe de fonctionnement correct est le schéma WSDL généré.Pour vérifier, il suffit d'aller à l'adresse de ce schéma (http://localhost/HelloService/HelloService.wsdl) et de voir : le fichier xml doit y être affiché. Si rien ne s'est affiché ou quelle erreur est apparue, nous relisons attentivement l'intégralité de l'article et recherchons ce que nous avons fait de mal.
Pour plus de vérification, nous avons besoin de soapUI (j'ai la version 3.0.1).
Installez-le et exécutez-le.
Créez un nouveau projet : Fichier => Nouveau projet soapUI. Dans le champ Initial WSDL / WADL, insérez un lien vers le schéma WSDL (http://localhost/HelloService/HelloService.wsdl).
Dans le projet créé, ouvrez la demande requise. 
Dans le champ Nom, saisissez le nom et cliquez sur le bouton "Envoyer la demande" 
En conséquence, nous recevons une réponse du serveur avec un message d'accueil et l'heure actuelle. 
Si quelque chose ne va pas, alors nous relisons cet article à nouveau.
Et après?
Eh bien, la prochaine étape consiste à écrire un client pour ce service Web. Mais c'est déjà du matériel pour un autre article, qui pourra être écrit plus tard, si ce matériel intéresse quelqu'un.Le titre du sujet est vraiment une question, car Je ne sais pas moi-même ce que c'est et pour la première fois je vais essayer de travailler avec dans le cadre de cet article. La seule chose que je peux garantir que le code ci-dessous fonctionnera, mais mes phrases ne seront que des suppositions et des suppositions sur la façon dont je comprends moi-même tout cela. Alors allons-y ...
introduction
Nous devons commencer par la raison pour laquelle le concept de services Web a été créé. Au moment où ce concept est apparu, des technologies existaient déjà dans le monde qui permettaient aux applications d'interagir à distance, où un programme pouvait appeler une méthode dans un autre programme, qui pouvait être exécuté sur un ordinateur situé dans une autre ville ou même un pays. Tout cela est abrégé en RPC (Remote Procedure Calling). Les exemples incluent les technologies CORBA et pour Java - RMI (Remote Method Invoking). Et tout semble bien en eux, surtout en CORBA, tk. vous pouvez travailler avec n'importe quel langage de programmation, mais il manquait toujours quelque chose. Je crois que l'inconvénient de CORBA est qu'il fonctionne à travers certains de ses propres protocoles réseauà la place de HTTP simple qui rampera à travers n'importe quel pare-feu. L'idée derrière le service Web était de créer un RPC qui collerait aux paquets HTTP. C'est ainsi que l'élaboration de la norme a commencé. Quels sont les concepts de base de cette norme :- SAVON... Avant d'appeler une procédure distante, vous devez décrire cet appel dans fichier XML e de format SOAP. SOAP est simplement l'un des nombreux balisages XML utilisés dans les services Web. Tout ce que nous voulons envoyer quelque part via HTTP est d'abord transformé en une description XML SOAP, puis il est placé dans un paquet HTTP et envoyé à un autre ordinateur du réseau via TCP / IP.
- WSDL... Il existe un service Web, c'est-à-dire un programme dont les méthodes peuvent être appelées à distance. Mais la norme exige qu'une description soit attachée à ce programme, qui dit que "oui, vous ne vous trompez pas - c'est vraiment un service Web et vous pouvez appeler telle ou telle méthode à partir de celui-ci". Cette description est représentée par un autre fichier XML qui a un format différent, à savoir WSDL. Ceux. WSDL n'est qu'un fichier de description XML pour un service Web et rien d'autre.
Approche générale
Les services Web ont toujours un client et un serveur. Le serveur est notre service Web et est parfois appelé point de terminaison (comme le point de terminaison où Messages SOAP du client). Nous devons procéder comme suit :- Décrire l'interface de notre service Web
- Implémenter cette interface
- Lancer notre service Web
- Ecrire un client et appeler à distance la méthode de service Web requise
Serveur
Commençons IDEA et créons un nouveau projet Créer un nouveau projet... Entrons un nom BonjourWebService et appuyez sur le bouton Prochain, puis le bouton Finir... Dans le dossier src créer un paquet ru.javarush.ws... Dans ce package, nous allons créer l'interface HelloWebService : package ru. javarush. ws; // ce sont des annotations, c'est-à-dire un moyen de marquer nos classes et nos méthodes, // en ce qui concerne la technologie des services Web importer javax. jws. WebMéthode ; importer javax. jws. Service Web; importer javax. jws. savon. SOAPBinding; // nous disons que notre interface fonctionnera comme un service web@Service Web // dire que le service web sera utilisé pour appeler des méthodes@SOAPBinding (style = SOAPBinding. Style. RPC) interface publique HelloWebService ( // on dit que cette méthode peut être appelée à distance@WebMethod public String getHelloString (nom de la chaîne); ) Dans ce code, les classes WebService et WebMethod sont des soi-disant annotations et ne font que marquer notre interface et sa méthode en tant que service Web. Il en est de même pour la classe SOAPBinding. La seule différence est que SOAPBinding est une annotation de paramètre. Dans ce cas, le paramètre style est utilisé avec une valeur qui indique que le service Web ne fonctionnera pas via des messages de document, mais comme un RPC classique, c'est-à-dire pour appeler la méthode. Implémentons la logique de notre interface et créons une classe HelloWebServiceImpl dans notre package. En passant, je note que la fin de la classe dans Impl est une convention en Java, selon laquelle l'implémentation des interfaces est désignée de cette manière (Impl - du mot implémentation, c'est-à-dire implémentation). Ce n'est pas une obligation et vous êtes libre de nommer la classe comme bon vous semble, mais les règles de bonne forme l'exigent : package ru. javarush. ws; // la même annotation que lors de la description de l'interface, importer javax. jws. Service Web; // mais utilisé ici avec le paramètre endpointInterface, // en spécifiant le nom de classe complet de l'interface de notre service web@WebService (endpointInterface = "ru.javarush.ws.HelloWebService") la classe publique HelloWebServiceImpl implémente HelloWebService (@Override public String getHelloString (nom de chaîne) ( // simplement renvoyer un message d'accueil return "Bonjour," + nom + "!" ; )) Commençons notre service Web en tant que serveur indépendant, c'est-à-dire sans l'implication de Tomcat et de serveurs d'applications (ceci est un sujet pour une discussion séparée). Pour cela, dans la structure du projet dans le dossier src créez un package ru.javarush.endpoint, et créez-y une classe HelloWebServicePublisher avec une méthode principale : package ru. javarush. point final ; // classe pour démarrer un serveur Web avec des services Web importer javax. xml. ws. Point final ; // classe de notre service web importer ru. javarush. ws. HelloWebServiceImpl; classe publique HelloWebServicePublisher (public static void main (String... args) ( // démarre le serveur web sur le port 1986 // et à l'adresse indiquée dans le premier argument, // démarre le service web passé en second argument Point final. publier ( "http: // localhost: 1986 / wss / bonjour", nouveau HelloWebServiceImpl ()); )) Maintenant, exécutons cette classe en cliquant sur Maj + F10... Rien n'apparaît dans la console, mais le serveur est en cours d'exécution. Vous pouvez le vérifier en tapant dans le navigateur la ligne http://localhost:1986/wss/hello?Wsdl. La page qui s'ouvre, d'une part, prouve qu'un serveur web (http://) a démarré sur notre ordinateur (localhost) sur le port 1986, et, d'autre part, affiche la description WSDL de notre service web. Si vous arrêtez l'application, la description deviendra inaccessible, ainsi que le service Web lui-même, nous ne le ferons donc pas, mais procéderons à l'écriture du client.Client
Dans le dossier du projet src créez un package ru.javarush.client, et dans celui-ci la classe HelloWebServiceClient avec la méthode principale : package ru. javarush. client; // nécessaire pour obtenir la description wsdl et à travers elle // accéder au service web lui-même importer java. rapporter. URL ; // une telle action se produira lors de l'utilisation d'un objet URL importer java. rapporter. Exception URL malformée ; // classes pour analyser xml-ku avec la description wsdl // et atteindre la balise de service dedans importer javax. xml. espace de noms. QName ; importer javax. xml. ws. Service; // l'interface de notre service web (il nous en faut plus) importer ru. javarush. ws. BonjourWebService ; classe publique HelloWebServiceClient (public static void main (String args) lève MalformedURLException ( // crée un lien vers la description wsdl Url url = nouvelle url ( "http: // localhost: 1986 / wss / bonjour? wsdl") ; // On regarde les paramètres du constructeur suivant dans la toute première balise de la description WSDL - définitions // Regardez le 1er argument dans l'attribut targetNamespace // voir le 2ème argument dans l'attribut name QName qname = nouveau QName ("http://ws.javarush.ru/", "HelloWebServiceImplService"); // Maintenant, nous pouvons atteindre la balise de service dans la description wsdl, Prestation de services= Service. créer (url, qname); // puis jusqu'à la balise de port imbriquée, de sorte que // obtenir un lien vers un objet de service Web distant de nous BonjourWebService bonjour = service. getPort (classe HelloWebService.); // Hourra ! Vous pouvez maintenant appeler la méthode distante Système. en dehors. println (bonjour. getHelloString ("CodeGym")); )) J'ai donné un maximum de commentaires sur le code dans la liste. Je n'ai rien à ajouter, alors on lance (Shift + F10). Nous devrions voir le texte dans la console : Hello, CodeGym ! Si vous ne l'avez pas vu, vous avez probablement oublié de démarrer le service Web.Conclusion
Dans ce sujet, une brève excursion dans les services Web a été présentée. Encore une fois, une grande partie de ce que j'ai écrit est une conjecture sur la façon dont cela fonctionne, et par conséquent, il ne faut pas trop faire confiance. Je serais reconnaissant si des personnes bien informées me corrigeaient, car alors j'apprendrais quelque chose. UPD.Page 2 sur 3
Décrire avec WSDL
SOAP fonctionne très bien si vous savez tout sur le service Web. Par contre, ce n'est pas toujours le cas. Le Web Services Description Language (WSDL) est utilisé pour décrire l'interface d'accès à un service Web. Cette norme a été développée conjointement par IBM, Microsoft et webMethods. Les trois sociétés avaient chacune leur propre approche pour développer une norme de description des services Web : IBM a créé NASSL, Microsoft a développé SCL et webMethods a proposé WIDL.
Le résultat de leur collaboration a été la version 1.1 du langage WSDL Concernant le W3C, il est à noter que, comme pour SOAP, le W3C, basé sur la version 1.1, a développé WSDL 1.2, qui est maintenant une recommandation du W3C. La description WSDL d'un service Web contient toutes les informations nécessaires à l'utilisation du service, y compris les méthodes disponibles et leurs paramètres. Ces informations sont contenues dans les cinq éléments suivants :
- Protocoles pris en charge. - Messages de service Web (demande, réponse). Toutes les méthodes disponibles. - URI de service. - les types de données utilisés.
Toutes ces informations sont stockées dans l'élément racine de la description WSDL.
Description du service Web WSDL
Ouais ... vous ne pouvez pas le comprendre sans un verre, mais c'est l'un des fichiers WSDL les plus simples (!). Malheureusement, l'un des inconvénients de l'extension SOAP pour PHP 5 est que, contrairement à d'autres implémentations SOAP, elle ne crée pas automatiquement de descriptions WSDL (du moins pas encore). Cette faille sera sûrement corrigée dans les futures versions de PHP.
D'ailleurs!
Vous pouvez utiliser des implémentations SOAP alternatives en PHP pour générer automatiquement une description WSDL :
Recherche dans l'annuaire avec UDDI
Maintenant que nous savons comment obtenir des informations sur un service Web et comment en faire la demande, nous devons apprendre à trouver un tel service. A cet effet, il existe quelque chose qui s'apparente aux Pages Jaunes, à savoir les Universal Business Registries (UBR) - annuaires de services Web.
Il existe plusieurs registres de ce type, notamment ceux d'IBM, de Microsoft, de NTT-Com et de SAP. Ces registres synchronisent leurs données, vous pouvez donc utiliser n'importe lequel d'entre eux. La version actuelle de la norme UDDI est UDDI 3.0, bien que la plupart des implémentations utilisent la version 2. Les développeurs de cette norme incluent des géants tels que HP, Intel, Microsoft et Sun.
Pour interagir avec UBR, il y a deux types d'API : API d'enquête et API de publication... Interface L'API d'enquête est pour la demande services dans les registres UBR, et l'interface L'API de publication permet aux développeurs d'enregistrer leurs services... Il semble que remplir le contenu des registres avec du spam n'est qu'une question de temps :)
D'ailleurs!
Il existe des registres de test pour tester les enregistrements de service avant de les placer dans de « vrais » registres.
Voici à quoi ressemble la demande de service Web :
Dans l'exemple ci-dessus, vous pouvez voir que la requête UDDI est encapsulée dans un message SOAP, elle semble donc assez familière. La réponse à la demande est également le document SOAP ci-dessous :
Installation
L'installation de l'extension SOAP pour PHP5 est assez simple. Sous Windows, ce module se trouve dans le sous-répertoire ext du répertoire d'installation de PHP. Pour l'utiliser, ajoutez la ligne suivante au fichier php.ini : extension = php_soap.dll Pour que ce module fonctionne, il est nécessaire, ce qui est inclus dans PHP 5 par défaut, au moins dans la version Windows.
XSD : définition de schéma XML.
XML : Langage de balisage extensible.
WSDL : Langage de définition de services Web.
Je ne vais pas répondre techniquement. Je dirige cette explication vers les débutants.
Il n'est pas facile de communiquer entre deux applications différentes qui sont développées à l'aide de deux technologies différentes. Par exemple, une entreprise de Chicago pourrait développer une application Web en utilisant Java, et une autre entreprise de New York pourrait développer une application en C #, et lorsque les deux entreprises décident d'échanger des informations, alors XML apparaîtra dans l'image. Il permet de stocker et de transporter des données entre deux applications différentes développées à l'aide de technologies différentes. Noter. Ceci n'est pas limité à un langage de programmation, veuillez étudier le transport d'informations entre deux applications différentes.
XSD est une définition de schéma. J'entends par là qu'il dit aux utilisateurs de concevoir leur XML dans un tel schéma. Veuillez voir l'image ci-dessous et regardez attentivement avec l'élément "load-on-startup" et son type, qui est un entier. Dans l'image XSD, vous pouvez voir qu'il s'agit d'une valeur entière pour "load-on-startup" et donc, lorsque l'utilisateur a créé son XML, il a transmis la valeur int à cet élément particulier. Rappelez-vous que XSD est un schéma et un style, alors que XML est une forme de communication avec une autre application ou un autre système. Vous devez voir le XSD et créer du XML de cette façon, sinon il ne communiquera pas avec une autre application ou un autre système développé à l'aide d'une technologie différente. La société de Chicago fournit un modèle XSD à la société texane pour écrire ou générer son XML dans ce format XSD. Si la société texane n'a pas respecté les règles ou les schémas mentionnés dans le XSD, il est alors impossible d'attendre des informations correctes de la société de Chicago. Après l'histoire ci-dessus, il y a tellement plus que l'amateur ou le débutant doit savoir tout en codant certaines choses comme je l'ai dit ci-dessus. Si vous voulez vraiment savoir ce qui va suivre, il est préférable de vous asseoir avec les ingénieurs logiciels seniors qui ont réellement développé les services Web. Vient ensuite le WSDL, veuillez suivre les images et essayer de comprendre où le WSDL s'adaptera.
*************** ======== Ci-dessous une image XML partielle ========== ********* ** * ***
*************** ======== Ci-dessous une image XSD partielle ========== ********* ** * ***
************* ======== Ci-dessous une image partielle de WSDL ======= *********** **
J'ai dû créer un exemple de WSDL pour un service Web appelé Book. Notez qu'il s'agit de XSD, mais vous devez le nommer WSDL (Web Services Definition Language) car il est très spécifique aux services Web. Ci-dessous, WSDL (ou en d'autres termes XSD) est généré pour la classe Book.java et a créé le service SOAP. La façon dont le service Web SOAP a été créé est un sujet différent. Une classe Java doit être écrite et avant de procéder à sa création en tant que service Web, l'utilisateur doit s'assurer que l'API Axis2 est installée et que Tomcat héberge le service Web en place.
En tant que fournisseur de services (celui qui permet à d'autres (clients) d'accéder aux informations ou aux données de leurs systèmes) donne réellement au client (ceux qui ont besoin d'utiliser les informations ou les données du fournisseur de services) un accès complet aux données via le service Web, aucune entreprise sur terre n'est prête à partager sa base de données avec des étrangers. Comme mon entreprise, j'ai décidé de fournir des informations sur les produits via des services Web, nous avons donc dû créer un modèle XSD et transmettre certains de nos clients qui souhaitent travailler avec nous. Ils doivent écrire du code pour utiliser pleinement le XSD donné et effectuer des appels de service Web pour récupérer les données du serveur et transformer les données renvoyées à leur demande appropriée, puis afficher ou publier les données ou les informations sur le produit sur leur site Web. Un exemple simple est la réservation de vol VOL. La compagnie aérienne autorisera des tiers à utiliser les détails du vol sur son site Web pour vendre des billets. Mais là encore, il y a beaucoup plus, juste en n'autorisant pas une compagnie aérienne tierce à vendre des billets, il y aura une synchronisation et une sécurité en place. S'il n'y a pas de synchronisation, la probabilité est de 100 % que plus d'un client peut acheter le même billet d'avion auprès de différentes sources.
J'espère que les experts contribueront à ma réponse. Il est très difficile pour un débutant ou un novice de comprendre XML, XSD, puis de travailler avec des services Web.
