Discussion :

[hugo123]

Bonjour,

Je vous propose de faire le point sur les plugins Maven permettant d'industrialiser vos développements de webservices. Ces plugins très pratiques vous permettront :

• de générer vos objets modèles à partir d'une XSD ;
• de paramétrer cette génération pour que vos objets soient pratiques à utiliser ;
• de générer un WSDL ou un WADL de vos services ;
• de distribuer un client de vos services généré à partir de votre WSDL ;
• de tester vos services déployés sur un serveur Jetty en intégration continue avec SoapUI.

http://hugo.developpez.com/tutoriels...eb-avec-maven/
N'hésitez pas à faire vos remarques, commentaires.

[tnodev]

Bonjour,

et merci pour cet article très complet et très intéressant.

Un point que j'aurai aimé voir aborder est la connexion au WS via https et certificat.

[DrHelmut]

Pour ma part, je ne fait plus que des webservices Rest, le soap c'est mort :p

Du coup, as-tu déjà essayé RestFuse ? C'est une extension de JUnit pour tester des web services REST qui gère le https sans certificat (ou alors j'ai réussit à bidouiller malgré moi :p)

Je trouve ça plus pratique que de passer par soapUi, et je l'utilise comme toi dans maven durant la phase de test d'intégration, sous jetty.

La doc n'est pas forcément très bien faite ni très claire, mais en fouinant un peu l'usage du framework est vraiment simple et agréable ^^

[tchize_]

Pour ma part, je ne fait plus que des webservices Rest, le soap c'est mort :p

Je peux me tromper, mais il me semble que l'avantage du Soap, par rapport au Rest, c'est ça rigueure. Avec le wsdl qui décrit tout le service, la validation xsd derrière, c'est presque impossible de répondre du caca à une requête. C'est important quand on utilise les webservice pour faire communiquer des système informatiques important.

Maintenant, quand il s'agit de mettre un petit service à disposition des clients tiers, c'est sur que du REst c'est bien plus rapide à mettre en place et à gérer

[Ceddoc]

Sympa le tutoriel, j'aurais bien aimé que tu l'ai écris un an avant car j'ai mis ça en place et j'avais pas mal bataillé a l'époque.

Donc bon boulot

Peut être un peu plus de précisions au niveau des classes générées par le wsdl2java quel sont les rôles du Package-info, le l'objectFactory, j'ai fait des déductions mais une mise au clair aurait été cool.

[hugo123]

@Ceddoc : En fait l'objectif de l'article c'était surtout de montrer l'industrialisation avec Maven et non d'expliquer les WS. D'ou le peu de détail sur les fichiers générés.

@DrHelmut : je n'ai pas essayé RestFuse. Quand je teste mes WS Rest en général soit je teste les méthodes unitaires, soit je teste mon service sur un Jetty embarqué (sans https) pour un test d'intégration.
Tester avec Https c'est uniquement sur du test de bout en bout que ca devient nécessaire or on est déjà plus sur les mêmes outils dans ce cas la.
Le test unitaire par définition c'est unitaire, le HTTPS c'est une surcouche que je ne devrais pas avoir besoin de tester.

@tchize_ : un service REST peut déclarer un contrat de service. Quand à la validation, dans le monde Java, c'est relativement simple à mettre en place avec la JSR 303 combiné avec un intercepteur Jersey.
Pour la petite anecdote de gros services proposent uniquement des APIs REST : Github, Twitter pour ne citer qu'eux. On est loin du "petit service"

[tchize_]

Pour la petite anecdote de gros services proposent uniquement des APIs REST : Github, Twitter pour ne citer qu'eux. On est loin du "petit service"

Je ne parle pas de petit au sens du débit hein. Mais si demain twitter change un paramètre dans son service REST, tout le monde s'en fou, la pluspart des programmes vont ignorer ce paramètres. Avec du SOAP, t'as envie que tout les service qui ne sont "pas à jour" crashent joyeusement plutot que d'ignorer ce paramètre supplémentaire, histoire que tu sache tout de suite que tu as oublié de migrer une partie de ton infrastructure


PS: J'ignorais qu'ils existait des contrat de service RESt, puisque je n'en ai jamais croisé dans aucun service REST que j'ai contacté. Ca a toujours été "vla la doc, débrouille toi pour essayer de plus ou moins la suivre".

[hugo123]

Le fait de rendre un paramètre obligatoire n'est pas tributaire de la techno. Tu as plein de framework REST qui propose une validation et qui renvoie une 400 (bad request) avec le descriptif de l'erreur rencontré.

Si Twitter ou Github propose des migrations silencieuses c'est surtout une question de stratégie de migration mais pas une limitation technologique.
(Ca les empêche pas de déprécier des anciennes versions de leurs APIs de temps en temps)

[tchize_]

Le fait de rendre un paramètre obligatoire n'est pas tributaire de la techno. Tu as plein de framework REST qui propose une validation et qui renvoie une 400 (bad request) avec le descriptif de l'erreur rencontré.

Je parle bien d'un document normatif que tu peux appliquer facilement à la requête et à la réponse, pas du comportement du serveur. Le SOAP fournis un typechecking et un contrat d'utilisation. Chacun ses besoins, SOAP ne peux pas remplacer le RESt, mais à l'inverse, REST ne fournis pas tous les avantages du SOAP non plus. Donc comme je l'ai dit, l'avantage du SOAP reste sa rigueur.

[hugo123]

SOAP en lui même n'est qu'un protocole d'échange.

Le "typechecking" est fourni par l'utilisation de XSD et la validation du message XML par rapport à cette XSD. C'est bien à cela que tu fais référence ?

Avec REST tu as la possibilité d'utiliser WSDL2.0 pour exposer ton contrat de service (et potentiellement une XSD).
Pour être honnête la norme WSDL2 n'est pas vraiment adopté dans le monde des services REST. Elle même faisait suite à WADL qui avait déjà essayé de s'imposer sans succès. Enfin peut être que certains l'utilisent, mais j'en connais pas.

Du coup effectivement il n'y a pas de solutions "standard" pour générer son modèle côté client. Il existe par contre des solutions qui émergent et vraiment utilisé :
- swagger
- http://restdesc.org/about/discovery (qui utilise le verbe OPTIONS de HTTP)

Côté serveur, la validation est trivialement faite avec la majorité des frameworks REST. Et le code 400 est renvoyé par le code applicatif, pas par le frontal. C'est la facon standard de renvoyer une erreur signalant un input incorrect (l'équivalent de ton erreur de validation XSD).

C'est bien possible d'être rigoureux en REST. Mais on n'est pas encore sur la même standardisation qu'avec un service SOAP.

La norme WS-* par contre va bien plus loin :

• WS-Adressing
• WS-ReliableMessaging
• WS-Security

Et surtout SOAP est utilisable au dessus d'autre protocoles que HTTP, JMS par exemple.
En même temps on compare des choux et des carottes. SOAP définit un protocole d'échange, REST un style d'architecture WEB.

[tchize_]

Avec REST tu as la possibilité d'utiliser WSDL2.0 pour exposer ton contrat de service (et potentiellement une XSD).
Pour être honnête la norme WSDL2 n'est pas vraiment adopté dans le monde des services REST. Elle même faisait suite à WADL qui avait déjà essayé de s'imposer sans succès. Enfin peut être que certains l'utilisent, mais j'en connais pas.

Merci pour l'info, je ne connaissais pas

[geforce]

Merci pour l'info, je ne connaissais pas

Selon moi tu ne peu utilisé du WSDL 2.0 ou du WADL que si tu envoi du XML avec du RestFul, mais si tu envoi par exemple du JSON tu peu pas avoir la définition des WS et donc pas de XSD ?? problème dit moi si je fait erreur

[geforce]

Allo Hugo

Ta mis comme conclusion a la Fin du toto :

Avec cet article nous avons vu comment :

• générer notre modèle à partir de XSD ;
• écrire nos services Web à partir de ce modèle ;
• générer notre WSDL à partir du code des services ;
• générer un client à partir du WSDL ;
• automatiser nos tests d'intégration avec SoapUI.

Désormais vous n'avez plus d'excuse pour ne pas générer vos clients, ne pas écrire de tests ou copier votre WSDL à la main dans un autre projet !

Tu dis en a "écrire nos services Web à partir de ce modèle" du modèle = l’entité Profils

Mais le code du service web SOAP lui a été généré ou codé a la main ? (dans le tutoriel sans le dire en comprend qu'il est fait à la main) y t'il pas une façon pour le généré lui ?

Merci.
NB: possible amélioration serai de faire des services web CRUD voir les généré.

[hugo123]

Le service qui contient le code métier est effectivement écrit à la main.
L'interface aussi d'ailleurs dans mon exemple puisqu'il s'agit d'une approche code first. C'est à dire que c'est le code qui permet de générer le WSDL et non l'inverse.

Par rapport à ta dernière remarque, il existe déjà des frameworks permettant de générer des services REST à partir d'un modèle. Regardes du côté de spring-data-rest.

a+

[geforce]

Bonjour, hugo123

Serait-il possible de généré des WSDL avec une implémentation Resteasy ? si c'est avec le même plugin Maven ? s'il existe un exemple de configuration maven serai le bienvenu

--
J'ai trouvé ce lien qui fait modèle https://gist.github.com/yclian/90655...adl-plugin-xml

Code XML :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
<plugin>
    <groupId>com.sun.jersey.contribs</groupId>
    <artifactId>maven-wadl-plugin</artifactId>
    <version>1.8</version>
    <executions>
        <execution>
            <id>generate</id>
            <goals>
                <goal>generate</goal>
            </goals>
            <phase>prepare-package</phase>
        </execution>
    </executions>
 
    <dependencies>
        <dependency>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-simple</artifactId>
            <version>${slf4j.version}</version>
        </dependency>
    ...
    </dependencies>
 
    <configuration>
        <wadlFile>${restdoc.directory}/foo.wadl</wadlFile>
        <formatWadlFile>true</formatWadlFile>
        <baseUri>http://example.com:8080/foo/rest/</baseUri>
        <packagesResourceConfig>
            <param>..</param>
        </packagesResourceConfig>
        <wadlGenerators>
            <wadlGeneratorDescription>
                <className>com.sun.jersey.server.wadl.generators.WadlGeneratorApplicationDoc
                </className>
                <properties>
                    <property>
                        <name>applicationDocsFile</name>
                        <value>${xsl.directory}/application-doc.xml</value>
                    </property>
                </properties>
            </wadlGeneratorDescription>
            <wadlGeneratorDescription>
                <className>com.sun.jersey.server.wadl.generators.WadlGeneratorGrammarsSupport
                </className>
                <properties>
                    <property>
                        <name>grammarsFile</name>
                        <value>${xsl.directory}/application-grammars.xml</value>
                    </property>
                </properties>
            </wadlGeneratorDescription>
            <wadlGeneratorDescription>
                <className>
                    com.atlassian.plugins.rest.doclet.generators.resourcedoc.AtlassianWadlGeneratorResourceDocSupport
                </className>
                <properties>
                    <property>
                        <name>resourceDocFile</name>
                        <value>${restdoc.directory}/resourcedoc.xml</value>
                    </property>
                </properties>
            </wadlGeneratorDescription>
        </wadlGenerators>
    </configuration>
</plugin>

Comment je peu l'utilisé avec RESTEasy ?

Merci