Discussion :

[cyrille37]

Salut,

J'ai passé les mois précédents à apprendre le monde du Web en Java. Cet apprentissage m'a amené à choisir les outils suivants: Tomcat, Tapestry (framework web) et Spring. Avec cette suite j'arrive à me passer d'un serveur d'application (JBoss, Glassfish...)

J'attaque maintenant la conception de l'architecture d'un projet réèl et il y a un point sur lequel je n'arrive pas à être clair, c'est l'interface entre la couche Web et la couche Application sachant que cette interface doit fournir un équilibrage de charge (load balancing)

Voici où j'en suis:

Web layer: Apache2+mod_jk & Tomcat5 & Spring2 & Tapestry4
Application layer: Tomcat & Spring2
Database layer: Mysql5 Cluster

Je pense que cet ensemble est traditionnel aux utilisateurs de Spring.
Le point noir c'est la communication entre le Web Layer et l'Application Layer.
J'imagine que le connecteur RMI de Spring2 doit être le bon tuyau, mais il n'y a pas à ma connaissance de fonction Load Balancing ?

Alors j'ai trouvé quelques pistes :

L'article "Use a distributed cache to cluster your Spring remoting services" mais il faut ajouter à l'architecture le service Cache de JBoss.

Une autre idée que je n'ai pas encore éclaircie par manque de connaissance serait d'utiliser un Serveur de messages comme ActiveMQ. L'idée serait que le Web Layer poste des messages JMS et que l'Application Layer consomme ces messages.
Est-ce une solution viable ? Serait-ce surdimensionné ?
Comment serait gérés les Session-Beans côté Application Layer ?

Une autre idée ?
Cyrille

[*alexandre*]

je comprend pas trop ce que les applications font dans ta description de l'architecture que tu veux utilisé

je verais plutot

presentation layer : taperstry + spring
business layer : spring + business service
database layer : un ORM de ton choix avec un DAO pour accéder à tes données

un ex : http://wiki.apache.org/tapestry/Tapestry4Spring

le load balancing sera gérer par tomcat spring n a rien à voir la dedans

il me semble que tu compliques un peu !

[cyrille37]

presentation layer : taperstry + spring
business layer : spring + business service
database layer : un ORM de ton choix avec un DAO pour accéder à tes données

C'est exactement ça au niveau des layers, mais au niveau sécurité j'ai la contrainte suivante qui m'est imposée :

Les serveurs exécutants le Presentation Layer doivent être en DMZ tandis que les autres serveur exécutants les Business et Data Layers doivent être dans la zone protégée.

Du coup il me faut un moyen de communiquer entre les Spring's beans du Presentation Layer et les Spring's beans du Business Layer qui gère du Load Balancing.

Si j'utilise la communication Soap (WebService) je devrait (peut être) pouvoir utiliser le Load Balancing de Tomcat côté Business, mais j'aimerais creuser encore afin de trouver un protocol plus léger que Soap.
Je me dis RMI est plus performant mais je ne vois pas de moyen d'équilibrer la charge. je me demande aussi si JMS ne serait pas approprié ?

Je te rassure quand même: Je perds un peu de temps autour de ce sujet que je trouve intellectuellement interressant, mais si aucune solution ne se dessine, je metterais en place des serveurs EJB (Glassfish ou JBoss).

Peut être puis je résumé le sujet ainsi : une communication distante entre Beans qui gère l'équilibrage de charge. Peut être existe-t-il un framework quelque part (ObjectWeb, Sourceforge, ...)

En tout cas, merci pour ta participation à mon "délir"
Cyrille.

[cyrille37]

J'ai trouvé une piste :

FailoverProxyFactoryBean

Il y a le code source que je n'ai pas encore lu mais déjà la déclaration Spring est alléchante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
<bean id="highAvailabilityBean"
class="org.springframework.remoting.support.FailoverProxyFactoryBean">
  <property name="serviceInterface" value="com.x.MyInterface" />
  <property name="serviceBeans">
  <list>
  <!-- service beans are typically proxies to remote services  -->
  <ref bean="primaryServiceProvider"/>
  <ref bean="fallBackServiceProvider"/>
  </list>
  </property>
</bean>

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
public class FailoverProxyFactoryBean
 extends RemoteAccessor
 implements MethodInterceptor, InitializingBean, FactoryBean
 { ...

Encore un concept qui démontre la puissance de Spring. Et qui me motive pour éviter l'utilisation de Conteneur EJB !
Cyrille.

[*alexandre*]

EJB c est de la daube, ca rajoute de la complexité la ou il n y en pas besoin

y a rien d exceptionel dans la déclaration de bean et d injection que tu viens de fournir

je me penche sur DMZ pour voir ce qu il y en a tirer

[*alexandre*]

"communiquer entre les Spring's beans du Presentation Layer et les Spring's beans du Business Layer"

c est le principe meme de l injection, tu n as qu as déclarer dans ton presentation layer un getter / setter sur ton business service