J2EE og distribuerte systemer Leksjon 8: Oppbygning av J2EE-applikasjoner

Transkript

1 J2EE og distribuerte systemer Leksjon 8: Oppbygning av J2EE-applikasjoner 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 Frist innlevering av øvingsoppgaver Innhold 1 KOMMENTAR TIL LEKSJONEN EJB KONTRA RMI VIKTIGHETEN AV INTERFACE EJB OG INTERFACE gethelloworldstring() og tilhørende Remote-interface ejbcreate() og tilhørende Home-interface Kommentar til Home- og Remote-interfacet KLIENTEN NAVNEKONVENSJONER LOKALE INTERFACE OG SKALERBARHET DEPLOYMENT DESCRIPTOR (DD) HVA ER EN KOMPONENT? HVORDAN BRUKE KOMPONENTENE? BRUK AV DEPLOYTOOL BRUK AV VERIFIER I DEPLOYTOOL UPDATE FILES DEPLOYTMENT DESCRIPTOR (DD) INDIREKTE BRUK AV JNDI-NAVN...25 OPPGAVER...28

2 1 Kommentar til leksjonen Tiden er nå inne for å se litt mer detaljert på hvordan J2EE-applikasjoner er bygd opp. Vi skal i denne leksjonen se detaljert på standarden som ligger til grunn for å lage slike applikasjoner. Vi skal selv lage en enkel applikasjon bestående av en SessionBean og en klient. Denne leksjonen omhandler kapittel 3 og 4 i boka. Jeg foreslår at du leser denne leksjonen først, da jeg tror det blir enklere å forstå det som står i boka. Boka vil være mer detaljert enn denne leksjonen. Kapittel 4 i boka kan du nok lese ganske fort igjennom. Særlig det som har med hvordan bruke deploytool synes jeg var litt for dårlig forklart. Jeg har derfor tatt med dette i leksjonen. Et verktøy som heter ant er gjennomgått i boka. Interesserte kan lese og bruke ant. Dette er ikke tema i dette kurset da andre verktøy like så godt kan gjøre dette for brukeren. 2 EJB kontra RMI Det finnes flere typer EJB. Vi skal se nærmere på de ulike typene senere i kurset, men i første omgang skal vi bruke Session Beans som eksempel på hvordan en klient og en EJB fungerer. La oss først se på hva som skjer når en RMI-klient tar kontakt med et fjernobjekt på tjeneren. 2.1 Viktigheten av interface KlientImpl.java... Tjener obj = Naming.lookup(..); int tall = obj.henttall();... TjenerImpl.java int henttall(){ return 10; stedfortreder-objekt (proxy/stub) stedfortreder-objekt (proxy/skeleton) JVM JVM Nettverk Figur 1: RMI og nettverksstakken Det som skjer i figuren er at klienten (et objekt av KlientImpl) først finner tjeneren (et objekt av TjenerImpl). Dette skjer via Naming.lookup(). Merk at klienten ikke ser selve TjenerImpl objektet, men interfacet (Tjener) til dette objektet. Her er vi inne på noe veldig viktig. Klienten ser altså bare selve interfacet til tjeneren, ikke hvordan selve implementasjonen er 1

3 utført (se figuren under). Dette er meget viktig da det gjør det enkelt å endre implementasjonen på tjenersiden. La oss si at vi har spredd klienten på mange maskiner rundt omkring. Vi finner metoden henttall() skal returnere 9 i stedet for 10. Vi endrer metoden i TjenerImpl.java (og rekompilerer). Når klientene nå bruker metoden vil de få returnert 9 og ikke 10 som før. Dette fungerer fordi klientene kun ser interfacet Tjener. Dette interfacet ligger på klientmaskinen sammen med KlientImpl.class. Hvis vi hadde vært nødt til at TjenerImpl.class lå på alle klientmaskinene hadde ikke eksemplet over fungert. Da måtte vi ha oppdatert alle klientmaskinene med den nye implementasjonen av TjernerImpl.class. Bruken av interface sørger altså for at det holder å endre implementasjonen på tjeneren og alle klientene vil se disse endringene. Vedlikeholdet vil altså være mye enklere enn i tilfellet der alle klientene må oppdateres.... KlientImpl.java int tall = obj.henttall();... Tjener.java public interface Tjener{... public int tall() throws RemoteException;... Klientens "syn" TjenerImpl.java public int henttall() throws RemoteExcpetion { return 10; Figur 2: Klientens syn på tjeneren 2.2 EJB og interface Akkurat som for RMI vil en EJB-klient forholde seg til et (for å være eksakt; flere) interface og ikke direkte til implementasjonen av EJB en. Navnekonvensjonene vil være litt ulikt tilfellet for RMI, og det hele er litt mer komplisert. La oss først se på HelloWorldBean som er EJB-implementasjonen vi brukte i forrige leksjon: import javax.ejb.*; public class HelloWorldBean implements SessionBean{ private String value="helloworldbean says hello"; public void ejbcreate(){ log("ejbactivate()"); public String gethelloworldstring(){ return value; 2

4 public void ejbremove(){ log("ejbremove()"); /* * metoder som ikke er av interesse foreløpig */ public void ejbactivate(){ log("ejbactivate()"); public void ejbpassivate(){ log("ejbpassivate()"); public void setsessioncontext(sessioncontext con){ log("setsessioncontext()"); /*************************************************************/ //brukes for å lette endring av utskriftsrutiner... private void log(string s){ System.out.println("HelloWorldBean: " + s); Dette er altså hvordan EJB-implementasjonen kan se ut. Vi bruker begrepet EJBimplementasjon om klassen som implementerer logikken (dette vil altså være Bean-klassen). Merk deg følgende i koden: javax.ejb.* pakken inkluderes. Denne trenger vi da SessionBean-interfacet ligger i denne pakken. Klassen implementerer interfacet SessionBean. Dette angir at det her er snakk om en SessionBean EJB. Dette interfacet har 4 metoder som følgelig må implementeres. Metodene er som følger: o ejbactivate() o ejbpassivate() o ejbremove() o setsessioncontext(sessioncontext con) Som du kan se av koden over gjør alle metodene i SessionBean-interfacet kun en enkel utskrift (i stedet for å ha System.out.println() i hver metode er dette samlet i den private metoden log(). Dette gjør det mye enklere om vi skulle finne på å endre utskriftsrutiner). Utskriften fra EJB-implementasjonen havner i konsollvinduet der applikasjonstjeneren kjører. EJB en her er meget enkel, alt den gjør er jo å returnere strengen HelloWorldBean says hello. Dette gjøres hver gang. Vi kaller denne typen Session Bean en tilstandsløs Session Bean. Grunnen til dette er at om klienten skulle kalle denne EJB en flere ganger så vil alltid tilstanden til EJB en være det samme (den returnerer alltid samme streng, dette er faktisk en sannhet med modifikasjoner som vi kommer tilbake til i neste leksjon). Slike EJB er har faktisk ingen bruk for metodene ejbactivate() og ejbpassivate(). Metoden ejbremove() kan brukes til å gjøre opprydning når klienten er ferdig med EJB en. Du vil nok sjeldent bruke denne metoden. 3

5 2.2.1 gethelloworldstring() og tilhørende Remote-interface EJB-implementasjonensklassen HelloWorldBean har metoden gethelloworldstring(). Poenget med denne metoden er jo at klienten skal kunne kalle den. Dette skal være mulig over et nettverk. Vi vet hvordan dette gjøres i RMI. For at en klient skal kunne kalle en fjernmetode, må vi lage et Remote-interface. Remote-interfacet vi lager vil altså inneholde de metodene som klienten skal kunne kalle på EJB en. I vårt tilfelle er vi bare interessert i at klienten skal kunne kalle gethelloworldstring(). Remote-interfacet til HelloWorldBean blir slik: import javax.ejb.*; import java.rmi.remoteexception; public interface HelloWorld extends EJBObject{ public String gethelloworldstring() throws RemoteException; Vi ser at Remote-interfacet vårt arver fra interfacet EJBObject. Tilslutt ser vi metoden gethelloworldstring() som er den metoden vi vil gjøre tilgjengelig for klienten. Legg merke til at metoden her kaster unntaket RemoteException. Dette er altså en fjernmetode. Se nærmere på metoden gethelloworldstring() i HelloWorldBean. Denne metoden hiver ikke unntaket RemoteException. Dette er altså ingen fjernmetode!!! Nå begynner du vel å lure på hva i all verdens navn som foregår. Dette strider jo mot all fornuft? Nei det er faktisk ikke helt tilfellet, men vi har ikke helt kommet til bunns i hva som faktisk skjer når en klient kontakter en EJB. En klient vil aldri direkte kalle EJBimplementasjonensobjekt (for eksempel HelloWorldBean). Det vil bestandig være et fjernobjekt som ligger i mellom klienten og EJB-implementasjonensobjektet. Vi kaller dette objektet EJB-objektet, men det må ikke misforstås med EJB-implementasjonenobjektet. EJBobjektet er laget på grunnlag av Remote-interfacet. I applikasjonstjeneren vil det bestandig ligge et/flere slikt objekt klart til å ta i mot forespørsler til EJB en. Hvor kommer så dette objektet fra? Klassen lages automatisk når du legger ut en EJB på applikasjonstjeneren (tjeneren bruker Remote-interfacet du har laget som mal). Når en klient vil snakke med en EJB så vil den kalle fjernmetoden på EJB-objektet. Igjen: DETTE ER IKKE EJBimplementasjonenobjektet, men et fjernobjekt som ligger på applikasjonstjeneren. EJBobjektet vil så kalle opp metoden på EJB-implementasjonenobjektet og returnere svaret. Dette kan virke veldig tungvindt. Hvorfor kan ikke klienten kalle metoden direkte på EJBimplementasjonenobjektet? Når all trafikk til EJB-implementasjonenobjektet går igjennom dennes EJB-objekt gjør dette at all trafikk til og fra EJB-implementasjonenobjektet kan kontrolleres av dette objektet. For eksempel kan dette objektet sjekke at brukeren er den han utgir seg for og at han har rettigheter til å kalle metoden på EJB-implementasjonenobjektet. Dette er oppgaver som EJB-objektet gjør automatisk for deg. Du kan derfor se på EJBobjektet som en portal inn til selve EJB-implementasjonen. 4

6 Klient Container EJBimplementasjonsobjekter //bruk JNDI til å finne fjernobjekt //(se omtale home-objektet) //kaller en fjernmetode på EJB-objektet String str = hello.gethelloworldstring(); HelloWorldBean HelloWorldBean HelloWorldBean EJB-objekt (basert på HelloWorld) EJB-object (basert på HelloWorld) Figur 3: EJB-objektet Merk at det ikke er noe bestemt forhold mellom antall klienter EJB-objekter og EJBimplementasjonsobjekter. I tilstandsløse SessionBeans vil det ikke spille noen rolle hvilken EJB som utfører klientenes kall. Ettersom EJB en aldri husker tidligere kall, vil alle EJB ene kunne løse samme oppgave (dette er selvsagt ikke tilfellet med EJB er som husker tidligere kall fra klienten ). Det vil derfor være tjeneren sin oppgave å sørge for at det finnes et passende antall EJB-implementasjonsobjekter som kan betjene klientene. Det er da viktig at det ikke blir for få objekter, for i dette tilfellet må noen klienter vente (kun en klient kan bruke et gitt EJB-implementasjonsobjekt i et tidsrom). I den andre enden av skalaen er det viktig at det ikke blir for mange, da dette krever mye ressurser på tjeneren. Merk at man for tilstandsløse SessionBeans godt kan spre EJB ene på flere tjenere. Alle EJB ene ser jo akkurat like ut, så det spiller ingen rolle for klienten hvilken tjener EJB en som kalles ligger på. Du lurer nå kanskje på hva en EJB er? En EJB består av en EJB-implementasjonsklasse, tilhørende interface m.m. Vi trenger å vite litt mer om hvordan en EJB er bygd opp før vi forklarer dette mer grundig ejbcreate() og tilhørende Home-interface Det er vanlig å lage to (eller enda flere) interface for hver EJB-implementasjonklasse. Remote-interfacet brukes som forklart over for at applikasjonstjeneren skal kunne lage EJBobjektet som klienten vil kommunisere med. Mao. Remote-interfacet beskriver metodene som utgjør forretningslogikken i EJB en (altså de metodene som løser problemet EJB en er laget for å løse). I forrige leksjon kjørte du HelloWorld-eksemplet. Tenkte du over hvordan EJB en faktisk blir opprettet? Hvis vi hadde brukt RMI ville koden sett noe slik ut: 5

7 HelloWorld hello = new HelloWorldBean();//oppretter tjenerobjektet Naming.rebind(hello, bønna );//gjør objektet tilgjengelig via RMI-registret I dette eksemplet vil det være et HelloWorldBean-objekt tilgjengelig for klientene. Et og kun et objekt. Jeg har tidligere forklart at det er applikasjonstjeneren sin oppgave å sørge for at et fornuftig antall EJB er er tilgjengelig for klientene (ikke for mange og ikke for få). Dvs. at vi ikke kan opprette EJB ene selv som programmerer. Det er applikasjonstjeneren sin jobb. Spørsmålet blir da, hvordan kan applikasjonstjeneren vite når det er behov for å opprette en EJB. Faktisk er det slik at klienten selv gir beskjed. La oss se på hvordan det er løst. HelloWorldBean har metoden ejbcreate(). Det vil bestandig finnes en eller flere ejbcreate()- metoder i en EJB-implementasjonklasse. Merk imidlertid at denne metoden ikke er beskrevet i SessionBean-interfacet som vi implementerer. Saken er den at man ikke kan være sikker på hvordan denne metoden bør se ut. I vårt tilfelle har ikke ejbcreate() noen argumenter, men det kan helt klart være tilfeller der vi er interessert i å sette en verdi ved opprettelsen av EJB en. Tenk for eksempel hvis vi har en EJB som representerer en person. Når det da opprettes en nytt objeket av EJB-implementasjonen så vil det være normalt at denne personen får et navn (alle personer må ha et navn). I dette tilfellet vil det være naturlig at metoden ser noe slik ut: ejbcreate(string navn, String adresse). Poenget er at det ikke på forhånd er mulig å vite hvordan ejbcreate-metoden for en EJB bør se ut. Derfor er det heller ikke mulig å ha denne metoden i SessionBean-interfacet. Det blir derfor opp til deg som utvikler å lage et interface som passer til denne metoden. Dette kalles Home-interfacet til EJB en. Til hver EJB vil vi lage et Home-interface. La oss foreløpig si at dette interfacet lages for at klienten skal kunne kalle ejbcreate()-metoden til EJB-implementasjonenklassen. For HelloWorldBean vil dette interfacet få navnet HelloWorldHome. Interfacet vil se slik ut: import javax.ejb.*; import java.rmi.remoteexception; public interface HelloWorldHome extends EJBHome{ public HelloWorld create() throws CreateException, RemoteException; Først kan vi konkludere med at vi må arve fra interfacet EJBHome. Dette forklares nærmere i boka kapittel 3.9, men la oss foreløpig la dette ligge. Det som er viktig først er å få en forståelse av hva som skjer i stedet for alle detaljer. Se på metoden create(). Metoden kaster to unntak: CreateException og RemoteException. Disse to unntakene kastes bestandig av create()-metoden. I og med at det her kastes et RemoteException beskriver dette interfacet en fjernmetode. Hvorfor heter så ikke denne metoden ejbcreate() i stedet for create()? Navnet på metoden i EJB-implementasjonenklassen er jo ejbcreate(), mens i interfacet heter beskrivelsen av metoden create(). Grunnen er at klienten aldri direkte vil kalle metoden ejbcreate() på et EJB-implementasjonsobjekt fordi klienten aldri direkte kontakter dette objektet. Når du legger ut en EJB på applikasjonstjeneren så vil tjeneren sørge for å opprette et homeobjekt. Dette objektet er laget på grunnlag av Home-interfacet. Dette home-objektet vil være knyttet til JNDI-navnet til EJB en, så det er dette objektet vi finner i første omgang ved et JNDI-oppslag. Metodene du finner i home-objektet vil følgelig være de create()-metodene som du har beskrevet i interfacet. I vårt tilfelle vil det kun være en metode uten argumenter. Dette vil bestandig være tilfellet for tilstandsløse SessionBeans (nettopp fordi de ikke har 6

8 tilstand er det ikke noen vits i å initialisere EJB en, den skal ikke huske det likevel). For andre typer EJB kan det være mange create()-metoder. Hver metode du beskriver i Home-interfacet vil da være oppfulgt med en ejbcreate()-metode i EJB-implementasjonen med samme argumenter (vi kommer tilbake til dette). Merk at ejbcreate()-metodene ikke returnerer noe, mens create()-metodene i Home-interfacet returnerer en referanse av typen Remote-interface (forklaring kommer snart). Legg merke til hva som returneres fra create()-metoden. Det er en referansen til et HelloWorld-objekt. Dette er altså EJB ens EJB-objekt (se forrige kapittel). Det som skjer når klienten kaller create()-metoden er at tjeneren vil om nødvendig opprette et EJBimplementasjonsobjekt og tilhørende EJB-objekt og så returneres referansen til EJB-objektet som klienten bruker som portal til EJB-implementasjonsobjektet. En klient vil derfor (vanligvis) kalle create() når den skal ha kontakt med en EJB, men det er ikke sikkert at dette faktisk fører til opprettelsen av nye objekter. Dette blir opp til tjeneren å bestemme (denne logikken kan ligge i selve home-objektet som også blir omtalt som et fabrikkobjekt) Kommentar til Home- og Remote-interfacet Forklaringene over er faktisk litt forenklet i forhold til virkeligheten. Kapittel i boka forklarer at det ikke nødvendigvis vil være noen sammenheng mellom interfacet Home og home-objektet. Det samme holder stikk for Remote-interfacet og EJB-objektet. For oss spiller dette imidlertid ingen rolle, da dette blir helt og holdent opp til de som lager applikasjonstjeneren. Forenklingen over er derfor i mine øyne å foretrekke framfor den mer detaljerte. 2.3 Klienten Klienten for HelloWorld-applikasjonen vil se slik ut: 7

9 import javax.ejb.*; import javax.naming.*; public class HelloWorldClient{ public static void main(string args[]){ try{ System.out.println("starter"); Context context = new InitialContext(); System.out.println("etter context"); Object objref = context.lookup("hello"); System.out.println("ferdig med lookup "); HelloWorldHome home = (HelloWorldHome) javax.rmi.portableremoteobject.narrow(objref, HelloWorldHome.class); System.out.println("ferdig med casting"); HelloWorld hello = home.create(); System.out.println("ferdig med create()"); System.out.println(hello.getHelloWorldString()); catch(exception e){ System.out.println(e); Ok, la oss oppsummere gangen. Punktene under vises også i figuren lenger ned. Når en klient vil snakke med en EJB så vil den 1. først finne tak i home-objektet via et JNDI-oppslag 2. og via å kalle create() på dette fjernobjektet vil man 3. sørge for at det blir opprettet/gjenbrukt en EJB-implementasjonsobjekt 4. og tilhørende EJB-objekt. 5. Referansen til EJB-objektet returneres til klienten. 6. Klienten kaller metoder på EJB-objektet som formidler kallene videre til EJBimplementasjonsobjektet. Returverdier går samme vei tilbake. 7. 8

10 Klient //gjør JNDI-lookup for å finne home-objektet //dette må castes til riktig interface HelloWorld hello = home.create(); String str = hello.gethelloworldstring(); 1 Container homeobjekt (basert på HelloWordHome) EJBimplementasjonsobjekter HelloWorldBean HelloWorldBean 6 4 EJB-objekt (basert på HelloWorld) HelloWorldBean EJB-objekt (basert på HelloWorld ) Av figuren over kan du også se at home-objektet og EJB-objektet faktisk blir en del av containeren. 2.4 Navnekonvensjoner Vi følger følgende navnekonvensjoner i dette kurset. En EJB ender bestanding med Bean, for eksempel HelloWorldBean. Home-interfacet slutter bestandig med Home og blir da HelloWorldHome. Remote-interfacet får ingen ending og blir bare HelloWorld. 2.5 Lokale interface og skalerbarhet Det finnes to interface som vi ennå ikke har vært inne på. Dette er de lokale interfacene LocalHome og Local. Disse interfacene utfører samme oppgave som fjern interfacene Homeog Remote (beskrevet tidligere), bortsett fra at de er beregnet på klienter som ligger på samme maskin som EJB en (og i samme JVM). Dette kan for eksempel være andre EJB er. Hvis vi har en EJB-implementasjonsklasse som heter HelloWorldBean så vil fjern interfacene hete HelloWorld og HelloWorldHome, de lokale vil hete HelloWorldLocal og HelloWorldLocalHome. Navnekonvensjonen for disse interfacene er altså bare å slenge på Local. De lokale interfacene vil være som fjern interfacene med unntak av at ingen av metodene hiver RemoteException og at de arver fra EJBLocalHome og EJBLocalObject i stedet for EJBHome og EJBObject. 9

11 For mer informasjon les kapittel 3 i boka. Fordelen med de lokale variantene av interfacene er at vi i dette tilfellet slipper en del overhead som er nødvendig ved kommunikasjon over nettverk. Vi skal senere i kurset se at vi må bruke disse interfacene i forbindelse med Entity Beans, men i de fleste tilfeller vil det ikke være naturlig å bruke de lokale variantene i forbindelse med Session Beans. Dette fordi klienten ofte vil ligge på en annen maskin. I tillegg så vil vi miste muligheten for å spre EJB en på flere maskiner, noe som er mye av poenget med å bruke EJB er i første omgang. På denne måten vil man kunne skalere systemet etter hvert. Med dette menes at man kan starte med en maskin, og ved behov legg til flere maskiner. Dette er ofte aktuelt, da man ikke i starten har oversikt over hvor stort behovet kan bli etter hvert. Flere faktorer bestemmer hvor stor belastning det blir på et system. For eksempel kan det være slik at systemet ble mye mer populært enn man hadde trodd. Det ble 1000 klienter i stedet for 200 som systemet ble laget for. Applikasjonen har blitt utvidet etter hvert, og krever nå mer ressurser enn tidligere. I slike tilfeller er det utrolig greit å kunne skalere systemet bare med å legge til flere tjenere slik at ballasten kan spres mellom disse. 2.6 Deployment descriptor (dd) Nå har vi kommet så langt at du begynner å forstå hvordan hele systemet med applikasjonstjener og EJB fungerer. Det er en ting som mangler for å komplettere bildet. Vi har tidligere vært inne på at containeren sin oppgave (gjerne igjennom home/ejb-objektene) faktisk har som oppgave å sørge for en del tjenester til EJB en. Dette kan som tidligere omtalt for eksempel være å sjekke om brukeren faktisk har rettigheter til å kalle en bestemt metode på EJB en. Hvordan gjøres så dette i praksis? Det vi trenger er en fil der disse reglene er beskrevet. Da kan containeren bruke denne filen og reglene som ligger i denne til å løse sine oppgaver. <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN' ' <ejb-jar> <display-name>helloworldjar</display-name> <enterprise-beans> <session> <display-name>helloworldbean</display-name> <ejb-name>helloworldbean</ejb-name> <home>helloworldhome</home> <remote>helloworld</remote> <ejb-class>helloworldbean</ejb-class> <session-type>stateless</session-type> <transaction-type>bean</transaction-type> <security-identity> <description></description> <use-caller-identity></use-caller-identity> </security-identity> </session> </enterprise-beans> </ejb-jar> 10

12 Over ser du dd (deployment descriptor) for HelloWorld EJB en. Det er mye forskjellig som kan stå i en slik XML-fil. Med fet skrift kan du se hva navnet på EJB en er, hva som er dennes Remote-interface og Home-interface. Dette er nødvendig da containeren må vite hvilket interface som tilhører EJB en HelloWorldBean for å kunne opprette home-objektet og EJB-objektet. Vi kan også se at dette er en tilstandsløs (stateless) EJB. Mer forklaring på dd finner du i appendix b i boka. Det er fullt mulig å lage slik filer som vist over selv, men dette er en jobb som er mye bedre egnet for verktøy. Vi skal bruke deploytool for dette. 2.7 Hva er en komponent? Vi har vært bort i begrepet komponent tidligere, men du sitter sikkert med en følelse av at du ikke helt vet hva det er. En komponent kan lages av en utvikler, men den skal kunne brukes rundt omkring i forskjellige omgivelser og systemer. Er så EJB en komponenten. Tja. Det spørs vel hva man legger i begrepet EJB. I denne leksjonen har vi omtalt en EJB som bestående av EJB-implementasjonen og nødvendige interface (lokale og/eller fjerne). I tillegg så vil det være en dd inn i bildet. Dette utgjør til sammen EJB-komponenten. Filene pakkes sammen i en jar-fil (dette er en arkivfil og kan sammenliknes med en zip-fil) og blir således en komponent. Jar-filen vår vil se slik ut: HelloWorldBean.class HelloWorld.class HelloWorldHome.class META-INF/ ejb-jar.xml META-INF er en katalog i jar-filen. Filen ejb-jar.xml er dd-filen beskrevet i forrige kapittel. Deploytool sørger for å lage denne jar-filen for oss. 2.8 Hvordan bruke komponentene? For å bruke komponenten beskrevet over, må vi gjøre noe mer. Vi må nemlig legge den ut på applikasjonstjeneren. I denne prosessen vil vi også tildele komponenten JNDI-navn (vi kan også konfigurere andre ting, men det kommer senere). Det er viktig å skjønne at vi må sette JNDI-navnet i det vi legger komponenten ut på applikasjonstjeneren (se kapittel 3.4). Utvikleren av komponenten kan ikke sette dette fordi vi da fort kan få navnekonflikter om vi bruker komponenter fra flere leverandører. Når vi skal legge ut komponenten vår så gjør vi det på den måten at vi pakker den inn i en earfil. Dette er også en arkivfil, men dette er en fil som inneholder en Enterprise (J2EE) applikasjon, som igjen kan inneholde en eller flere komponenter. I det vi legger ut denne earfilen på tjeneren vil det bli laget en XML-fil til som blant annet inneholder hvilket JNDI-navn de ulike komponentene skal ha. Dette er en fil som er spesifikk for den aktuelle applikasjonstjeneren. 3 Bruk av deploytool Bruken av deploytool vil være en viktig del av kurset siden vi skal bruke dette verktøyet til å sette sammen applikasjonene våre. Du skal nå selv få pakke HelloWorld-eksemplet i en ear-fil og legge denne ut på applikasjonstjeneren. 11

13 Last ned HelloWorld.zip fra fagets web-side. Pakk ut disse filene i en katalog. Du skal da ha filene HelloWorldBean.java HelloWorld.java HelloWorldHome.java Først bør du starte applikasjonstjeneren (du bør gjøre dette før du starter deploytool fordi deploytool kobler seg opp mot applikasjonstjeneren). Skriv (i et kommandolinjevindu): j2ee verbose Nå starter vi opp deploytool. Skriv (i et kommandolinjevindu): deploytool Når deploytool har startet opp, velg File > New > Application. Dette angir at vi nå skal lage en ny J2EE-applikasjon. Det vil få opp følgende vindu: : I feltet Application File Name angir vi navnet på filen til å være HelloWorld.ear (i katalogen d:\pakker..). Application Display Name bestemmer bare hvilket navn som vil vises i deploytool, og har ingen betydning utover at du bør gi applikasjonen et navn som du kjenner igjen. Trykk ok. Deploytool vil da se slik ut: 12

14 Av figuren over ser du at applikasjonen HelloWorld (gitt av Application Display Name i forrige figur) er opprettet. Informasjonen om denne applikasjonen lagres i filen HelloWorld.ear som oppgitt i forrige figur. Vi har nå opprettet selve applikasjonen, men vi mangler foreløpig innhold. Det naturlige nå vil være å legge til en (eller flere ) EJB. Velg File > New > Enterprise Bean Du vil da se følgende: 13

15 Skjermen over gir deg detaljer om hvilke innstillinger du kan gjøre for en EJB. Vi kommer nærmere tilbake til muligheter senere, men du kan gjerne lese det som står. Trykk Next. 14

16 Sørg for å velge Create New JAR File in Application. I nedtrekkslisten velger du riktig applikasjon (vi har gitt vår nye applikasjon navnet HelloWorld og velger derfor denne). Det som skjer nå er at det blir opprettet en ny jar-fil som inneholder EJB en vår. Vi velger å gi denne navnet HelloWorldJAR, men du kan selv velge et hvilket som helst navn. Ok, nå skal vi velge hvilke filer som skal ligge i jar-filen vår. Dette skal da være EJBimplementasjonen og tilhørende interface (Remote- og Home-interface). Trykk på knappen edit. Du får da opp et skjermbilde der du velger filene som utgjør komponenten din. 15

17 Først må du finne katalogen hvor EJB-filene ligger lagret. Disse må nå være kompilert (alle filene i en katalog kompileres med javac *.java). Velg så de filene som skal være med i det øverste vinduet og trykk Add. Du vil da i nederste del av vinduet se hvilke filer som er lagt til i jar-filen (komponenten). (Husk at en komponent består av Bean/Remote/Home-filene). Trykk så OK. Du vil da se: 16

18 Trykk så Next. 17

19 Sørg for å gjøre samme valg som vist i figuren over. HelloWorldBean er som tidligere nevnt en tilstandsløs (Stateless) SessionBean, så vi velger dette. I nedtrekksmenyen Enterprise Bean Class velger vi Bean-klassen, som her vil være HelloWorldBean. Enterprise Bean Name vil bare være navnet som vises på EJB en i deploytool, så her kan du gi det navnet du ønsker. Vi har nå oppgitt hva som er EJB-implementajonsklassen, men som tidligere forklart blir det ikke en komponent uten tilhørende Remote/Home-interface. Vi må derfor oppgi hva som er komponentens Remote Home Interface. Dette er det samme som Home-interfacet og blir følgelig HelloWorldHome. Tilslutt oppgir vi Remote-interfacet til EJB en som er HelloWorld (du husker vel navnekonvensjonene?). For Local interfaces oppgir vi i dette tilfellet ingenting. Grunnen er rett og slett at vi ikke har noen lokale interface. Det vil være tilfeller hvor vi også har dette (evt. bare slike interface). Trykk nå Next og så Finish. Skjermbildet vil da bli slik: 18

20 Se på figuren over. Da kan du se at feltet JNDI Name ikke er fylt ut for HelloWorldBean. For at klienten skal finne komponenten vår må vi derfor fylle ut et JNDI-navn. I klienten har vi gjort det slik at vi leter etter JNDI-navnet Hello. Vi fyller derfor inn dette navnet, og resultatet blir slik: Ok, nå har vi faktisk en ferdig applikasjon som inneholder en EJB. For at denne applikasjonen skal være litt mer meningsfylt vil det være naturlig å lage en klient. Den enkleste måten å 19

21 gjøre dette på er å bruke deploytool. Verktøyet vil da sørge for å legge til nødvendige pakker/klasser som trengs for å kjøre klienten (husk at vi trenger pakker fra J2EE SDK her, og ofte også pakker som er spesifikk for den enkelte applikasjonstjener). Velg File > New > Application Client. Les så informasjonen som dukker opp og trykk Next. Skjermbildet blir da slik: Velg i øverste del av vinduet filen for klienten (i vårt tilfelle blir det HelloWorldClient.class) du har laget og trykk Add. Trykk så OK og Next. 20

22 Sørg for å velge riktig Main Class for klienten. Dette vil være HelloWorldClient (vi må fortelle dette, da klienten kan bestå av flere klasser. Det vi gir beskjed om er i hvilken klasse man finner main()-metoden som starter klienten). I Display Name setter vi et navn som blir vist i deploytool. Trykk så Next og Finish. Da har vi en fullstendig applikasjon, med tilhørende klient. 21

23 Det som gjenstår nå er å legge applikasjonen ut på applikasjonstjeneren. Dette gjør vi ved å velge Tools > Deploy. I figuren over velger du hvilken applikasjon som skal legges ut (deploy). Vi har foreløpig bare muligheten for å velge en applikasjon og velger derfor HelloWorld. Target Server angir på hvilken tjener (applikasjonstjener) vi vil legge ut applikasjonen på. For oss så vil dette bli localhost, dvs. at applikasjonstjeneren kjører på samme maskin som deploytool. Sørg for å krysse av for Return Client Jar og velg hvilket navn denne jar-filen skal få (lagre på samme katalog som du lagret ear-filen). Denne jar-filen vil nå inneholde nødvendige pakker for å kjøre klienten. Trykk nå Finish. 22

24 Forhåpentligvis vil du se skjermbildet over. Hvis ikke har du gjort noe feil. Se da kapittel 3.1. Da tester vi applikasjonen vår. Skriv på kommandolinjen: set APPCPATH=<sti>\HelloWorldClient.jar <sti> skiftes ut med stien til der du lagret HelloWorldClient.jar. Skriv så: runclient client HelloWorld.ear name HelloWorldClient textauth Sørg for å stå på katalogen hvor HelloWorld.ear er lagret når du skriver kommandoen over. Brukernavn er guest og passord er guest123 (det fungerer også med bare enter til meg). Dette er måten vi skal kjøre J2EE-applikasjoner på. Når vi lager nye applikasjoner vil vi imidlertid skifte ut HelloWorldClient/HelloWorldClient.jar/HelloWorld.ear med tilsvarende for den nye applikasjonen. 3.1 Bruk av verifier i deploytool Får du feilmeldinger når du skal legge ut applikasjonen? Deploytool har et eget verktøy for å hjelpe deg i slike tilfeller. Det er mange grunner til at du kan få feil i en applikasjon/komponent. La oss si at du lager følgende metode i Remote-interfacet HelloWorld. public String gethelloworldstring() Når du skal lage EJB-implementasjonen HelloWorldBean så skriver du feil og metoden blir slik: public String gethellworldstring() 23

25 Merk at det mangler en o i navnet på metoden over. Du kan gjerne prøve å forandre koden i eksemplet slik at du prøver dette. Kompilering av interfacene/klassene går fortsatt greit. Når vi prøver å legge ut applikasjonen får vi imidlertid denne feilmeldingen: Problemet er at de to metodene ikke harmonerer. Java kompilatoren har imidlertid ingen måte å finne ut dette på fordi EJB-implementasjonensklassen implementerer ikke Remote-interfacet (det er det EJB-objektet som gjør). Når slike feilsituasjoner oppstår sørg for å merke applikasjonen det er snakk om i deploytool. Trykk så Tools > Verifier. Figur 4: Verifier i deploytool 24

26 Se på boblene i figuren over. La meg beskrive hva som skjer i forhold til hver enkelt boble: 1. Her kan du se at riktig applikasjon er valgt. 2. Her velger du hvilke meldinger du vil se. Jeg har her valgt bare å få feilmeldinger. Det kan også være fornuftig å se warnings, da dette kan gi tilbakemeldinger på at du har gjort noe du strengt tatt ikke burde 3. Ved å velge en av linjene i tabellen vil du i vindu 4 (boble 4) se 4. en beskrivelse av feilmeldingen. Vi kan her se at Remote-interfacet HelloWorld har metoden gethelloworldstring(), men at det ikke finnes en tilsvarende metode i HelloWorldBean. Dette må derfor rettes opp. 3.2 Update Files Når du har gjort oppdateringer i koden din må du sørge for at deploytool blir gjort oppmerksom på dette. Dette er viktig hvis du skal kjøre verifier på nytt, eller at du skal legge ut en oppdatert versjon av koden på applikasjonstjeneren. I deploytool kan du velge Tools > Update Files. Du vil da få opp et vindu med hvilke jar-filer som inneholder endringer. Trykk OK og alt skal være i orden. Du kan også sørge for å oppdatere og legge ut filene på applikasjonstjeneren i en fei. Du velger da Tools > Update and Redeploy. Merk at verifier ofte ikke får med seg oppdateringer gjort i koden din uten at du velger Tools > Deploy etter at du har gjort Tools > Update Files. 3.3 Deploytment descriptor (dd) I deploytool har du også muligheten til å se dd for applikasjonen din. Ved å merke av applikasjonen og trykke Tools > Descriptor Viewer vil du se dd en for selve applikasjonen. Hvis du i stedet merker av komponenten så vil du se dd en til denne. Det samme gjelder hvis du merker av for klienten, da vil du se klientens dd. 3.4 Indirekte bruk av JNDI-navn Jeg håper nå du begynner å bli fortrolig med hvordan J2EE-applikasjoner lages. I gjennomgangen av HelloWorld-eksemplet hoppet vi over en ting. Klienten leter opp JNDInavnet Hello. I deploytool setter vi JNDI-navnet til EJB en til å være Hello. Dette fungerer derfor fint. Klienten finner EJB en. Det er imidlertid et problem. La oss si at både du og jeg lager en applikasjon. Du kaller din HelloWorld og jeg kaller min HelloW. Vi begge lager klienter til applikasjonene som bruker JNDI-navnet Hello for å lete opp EJB en. Dette blir selvsagt trøbbel. Vi kan ikke ha to EJB er knyttet til samme JNDI-navn. I dette tilfellet er jo enkelt å endre en av klientene slik at den leter opp et annet JNDI-navn og å knytte den ene EJB en mot dette navnet. Hva om begge applikasjonene er laget av to amerikanske bedrifter, og du har kjøpt disse komponentene? Du vil bruke begge på samme applikasjonstjener, men problemet er at du har en navnekonflikt. Du har ikke java-filene, men kun de kompilerte filene. Hva gjør du da? For å løse denne type problemer har man valgt en noe mer indirekte måte å finne EJB er. I stedet for å gjøre JNDI-lookup på navnet Hello i klienten, gjør vi oppslag på JNDI-navnet 25

27 java:comp/env/ejb/hello. Merk at begge klientene i eksemplet over kan gjøre oppslag på java:comp/env/ejb/hello. Løsningen ligger i å ha egen mapping for hver enkelt applikasjon. I den ene applikasjonen vil navnet mappes til f.eks. JNDI-navnet Hello, mens i den andre applikasjonen vil navnet mappes til JNDI-navnet HelloWorld. Hver applikasjon (komponent) kan derfor sies å ha sin egen lokale JNDI-context hvor denne mappingen foregår. Merk at vi gir applikasjonene ulikt JNDI-navn. Dette kan vi bestemme i det vi legger ut applikasjonen. I figuren under har jeg lagt til en ekstra klient til eksemplet. Jeg har kalt denne klienten HelloWorldClientIndirectLookup. Ved å merke denne klienten og trykke på skillearket EJB Refs får jeg opp følgende figur. Her har jeg muligheten til å spesifisere navnet som brukes til oppslag (lookup) i klienten, og hva klienten faktisk venter å finne med oppslaget. Ved å trykke på Add kan jeg spesifisere nettopp dette. Klienten bruker java:comp/env/ejb/helloworldexample i sitt oppslag. Coded Name blir da siste del av dette oppslaget; ejb/helloworldexample (java:comp/env er implisitt gitt). Ok, da har vi forklart strengen klienten bruker i oppslaget. Vi må så spesifisere at klienten venter å finne en Session EJB, så vi velger Session i feltet Type. I feltet Interfaces velger vi Remote da vi ikke bruker lokale interface. Skriv så inn navnet på Home-interfacet og Remote-interfacet til EJB en. Da gjenstår bare å oppgi hvilken EJB det er snakk om. Dette kan vi enten gjøre ved å spesifisere JNDI-navnet (dette spesifiserte vi tidligere. Du kan finne dette med å trykke på komponenten og velge skillearket JNDI) eller du kan direkte spesifisere navnet på EJB-implementasjonen. Figuren under viser mappingen for vår klient. 26

28 Prøv selv å lage deg en klient til som bruker java:comp/env/ ved oppslag etter EJB en. Fortsett å bruke denne metoden senere. 27

29 Oppgaver 1) Vedlagt denne leksjonen finner du klassene ValutaKurser og Valuta. Du nå lage en Tilstandsløs EJB som omregner fra en valuta til en annen. All logikk for denne omregningen finner du i klassen ValutaKurser så dette er kode du ikke trenger å lage. Det du må lage er: EJB-implementasjonsklassen som bruker ValutaKurser. Denne klassen må ha en forretningsmetoden public double regnom(string fravalutanavn, String tilvalutanavn, double belop). I tillegg må klassen selvsagt inneholde de nødvendig Session Bean metodene. Klassen skal hete ValutaOmregnerBean. Nødvendige interface til EJB en. Merk at når du nå skal bruke klassene ValutaKurser og Valuta så må disse klassene pakkes i samme jar-fil som EJB-implementasjonsklassen og interfacene. Du må altså også sørge for også å velge disse klassene når du lager EJB jar-filen i deploytool. Du kan bruke den ferdiglagde klienten ValutaKlient lagt ved leksjonen. Det som skal leveres er en ear-filen for applikasjonen (applikasjonen må også inneholde en klient). 2) Du har nå laget en J2EE-applikasjon. Forklar hvilke filer som må ligge i jar-filen til klienten. 3) Du har nå brukt fjern-interface (Remote/Home) i det du lagde EJB en. Hva ville du kalt interfacene om du skulle ha brukt de lokale variantene i stedet? Hvorfor kan det være ønskelig å velge de lokale-interfacene i stedet for de fjerne? 28