[J2EE] EJB create. Wie is verantwoordelijk?

[Bbfreak]

Ben bezig met een schoolproject aangaande j2ee.
We hebben een bank. Deze heeft een Bank object.
Aan dit bank object wordt nu of een Klant object gevraagd
of een Beheer object. Dit bepaald dus of het een klant is of een beheerder,
van de bank. Dit gebeurd in LoginAction.java.
- Bank.geefBeheerder()
- Bank.geefKlant()
Deze komen dan in een HttpSession object.

Nu is het de bedoeling dat we EJB's gaan toepassen.
Misschien overkill maar het gaat om de techniek.
De Klant en Beheerder hebben een status en worden dus Session Beans.
De Session Beans zijn gemaakt, alleen nu de vraag:
Wie roept die EJB's aan? De LoginAction.java of Bank.java?
De LoginAction zit in de FO en Bank in de BO.
Wat gebeurd er met het HttpSession object? Dit vervalt toch?

Alvast bedankt.

[Verwijderd]

Bank.java, je vraagt vanuit loginAction.java aan Bank.java om een status. Bank.java is zelf verantwoordelijk voor het teruggeven van die status. loginAction.java hoeft/mag helemaal niets weten van statussen, of beans. Die moet alleen reageren. Bank is helemaal verantwoordelijk voorzichzelf.

[ Voor 9% gewijzigd door Verwijderd op 03-01-2005 12:15 ]

[Verwijderd]

Bbfreak schreef op maandag 03 januari 2005 @ 12:05:
Ben bezig met een schoolproject aangaande j2ee.
We hebben een bank. Deze heeft een Bank object.
Aan dit bank object wordt nu of een Klant object gevraagd
of een Beheer object. Dit bepaald dus of het een klant is of een beheerder,
van de bank. Dit gebeurd in LoginAction.java.
- Bank.geefBeheerder()
- Bank.geefKlant()
Deze komen dan in een HttpSession object.

Nu is het de bedoeling dat we EJB's gaan toepassen.
Misschien overkill maar het gaat om de techniek.
De Klant en Beheerder hebben een status en worden dus Session Beans.

Bekijk jij je session beans object georienteerd?
Misschien ben ik fout, maar ik bekijk de session layer op niveau van services. (en voor een webapplicatie zelfs stateless services, maar da's een kwestie van smaak).

De Session Beans zijn gemaakt, alleen nu de vraag:
Wie roept die EJB's aan? De LoginAction.java of Bank.java?
De LoginAction zit in de FO en Bank in de BO.
Wat gebeurd er met het HttpSession object? Dit vervalt toch?

Alvast bedankt.

Je kan ook een realm gebruiken op je servlet container en je users indelen in groepen. (JDBCRealm, LDAPRealm, ...) en niet met Session beans werken. Dan handelt de container de login af...

Ik zou voor klant/beheerder eenzelfde service maken. PersonServiceEJB ofzo, en daar vraag je dan getPerson of getActor ofzoiets. Person is dan een abstracte klasse met naam, unique ID, leeftijd, wat je maar wil weten. En als je dat (value object) in je session stopt heb je een geldige login. Aan te roepen vanuit je loginaction.

als je statefull session beans gebruikt zul je die reference hoogstwaarschijnlijk bijhouden in je httpsession.

FO = presentation layer
BO = business layer
(of heb ik meer uitleg nodig?)

--EDIT--
ofeuhm, heb je maar 1 klant en 1 beheerder voor de hele bank?
Je construeert je bank toch niet adhv de ingelogde persoon? (ik mis de boot vrees'k )

[ Voor 5% gewijzigd door Verwijderd op 03-01-2005 13:58 ]

[Bbfreak]

Verwijderd schreef op maandag 03 januari 2005 @ 13:56:
[...]


Bekijk jij je session beans object georienteerd?
Misschien ben ik fout, maar ik bekijk de session layer op niveau van services. (en voor een webapplicatie zelfs stateless services, maar da's een kwestie van smaak).

Ik denk het wel ja.
Doe ik hier iets fundamenteels fout?

[...]


Je kan ook een realm gebruiken op je servlet container en je users indelen in groepen. (JDBCRealm, LDAPRealm, ...) en niet met Session beans werken. Dan handelt de container de login af...

Ik zou voor klant/beheerder eenzelfde service maken. PersonServiceEJB ofzo, en daar vraag je dan getPerson of getActor ofzoiets. Person is dan een abstracte klasse met naam, unique ID, leeftijd, wat je maar wil weten. En als je dat (value object) in je session stopt heb je een geldige login. Aan te roepen vanuit je loginaction.

als je statefull session beans gebruikt zul je die reference hoogstwaarschijnlijk bijhouden in je httpsession.

FO = presentation layer
BO = business layer
(of heb ik meer uitleg nodig?)

--EDIT--
ofeuhm, heb je maar 1 klant en 1 beheerder voor de hele bank?

Je construeert je bank toch niet adhv de ingelogde persoon? (ik mis de boot vrees'k )

Ja dus
Het is een opdracht voor school dus ik kan niet teveel veranderen.
We moeten handigheid krijgen met EJB's.
En zo was de bank nu eenmaal geimplementeerd.
Leraar heeft het ook maar uit een boek hebben wij het idee.

We moeten Session Beans toevoegen voor Beheerder en Klant.
Entity Beans om het db werk te doen.
En een MDB voor een queue.
Die naar ik denk gevuld moet worden door de Session Beans.
Ik ben ook maar aan het prutsen hoor.
Ik ben eigenlijk op zoek naar een goed artikel die het hele plaatje goed laat zien.
Het liefst met voorbeelden. Wat je vaak ziet is een uitleg over de losse EJB's.
Het concept vat ik daarom ook wel maar het hele plaatje vind ik nog moeilijk
toe te passen. Misschien dat andere hier goede artikelen voor hebben.

Alvast bedankt.

[Verwijderd]

hmm, ik snap'm nog steeds niet zo goed en zal dus wijselijk m'n mond houden.

Maareuhm, een ietwat samenhangend voorbeeld van J2EE is http://java.sun.com/developer/releases/petstore/
(de vroegere reference application, maareuhm, ik zou er geen enterprise app op durven baseren... iig geeft het je waarschijnlijk wel wat meer inzicht in de technologie)

[Verwijderd]

Ik zal je twee links geven:
J2EE Design Patterns
Stukjes klassencode voor veel voorkomende "problemen". Je kunt op de plaatjes klikken.

Mastering EJB
Hier kun je het boek Mastering EJB downloaden. Ik heb het hier eigenlijk mee geleerd. Het is legaal om het daar te downloaden, maar je kunt het natuurlijk ook kopen. Ik geloof dat er nog een 2ehands van lag in de Slegte in Utrecht.

overigens denk ik dat alle leraren hun informatie ooit uit boeken gehaald hebben. Daar begin je immers mee

[Bbfreak]

Verwijderd schreef op dinsdag 04 januari 2005 @ 08:53:

overigens denk ik dat alle leraren hun informatie ooit uit boeken gehaald hebben. Daar begin je immers mee

Er zijn ook leraren uit het bedrijfsleven en die weten het meestal beter
Maar ik heb het blijkbaar niet getroffen.

Ik zal iig de gegevens links bekijken. Bedankt!

[edit]

Ik zie vooral veel communicatie tussen de Session en de Entity Beans.
Ik zie geen Message-Driven Bean. Waar moet deze tussen? Dat is dus het plaatje wat ik mis

Om het even te projecteren op onze opdracht:
Nu is het een paar packages voor het web.
Dit is de FO. Veranderd niet.
Dan heb je een bank.model en bank.database package.
Dit is de BO zoals het was.
Nu moet het dus gedeeltelijk vervangen worden door EJB's.
Nu hebben we dus de Session Beans gehad. Beheer en Klant.
We hebben de Entity Beans voor het db werk.
Nu moet er ook een MDB tussen maar waar?
Ik dacht zelf tussen de SB en de EB. Ik hoop dat het plaatje nu duidelijk is.

Was de leraar maar duidelijker

[ Voor 48% gewijzigd door Bbfreak op 04-01-2005 13:13 ]

[Verwijderd]

MDB is een message driven bean om asynchroon dingen uit te voeren. Je plaatst een message in een queue en hebt een (of meerdere) consumers om die message af te handelen. Heb je die functionaliteit nodig?
Je kan het (als het echt moet gebruikt worden) wel inpassen in het creeren van een overschrijving ofzo. Zodat de bank 's nachts alle overschrijvingen kan uitvoeren die gepland staan. Dus 's nachts start de consumer die de queue leegt... (jak, enkel als je dat onding moet gebruiken).

Voorlopig weet ik niet waarom je dat ding zou moeten gebruiken
Wij gebruiken het bijvoorbeeld om mails te versturen. Als dat niet lukt wordt dat later wel nog eesn geprobeerd of komt een sysadmin tussen om het een en't ander aan te passen. Een mail send mag onze applicatie niet blokkeren terwlijl mails toch wel moeten aankomen, dus zeker aan moeten komen...

En die CMP moet je zien als een persistent Value Object. Elke setter die je daarop aanroept wordt doorgeduwd naar de DB. Iets als hibernate dus, maar je kan het zelfs een remote interface geven (niet aan te raden ). Je session zal een remote interface hebben > je app. Vanuit de session bewerk je je CMP's (data) zoals gelijk welke service laag zou moeten doen. (en nog beter is het om zo weinig mogelijk code in EJB's te hebben, maar dat is voor een schoolproject niet zo belangrijk )