[JAVA] Stateless session bean of class?

[zneek]

Ik zit me af te vragen: waarom gebruik je een Stateless Session bean ipv een normale Java class?

Stel een simpel voorbeeld:

code:

public class Test{
  
  public int telOp(int getal1, int getal2)
  {
    return getal1+getal2;
  }

}

Niet echt zinnig, maar goed

Waarom zou ik zoiets in een Stateless Session Bean stoppen ipv deze simpele class?

Heeft het met snelheid te maken? Dat de stateless session beans gepooled worden? Of met delen over geclusterde servers met meerdere jvm's?

Ik kon in de search niet veel zinnigs over het waarom vinden. Via Google genoeg voorbeelden om Stateless Session Beans te bouwen, maar uitleg waarom kon ik niet vinden.

[Verwijderd]

omdat je bedrijfslogica over meerdere CMP/BMP's wil spreiden.
Omdat je Remote wil werken (al je bedrijfslogica centraal als blackbox, en de cliënt is véél makkelijker up te daten)
Om gebruik te kunnen maken van de services die de container je standaard levert (transacties, security, ...) zonder een letter code te tikken
omdat .....


er zijn héél wat redenen om een session façade te behouden en daarachter CMP's of Hibernate, je hoeft tenslotte geen CMP's te gebruiken om SessionBeans te maken.

Is natuurlijk wel een mooie discussie om even uit te zoeken wanneer wel en wanneer niet....ik ga dit topic volgen

[zneek]

Jij hebt het nu over CMP/BMP. Ik heb het puur over "platte" logica. Ik gebruik verder EJB CMP. Ik ben nu bezig een FlashRemoting client aan deze applicatie te hangen. Voor zover ik nu weet moet die "platte" objecten aanroepen, of beter gezegd, ik heb het alleen nog maar getest met platte objecten. Er zit ook een EJBInvoker bij, die moet ik nog testen.

Maar ik kwam deze vraag tegen. Waarom ingewikkeld doen met een Home interface, instantie opvragen van de Stateless bean en dan pas een rekenfunctie aanroepen?

Ik heb inmiddels nog wat verder gezocht, en nog steeds geen antwoord gevonden. Het enige wat ik tot nu toe heb is dat in veel gevallen ze uitwisselbaar zijn, maar waarom je expliciet voor de een of de ander kiest is me nog niet duidelijk.

Nog maar eens even de Sun site checken ... alsof ik daar een simpele uitleg ga vinden

[momania]

zneek schreef op 12 januari 2004 @ 23:41:
Maar ik kwam deze vraag tegen. Waarom ingewikkeld doen met een Home interface, instantie opvragen van de Stateless bean en dan pas een rekenfunctie aanroepen?

Kijk, als je er alleen zelf gebruik van gaat maken, dan kan je het overwegen om er geen bean van te maken.

Maar in bedrijven heb je veelal standaarden die bedrijfs breed zijn zoals berekeningen die bedrijfs critisch kunnen zijn. Daarvan wil je niet dat ierdeen z'n eigen implementatie gebruikt en dus wil je dat iedereen een centrale bean gebruikt.

[zneek]

even een kickje.

Is de reden die momania noemt echt de enige? Ombouwen is niet zo'n probleem (zeker wanneer je XDoclet gebruikt), maar ik twijfel nog steeds.

Standaardisering en instance reuse zijn de enige redenen om voor Statelss Bean te gaan ipv een POJO?

[Verwijderd]

zneek schreef op 22 januari 2004 @ 13:23:
Standaardisering en instance reuse zijn de enige redenen om voor Statelss Bean te gaan ipv een POJO?

het updaten van de logica. Stel dat er een bugje in de logica zit, fix je dat in de (stateless) sessionBean, en je hele applicatie moet niet geupdated worden.

Stel, in een zeer speciaal geval heb je een héél stomme fout gemaakt die in JUnit tests niet echt naar voor komt. Ergens wordt een bug gemeld, het probleem wordt in de business logic gevonden en gecorrigeerd. Enkel de session layer aanpassen is héél centraal. Voor elke cliënt een update verzorgen is echter héél wat lastiger. Dus het hangt zeker van je applicatie af.