1. ez fontos szempont, nem abban a tekintetben, hogy "sok" kliensre szamitok, hanem mert tanulom az EE-t, es szeretnem kiprobalni klaszteren is a kodot? Nagyon nagy pofatlansag lenne a reszemrol, ha megkernelek, hogy reszletezd egy kicsit, miert nem klaszterezheto ekkor az alkalmazas? :))) (nagyon bizonytalan vagyok meg ezen a teruleten. elkepzelem most a stateful bean-eket, amikkel kiszolgalnam a klienseket, esetleg lenne valami egyke POJO, ami meg beekelodne a beanek, es a kliens koze.... Miert veszitenem el ekkor a custer lehetoseget?)

2. Pl egy chatszervert szeretnek EE-n kesziteni. :) Egyebkent nem azt akarok. :)

Az "A" kliensnek, mikozben dolgozik a szerverrel, a munkaja soran fontos lenne, hogy ha "B" kliens hozzanyul az "A" kliens szamara erdekes objektumhoz, akkor arrol "azonnal" ertesuljon, mert befolyassal van a munkajara az adott objektumban bekovetkezo valtozas. Egyszerre dolgozna az adott objektumon (persze most nem a JAVA nyelv objektumara gondolok), annak egyik reszen az egyik kliens, masik reszen a masik, de "latniuk" kell real time egymas munkajat

(Azt saccolom, par masodperce keslekedes belefer, de pl egyperces mar nem)

3. vastag kliensek lesznek. Teljes a kod a tulterheleses problemaval kapcsolatban. Nem tudom ezt hogyan kellne kezelnem, de webkontener - azt gondolom - nem lesz a rendszerben.

"A lényeg a lényeg: ilyen megoldást akkor érdemes választani"

Az a baj, hogy van itt egy kenyszer. Realtime kozeli kliensoldali frissules. Szoval a klienseknek "azonnal" latniuk kell a szerveren tortent valtozast.