Discussion :

[mavric.fr]

Bonjour à tous,
Dans le cadre de la refonte d'une application en 3 tiers, je suis en charge de son découpage en 3 EAR (Pres, services, persistance).
Je n'ai pas fait ca depuis des années et je suis un peu rouillé.
Je souhaiterais utiliser spring couplé à du JNDI url pour ce découpage.
Mais il y a tellement de techno que l'on peut utiliser pour la communication entre EAR que je suis un peu perdu.

J'ai jeté un coup d'oeil a Spring Remote et tous les protocoles associé, sans réellement savoir le quel choisir.

Avant j'utilisais des EJB avec du RMI mais c'était vraiment la galère a configurer.

Es ce que EJB 3 vaut le coup? peut on facilement l'utilisé avec Spring (surement :p).
Auriez vous quelques conseil, exemples a me donner pour m'aider dans ce découpage.

Ps: Je travail dans un environnement IBM, avec RAD7.5 en IDE, et WAS 7 comme SA.

Merci d'avance

Cordialement

[alexismp]

Si Spring est la solution, quel est le véritable problème à résoudre?
Pourquoi 3 EAR et pas un seul?

[mavric.fr]

Salut,
Alors pour répondre à ta question, mon veritable problème, comme indiqué dans mon premier post, c'est que je ne sais pas quoi choisir comme techno.

J'ai éliminé les webservices et les ejb.

Parcontre je penchais sur du http remote. Mais je suis à la recherche de conseil, genre pourquoi c'est mieux d'utilisé cette techno plutot qu'une autre. Bref avoir l'avis d'intégrateur JEE qui ont déjà mis en place ce genre d’architecture logiciel.

Pour le pourquoi du comment des 3 ear, parce que chaque partie (pres, metier, persistance) sera hébergée sur des serveurs physique différents, avec chacun son SA, dans des réseaux protégés.

[alexismp]

J'ai éliminé les webservices et les ejb.

Pourquoi? Même commentaire que pour Spring, quel est le problème à résoudre?

Pour le pourquoi du comment des 3 ear, parce que chaque partie (pres, metier, persistance) sera hébergée sur des serveurs physique différents, avec chacun son SA, dans des réseaux protégés.

Soit ce sont des services distincts et les web services (SOAP ou REST) seraient adaptés, soit c'est une seule application et la répartir sur des machines séparer revient à se priver de toutes les optimisations proposées par des AS modernes.

[mavric.fr]

Pourquoi? Même commentaire que pour Spring, quel est le problème à résoudre?

Hum mon problème à résoudre c'est comment faire communiquer les diverses couches de mon application. Spring ne sert ici au final que pour le SOA. Je pourrais très bien coder des classes dédier a l'exposition de mes diverses interfaces. Mais spring le fait très bien et mon application utilise déjà Spring.
Ce qui me reste a faire c'est choisir la techno pour l'exposition distante des mes interfaces, et il y a du choix, beaucoup trop même.
-RMI
-Http invok
-Hessian/Burlap
-Jax rpc
-JMS
-etc...

Bref quand on a pas fait ca depuis des années, il est pas évident de faire un choix.

Soit ce sont des services distincts et les web services (SOAP ou REST) seraient adaptés, soit c'est une seule application et la répartir sur des machines séparer revient à se priver de toutes les optimisations proposées par des AS modernes.

Analyse pertinente mais incomplète.
J'ai bien pour le moment une seule application, mais demain j'en aurais deux, puis 3, etc.
Et pour chaque application, on aura un EAR de front (présentation, Web services, etc) et un EAR metier ( qui contiendra le metier specifique à l'application).
Mais toutes ces applications seront dans notre SI, et donc auront une couche métier commune. Cette couche métier commune, ainsi que la persistance seront dans le même EAR.
Avec cette architecture, on est completement modulaire et sécurisé.
On peut débrancher n'importe quelle application sans impacter les autres.

Qui plus est les serveurs websphere sont très bien optimisé pour travailler comme ca.