| Astuce | ||
|---|---|---|
| ||
Relecture RB |
La méthode qui est présentée ici consiste à :
- Générer automatiquement du code java d'accès au service distant via Maven (Ici, on utilise, à titre d'exemple, un service de création d'entrée dans le WorkFlow de ORI-OAI cf. ori-oai.org )
- Utiliser ce code java dans la couche métier de l'application
Au final, on accède au service avec très peu de code. Tout le travail est fait par le plugin CXF pour maven qui va complétement masquer la complexité du code JAX-WS en le générant automatiquement.
...
Sommaire :
| Sommaire | ||
|---|---|---|
|
...
Dans le premier cas on a accès au code JAVA de l'interface définissant la couche métier mais aussi au code des objets manipulermanipulés. On aura alors intérêt à partager l'interface JAVA entre le client et le serveur.
Dans le deuxième cas, le Web Service n'est pas forcément développé en JAVA et on n'a pas accès au code de des objets métiers. On aura alors intérêt à générer automatiquement du code java client via un plugin CXF pour maven.
...
Dans ce cas, l'application doit avoir accès aux mêles mêmes modules maven (ou aux jar correspondants) domain-service et domain-bean de l'application serveur exposant le Web Service. L'interface étant dans le module domain-service et les potentiels objets métiers manipulés dans la le module domain-bean.
Afin d'accéder à la couche service d'un Web Service il y a quelques éléments de configuration CXF à mettre dans la configuration Spring de la couche métier (properties/domain/domain.xml) :
...
Au final on accède au service avec très peu de code. Tout le travaille est fait par le plugin CFX CXF pour maven qui va complètement masquer la complexité du code JAX-WS en le générant automatiquement.
...
Le plugin
Pour que le plugin CFX CXF pour maven génère automatiquement le code, il faut ajouter ces lignes dans les le pom.xml :
| Bloc de code | ||||
|---|---|---|---|---|
| ||||
<plugin>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-codegen-plugin</artifactId>
<version>2.4.3</version>
<executions>
<execution>
<id>generate-sources</id>
<phase>generate-sources</phase>
<configuration>
<wsdlOptions>
<wsdlOption>
<wsdl>http://srv.univ.fr/workflow/xfire/OriWorkflowService?wsdl</wsdl>
</wsdlOption>
</wsdlOptions>
</configuration>
<goals>
<goal>wsdl2java</goal>
</goals>
</execution>
</executions>
</plugin>
|
...
| Remarque |
|---|
Ce WSDL sera redéfini, par la configuration de l'application, lors de l'excursionexécution. En effet, on ne peut pas préjuger, lors de l'écriture du code, de la localisation du Web Service à utiliser. |
...
| Bloc de code | ||||
|---|---|---|---|---|
| ||||
<dependency>
<groupId>org.esupportail</groupId>
<artifactId>esup-commons2-ws-cxf</artifactId>
<version>${esup-commons.version}</version>
<type>pom</type>
</dependency>
|
| Remarque |
|---|
Le fait d'utiliser cette dépendance esup-commons permet de rationaliser les différents développements en garantissant que tous les développements utilisentl'utilisation, pour une même version des d'esup-commons donnée, les des mêmes librairies. |
| Remarque | |||||||
|---|---|---|---|---|---|---|---|
Avec la version 0.2 de esup-commons on a constaté qu'il fallait aussi préciser d'utiliser cette dépense explicitement dans le pom.xml de l'application :
Cette dépendance sera ajoutée dans les futures versions de esup-commons2-ws-cxf afin d'éviter au développeur de s'en préoccuper et de perdre du temps à comprendre pourquoi son développement ne fonctionne pas. |
...