Discussion :

[mauvais_karma]

Bonjour a tous
J'étudie actuelement la migration d'une plateforme ASP Application Service Provider, orientée vers l'échange de documents.

L'architecture est celle ci: une servlet JAXMServlet à l'écoute des requetes SOAP qu'elle transmet par TCP/IPà un "router" qui l'analyse puis recrée la requete SOAP vers un "module" qui contient la fonction à executer, ...
Chaque "module" est donc indépendant, communique par socket, et regroupe des fonctions qui rendent des services communs. Bref une architecture où on réinvente un peu la roue, mais qui marche pas mal(rajouter des fonction est simlple, de meme que creer de nouveaux modules)

Les problemes:
1- actuelement sous Tomcat4.1, on plante occsionlement avec OutOfMemory... et on est tenté de passer à un AS (genre JBoss ou Jonas)
2 - impossible de monitorer finement le comportement des modules 'à part les log,...)
3- plantage dans l'échange de gros doc (réglé par plusieurs requetes)

Mes objectifs:
1- passer d'une servlet perso vers un JAX-RPC Runtime, genre servlet Axis (à moins que vous n'ayez d'autres suggestions!), pour éviter de construire/parser manuelement les requetes
2- passer de JAXM-SAAJ vers JAX-RPC-SAAJ, pour faire de vrais WebServices
3- coté serveur, suuprimer les transmissions de SOAP
4- choisir un endpoint pour ses WS (EJB ou classes standard)

Mes observations:
1- passer à un modele de composant EJB semble assez tentant, tant les "modules" ressemblent à des SessionBean
2- pratiquement pas d'objets métiers actuelement, de + toutes les requetes à la base de données se font en PL/SQL (pas d'EntityBean, CMP ou JDO en gros)


Mes questions:
J'ai 2 solutions pour les WS endpoint:
1- soit rester dans le contexte d'une appli Web, où j'ai par exemple un WS (et plusieurs méthodes) par module: ensuite ma facade fait appel aux EJB
2- soit ma facade est un EJBSession Stateless qui appel d'autres EJBSession (avec état dans certains cas si c possible???)

=> si la sol1 est possible, je vais sérieusement réfléchir si il est raisonable d'utiliser des EJB

Quand pensez vous? Est ce commun d'utiliser des EJB sans EntityBean?
Merci d'avance.

[ego]

Tu peux faire la solution 1 = des WS et qq chose derrière.
Moi, je ne mettrai pas forcément des EJBs mais des classes Java (POJO) classqiues.
Pour encapsuler ces classes POJO dans des WS, je te recommande de regarder SPRING qui fait cela automatiquement (cf. http://www.springframework.org)
Si tu as besoin de transactionnel, SPRING prend cela en charge aussi

[mauvais_karma]

ok merci
j'ai lu avec interet ton papier sur Spring, très instructif, d'ailleurs je savais pas qu'il faisait de l'AoP...

Par contre, est ce que vous connaissez un moyen de monitorer plus finement une application web et ses objets instanciés (thread, sessions, reseau), avec des graphiques rafraichis... Tomcat5 le fait un peu, peut etre faut il monitorer la JVM?

Sinon, pour en revenir aux EJB, est ce que ce n'est pas incohérent de n'utiliser que des SessionBean (avec ou sans etat) et des ValueObjet dans un projet J2EE. Ou bien est ce que l'usage des EJB n'est justifié que lorque l'on doit manipuler des Entity? J'aurai d'autres questions mais je vais changer de topic!

Je pense que je vais étudier + longuement les 2 solutions, d'autant + que nos objectifs à moyen terme sont de supporter une prochaine montée en charge des services. De plus, le concept des "modules" indépendant doit être conservé au cas ou l'on désire les répartir sur plusieurs machines.

Une dernière pour finir: Axis est il vraiment performant? Est ce un bon point d'entrée (std sous Jonas) ou en existe t'il des mieux (free)?

[mauvais_karma]

A propos de mes facades (1 par service):
Il vaut mieux 1) les intégrer sur l'appli Web, et elle se chargent de faire l'appels aux EJB par JNDI puis récuperer des VO (c + un business delegate)
ou 2) on les integere au conteneur EJB comme SeesionBean et le runtime JAX-RPC s'occupe de les appeler tout seul

Ce dernier cas utilise t'il JNDI?

Rem: je posterai des images ce soir!

[ego]

Pour l'usage des seuls EJB session, je dirai même que c'est la seul utilité réelle des EJBs. Les EJB entity ne sont pas vraiment adaptés à la gestion de la persistance.

Pour revenir à ton problème, est-ce que les WS sont physiquement hébergés par une machine différente de la ou des machines qui hébergent tes "modules" ?
Si elle est et doit être différente, il vaut mieux effectivement utiliser des EJBs Session côté "module" (car il faut faire des appels remote)
Si les "modules" sont physiquement sur la même machine et même AS que tes WS, il n'est absolument pas nécessaire de mettre en oeuvre des EJBs. Avec SPRING, tu peux même créer des classes "POJO" est les encapsuler pour qu'elles soient appelées via JAX-RPC.
Maintenant, pourquoi utilisez-vous des services web ?

[mauvais_karma]

merci ego pour tes réponses
co tu as du t'en rendre compte, je débute sur les EJB (étudiant en stage)
par contre j'ai déja pas mal travaillé sur les WS & wsdl (un peu moins sur soap). Voila pour la ptite histoire;-)

Pour l'instant nous utilisons du SOAP généré par JAXM car notre client lourd doit passer les firewall/proxy. En effet l'utilisation d'un client lourd est obligatoire pour afficher des scènes en 3d...
De plus, on utilise SAAJ pour ajouter des attachements(de qq ko à plusieurs mo)

Sans doute pour des histoire d'"homogénéité", on a su soap de bout en bout de la chaine de com (over http puis tcp). Je trouve que c'est trop lourd, sans vraiment pouvoir le mesurer, surtout qu'il y a 3 intermédiaires entre un client et la fonction du module qui doivent parser puis reconstruire la requete. Tu es certainement d'accord avec moi que c'est inutile, d'autant qu'on injecte pas de valeur ajoutée dans les messages.

J'ai proposé l'utilisation de WS avec WSDL qui doit nous permetre à long terme de proposer l'acces à certains de nos modules par des tiers sans passer par notre client lourd.

Pour l'instant, les modules sont sur la meme machine mais ils peuvent êtres configuré pour s'executer ailleurs sur le reseau vu qu'ils communiquent uniquement par socket. On veut pouvoir garder cette possibilité si on passe avec des composants, mais également passer par une interface Locale.

[ego]

Regardes dans SPRING, il y a une intégration avec Hessian.
Je ne connais pas Hessain mais cela te permet de passer par HTTP et surtout, l'intégration avec SPRING te permet de complètement t'affranchir du marshalling/unmarshalling de la requête

[mauvais_karma]

ok c noté
je bouquine Spring, la doc de reference est bien faite
encore merci

[mauvais_karma]

salut

je remet au gout du jour ce post mais j'aimerai l'orienter sur le endpoint de mes WS.

Est il plus interessant d'avoir:
1) [ servletSoap (Axis) --> business delegate ] ----> [SesionFacade]

ou
2) [ servletSoap (Axis) ] -----> [SesionFacade]

La différence entre les 2 est que dans la 1) mes services sont dans le conteneur Web et je dois coder moi meme les appels à mon EJB Session
alors que dans la 2) mon Session est lui meme le Web Service

Pkoi utiliser la solution en 2 comme le conseil la + part des sites quit traite de EJB2 et des WS?

[ego]

je ne comprend pas ta notion [...] --> !?
Que veux-tu dire avec des 2 solutions ?

La notion de BusinessDelegate est là pour faire de l'adaptation de service / transformation de données et de la gestion d'accès à des services.
Il faut nous dire précisément quel est ton contexte car une solution dans l'absolue n'a pas vraiment de sens

[mauvais_karma]

effectivement c pas tres clair!
en fait les crochets sont des conteneurs [web] et [ejb]
Quant au contexte, c'est un WS d'un coté, un EJB session de l'autre, pour pas trop compliquer.



On a 2 approches concernant les EJB et les WS:
- soit dire j'ai "un WS qui accede à un EJB" (sol 1, appelée "JAXrpc endpoint") --> dans ce cas la, les méthodes de mon WS se trouvent coté serveur web (provider jax-rpc), et j'appel moi meme mon EJB en remote ou en local au choix

- soit dire j'ai "un EJB qui peut être appelé par un WS" (sol2, "appelée ejb enpoint") --> on ecrit dans le descripteur de déploiement que l'EJB est accédé par un WS, est lors du deploiement du WS on précise que le provider est un EJB...

Pour acceder à des ws, si j'uilise la sol1, je peux avoir besoin d'une couche de BusinessDelegate qui se charge d'appeler mon EJB et fait d'eventulles vérifs, + d'autres services que tu a cit"

Avec la sol2, la servlet soap accede directement à mon EJB, et c'est ce que propose EJB2.

perso, je suis pluis tenté par la sol1 mais, si la pécif propose la sol2 c'est qu'il y a bien un interet. Lequel???

[mauvais_karma]

un petit up pour rappeler que je me pose tjs la question sur où placer mon endpoint pour les EJBs et surtout avantages/inconvénients?

je reprend la fin du post précedent:

Pour acceder à des ws, si j'uilise la sol1, je peux avoir besoin d'une couche de BusinessDelegate qui se charge d'appeler mon EJB et fait d'eventulles vérifs, + d'autres services que tu a cit"

Avec la sol2, la servlet soap accede directement à mon EJB, et c'est ce que propose EJB2.

perso, je suis pluis tenté par la sol1 mais, si la pécif propose la sol2 c'est qu'il y a bien un interet. Lequel???

d'autant + que je viens de m'apercevoir que dans le cas d'un EJB endppoint, l'appel se fait par rmi, et pas en local, donc question perf, cela semble équivalent ( sur un forum us, un gars s'avancait à dire 3x -rapide que par le jaxrpc endpoint apres qq tests!?...)

De plus, je dois rajouter une couche de sécurité sur les WS et sur les EJB

[mauvais_karma]

hello, je suis dee retour avec ce post pour apporter ma réflexion:

La question était: est ce qu'il vaut mieux placer le service endpoint directement sur un ejb, ou au niveau du conteneur web (jaxrpc), étant donné que les 2 sont rendus possibles depuis ejb2.1

EJB endpoint:
+ facile à deployer si un ejb en facade existe déja
+ le contexte du message soap est accessible dans l'ejb
+ le contexte de sécurité est propagé automatiquement
- les appels se font sur rmi et pas en local
- on ne peut pas manipuler autres choses que des tableaux en guise de collection

Jaxrpc endpoint:
+ on n'est pas obligé d'utiliser les ejbs, on peut switcher/mixer avec des pojo
+ excellent candidat au "business delegate", permet de gérer un cache par exemple
+ on ne cherche pas à adapter a tout prix l'ejb pour l'exposer en WS: cette adaptation peut etre réalisée ici.
+ on peut choisir d'appeler l'ejb en local ou en remote


Perso, j'ai choisi la dernière méthode...