HØGSKOLEN I SØR-TRØNDELAG Avdeling for informatikk og e-læring Kandidatnr: Eksamensdato: 10.desember 2008 Varighet: 0900 1200 Fagnummer: Fagnavn: LO346D Java EE og distribuerte systemer Klasse(r): NETT ING Studiepoeng: 6 Faglærer(e): Tomas Holt 73 55 95 70 Hjelpemidler: Oppgavesettet består av: Vedlegg består av: Alt skriftlig materiale 2 oppgaver, 3 sider inkludert denne Ingen vedlegg Merknad: Oppgaveteksten kan beholdes av studenter som sitter eksamenstiden ut. Lykke til! OBS! Dersom du mener det mangler opplysninger i oppgaveteksten, sett dine egne forutsetninger. Tips: Det er viktigere å få fram forståelse enn små detaljer. Fokuser derfor på helhet og at løsningene er fornuftige. 1
Case Du skal nå lage en reserveringsløsning for kollektivtransport (tog, buss, fly, trikk og evt. flere). Løsningen er tenkt for reisebyrå og private. Man skal i systemet kunne finne transportmiddel på ønskede strekninger, se pris og ledig kapasitet. Det skal også være mulig å reservere sete. Merk at kunden selv må angi hvilken strekning han skal reise og at systemet kun finner transportmiddel som går direkte mellom startpunkt og sluttpunkt (systemet skal altså ikke komme opp med alternativer som f.eks. du kan ta tog halve distansen og buss resten). For at oppgaven ikke skal bli for komplisert så kan du se bort fra tid (vi har altså ikke starttid og slutttid for en reisestrekning). Løsningen må være slik at det er mulig å reservere ett sete for en person på en strekning. å reservere sete på flere strekninger for en person. I dette tilfellet må sete for alle strekningene reserveres eller ingenting. å reservere sete på flere strekninger for flere personer. Også i dette tilfellet må alt eller ingenting reserveres. å avbestille en reservasjon. Du kan anta at alle nødvendige data lagres i en database. All databasekommunikasjon skal skje via Java Persistence. Anta også at det for reisebyrå skal være mulig å få beskjed om det blir ledig kapasitet på en reise som allerede er full (altså om det kommer avbestilling). Du kan se bort fra eventuell sikkerhetsproblematikk (dvs. lag løsningen enkel). Oppgave 1 (RMI og Persistence, vekt 60 %) I denne oppgaven skal case't løses med Java og Java RMI med de muligheter og begrensninger den teknologien setter. Oppgave a) Tegn en skisse av systemet, der du tegner en "boks" pr PC. Angi hvor tjenerobjekt(er) kjører, og hvor klienten(e) kjører. Her kan man med fordel ha en type klient for reisebyrå og en for private brukere. Denne oppgaven vektlegges lite. De som ikke klarer å lage noe fornuftig her ligger langt ned på skalaen. Oppgave b) I RMI er fjernobjekter (objekter som tilhører en subklasse av UnicastRemoteObject) sentralt. Det er også aktuelt å serialisere objekter (uten å lage dem som fjernobjekter). Lag RMI-grensesnitt for fjernobjektet/-ene i denne oppgaven. Du vil også trenge en del objekter som ikke er fjernobjekter. Angi de du trenger, og om noen av disse bør serialiseres. Angi også sammenhengene mellom entitetsobjektene (Java Persistence). 2
Her må studenten beskrive hvordan interfacet til tjenerklassen ser ut. Dette må altså inneholde metodene som skal til for å løse case't. Import-setninger osv. er ikke nødvendige. Det er her en fordel å ha et interface for private og et for reisebyrå. I tillegg er det veldig viktig at studenten viser forståelse for hvordan tilbakekall fungerer. Man trenger da ogå et interface for klientene. Interfacene kan se slik ut: public interface ReiseSentral extends Remote{ public Person finnperson(long fodselsnr) throws RemoteException; public List<DelReise> finndelreise(sted start, Sted slutt) throws RemoteException; public Reservasjon reserverreise(list<person> persliste, Reise reise) throws RemoteException; //reise inneholder delreiser. Reservasjon-entitet returneres og inneholder reiser + personer. public interface ReiseSentralUtvidet extends ReiseSentral{ public void registrerfortilbakekall(klient klient) throws RemoteException; public interface Klient extends Remote{ //callback metode for ReiseSentralUtvidet public void reservasjonmulig(arraylist<delreise> reiseliste) throws RemoteException; Objekter som sendes fram og tilbake mellom klient og tjener må kunne serialiseres. Dette gjelder her (i eksemplet over): Sted, DelReise, Reise og Reservasjon. Når det gjelder entitetene så må disse lages fornuftige i forhold til å løse problemet. Her vil det være naturlig å lagre både reiser og delreiser i databasen. Disse vil også ha en en-tilmange (evt. mange-til-mange) sammenheng i mellom seg. Studentene tenker imidlertid ulikt så her må man bare vurdere om løsningen vil fungere. Oppgave c) Du skal nå implementere en begrenset del av systemet. Lag funksjonaliteten som trengs for å finne mulige reiser for en valgt strekning. Lag en enkel klient og vis nødvendig kode på tjenersiden. Se bort fra feilhåndtering. Du kan anta at du har en ferdig GUI-klasse. Denne klassen skal imidlertid ikke inneholde nettverkskommunikasjon. Det skal gjøres fra en egen klasse (som vi da antar at GUI-klassen vil kalle). Merk at vi i denne oppgaven er opptatt av helheten. Programmeringsdetaljer som ikke er relatert til Java Persistence eller RMI/nettverkskommunikasjon er lite interessant. Bruk derfor gjerne pseudokode/forklaring hvor naturlig (f.eks. ved manipulering av lister/tabeller o.l.). Forslag til kode vises under. Det som er særdeles viktig i denne oppgaven er at man unngår å lage en løsning som gir en stygg flaskehals eller samtidighetsproblemer. Eks: Ettersom man skal bruke EntityManager må man selv sørge for å håndtere samtidighetsproblemet. EntityManager-objektet er ikke trådsikkert (men 3
EntityManagerFactory er). Dette gjør at man aldri må slippe mer enn en tråd til på et EntityManager-objekt. Samtidighetsproblemer har vært fokus i kurset og er derfor meget viktig! Løsninger som ikke håndterer dette problemet vil ikke kunne vurderes til A. public class ReiseSentralImpl extends UnicastRemoteObject implements ReiseSentral { private EntityManagerFactory emf ; public ReiseSentralImpl(EntityManagerFactory emf) throws RemoteException{ this.emf = emf; public List<DelReise> finndelreise(sted start, Sted slutt) throws RemoteException,...{ EntityManager em = null; try{ em = getem(); //antar at delreise har en sammenheng med transportmiddel og sted (fra og til) og sørger //for å laste disse fra DB, da de skal resultatet skal serialiseres //mao. man kan ikke bruke LAZY-loading her. Vi bruker derfor JOIN FETCH Query q = em.createquery("select r FROM DelReise r JOIN FETCH r.transportmiddel, r.sted WHERE r.frasted.navn=:startnavn AND r.tilsted.navn=:sluttnavn AND r.frasted.postnr=:startpostnr AND r.tilsted.postnr=:sluttpostnr"); q.setparameter("startnavn",start.getnavn()); q.setparameter("sluttnavn",slutt.getnavn()); q.setparameter("startpostnr",start.getpostnr()); q.setparameter("sluttpostnr",slutt.getpostnr()); return q.getresultlist(); catch(persistenceexception e){ finally{ //log //hiv evt. exception lukkem(em); 4
private EntityManager getem(){ return emf.createentitymanager(); private void lukkem(entitymanager em){ try{ if (em!= null) em.close(); catch(exception e){//logg feil) Oppgave 2 Java EE (vekt 40 %) Oppgave a) Tenk det at du skal implementere case't med EJB'er (hvor naturlig). Forklar hvordan en slik løsning vil se ut på overordnet nivå. Hvilke EJB'er ser du for deg, og av hvilken type vil de være? Her bør det grunngis hvorfor man ønsker å bruke tilstandsløse eller tilstandsfulle SesssionBeans (eller en kombinasjon). Å komme med en helt annen tilnærming her enn i RMI (f.eks. å ikke bruke tilstander på tjenersiden i RMI for så å plutselig bruke tilstandsfulle SessionBeans her, ansees ikke som spesielt bra). Oppgave b) Det skal være mulig med tilbakekall i løsningen. Er dette mulig i en løsning med EJB'er på tjenersiden? Forklar i så fall hvilke muligheter du ser. Java Message System gir mulighet for at klienter kan få beskjed fra applikasjonstjener når noe har skjedd. Klienten abonnerer da på spesielle hendelser. Å løse problemet med SessionBeans (enten det er tilstandsfulle eller tilstandsløse) er ikke så enkelt. Man kan imidlertid få dette til med å bruke singelton-objekter. F.eks. ved å registrere et vanlig java/rmi-objekt i JNDI-registret. EJB'ene kan dermed finne dette objektet via JNDIoppslag. Klientene må selvsagt da sende sin egen referanse til tjeneren og denne må da lagres i singelton-objektet. Oppgave c) I case't er det antatt at man har alle data i en sentral database. Dette er nok urealistisk. Hvilke følger vil det ha ha om man bruker flere databaser i systemet (f.eks. en/flere for fly, en/flere for tog osv). Beskriv hvilke følger det får for Java Persistence løsningen RMI-løsningen EJB-løsningen 5
Transaksjoner. Er det i det hele tatt mulig å få til fornuftige transaksjoner i dette systemet? Persistence løsningen vil vel neppe bli særlig endret, bortsett fra at man må ha en persistence-unit pr. database (og dermed flere EntityManagere). At JTA brukes er en selvfølge. RMI-løsningen takler deler av problemet. Så lenge man har en 3-lagsløsning så vil man kunne legge til kode for flere databaser på tjenersiden og klientene vil ikke merke noe. Problemet ligger i transaksjonshåndtering. Vi trenger nå 2-fase-commit, noe RMI ikke gir støtte for. EJB-løsningen vil fungere fint. Her ser vi fordelen med at applikasjonstjeneren kan opptre som monitor i 2-fase-commit. Man er dermed sikker på at alle databasene som er med i en transaksjon enten blir oppdatert eller rullet tilbake (dette krever databasedrivere som støtter 2-fase-commit). Oppgave d) Man har livsyklusmetoder på EJB'er. En av disse brukes når man ønsker å fjerne en EJB. Forklar hvordan man kan bruke denne og for hvilke typer EJB'er den er aktuell å bruke. @Remove annotasjonen angir at dette er en metode som skal kjøres før EJB'en blir slettet. Denne bør absolutt kjøres av en klienten til en Tilstandsfull Session Bean da det frigir ressursene (som ellers vil måtte lagres på tjeneren over lengre tid). Oppgave e) Bruk av Tilstandsfulle Session Beans (Statefull Session Beans) gir risiko for å gå tom for minne på tjenermaskinen. Forklar hvorfor dette er tilfelle. Hva har man gjort for å prøve å begrense problemet og hva gjør man om alt minne er brukt (og man fortsatt har behov for mer)? Problemet ligger i at man må lagre data for hver klient. Man gjør det imidlertid slik at man pooler TFSB også. Man må imidlertid være i stand til å lagre dataene på disk. Dette er imidlertid ikke helt uproblematisk, da f.eks. databaseoppkoblinger ikke kan lagres på disk. 6