Discussion :

[galyathee]

Bonjour,
je me retrouve aujourd'hui à développer des web services dont la logique devrait clairement être pris en charge par un module particulier (parsing de fichiers de plusieurs Mb, appel à différentes bibliothèques et modules d'autres projets, etc...). Je me suis donc dis qu'un WS en tant que point d'entrée d'un traitement devrait être capable d'accéder à des resources externes. Pour le moment la seule solution que je connaisse est que le WS dépose un fichier dans un dossier visé par un CRON, ou alors passe tous ses paramètres par socket à un autre programme.

Mon problème c'est que je me doute qu'une solution élégante facon Delegate doit exister pour ce genre de traitements.

Pourriez-vous me mettre sur la voie ?

[Pour plus de précisions: Mes web services sont des RestFull services déployés dans Tomcat avec Jersey. Ils auraient besoin d'accéder à la logique métier d'un composant externe à Tomcat en définitive]

Merci !

[galyathee]

[Re] je ferme ce post. J'ai adopté la solution d'un Delegate avec JMS. Les WS sont déployés en RestFull avec Jersey sous Tomcat. Les services utilisent 2 modèles:
[1] Si le client propose un système de notifications le WS se contente de transmettre la notification dans un Topic JMS
[2] Si le client ne propose pas de système de notification le WS transmet le contenu des paramètres dans un Topic JMS.

Le but atteint est que le WS se contente de relayer les informations et ne porte en rien la logique métier du service qui est implémentée dans un ensemble de composants externes.

Si le service doit délivrer une réponse synchrone, le WS bloque sur une queue privée de message et relaie la réponse recue.

Si le service peut délivrer une réponse asynchrone, un client de WS implémentant l'interface JMSListener inscrit sur un Topic dédié se chargera de relayer la réponse recue.

[DON_VITO]

Permets-moi de solliciter ton opinion sur cette discussion que tu as eu le soin de fermer
moi aussi je suis presque dans le même contexte, un business delegate qui orchestre l'appel de plusieurs web service par plusieurs clients, le BD doit récupérer l'id et la version du service que le client souhaite appeler , ensuite il localise le service et il lui fait appel pour ensuite retourner le résultat au client.
NB; c'est la première fois que suis confronté à ce genre de développement avec cette architecture séduisante, ça fait un bout de temps que je n’ai pas développé en java .juste cobol.

[galyathee]

Permets-moi de solliciter ton opinion sur cette discussion que tu as eu le soin de fermer
moi aussi je suis presque dans le même contexte, un business delegate qui orchestre l'appel de plusieurs web service par plusieurs clients, le BD doit récupérer l'id et la version du service que le client souhaite appeler , ensuite il localise le service et il lui fait appel pour ensuite retourner le résultat au client.
NB; c'est la première fois que suis confronté à ce genre de développement avec cette architecture séduisante, ça fait un bout de temps que je n’ai pas développé en java .juste cobol.

Bonjour,

ce que tu décris est en effet un Business Delegate. Je ne vois cependant pas où se trouve ton souci. Le problème que j'expose est le cas où le retour d'un service doit traiter des Mb de données et je ne souhaite pas que le service effecue cela pour des raisons de blocage de rôle (le service n'est pas habilité pour cela, et de ressources : inutile de bloquer un thread sur tomcat pour effectuer ce travail).

J'imagine donc dans ton cas que tu dois livrer en retour ces fameux Mb traités par ton service ? Si c'est le cas, alors décrivons le:

Le BD est un simple point d'entrée, un service à tout faire qui:
[1] recoit un appel avec des critères de sélection, dans ton cas un ID et un VNUM de service disons.
[2] Muni de ces informations, le service doit faire en sorte qu'un service soit appelé. C'est donc ici que commencent les problèmes à résourdre:
[2.1] Le BD peut-il poster ces informations dans un Topic JMS ?
[2.2] Quels sont les enchaînements de service qui se succèdent avant d'arriver au service traitant final (ca fonctionne comme un décorateur: un appel de service est transmis à des relais disons r1 (vérifie la provenance de l'appel), r2 (ajoute des infos de sécurité), r3 (attribue une priorité d'exécution) ... donc au final, c'est le principe du BD, il peut y avoir N couches entre le point d'entrée et le service en question à l'aller ... mais aussi au retour. C'est donc quelque chose de primordial à fixer dès le début. Je considère par la suite le cas simple: le BD poste les infos dans un Topic JMS et raccroche (il est donc dispo pour recevoir d'autres appels).
[3] Un "Durable Subscriber" recoit les infos du Topic et les transmet à un Composant chargé de lire ID et VNUM. Il doit donc avec cela sélectionner le service à appeler. Prenons le cas le plus simple, une bête fonction de if ... then se charge de sélectionner le service.
[4] Le service appelé fait d'autres appels de service et au final se retrouve avec 10 Mb de selects en base ou de XML à livrer au client qui a appelé le service. Oui mais, pour des raisons d'efficacité, le service a raccroché depuis longtemps ...

Il y a ici 1000 facons (un peu moins si cela se trouve!) de procéder, j'en fournis une qui fonctionne très bien : le client qui appelle le service va fournir son identifiant au BD. Et le service de [4] va se charger de créer une Queue temporaire de message qui portera un nom composé des infos que le client a fourni.

De son côté, le client qui a effectué l'appel de service enregistre que l'appel a été effectué et va lancer un processus chargé de bloquer sur une queue de message dont il connait déjà le nom (c'est le cas le plus simple je le rappelle). Disons que la Queue JMS, pour les infos fournies CLIENT_ID, SERVICE_ID, SERVICE_V aura le nom: Q.CLIENT_ID.SERVICE_ID.SERVICE_V

Donc la solution que je propose ici est un mode asynchrone où le client et le serveur utilisent JMS et où le client et le serveur connaissent par avance le nom de la Queue de message qui sera créée au final.

Une telle solution fonctionne bien. Un mécanisme de "Timeout" devrait être prévue de manière à ce que le client n'attende plus de réponse au bout de disons 10 minutes, histoire de vaquer à d'autres occupations.

Le BD est simplement un moyen de découpler et de décorer un appel de service. Il y a cependant des contraintes de temps et de sécurité à ne pas négliger ...

J'espère que cette réponse "au hasard" répondra peu ou prou à ta question

[DON_VITO]

Merci de votre réponse.
J'ai effectué quelques recherches sur la toile, je commence à comprendre le principe.
Ce que j'aimerais savoir est:

• Est ce obligatoire d'utiliser les EJBs pour arriver à cette finalité.
• Quelle est l'approche la plus facile pour le faire (J'ai constaté que beaucoup de personnes utilisent un système de cache)
• Serait ce facile pour des services web implémenter avec l'approche BOTTOM-UP (des classes POJO exposées comme web services)

Et merci d'avance pour ton aide précieuse