Introduction

Depuis plusieurs années, l’utilisation des architectures REST n’a cessé de se développer.
Porté par l’explosion du développement sur plateformes mobiles et l’utilisation d’API, le « REST » présente en effet de nombreux avantages :

• implémentation des ressources rapide (notamment grâce à l’utilisation d’URIs et d’objet au format JSON)
• flexibilité à l’utilisation grâce à un découpage fin des ressources.
• facilité d’usage grâce au protocole HTTP et aux verboses associés (GET, PUT, POST, DELETE, OPTION…)
• faible couplage entre le serveur et les clients.
• …

C’est donc sans grande surprise que la version 12C de la SOA se voit dotée d’un nouvel adapteur REST.
Celui-ci permet à la fois d’invoquer des services « REST » mais également d’en exposer dans différents formats, dont bien entendu le JSON.
L’utilisation native de ce format est facilitée par l’utilisation d’un assistant permettant de décrire le format désiré grâce à l’utilisation d’un fichier de représentation « NXSD ».

Cas pratique

Dans un premier temps, nous allons voir comment invoquer un service REST au format JSON.
L’exposition d’un service de même type fera l’objet d’une seconde partie.

Invocation d’un service REST au format JSON

L’objectif ici est d’invoquer un service REST (format JSON) de sélection de client en partant d’un appel HTTP SOAP.

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Remarque : Pour les besoins du test, j’ai réalisé un bouchon REST à l’aide de l’outil « SOAPUI« , ce qui me permettra de simuler le « service REST » à invoquer.
1 – Nous créons un projet SOA nommé « ProjetClient ». Ce projet expose un service SOAP basé sur un WSDL qui propose une opération « SelectionClient » à partir d’un identifiant client et qui renvoie les informations complètes de celui-ci. Nous y ajoutons ensuite un connecteur REST en tant que « External Reference ».

 
2 – A l’aide de l’assistant, nous allons configurer notre connecteur de sortie REST. Celui-ci va nous permettre des décrire le service REST et générera entre autre le WADL associé.
Nous choisissons un nom pour le connecteur « Client_REST » et nous cochons la case « Reference will be invoked by components using WSDL interfaces ». Cette option nous permettra par la suite de définir le format des données et de générer un WSDL associé au service REST.
Puis nous définisson le « host », le « port » et le « chemin » de la ressource que nous souhaitons utiliser, dans notre cas : http://localhost:8099/client


Toujours à l’aide de l’assistant, nous définissons les opérations et les paramètres du service REST. Ici, une opération « SelectionClient » qui utilise le « HTTP verb » « GET ».
Remarque : Il est également possible de fournir directement une WADL qui est une représentation du service REST. 

La requête est constituée d’un paramètre de type « string », l’IdClient.
Pour la réponse, nous allons définir un format d’interchange JSON en cliquant sur la « roue » à coté de « Schema URL ». Un nouvel assistant s’ouvre alors et va nous permettre de définir le format qui nous servira à communiquer avec le service REST.

Nous sélectionnons donc « JSON interchange format ». Ceci permettra par la suite au connecteur de transformer le JSON directement en XML et facilitera ainsi la manipulation des données.

Nous fournissons un exemple de message JSON attendu en retour afin de générer le « XSD » »associé.

Nous poursuivons les étapes suivantes pour compléter la création du connecteur. Nous le relions au BPEL et obtenons la configuration ci-dessous.

3 – Dans le BPEL, nous pouvons désormais invoquer le « Client_REST », assigner le paramètre d’entrée (IdClient) et récupérer les paramètres de sortie. Grâce à l’utilisation du format d’interchange défini précédemment, le mapping (JSON<=>XML) se fait de façon transparente comme lors d’un mapping (XML<=>XML).




 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
4- Une fois le projet déployé sur le serveur, nous le testons depuis l’Enterprise Manager (EM) en démarrant préalablement le « bouchon » SOAPUI évoqué plus haut.
Ceci nous permet de visualiser le détail de l’exécution. Nous voyons bien que la requête comme la réponse ont été transmises au format XML vers et depuis le connecteur REST.


 

Conclusion

En conclusion de cette première partie, nous pouvons constater que ce nouveau connecteur remplit bien son rôle.
Tout du moins dans un cas d’utilisation simple :

• La prise en main est plutôt facile et intuitive.
• L’utilisation d’un format d’interchange permet désormais la manipulation des données « JSON » de façon native et rapide. Ce qui n’était pas le cas dans les versions précédentes.