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

[*alexandre*]

renome ton bean id="highAvailabilityBean"
en bean id="highAvailabilityService"

[cyrille37]

"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

Salut Alexandre.
Je ne sais pas si tu as bien compris mon besoin qui n'est pas fourni par Spring: "L'équilibrage de charge / Load Balancing".

je suis donc à la recherche de toute les idées et moyens pour fournir du Load Balancing dnas les communications distantes entre Beans, et sans utiliser un Serveur d'Application.

[*alexandre*]

apres relecture j ai bien compris lol

j ai trouvé ca qui m a l air intéressant
http://www.springframework.org/docs/...terceptor.html

edit encore mieux

http://www.springframework.org/docs/.../remoting.html

un vieux thread http://www.developpez.net/forums/arc...p/t-23334.html

[cyrille37]

apres relecture j ai bien compris lol
j ai trouvé ca qui m a l air intéressant
http://www.springframework.org/docs/...terceptor.html
edit encore mieux
http://www.springframework.org/docs/.../remoting.html
un vieux thread http://www.developpez.net/forums/arc...p/t-23334.html

Merci monsieur, mais je connais ces pages. Elles traitent du Remoting "Standard" et il n'y a rien à propos de Load Balancing.

Merci en tout cas pour ton aide. Tu arriveras peut être à trouver une piste ...

[*alexandre*]

Merci monsieur, mais je connais ces pages. Elles traitent du Remoting "Standard" et il n'y a rien à propos de Load Balancing.

Merci en tout cas pour ton aide. Tu arriveras peut être à trouver une piste ...

j hésitais à éditer pour préciser que ca ne parlait que du remoting

[*alexandre*]

a premiere vue si tu utilises le remoting via Http tu peux utilisé le load balancing de tomcat

It really comes down to where you want to do your load balancing.

You could write a Java-based distributor to do it, maintaining a list of target beans on different servers and their current load, bouncing long-running requests through to each.

Or you could use a load balancer (as Olivier suggested) which does the same thing, but instead of at a Java level it works at the HTTP level. Load balancers can distribute traffic in various configuration patterns based on round-robbin and even based on individual server load. They tend to offer quite sophisticated options as well, such as the target server being able to work at the MAC address level and respond directly to the client rather than directing the response back through the load balancer. Load balancers are a mature technology backed by a lot of R&D and real-world deployments. To give you some idea, see "Three Ways to Load Balance" at http://www.linux-mag.com/2003-11/clusters_01.html.

The nice thing about a dedicated load balancer is you don't have to write it. A Java-based distributor will be time-consuming as you need to poll target beans (to determine their present load/availability) or otherwise track the volume of outstanding requests for each target bean. For all the effort, it will probably be comparatively inefficient unless you spend lots of engineering time. It really isn't the sort of thing you want to be developing if a standard load balancer will meet your needs. Of course many application servers will load balance for you, but then you're adding a layer of software and typically RMI which would probably still not be as efficient as the web services clients being directed by a proper load balancer at a nice low OSI layer to an available web container.

[cyrille37]

a premiere vue si tu utilises le remoting via Http tu peux utilisé le load balancing de tomcat

C'est une piste que je dois étudier.
En plus si j'utilise un protocol léger sur http comme REST les performances ne devraient pas être trop mauvaises.

Merci
cyrille

[cyrille37]

Bonjour,

Je viens aux nouvelles sur le sujet. Est-ce que certains de vous ont ils eu besoin d'équilibrage de charge pour leur bean gérés avec Spring ?
Ce ne semble pas être un sujet très courru, ce qui m'étonne car en réponse à la montée en charge d'une application l'équilibrage de charge devient nécessaire. Il y a bien sûr la possibilité de passer à un Serveur d'Application, mais j'aimerai tant rester sur une architecture Tomcat + Spring.

Merci pour vos éventuelles nouvelles fraîches ;-)
Cyrille.

[fr1man]

Je suis loin de maitriser le sujet, mais il me semble qu'on avait fait ça sur un projet.
En fait l'équilibrage de charge se faisait au niveau du serveur web, qui redirigeait les requêtes vers le serveur d'application le moins chargé.
(il y avait deux serveurs d'applications)
Je crois que la répartition se faisait matériellement mais il doit exister la même chose au niveau logiciel.
J'espère ne pas avoir été à côté de la plaque.

[cyrille37]

Merci de ta contribution ... un peu vague ... comme ça je me sens moins seul

Merci à toi
cyrille

[fr1man]

Tout ça pour dire que j'aurais cherché plutôt du côté du serveur web ou d'appli et non pas du côté de Spring.
La répartition de charge se fait au niveau des serveurs.
Je ne vois pas comment tu veux le gérer au niveau de tes beans.
Je n'ai peut-être pas compris exactement ce que tu voulais.

[cyrille37]

En fait certains beans ont besoin de beaucoup de CPU pour des calculs assez lourds. Je souhaite donc les hébergés sur un ensemblesde machines dédiées à ces beans gourmands.

mais peut être que ta réopnse contient effectivement la réponse. Si j'utilise un remoting over http pour accéder à ces fameux beans, je pourrai peut être bénéficier d'une de load balancing http existante.

je vais y réfléchir. Est-ce que mon besoin est plus clair ? Quel est ton avis ?

[mat360]

Salut,

Je ne comprends pas très bien ce que vient faire Spring dans ton problème de load balancing et de DMZ.
Je suis loin d'être un expert des deux sujets mais la résolution classique que j'en ai vu est la suivante:
- load balancing: installer en frontal un load balancer devant 2 serveurs web qui dispatchent vers des serveurs d'appli ou avoir un serveur web dispatchant vers 2 serveurs d'application derrière
- DMZ: configurer les firewalls entre tes serveurs web et serveurs d'appli pour qu'ils ne laissent passer que les appels des IP de tes serveurs web

Je pense que tu es un peu embrouillé par le découpage logiciel de ton appli. Tes problèmes de load balancing et DMZ nécessitent que tu réflechisses sur ton archi physique.
Après, je crois qu'il existe aussi des solutions plus logicielles au problème de load mais je ne les connais pas.

[nicØB]

Salut,

Pour les DMZ, comme le dit mat360, c'est avec les firewall que ça se passe.

Concernant le load balancing, il y a différentes méthodes.
J'en ai besoin pour ce que je développe en ce moment et c'est le "frontend" serveur qui s'occupe de ça avec un algo Round Robin (qui est très simple).