J2EE og distribuerte systemer Leksjon 11: Entity Beans (CMP)

J2EE og distribuerte systemer Leksjon 11: Entity Beans (CMP) Leksjonen er forfatters eiendom. Som kursdeltaker kan du fritt bruke leksjonen til eget personlige bruk. Kursdeltakere som ønsker å bruke leksjonene f.eks. til undervisning eller kursformål må ta direkte kontakt med forfatter for nærmere avtale. Copyright: Tomas Holt/TISIP Publisert 28.01.03. Frist innlevering av øvingsoppgaver 07.02.03 Innhold 1 KOMMENTAR TIL LEKSJONEN... 2 2 ENTITY BEANS MED CMP... 2 3 EKSEMPEL KONTO EJB MED CMP... 2 3.1 Get/set-metoder... 4 3.2 Entity-metoder... 4 3.3 Forretningslogikk-metoder... 5 3.4 Finnmetoder... 5 3.5 Bruk av deploytool... 5 3.6 Resulterende dd... 11 3.7 EJB-QL... 12 4 HVILKE METODER KAN MAN KOBLE MOT EJB-QL SPØRRINGER?...12

1 Kommentar til leksjonen Leksjonen omhandler kapittel 13 i boka. Vi er kun interessert i det som har med CMP 2.0 (og senere) å gjøre. Alt som har med CMP 1.1 er derfor ikke pensum. 2 Entity Beans med CMP CMP står for Container Managed Persistence. Når vi bruker CMP i en Entity Bean så vil containeren sørge for varig lagring av dataene. I forrige leksjon så vi hvordan dette ble gjort med BMP. Det ble ganske mye databasekode. Vi skal nå se på hvordan vi kan slippe å skrive all denne koden. Ved bruk av CMP så lages denne koden automatisk. I starten på kapittel 13 tar boka opp ulike måter man kan sørge for varig lagring i slike EJB er. Merk at EJB er laget med CMP faktisk har mulighet for å være mer effektive enn BMP EJB er. Hvorvidt CMP faktisk blir effektivt, er avhengig av implementasjonen av containeren. En annen ting man skal merke seg med CMP er at EJB en blir mer fleksibel. Det er ikke nødvendig å gjøre om en CMP EJB når man velger å flytte EJB en fra en applikasjonstjener til en annen (likevel om de benytter ulike databasesystemer). Dette kan bli tilfellet når vi bruker BMP (bruk av DAO begrenser imidlertid denne problematikken, se forrige leksjon). 3 Eksempel Konto EJB med CMP La oss se hvordan kontoeksemplet fra forrige leksjon blir med CMP. Interfacene vil bli som for BMP (se forrige leksjon). For å oppsummere kort: Home-interfacet har følgende metoder: create(integer kontonr, String fornavn, String etternavn) findbyprimarykey(integer kontonr) findbysaldooverbeløp(int saldo) findallekontoer() beregntotaltantallkontoer() //home metode Remote/Local interfacene har følgende metoder: settinn(int belop) taut(int belop) hentsaldo() Ok, vi har nødvendige interface, la oss lage implementasjonsklassen:

import javax.ejb.*; import java.util.*; public abstract class KontoCMPBean implements EntityBean{ private EntityContext ctx; //konto er representert ved de varige feltene kontonr og saldo // i BMP lager vi objektvariabler, men ikke her! //her lager vi kun get og/eller set-metoder! /**************** SET/GET-metoder ********************/ public abstract void setkontonr(integer kontonr); public abstract Integer getkontonr(); public abstract void setfornavn(string fornavn); public abstract String getfornavn(); public abstract void setetternavn(string etternavn); public abstract String getetternavn(); public abstract void setsaldo(double nysaldo); public abstract int getsaldo(); /************* ENTITY METODER **********************/ public void setentitycontext(entitycontext ctx){ this.ctx = ctx; public void unsetentitycontext(){ public Integer ejbcreate(integer kontonr, String fornavn, String etternavn) throws CreateException{ if (kontonr == null kontonr.intvalue() < 1) throw new CreateException("Kontonr må være et positivt tall"); if (fornavn == null fornavn.equals("")) throw new CreateException("Eier av konto må ha et fornavn"); if (etternavn == null etternavn.equals("")) throw new CreateException("Eier av konto må ha et etternavn"); setkontonr(kontonr); setfornavn(fornavn); setetternavn(etternavn); setsaldo(0); return null; //gjøres når det er snakk om CMP. public void ejbpostcreate(integer kontonr, String fornavn, String etternavn){ public void ejbload(){ public void ejbstore(){ public void ejbactivate(){ public void ejbpassivate(){ public void ejbremove(){ /******* Foretningslogikk ***********************/ public void settinn(int belop){ int saldo = getsaldo(); setsaldo(saldo + belop); public void taut(int belop) throws KontoException{ int saldo = getsaldo(); if (saldo - belop < 0) throw new KontoException("Ikke dekning på konto"); setsaldo(saldo - belop); public int hentsaldo(){

return getsaldo(); /*********** Select-metoder **********************/ public abstract Collection ejbselectallekontoer() throws FinderException; /************ Ekstra home-metode *****************/ public int ejbhomeberegnantallkontoer() throws FinderException{ return ejbselectallekontoer().size(); Sammenlikn denne klassen med BMP klassen fra forrige leksjon! Særlig kortere kan det vel ikke gjøres? Jeg regner med at du nå spekulerer på hva som skjer her. Så la oss starte fra toppen. Det vi lager er en abstrakt klasse. Grunnen til dette er at applikasjonstjeneren vil sørge for å lage en sub-klasse til vår klasse, der alle nødvendige metoder blir implementert. Tjeneren vil blant annet sørge for å implementere ejbload()- og ejbstore()-metodene. 3.1 Get/set-metoder La oss først konstantere at du ikke finner variabler i klassen, verken for kontonr eller saldo (som vi hadde for BMP). Du finner imidlertid metoder for å sette og hente verdiene. Metoden getkontonr() vil altså returnere kontonr, mens setkontonr(integer kontonr) vil sette kontonr til en verdi. Legg merke til at disse metodene er abstrakte. Det vil de bestandig være. Applikasjonstjeneren vil implementere metodene. Get-metodene viser hvilke datatyper det er snakk om. Tjeneren er derfor i stand til å lage kode for å lagre/hente disse feltene (fra datalager) automatisk. Når du i EJB en trenger å få tak i saldoen, så kaller du ganske enkelt metoden getsaldo(), i stedet for å bruke variabelen saldo. Eksempel på dette kan du se i metoden hentsaldo(). Det eneste du trenger å gi applikasjonstjeneren beskjed om, er hvilken av variablene (kontonr eller saldo) som er primærnøkkel. Dette gjøres i deploytool. Vi kommer tilbake til hvordan dette gjøres. 3.2 Entity-metoder Dette er metodene som må være med i en Entity Bean. Disse vil være de samme som for BMP (men det kan også finnes noen flere som vi skal komme tilbake til) og er beskrevet på s. 413 i boka. Som du ser av implementasjonsklassen, er alle disse metodene unntatt ejbcreate() og setentitycontext() tomme. Det vil normalt være tilfelle, metodene er imidlertid tilgjengelig om vi vil bruke dem. Metodene blir kalt opp av containeren på samme måte som for BMP, men nytteverdien av dette er mye mer begrenset i CMP. Ettersom alle disse metodene vanligvis vil være tomme, kan det være en fordel å lage seg en generell klasse, som dine Entity Beans arver fra (på samme måte som vi gjorde for Session Beans).

3.3 Forretningslogikk-metoder Da har vi kommet fram til metodene som danner forretningslogikken. Disse metodene vil da være beskrevet, enten i et Remote-interface, og/eller et Local-interface. Vi har tidligere vært inne på at Entity Beans helst skal skjermes med en fasade av Session Beans. Det normale vil derfor være å bruke lokale-interface (men det kan være fornuftig med fjern-interface for testing). Ettersom vi har tre metoder i interfacet vårt, får vi tre metoder også i implementasjonsklassen. Legg merke til hvordan disse metodene bruker get/set-metodene for å endre tilstanden til EJB en. Skal du f.eks. endre saldoen til denne EJB en, så kaller du metoden setsaldo(). 3.4 Finnmetoder Når vi brukte BMP så lagde vi ejbfindxxx() metoder for findxxx() metodene beskrevet i Home-interfacet. I vårt tilfelle har vi flere slik metoder: findbyprimarykey(integer kontonr) findbysaldooverbeløp(int saldo) findallekontoer() (ikke laget i eksemplet her, det vil være en fin oppgave for deg å legge til denne). Ingen av disse metodene er implementert i implementasjonsklassen. Spørsmålet er da, hvordan blir disse implementert? Metoden findbyprimarykey() implementeres automatisk (skjer bestandig). Metoden findbysaldooverkroner() vil det imidlertid være vanskelig for applikasjonstjeneren å lage, uten hjelp fra deg. Hvordan kan tjeneren vite hva denne metoden faktisk skal gjøre? Det kan den rett og slett ikke skjønne på egen hånd. Du må derfor hjelpe tjeneren, men du slipper å skrive java-kode. Vi bruker deploytool til å lage en en dd (deployment descriptor), som forklarer hvilken spørring som skal gjøres av denne metoden. Ok, la oss gjøre dette i praksis. 3.5 Bruk av deploytool Framgangmåten er den samme som før. Vi starter med å lage en applikasjon og så skal vi lage en ny Enterprise Bean. Sørg for å velge filene som skal være med i EJB en (interface og implementasjonsklasse). Når du kommer til skjermbildet der du skal velge Bean Type så må du selvsagt velge Entity Bean (og ikke Session Bean). Du vil etter hvert få opp følgende skjermbilde:

Figur 1: Entity Settings Det er her du konfigurerer mye av en CMP EJB. Sørg for å merke av for Container managed persitence (2.0). Sørg videre for å merke av hvilke felter som skal være varige (disse er bestemt ut fra get-metodene). Så må du sørge for å bestemme hvilken type primærnøkkelen har. Vi må altså endre feltet Primary Key Class til java.lang.integer i dette tilfellet. I nedtrekkslisten Primary Key Field Name velger vi hvilket av feltene (kontonr eller saldo) som er primærnøkkelen. Skjermbildet skal altså se slik ut når du er ferdig:

Figur 2: Entity Settings for Konto EJB. Nå trenger vi å spesifisere hvilket databasesystem som skal brukes, og ikke minst spørringene for finn-metodene. Det første vi gjør er å bestemme Abstract Schema Name. Dette feltet inneholder navnet vi ønsker å bruke på databasen (merk at det ikke er navnet databasen faktisk kommer til å få, men det navnet vi bruker i vår spørring). Vi kan f.eks. kalle feltet KontoSkjema. Vi trykker så på knappen for Finder/Select Metods..

Figur 3: Finder/Select Metods I skjermbildet over får vi muligheten til å bestemme spørringene for de finnmetodene som vi har laget (ikke findbyprimarykey() da denne lages automatisk). I mitt tilfelle kan du se at metoden faktisk ligger i RemoteHome-interfacet, og at metoden heter findbysaldooverkroner(). Det kan godt være flere metoder her, og gjerne spredd over Local Finders (fra LocalHome-interfacet), RemoteHome-interfacet og Select Metods (kommer tilbake til disse). Ved å trykke på metoden findbysaldooverbeløp() kan jeg skrive inn spørringen i vinduet til høyre. Spørrespråket som brukes kalles EJB-QL. Dette er et spesielt spørrespråk laget for CMP. Det ligner imidlertid mye på SQL og er derfor ikke vanskelig å lære. Spørringen for findbysaldooverbeløp() blir slik: SELECT OBJECT(o) FROM KontoSkjema o WHERE o.saldo >?1 Første linje beskriver at vi skal hente alle objekter o fra KontoSkjema (husk at dette er det navnet vi ga databasen vår) som tilfredstiller kriteriet i andre linje. På norsk blir dette: Finn alle objekter hvor saldoen i objektet (o) er større enn?1. Hva er så dette siste leddet? Det er faktisk det første argumentet i metoden findbysaldooverbeløp(double saldo). Når metoden kalles f.eks. slik, findbysaldooverbeløp(1000), så vil?1 skiftes ut med 1000. Spørringen vil derfor returnere alle kontoer som har saldo større enn 1000. Hadde metoden hatt flere argumenter ville vi kunne hente disse med?2 for andre argument,?3 for tredje argument osv. Skjermbildet blir nå slik:

Figur 4: EJB-QL for findbysaldooverkroner() Trykk OK og så Finish. Du er nå nesten ferdig med å lage applikasjonen. Det er to ting som nå mangler. Først må du sørge for at riktig databasesystem blir valgt til lagring av dataene. Dette gjør du ved å velge EJB en du har laget (se figuren under). Velg så skillearket Entity. Skjermbildet skal da være som vist under: Figur 5: Entity

Velg Deployment Settings... Figur 6: Depl oyment settings Velg Database Settings. Merk deg at du i dette skjermbildet kan velge om databasen skal opprettes automatisk eller ikke. Hvis ikke må databasen opprettes på annen måte. F.eks. ved bruke av cloudscape isql. Figur 7: Velg database Skriv inn Database JNDI Name. For oss vil dette være jdbc/cloudscape, men vil du bruke en annen database er det fult mulig. Trykk OK. Du kommer nå tilbake til forrige skjermbilde og velger nå Generate Default SQL. Merk at cloudscape nå må være startet for at dette skal fungere. Hvis du nå trykker på metoden findbysaldooverbeløp() så vil du se at den genererte SQL-koden vises (den kan du faktisk endre hvis du vil) og at EJB-QL koden vises. Om EJB-QL koden ikke er gyldig (skrivefeil) så kan du trykke på Edit og rette opp. Merk at den genererte SQL-koden inneholder det

virkelige tabellnavnet som brukes i databasen, her KontoCMPBeanTable (se figuren under). Hvis du bruker cloudscape isql må du skrive <isql> select * from KontoCMPBeanTable for å se innholdet i databasen. Merk at det skilles mellom store og små bokstaver (og at vi derfor må bruke tegnet rundt tabellnavnet). Figur 8: SQL og EJB-QL kode Alt skal nå være i orden så vi trykker på OK. Nå gjenstår bare å gi EJB en et JNDI-navn og legge til en klient som bruker EJB en. Dette skal du nå være i stand til å gjøre (og du bør gjøre det). 3.6 Resulterende dd Hva er det egentlig som skjer i eksemplet over. Deploytool sørger for å lage en dd som inneholder en kobling mellom metoden findbysaldooverbeløp() og tilhørende EJB-QL. Dette er viktig fordi det må være en kobling herm, slik at riktig spørring utføres for denne metoden. Ved å velge EJB en i deploytool, og velge Tools > Descriptor Viewer, får du se dd en for EJB en. Under kan du se et utdrag: <guery> <query-method> <method-name>findbysaldooverbeløp</method-name> <method-params> <method-param>int</method-param> </method-params> </query-method> <ejb-ql>select object(o) from KontoSkjema o where o.saldo >?1</ejb-ql>

</query> 3.7 EJB-QL EJB-QL er beskrevet nærmere i kapittel 13.5 i boka, og dette kapitlet kan derfor brukes som referanse når du skal lage egne spørringer. 4 Hvilke metoder kan man koble mot EJB-QL spørringer? Vi har allerede sett at findbyprimarykey() håndteres automatisk. I tillegg så har vi sett at vi kunne lage en spørring koblet mot findbysaldooverbeløp(). Det er slik at alle finnmetodene som ligger i Home-interfacet (Local eller Remote) automatisk blir oppdaget, og at man kan spesifisere EJB-QL for disse. Finnmetodene har imidlertid begrenset fleksibilitet. Slike metoder returnerer alltid et eller flere objekter som implementerer enten Local- eller Remote-interfacet til EJB en det er snakk om (mao. EJB-objekter). Hva om vi ønsker en metode som returnerer antall kontoer? Hvordan kan vi få til dette? En løsning er selvsagt å lage metoden findallekontoer() og lage en EJB- QL spørring for denne som returnerer alle kontoene. Problemet er bare at nå blir det returnert en Collection med objekter, og så må klienten selv finne ut hvor mange kontoer det er snakk om. Dette er uholdbart, hva om vi har 1 million kontoer? Skal vi da sende 1 million objekter over nett til klienten? Det vi trenger er en måte som gjør det mulig å beregne antall kontoer på tjenersiden, og bare returnere et tall. Vi trenger metoden public int beregnantallkontoer() Vi kan jo godt lage denne metoden og gjøre den tilgjengelig for klienter, men hvordan kan vi knytte en spørring mot den? Alle metoder i implementasjonsklassen som starter med ejbselect... skal knyttes mot EJB-QL spørringer (akkurat på samme måte som finnmetodene). Metodene kalles select-metoder og vil bare defineres i implementasjonsklassen (ikke i noen av interfacene). Vi trenger altså en select-metode som henter alle kontoene. Vi kaller denne metoden ejbselectallekontoer(). Alle select-metoder skal være abstrakte. Vi må derfor legge til følgende linje i implementasjonsklassen: public abstract Collection ejbselectallekontoer() throws FinderException; Nå er det bare å bruke deploytool og å sette en EJB-QL spørring for select-metoden. Dette gjøres på samme plass som for finnmetodene (beskrevet tidligere). Husk å generere SQLkode. Nå har vi kommet ditt at vi har en metode som kan returnere alle kontoer. Vi kan nå bruke denne metoden i beregnantallkontoer() og metoden blir slik: public int beregnantallkontoer() throws FinderException return ejbselectallekontoer().size(); Denne metoden må nå beskrives i et av interfacene slik at klienten kan kalle denne metoden. Hvilket interface er det nå naturlig å bruke? Metoden ligner jo på en forretningsmetode, men

metoden er jo ikke spesifikk for et implementasjonsobjekt. Metoden er derfor best egnet som en home-metode. Som beskrevet i forrige leksjon er dette metoder som begynner ejbhome og vi vil derfor her kalle metoden ejbhomeberegnantallkontoer(). Metoden må også defineres i Home-interfacet (ene) og blir der hetende beregnantallkontoer().