Proxy web Services

Bonjour,

J'ai besoin d'aide concernant l'architecture d'une application qui doit s'interposer entre un client et un serveur et qui est capable de réceptionner des requêtes SOAP et REST.

Tout d'abord, ce que l'application a pour objectif :
- Via requête Rest : Déclencher ensemble de traitement python.
- Via requête SOAP : Forwarder le message au service web approprié selon table de routage définie.

Tout ceci doit être supervisé.

Questions :
1) Peut-on envoyer une requête SOAP sur une url qui ne correspond pas à un point d'entrée d'un WS ?
2) Comment gérer la performance et non bloquant ?

Donc voilà, par quoi commencer ?

J'ai déjà implémenté un début qui me parait pas propre, pour le rest j'ai un web service Rest et pour le soap j'ai un faux endpoint devant lequel je place un filtre qui va déléguer le forward à un composant interne dans un thread.

Peut-être devrais je regarder vers JMS ?

Merci d'avance pour votre aide.

Plop,

Si tu comptes passer par JMS, c'est que tu n'es pas obligé d'utiliser REST et SOAP je présume. Si oui, tu devrais surtout n'utiliser qu'une seule technologie pour ce genre de choses, la plus simple étant REST.

Citation:

---

Peut-on envoyer une requête SOAP sur une url qui ne correspond pas à un point d'entrée d'un WS ?

---

Normalement oui, mais tu risques d'avoir une erreur plus qu'autre chose. Si tu fais une requête HTTP sur une adresse inexistante, tu n'as pas grand chose, bien que tu puisses le faire.

Citation:

---

Comment gérer la performance et non bloquant ?

---

C'est à toi d'utiliser un système asynchrone, pour le non bloquant. Maintenant pour la performance, évite de base d'utiliser des protocoles de haut niveau (comme HTTP) quand tu peux utiliser TCP / UDP. Tu traverses des couches en moins.

Citation:

---

Peut-être devrais je regarder vers JMS ?

---

Pourquoi pas. Mais l'avantage d'un service REST est l'intéropérabilité (bien que ce soit vrai avec AMPQ), mais surtout la simplicité. Personnellement je ferai du pur REST, qui est très simple à utiliser en JEE.

Merci pour ta réponse.

Alors effectivement, regarder du côté de JMS était pas vraiment pertinent puisqu'il me faut réceptionner des requêtes soap et rest.

Alors, du coup j'ai créé un servlet dans le cas de la requête SOAP qui va appeler une EJB Session stateful, de manière à garder un contexte en mémoire pour les échanges avec ce client.

Je pourrais également en faire de même avec la requête quoi doit être passé par url en surchargant doGet de la servlet.

Mais, n'est il pas judicieux de tout implémenter en REST ?

Et questions :

Rest et EJB font ils bon ménage ?
Les servlets 3.0 permettent le lancement asynchrone, en est il de même avec le REST ?

Merci

PS : Sachant que dans un cas, je dois garder un certain contexte avec le client donc REST est il adapté sachant qu'il est stateless ?
Je m'y perd un peu avec tout ça !

Citation:

---

Mais, n'est il pas judicieux de tout implémenter en REST ?

---

Si le SOAP ne peut pas être modifié, tu dois t'y plier et offrir un endpoint. Par contre pour le reste tu peux tout faire en REST.

Citation:

---

Rest et EJB font ils bon ménage ?

---

Pourquoi pas. Tout dépend de ce que tu compte faire. Si tu dois déléguer un traitement à un service précis, il vaut peut-être mieux séparer le tout et utiliser des EJBs. S'il s'agit de faire un traitement simple, alors tu peux le faire dans la couche REST.

Citation:

---

Les servlets 3.0 permettent le lancement asynchrone, en est il de même avec le REST ?

---

En fait, quand je parle de REST, je parle de l'API JAX-RS. Derrière JAX-RS, c'est de la pur Servlet. Tu peux récupérer des informations comme HttpServletRequest etc...
Donc tu peux utiliser le lancement asynchrone des Servlets. Certaines implémentations de JAX-RS proposent leurs propres mécanismes pour l'asynchrone, comme JBoss RESTEasy (documentation). Maintenant, n'oublie pas qu'il y a un pool de connexions pour chaque serveur.

Alors en fait, l'idée est de fournir un service REST pour réception des requêtes SOAP et REST.
C'est via le service REST que je vais ensuite forwarder ma requête SOAP ou alors exécuter un traitement de lancement de batchs.

Donc du coup, je vais implémenter un REST avec gestion de cookie puisque dans le cas où je récupère une requête SOAP, je dois garder un certain oeil sur la conversation client/serveur.

Et donc, je ne suis plus sur de l'utilité de l'EJB.