Vita:Session bean
A HupWiki-ből...
Írtam egy két kommentet a lapba, valamint kiegészítettem néhány dolgot, ahol a vagy az iromány (vagy az irójának ismeretei) hiányosak voltak.
Aki eredetileg írta, javítsa ki az irományát annak figyelembe vételével.
Finrod írta: - Ezt az utolsó bekezdést szerintem gondold át, mert a Session bean-eket tipikusan szerver oldali komponensnek tekinti a szakma, ahova az ember üzleti logikát pakol. Lásd az entity-bean-ekhez írt megjegyzésemet.
Én átgondoltam és lenne egy kérdésem: Egy szerveroldali ,,valami" (objektum, alkalmazás) nem lehet kliens? Vegyünk például egy servletet. Szerveroldalon van, mégis elképzelhető olyan alkalmazás, amelynek részeként egyben kliens is. Például servleten és Swing-es kliensen keresztül is elérhető ua. az üzleti logika stb. Egy browseres usernek a servlet szerver oldalon fut, míg a servlet által használt Session Bean felől nézve a servlet ugyanolyan kliens, mint egy hagyományos GUI alkalmazás - a session bean-t nem fogja érdekelni, hogy ki hívogatja a metódusait. Ha pedig a web service-ek csodás világa felé tekintünk, akkor már igazán látható, hogy a hagyományos kliens-szerver szemlélet nem olyan egyértelműen alkalmazható.
Tehát egy kicsit meg tudom érteni Credo nézőpontját ill. bele tudtam helyezkedni ebbe a pontba. Aztán majd ő elmondja - talán -, hogy pontosan mire is gondolt.
Megj.: Más kérdés, hogy ehhez a J2EE témához nem igazán értek, tehát lehet hogy baromságokat firkáltam ide.
Ben
Szia Ben,
Ha megnezed, te is nagyjabol ugyanarra jutottal, amit en mondtam: miszerint a Session bean jellemzoen uzleti logikat futtat, ezert jellemzoen nem kliens, hanem szerepu komponens.
A servletekrol en egy szot sem ejtettem vegig. Ketsegtelen, az uzleti logika szempontjabol a servletek jellemzoen kliens szerepuek. Ennek fo oka az, hogy uzleti logikat relative veszelyes obelejuk elhelyezni, mivel a tranzakciokezeles nem annyira kenyelmesen biztositott, mint a session bean-ekben.
(Ez szintén egy hiba volt a session bean-ekre vonatkozó állítások között, mivel az entity lapon úgy állította be a session bean-eket, mintha nem vennének részt a tranzakcióban, ami kapitális baromság, már elnézést a kifejezésért.)
Mint említettem is, maga a kliens-szerver szemlélet szerintem hibás egy többrétegű alkalmazásnál, hiszen itt a kliens és szerver pozíciók relatívak, egy komponens vagy tier egy nézőpontban kliens, más nézőpontban szerver szerepű, pl. Böngésző - Servlet - Session Bean - Workflow [ - Session bean ] - Entity Bean láncolat esetén látszik mire gondolok (és ez egy valós példa volt).
Az viszont minden helyzetben igaz, hogy az Entity bean-ek jellemzően nem szerver hanem erőforrás szerepben állnak a session bean-ekhez képest, amennyiben csak adatperzisztálásra használjuk őket. A szerver funkcionalitás ugyanis szerintem önmagában foglalja azt, hogy a szerver valamilyen logikával leírt funkciót, funkciósorozatot hajt végre. Az Entity bean-ekre szerintem nem jellemző, de ezen állításra inkább filozófiai okaim vannak, leginkább az, hogy az Entity bean-ekre tipikusan csak úgy tekintünk általában, mint egy módra ahhoz, hogy az adatbázist elérjük, és a tényleges megszólított komponens az adatbázis, az entity bean ekkor pedig csak a kapcsolati contract része, és úgy tekinthető, mint paraméter.
Kivétel az említett dolog alól, amikor az Entity beant speciális tulajdonságai miatt logikai ill. vezérlési feladatokra használjuk, mint pl. Workflow processzeknek.
-- Finrod
Hello Finrod,
Persze, servlet-ekrol nem ejtettel szot, en csak peldanak hoztam fel oket. BMP Entity Bean-ek eseten a SELECT, INSERT, UPDATE vegrehajtasa JDBC-n keresztul miert nem tekintheto funcionak (meg ha igen primitiv is). Bizonyara van valami funcioja az Entity Bean-eknek, kulonben kihagytak volna oket - vagy nem.
Egy Session Bean pedig, ha uzleti logikat hajt vegre ugyanugy tekintheto parameternek - ahogy te tekintetted parameternek az Entity Bean-eket. Miert ne lehetne az uzleti logika is parameter egy almalmazasban. Hm? X cegnel igy kell mukodnie, Y cegnel meg amugy.
Te magad is emlitetted, hogy n-tier eseten relativ (nezopont kerdese), hogy mi
micsoda. Igy a te szavaiddal elve:
,,Ha megnezed, te is nagyjabol ugyanarra jutottal, amit en mondtam." :-)
Ben
Hello Finrod,
Szerinted miert kenyelmes session bean-ekbol a tranzakciokezeles? Nekem az a sejtesem, hogy ez nem a session bean-ek erdeme. Tehat servlet-ekbol is ugyanolyan kenyelmes lehet a tranzakciokezeles - velemenyem szerint.
Szerintem az uzleti logikat nem azert veszelyes servlet-be helyezni, mert szivas lesz a tranzakcikezeles miatt, hanem a hozzaferes modja igen specifikus lesz - HTTP-n keresztul. Bar webservice-kre gondolva ez megsem olyan nagy problema. Tehat nem csak a bongeszo marad, hanem nyugodtan lehet hozza epiteni jo oreg Swing-es GUI-kat is. Vagy nem csak Java alapu alkalmazasokat, hanem barmilyen mas nyelven is lehet klienst krealni egy servlet-hez.
Ben
Hello Ben!
Van egy hatalmas kulonbseg a Session Bean-ek es a Servlet-ek kozott. Megpedig az EJB-k deklarativ tranzakciokezelese. Csak megadod a megfelelo attributumot az EJB descriptorban (vagy a megfelelo XDoclet tag-et a session bean osztalyban), es a kontener lekezeli neked a tranzakciot. A servletek-nel ilyesmi nincs es soha nem is lesz, mivel azok nem erre valok. Ezert mondtam, hogy a tranzakciokezeles a session beaneknel sokkal egyszerubb.
Session beanhez is lehet barmilyen mas nyelven klienst krealni. A RMI-over-IIOP is defacto szabvany lett mara.
Session bean mint parameter: ez azert nem igazan stimmel, mivel a session bean onmagaban nem hordoz perzisztalhato erteket, sot mas komponens szamara sem bir feldolgozhato ertekkel (az erteket nem mint hasznot hanem mint olyan dolgot ertem, amin muveletet tudsz vegezni). Ha session bean-t mint parametert ohajtasz hasznalni, azt tipikusan erdemesebb inkabb command objektumokkal elkovetni.
Az entity bean igen. Alapvetoen azert hoztam fel az entity bean mint parameter szemleletet, hogy jobban ertheto perspektivaba helyezze az entity beanek celszeru hasznalatat, ami szinten nem a BMP hanem a CMP2.0 a kontener altal tamogatott egyeb szolgaltatasok miatt (pl. EJB-QL is macerasan, ha egyaltalan mukodik BMP entity-k eseten). Viszont ebben az esetben gyakorlatilag minimalis logika kerul az entity-kbe, mivel a getter setter metodusok a kontener altal implementaltak.
Finrod
