Björn Persson. Komponenter med J2EE. Del 2

Transkript

1 Del 2 Komponentbaserad applikationsutveckling december 2005

2 Om denna sammanfattning Detta är del 2 av sammanfattningen. Denna del behandlar EJB och relationer mellan EJB. Del 1 behandlar teknologier som bör förstås för att bättre kunna skapa applikationer med EJB. Avsikten med denna sammanfattning är att ge en introduktion till Sun s Java 2, Enterprise Edition (J2EE) och hur man skapar komponenter (d.v.s. EJB) med J2EE. Sammanfattningen har skrivits av författaren för att lära sig, och just sammanfatta, hur dessa teknologier fungerar. Detta är inte en ersättning till eventuell kurslitteratur! Kapitlen i denna sammanfattning har inte skrivits så att de är oberoende av varandra, d.v.s. de bör läsas från första till sista. Senare kapitel om relationer är dock inte tänkta att läsas från början till slut, utan skummas för att återkomma till när kunskapen i dem behövs. Koden i denna sammanfattning har skapats med Java 2, Enterprise Edition (J2EE) SDK version 1.4.x på datorer med operativsystemen Windows XP/2003. För att köra EJB så har Resin v. 3.0.x använts ( om en annan EJB-server används så kan exempel behöva justeras för att fungera). Som databashanterare har främst MySQL använts ( men vissa exempel har även testats i Oracle ( Övrig programvara som använts är Java-programmeringsmiljön JCreator ( för att skapa EJB och servlets), text-editor Crimson Editor ( för att skapa deployment descriptors, webbsidor, JSP samt skärmdumpar av mappstrukturer) och Microsoft Visio 2003 för klass- och sekvensdiagram (samt givetvis Word 2003 för detta dokument samt CutePDF och Adobe Acrobat för att skapa PDF ). Konventioner i sammanfattningen Vissa engelska begrepp saknar generellt accepterade översättningar och är därför skrivna på engelska för att kunna relatera till begreppen i engelsk litteratur. I de fall då översättning används så följs det översatta ordet första gången med det engelska inom parentes. Dessa ord skrivs i kursiv stil för att visa att de har lånats, t.ex. servlet och Java-bönor (Java beans). 1 Kod har skrivits med typsnitt av fast bredd (Courier New) för att göras mer lättläst samt längre exempel har inneslutits i en ram (se exempel nedan). envariabel = //Kommentarer i kod skriv med fet stil Jag är givetvis tacksam för alla konstruktiva synpunkter på sammanfattningens utformning och innehåll. Eskilstuna, december 2005 Björn Persson, e-post: bjorn.persson@mdh.se Ekonomihögskolan, Mälardalens högskola Personlig hemsida: 1 Eftersom många termer i J2EE saknar bra översättning, t.ex. servlets och deployment descriptor, så skrivs dessa endast med kursiv stil i de avsnitt de introduceras i (och för att spara tid för mig vid redigering ) /83

3 Innehållsförteckning 10 ENTERPRISE JAVABEANS (EJB) Introduktion EJB-komponenters uppbyggnad Exempel på gränssnitt och klasser för en EJB-komponent Entity, Session och Message-driven beans Transaktioner, objektpoolning och samtidighet Entity beans Kompilera och testa EJB Entity beans exempel Entity beans exempel med sammansatt primärnyckel Entity beans och EQL [ UTVECKLA ] Session beans Session beans exempel med stateful session bean Session beans stateless session bean Message-driven beans RELATIONER MELLAN EJB Grundläggande om relationer Exempel på implementationer av EJB-relationer Enkelriktad 1:1-relation Dubbelriktad 1:1-relation Enkelriktad 1:M-relation (en till många) Dubbelriktad 1:M-relation (och även M:1-relation) Enkelriktad M:1-relation (många till en) Enkelriktad M:N-relation (många till många) Dubbelriktad M:N-relation (många till många) Slutsats LITTERATURFÖRTECKNING Webbadresser till förlag Webbadresser ATT GÖRA (?): * Förklara EJB:ers olika livscykeltillstånd. * Förklara relationer och local-gränssnitt. * get-metoder i local- resp. remote-gränssnitt. * Förklara relationer med sammansatt nyckel? * Göra en sammanfattning om datorbokningssystem? /83

4 10 Enterprise JavaBeans (EJB) Enterprise JavaBeans (EJB) är en del av Sun s Java 2, Enterprise Edition (J2EE). Detta är den mest intressanta teknologin inom J2EE, i alla fall om vi talar om komponenter i distribuerade applikationer. Övriga teknologier i J2EE (och J2SE, t.ex. JNDI 2, JDBC 3 och RMI 4 ) är stöd för EJB, d.v.s. teknologier som krävs för att EJB ska fungera (och som vi bör ha en grundläggande förståelse av). EJB är komponenter som ska exekvera på en server och används därför av klienter över nätverk (eller via ett webbgränssnitt, servlets/jsp). Genom att placera komponenterna på en server så centraliseras affärslogiken, vilket gör det lättare att uppdatera applikationer. Centraliseringen gör även livet lättare för administratörer då endast ändringar i gränssnitt kräver uppdateringar av klientdatorer. Ytterligare en fördel med centralisering är att säkerheten kan ökas då den bara behöver upprätthållas på ett ställe. En nackdel med centralisering är att om servern havererar så är inte applikationen tillgänglig för klienterna. Detta kan lösas genom att duplicera applikationen på flera servrar (spegling eller klustring) Introduktion En EJB 5, d.v.s. komponenten, motsvarar bl.a. av en klass i de klassdiagram som tas fram i analysfasen vid utveckling av applikationer. Men en EJB implementeras med ett antal gränssnitt och klasser, d.v.s. inte bara en klass som i vanliga objektorienterade applikationer. Dessa klasser och gränssnitt betraktas som en enhet, d.v.s. en EJB. Ett av skälen till denna uppdelning av EJB i delar är för funktion. En del är, vad jag kallar, gränssnittet för livscykelhantering (vars riktiga namn är home-gränssnitt) ett gränssnitt vi kan fråga efter en existerande instans av EJB eller skapa en ny instans. Metoder i detta gränssnitt returnerar en referens till EJB:s, vad jag kallar, gränssnitt för affärslogik (vars riktiga namn är remote-gränssnitt). När vi har en referens till EJB:s affärslogikgränssnitt, så anropas metoder i gränssnittet som om EJB vore ett vanligt objekt (precis som med RMI). Denna uppdelning, och antal nya termer, kan till en början göra att utveckling av EJB:er kan kännas svårt (komplext), men med några EJB under bältet så brukar ett mönster framgå. 6 Att använda en EJB påminner om hur man använder distribuerade objekt med RMI. Precis som med RMI så registreras objekt i en namntjänst skillnaden är dock att vi registrerar home-gränssnittet istället för själva objektet. Registrering av home-gränssnittet sker då vi installerar EJB i EJB-server (oftast genom att vi kopierar EJB till en speciell mapp). För att kunna skapa eller hitta en instans av EJB så frågar vi sen EJB-server (eller snarare dess namntjänst) efter en referens till home-gränssnittet (via JNDI). Via home-gränssnittet så anropar vi metoder för att hitta eller skapa en instans av EJB, d.v.s. för att erhålla en referens till instans (dess remote-gränssnitt). Denna (andra) referens kan sen betraktas som ett vanligt objekt, om än med något längre svarstid om instansen finns på en annan dator i nätverk. 2 JNDI används för att erhålla referenser till instanser av EJB. 3 JDBC används inte direkt EJB-server gör (eller kan göra) jobbet åt oss. 4 RMI används när metoder i EJB anropas (utan att vi märker det, annat än prestandamässigt ) dock används inte RMI-register, m.m.. 5 Förkortningen EJB använder jag för både en komponent, böna, och för teknologin Enterprise JavaBeans. Sammanhanget avgör (eller bör avgöra) vilket som menas. 6 J2EE är, liksom de flesta Java-teknologierna, en relativt komplex teknologi men mycket genialisk. Detta gör ofta att Java-teknologier är aningen svårare att lära sig men också oftast värt mödan när man ser det genialiska /83

5 EJB-instans (distribuerat objekt) 5. Erhåll referens till EJB-instans Home-gränssnitt 1. Installera EJB EJB registreras i namntjänst 6. Använd referens till EJB-instans 4. Anropa metod för att hitta eller skapa instans av EJB 2. Begär referens till home-gränssnitt EJB-server/ namntjänst Klientapplikation 3. Erhåll referens till home-gränssnitt För att lättare kunna distribuera en EJB:s gränssnitt och klasser så paketeras dessa i JAR-filer (ZIP-filer med.jar som filändelse). För att koppla samman gränssnitt och klasser i EJB, samt beskriva för EJB-servern vilka tjänster som komponenten ska använda, så använder vi en XML-fil kallad deployment descriptor. Det finns två typer av komponenter: datakomponenter och arbetskomponenter. En datakomponent, kallat entity beans i EJB, och motsvarar data som lagras i datakällor (främst relationsdatabaser i J2EE). Arbetskomponenter motsvarar fasadklasserna, d.v.s. klasserna som skapas för att hantera logiken i objektorienterade applikationer, och kallas session beans i EJB. (Entity och session beans behandlas mer ingående senare i kapitlet.) I en J2EE-server så exekverar EJB i, vad som kallas, en container (eller EJB-container). Uppgiften för en container är att skapa en miljö för EJB:s att exekvera i samt erbjuda tjänster (t.ex. transaktionshantering) till EJB. Tjänsterna som containers erbjuder sparar utvecklare timmar med arbete då de slipper utveckla tjänsterna om och om igen (eller snarare anpassa efter att dom utvecklats första gången). Nackdelen med att använda tjänsterna är att det kostar i form av prestanda de har gjorts generella för att kunna användas av alla typer av komponenter. (I de fall då prestanda är mycket viktigt så kan det alltså vara värt tiden att själv utveckla de tjänster som önskas.) Ett skäl till att använda containers är för att skärma EJB från den faktiska implementationen av J2EE-serverar. Containers (eller snarare J2EE-servern) implementerar gränssnitten i J2EE som Sun definierat. (Allt detta leder till att redan existerande applikationsservrar kan utöka sin funktionalitet genom att, utöver redan existerande funktionalitet, implementera J2EEgränssnitten och nå fler kunder.) I Resin så exekverar EJB och servlets/jsp i samma container, d.v.s. servlets kan använda EJB:ers local- och local home-gränssnitt (se nedan för förklaring av begrepp). Av denna anledning kommer (för enkelhetens skull) alla EJB-exempel att använda servlets som klienter i denna sammanfattning EJB-komponenters uppbyggnad En EJB-komponent består som sagt av flera delar: två (eller fyra) gränssnitt (interface), en eller två klasser samt en konfigurationsfil. Remote-gränssnitt definierar komponentens publika metoder mot klienten, d.v.s. affärslogiken. Metoder i detta gränssnitt motsvarar oftast de i klassdiagram som togs fram i analysfasen för applikation. Utökar gränssnittet javax.ejb.ejbobject Namnstandard: <Komponentnamn> Ex: Hus, Kund /83

6 Home-gränssnitt innehåller metoder för komponentens livscykel (skapande, sökande, m.m.). Utökar gränssnittet javax.ejb.ejbhome Namnstandard: <Komponentnamn>Home Ex: HusHome, KundHome Bean-klass implementerar komponentens affärsmetoder, och några av homegränssnittets metoder, men inte någon av ovanstående gränssnitt (mer om detta nedan). Implementerar gränssnittet javax.ejb.entitybean eller javax.ejb.sessionbean Namnstandard: <Komponentnamn>Bean 7 Ex: HusBean, KundBean Primärnyckelsklass (primary key class endast entity bean) behöver endast skapas om primärnyckel i tabell är sammansatt, d.v.s. består av fler än ett värde (annars kan vi använda klasser som String eller någon av de primitiva typernas wrapper-klasser 8, t.ex. Integer för int och Float för float). 9 Implementerar gränssnittet java.io.serializable Namnstandard: <Komponentnamn>PK Ex: HusPK, KundPK Deployment descriptor (en textfil med XML) kopplar samman de två gränssnitten, bean-klassen och eventuell primärnyckelsklass. I EJB versioner tidigare än 2.0 så måste alla klienter, d.v.s. även andra EJB i samma container, använda remote- och (remote-)home-gränssnitt. Detta innebar att alla klienter måste använda RMI för att nå en EJB. Om klienten finns på en annan dator så är RMI ett måste, men om klienten finns på samma dator så är RMI mer av ett hinder (overhead). I EJB version 2.0 introducerades gränssnitten local och local home. Tanken var att klienter i samma container (d.v.s. andra EJB) skulle kunna hoppa förbi RMI och gå direkt på EJB, d.v.s. göra lokalt användande mer effektivt. Därmed kan en EJB har två eller fyra gränssnitt (remote och home och/eller local och local home). Local-gränssnitt definierar komponentens publika metoder mot klienten, d.v.s. affärslogiken. Detta motsvarar remote-gränssnittet, men kan endast användas av klienter i samma container som EJB. Utökar gränssnittet javax.ejb.ejblocalobject Namnstandard: <Komponentnamn> 10 eller <Komponentnamn>Local Ex: Hus, KundLocal Local home-gränssnitt innehåller metoder för komponentens livscykel (skapande, sökande, m.m.). Detta gränssnitt motsvarar home-gränssnittet, men kan endast användas av klienter i samma container som EJB. Utökar gränssnittet javax.ejb.ejblocalhome Namnstandard: <Komponentnamn>Home 11 eller <Komponentnamn>LocalHome Ex: HusHome, KundLocalHome Deployment descriptor används även för att koppla samman local- och local homegränssnitten med övriga gränssnitt och klasser. 7 Vissa författare vill använda suffixet EJB, t.ex. KundEJB, istället för Bean. 8 En wrapper-klass är en klass som innesluter ett annat värde (eller objekt). I Java-versioner tidigare än 1.5 så måste vi förpacka värden av de primitiva typerna innan vi kan lagra dem i klasser som Vector (som tar ett argument av typen Object som inparameter till metoden add()). 9 I Resin så fungerar det att använda de primitiva typerna som primärnyckelsklasser, d.v.s. vi behöver inte använda wrapper-klasserna (vilket dock rekommenderas för att behålla kompabilitet). 10 Att inte använda suffixet Local fungerar endast om vi inte har ett remote-gränssnitt också. 11 Ibid /83

7 Exempel på gränssnitt och klasser för en EJB-komponent I detta första exempel (som borde 12 fungerar i alla version av EJB) skapas en väldigt enkel stateless session bean (utan implementation av metod) för att visa hur gränssnitt och bean-klass kan se ut. Namnet på EJB (liksom klass i klassdiagram till höger) är SvensktDatum och, för att följa namnstandard ovan, så ges remote-gränssnittet detta namn (d.v.s. SvensktDatum), home-gränssnittet SvensktDatumHome samt bean-klassen namnet SvensktDatumBean. Eftersom det är en session bean så behöver vi ingen primärnyckelsklass. Remote-gränssnitt Remote-gränssnitt ska innehålla metoder som motsvarar affärslogik för komponenter, d.v.s. de metoder för klasser som tagits fram i applikationens analysfas (metoderna i klassdiagrammet). Detta är alltså EJB:s publika ansikte. I detta exempel så innehåller klassen bara en metod idag() som returnerar en sträng med dagens datum i svenskt format (på formen åååå-mm-dd). Eftersom metoder i en EJB är tänkta att användas från klienter på andra datorer (och att RMI är protokollet för kommunikation ) så måste alla metoder i remote-gränssnittet slänga undantaget java.rmi.remoteexception. Gränssnittet måste därför också utöka (ärva från) gränssnittet java.rmi.remote. Detta gör vi genom att utöka gränssnittet javax.ejb.ejbobject, som i sin tur utökar gränssnittet Remote. Gränssnittet EJBObject innehåller även en del metoder som vi inte behöver implementera (de implementeras av EJBserver). import java.rmi.remoteexception; public interface SvensktDatum extends javax.ejb.ejbobject public String idag() throws RemoteException; //interface SvensktDatum Home-gränssnitt Home-gränssnitt innehåller metoder för att bl.a. kunna skapa (eller hitta existerande) EJB. I detta enkla exempel så behöver vi endast en metod för att kunna skapa en ny instans av EJB, d.v.s. metoden create() utan några parametrar. Detta är den enklaste formen av createmetoder, d.v.s. en create-metod kan finnas i flera former (d.v.s. med noll eller fler parametrar). Precis som med remote-gränssnitt så måste home-gränssnitt utöka gränssnittet java.rmi.remote, vilket man gör genom att utöka gränssnittet javax.ejb.ejbhome (som i sin tur utökar gränssnittet Remote). Och precis som metoder i remote-gränssnitt så måste även metoder i home-gränssnittet slänga java.rmi.remoteexception. Create-metoder måste även slänga javax.ejb.createexception. (find-metoder, i entity beans, måste även slänga javax.ejb.finderexception mer om detta när entity beans beskrivs). import javax.ejb.createexception; 12 Med borde menar jag att jag testat att kompilera koden i JCreator samt installera i Resin. Men lägg inte ner tid på att själva skriva av (eller kopiera) koden för att testa. Senare exempel är bättre för det. Övriga exempel med entity beans i sammanfattning fungerar endast med EJB version 2.0 och senare /83

8 import java.rmi.remoteexception; public interface SvensktDatumHome extends javax.ejb.ejbhome SvensktDatum create() throws RemoteException, CreateException; //interface SvensktDatumHome Bean-klass Komponentklassen (eller bean-klassen, bean class) innehåller implementationen av vår EJBkomponents publika metoder metoden idag() i detta fall. Men observera att denna klass inte implementerar (ärver från) vårt remote-gränssnitt! Detta kan verka underligt till att börja med, men detta är en genialisk (om än svårförståelig) lösning som objektorientering ger möjlighet till (mer om detta nedan). Eftersom detta är en session bean så måste vår bean-klass implementera gränssnittet javax.ejb.sessionbean, även om metoderna från gränssnittet inte behöver innehålla någon kod. public class SvensktDatumBean implements javax.ejb.sessionbean public String idag() String datumidag = null; //Kod för att skapa en sträng enligt svenskt format (åååå-mm-dd) return datumidag; /*** Implementera metoder i gränssnittet SessionBean *************************/ public void ejbcreate() public void setsessioncontext(javax.ejb.sessioncontext ctx) public void ejbremove() public void ejbactivate() public void ejbpassivate() //class SvensktDatumBean Exempel på en faktisk implementation av EJB Metoderna i remote- och «gränssnitt» home-gränssnitten ovan java.rmi.remote implementeras inte av våra bean-klasser, utan av en (eller flera) klass(-er) som EJB-server genererar «gränssnitt» när vi installerar 13 javax.ejb.ejbobject våra EJB i EJB-container. Hur genereringen sker avgörs av tillverkaren av EJBservern. «gränssnitt» SvensktDatum Den (eller de) av EJBservern genererade klassen(-erna) skapar sen instans av bean-klass när klienten anropar en metod +idag() : String «gränssnitt» javax.ejb.ejbhome +create() : SvensktDatum EJB_SvensktDatum +create() +idag() : String «gränssnitt» SvensktDatumHome «gränssnitt» javax.ejb.enterprisebean «gränssnitt» javax.ejb.sessionbean SvensktDatumBean +idag() : String +ejbcreate() 13 De genererade klasserna kan även genereras när EJB används första gången avgörandet om när görs av tillverkaren av EJB-servern (d.v.s. har inte definierats av Sun) /83

9 i remote-gränssnittet (ett anrop som hanteras av metod i genererad klass). Den genererade klassens metod kan sen anropar metod med samma namn i den nyskapade instansen av beanklassen. Mellan metodanrop kan EJB-server förstöra instansen av bean-klassen för att spara minne (om den så önskar). Detta är inget som vi behöver bry oss om eftersom vi (och andra användare av våra EJB) endast kommer använda gränssnitten remote och home. Men förståelse av hur det skulle kunna lösas bör underlätta förståelse för hur EJB fungerar (och varför EJB-specifikationen kräver flera gränssnitt och klasser för en EJB). I klassdiagram visas hur gränssnitt i J2EE-specifikationen relaterar till gränssnitt och klasser som skapas för en EJB. Klassdiagrammet visar även ett exempel på hur de genererade klasserna är relaterade till en EJB:s klasser och gränssnitt. Klasser och gränssnitt som vi behöver skapa har inneslutits i en ram. 14 Remote-gränssnittet (SvensktDatum) utökar (ärver) från EJBObject som i sin tur ärver från Remote och homegränssnittet (SvensktDatumHome) utökar EJBObject som också, i sin tur, utökar Remote. Eftersom vår EJB är en session bean så implementerar bean-klassen (SvensktDatumBean) gränssnittet SessionBean som i sin tur utökar gränssnittet EnterpriseBean. EJB-server skulle kunna generera en klass (EJB_SvensktDatum) som implementerar EJB:s gränssnitt samt använder sig av EJB:s bean-klass (SvensktDatumBean). Men EJB-server skulle, som sagt, även kunna generera flera klasser för att implementera gränssnitten. I Resin Namntjänst så genereras t.ex. en klass SvensktDatumBean EJB med tre bpn::klient inre (nästlade) klasser (Remote, Home lookup() och Bean). : SvensktDatumHome I sekvensdiagram 15 till höger visas : SvensktDatumBean hur metoder anropas för att skapa och fråga EJB SvensktDatum om create() ejbcreate() aktuellt datum och tid. Gränssnitten SvensktDatumHome och SvensktDatum implementeras som : SvensktDatum sagt av en klass (eller klasser) som idag() EJB-server genererar idag() (EJB_SvensktDatum i klassdiagram ovan). Deployment descriptor Uppgiften för en deployment descriptor är att koppla samma de två (eller fyra) gränssnitten med klasserna (bean- och primärnyckelklass) samt ange vilka av EJB-servers tjänster som EJB vill använda (men även för att koppla samman EJB med relationer mer om detta senare). Allt i en deployment descriptor innesluts av taggen <ejb-jar> 16 samt alla EJB:er i taggen <enterprise-beans>. Därefter använder vi en tagg <session> eller <entity> för att beskriva varje session respektive entity beans. För varje EJB krävs minst namnet som EJB ska 14 Ramen är inte UML-standard. 15 Det finns en svag risk att diagram inte är korrekt analys har aldrig varit min starka sida. 16 D.v.s. rottaggen för XML-dokumentet är <ejb-jar> /83

10 refereras till (JNDI-namn, <ejb-name>), fullständiga 17 namnen på gränssnitten remote (<remote>) och home (<home>) samt fullständigt namn på bean-klassen (<ejb-class>). För entity beans behövs ytterligare fler taggar (mer om detta senare). <ejb-jar> <enterprise-beans> <session> <ejb-name>svensktdatum</ejb-name> <home>svensktdatumhome</home> <remote>svensktdatum</remote> <ejb-class>svensktdatumbean</ejb-class> </session> </enterprise-beans> </ejb-jar> Eftersom en deployment descriptor består av XML så är skiftläge (gemen eller versal) och mellanslag viktiga (liksom stavning ). D.v.s. texten i deployment descriptor måste skrivas 100% rätt!. M.a.o. börja felsöka i deployment descriptor (speciellt om kod kopierats från t.ex. Word- och PowerPoint-dokument, som detta, i PDF-filer). Paketera EJB När gränssnitt och klasser kompilerats (till.class-filer), samt deployment descriptor skapas, så brukar man paketera EJB. Genom att paketera EJB så kan en EJB hanteras som en enhet/modul istället för 3-6.CLASS-filer och en XML-fil (i en eller flera mappar). EJB paketeras i JAR-filer (Java Archive, ett ZIP-arkiv med filändelsen.jar istället för.zip) med bibehållen mappstruktur (om EJB skapas i paket så ska.class-filerna ligga i en mappstruktur som motsvarar paketen och dess delar). Om en applikation ska innehålla flera EJB så brukar JAR-filer med EJB paketeras i ytterligare ett paket en EAR-fil (Enterprise Archive). En EAR-fil är en JAR-fil med filändelsen.ear (d.v.s. ytterligare ett ZIP-arkiv). Man packar alltså JAR-filerna i ytterligare en JAR-fil. Genom att packa flera EJB (d.v.s. JAR-filer) i en och samma fil så underlättar man för administratörer av applikationsservrar att installera en EJB-applikation. Mycket av denna paketering, men även skapande av deployment descriptor, brukar kunna göras med EJB-servrars installationsverktyg, ofta med ett grafiskt gränssnitt. Verktyget, liksom tjänster som EJB-server erbjuder, är det som gör att olika EJB-servrar konkurrerar med varandra om kunder. (För att komplicera det ytterligare så kan man även skapa WAR-filer, Web Archive, som innehåller HTML-filer och andra webbresurser för installation i J2EE-servrar med webbcontainer. Återigen är det ett ZIP-arkiv fast med filändelsen.war.) Om vi använder Resin så behöver vi inte packa filer i JAR-filer för att använda EJB (ytterligare ett själ till varför jag gärna använder Resin jag kompilerar gränssnitt och klasser direkt till webbserver ), även om vi kan det. En nackdel med Resin (i alla fall gratisversionen) är att det inte finns ett grafiskt verktyg för att skapa JAR- och EAR-filer. 17 Med fullständigt namn menas paketnamn och gränssnitts-/klassnamn, t.ex. paket1.paket2.klassnamn /83

11 Installera EJB När EJB paketerats är det dags att installera (deploy) EJB i EJB-container. Hur detta sker beror på vilken EJB-container man använder. Av detta skäl är de flesta böcker om EJB vaga på denna punkt (vilket inte är så roligt om man är nybörjare på EJB). I Resin så finns det (bl.a.) två sätt att installera EJB på paketera i JAR-filer. kopiera in.class-filer direkt. Jag föredrar själv det andra alternativet då detta är lättast under tiden man utvecklar EJB, d.v.s. man slipper packa EJB varje gång men kompilerat en ny version av EJB. När sen EJB är buggfri (d.v.s. fungerar) så kan man paketera i JAR-filer. Resin (och andra webbservrar) använder ett begrepp kallat webbapplikation. En webbapplikation är en mapp, alla undermappar (som inte i sig är webbapplikationer) och alla webbresurser i dessa mappar. Webbresurser är HTML-/XML-dokument, bildfiler (JPG/GIF), servlets, JSP, EJB, m.m.. I bilden till höger så finns en mapp WEBAPPS (som oftast är namnet på roten för webbservern i Resin) i vilken två webbapplikationer har skapats: ban och bpn. I bpn (och andra webbapplikationer) finns en mapp WEB-INF 18 där konfigurationsfil för webbapplikation (WEB.XML) och deployment descriptor (filer med filändelsen.ejb) placeras. Mappen WEB-INF innehåller sen en mapp CLASSES där vi placerar filer med filändelsen.class, d.v.s. våra kompilerade gränssnitt och klasser för EJB (men även servlets). Observera att om våra gränssnitt och klasser ingår i paket så måste detta reflekteras i mappstrukturen under mappen CLASSES. I bilden ovan så finns t.ex. klassen Sal (i den icke expanderade mappen VERSION1) i ett paket bpn.datorbokning.version1 och gränssnittet SvensktDatum finns i paketet bpn. Om vi använder JCreator för att skapa våra EJB:s så genererar JCreator mappstrukturen åt oss när vi kompilerar gränssnitt och klasser. D.v.s. vi kan kopiera mappstrukturen (eller kompilera direkt till mappen CLASSES i Resin-servern). (I mappen LIB placeras JAR-filer i bild ovan så finns drivrutinerna för MySQL och Oracle där.) I webbapplikationens rotmapp (t.ex. bpn), eller någon av dess undermappar (utom WEB- INF 19 ), placeras HTML-dokument, bildfiler, JSP och andra webbresurser (utom servlets och EJB). Filen 10HELLO_WORLD.JSP ligger t.ex. i webbapplikationens rotmapp. I mappen CLASSES placeras alltså filer med extensionen.class, i WEB-INF filer med extensionen.ejb samt, om vi skapat JAR-filer, filer med extensionerna.jar,.war och.ear i mappen LIB. 18 Denna mapp bör vara namngiven med versaler övriga mappar och filer i Resin kan variera i skiftläge (gemener eller versaler). 19 Resin är konfigurerad så att klienter (d.v.s. webbläsare) inte kan läsa filerna i mappen WEB-INF och dess undermappar /83

12 Klient till EJB Klienter använder JNDI för att erhålla en referens till EJB:s home-gränssnitt. Vilken typ av drivrutin som krävs liksom URL till namntjänst (name server) varierar mellan olika J2EEservrar. Av detta skäl så är, åter igen, många böcker vaga på hur detta sker (vilket, åter igen, inte är så roligt om man är nybörjare på EJB). Resin har sin egen namntjänst och därmed sina egna drivrutiner. Så för att underlätta exempel i fortsättningen kommer jag att använda servlets för att testa EJB då man kan använda den lokala namntjänsten för att erhålla referenser till local home-gränssnitt. (Och därför, liksom att det är lättare, så använder exempel bara local- och local home-gränssnitt i fortsättningen.) I detta exempel så undviker jag att (exakt) visa hur man använder JNDI för att erhålla en referens till home-gränssnitt då detta sker på lite olika sätt beroende på vilken EJB-container man använder. Men som exempel försöker visa så är det endast erhållandet av referens till home-gränssnittet som gör användandet av EJB, liksom användandet av create-metoder i home-gränssnitt i stället för det reserverade ordet new, det som gör användandet av EJB annorlunda från vanliga objekt. Först deklareras variabler för både home- och remote-gränssnitt. I en större applikation så räcker det med en variabel för EJB:s home-gränssnittet medan vi kan deklarera en variabel av remote-gränssnittets typ för varje instans av EJB vi använder. I EJB måste vi, som sagt, först hämta en referens till EJB:s home-gränssnitt, vilket vi använder JNDI till. När vi har en referens till ett initialt kontext i namntjänst så kan vi fråga namntjänsten efter en referens till EJB:s home-gränssnitt. Här används JNDI-namn som vi anger i deployment descriptor. Nästa steg är att skapa en instans av EJB genom att anropa en create-metod som returnerar en referens till EJB:s remote-gränssnitt. Efter detta så kan vi, precis som med vanliga objekt, anropa metoder i remote-gränssnitt. SvensktDatumHome home = null; //Variabel för referens till home-gränssnit SvensktDatum sd = null; //Variabel för referens till remote-gränssnitt //Hämta en referens till initialt kontext i namntjänst ("hypotetiskt") Context initial = (Context) new InitialContext().lookup(...); //Fråga namntjänst efter referens till EJB:s home-gränssnitt home = (SvensktDatumHome) initial.lookup("svensktdatum"); //Skapa en instans av EJB returnerar en referens till EJB:s remote-gränssnitt sd = home.create(); //Anropa metod i remote-gränssnitt och skriv ut resultatet System.out.println("Datum idag på svenskt format" + sd.idag()); Dags att titta närmare på olika typer av EJB:er, d.v.s. vad entity och session beans är Entity, Session och Message-driven beans En komponent kan vara en entity bean, en session bean eller en message-driven bean. Komponenter av typen entity bean motsvarar objekt som ska manipuleras av applikationen och har därför tillstånd. D.v.s. entity bean har egenskaper som beskriver objektet som komponenten motsvarar. Komponentens tillstånd (värde på egenskaperna) lagras i databas, vilket kan hanteras av komponenten själv (bean managed persistence, BMP) eller av EJBservern (container managed persistence, CMP). I det senare fallet överlåter vi till EJB-servern att hantera transaktioner, d.v.s. risken för fel (buggar) minskar drastiskt (något som vi strävar efter ) /83

13 Komponenter av typen session bean sköter själva exekveringen av affärslogiken som applikationen ska hantera. En session bean kan vara en ren arbetskomponent (stateless) som inte behåller sitt tillstånd mellan metodanrop eller behålla sitt (eller del av sitt) tillstånd (stateful) mellan metodanropen (tillståndet lagras dock inte i en databas!). En message-driven bean fungerar som dess namn visar på: den utför något när den erhåller ett meddelande (ifrån en JMS-server, Java Message Service). Denna typ av komponenter behandlas inte vidare i denna sammanfattning. Utöver entity och session beans (liksom message-driven) olika funktion (data resp. arbete) så skiljer de sig även på andra punkter, bl.a. vilket gränssnitt som bean-klass ska ärva från och vilka typer av metoder (find- och create-metoder se nedan) som måste finnas i deras homegränssnitt Transaktioner, objektpoolning och samtidighet En av de mest intressanta tjänster som en EJB-server kan erbjuda är antagligen transaktionshantering. Att skriva korrekt kod för transaktioner är något som är viktigt, och att slippa behöva skriva koden om och om igen för den delen... Detta är något som EJB-servrar kan hjälpa till med. Exekvering brukar ske stötvis, d.v.s. oftast inte konstant. Därför brukar EJB-server använda något som kallas för objektpooler. Ett visst antal objekt av varje komponent skapas och placeras i en objektpool. När en klient anropar en metod i en komponent så tilldelar EJBserver ett objekt från poolen som kan exekvera koden åt klienten. Genom att endast skapa ett mindre antal med objekt så sparas resurser, främst minne. Allt detta är möjligt då klienten håller en referens till komponentens remote- (eller local-) gränssnitt och inte till bean-klassen (d.v.s. ett objekt) som exekverar koden. Samtidighet (concurrency), eller synkronisering, är ytterligare ett område av programmering i fleranvändarsystem som är komplext och svårt att få rätt. Återigen är det något som en EJBserver kan hjälpa oss med Entity beans En entity bean motsvarar alltså data som applikation ska behandla. De klasser i klassdiagram som innehåller, eller främst innehåller, tillstånd är våra entity beans, t.ex. Person, Dator och Bil. Affärslogiken i en entity beans består främst i accessmetoder (set- och get-metoder) för att läsa och sätta värden för attribut i EJB. Dessa affärsmetoder (accessmetoder) definieras i remote- och/eller local-gränssnitt. Utöver metoder för affärslogiken så måste användare av EJB kunna skapa nya, eller hitta existerande, instanser av EJB. För detta används home-gränssnitt och för entity beans måste gränssnittet därför innehålla find- och create-metoder för att hitta respektive skapa instanser av entity bean (se mer nedan). I de flesta fall vill vi använda oss av container-managed persistence (CMP), d.v.s. låta EJBserver hantera kommunikation med datakälla. Genom att använda CMP så slipper vi skriva SQL-satser för att läsa och uppdatera data i databaser samt vi slipper sköta transaktioner. Detta kan spara timmar med felsökning utöver den tid det tar att skriva koden för databaskommunikationen. I denna sammanfattning kommer alla EJB i exempel att använda CMP. En entity beans bean-klass ska implementera (ärva från) gränssnittet javax.ejb.entitybean (och en session beans bean-klass gränssnittet SessionBean). I detta gränssnitt finns metoder som EJB-servern anropar för att meddela EJB att något händer (främst att EJB:s tillstånd /83

14 ändras, t.ex. skapas eller förstörs). 20 Dessa metoder används främst vid bean-managed persistence (BMP) men beskrivs kort nedan. Metoder i gränssnittet EntityBean Gränssnittet javax.ejb.entitybean innehåller följande metoder: ejbactivate() anropas innan objekt tas från objektpool. ejbload() anropas innan objekts data läses från databas. ejbpassivate() anropas innan objekt placeras i objektpool. ejbremove() anropas innan objekts raderas i både EJB-server och databas. ejbstore() anropas innan objekts data skrivs till databas. setentitycontext() anropas efter att objekt har skapats. unsetentitycontext(entitycontext ctx) anropas innan objekt förstörs. Ovanstående metoder måste implementeras av bean-klassen 21! (Ett sätt att komma runt behovet av att implementera metoderna i varje EJB är att skapa en klass som ärver från EntityBean och implementerar metoderna samt sen låta alla EJB ärva från den nya klassen. Men om vi använder Resin så kan vi också använda Cauchos abstrakta klass AbstractEntityBean som gör just det. ) Och om BMP används så måste EJB-utvecklaren själv skriva kod för databasåtkomst, vilket bl.a. görs i metoderna ejbload() och ejbstore(). Find-metoder Find-metoder används för att finna en eller flera instanser av entity beans. Varje entity bean måste innehålla en metod som heter findbyprimarykey() med en parameter typen på parametern är samma som primärnyckelklassen och typen på returvärdet ska vara EJB:s remote- (eller local-) gränssnitt. Denna metod används bl.a. av EJB-server för att hitta en viss instans av en entity bean, d.v.s. metoden returnerar alltid en instans av EJB. Metoden ska definieras i EJB:s home-gränssnitt, men implementeras i klass genererad av EJB-server. I EJB Person (med personnummer som primärnyckel, och därmed String som primärnyckelsklass) så skulle findbyprimarykey() kunna definieras enligt följande: Person findbyprimarykey(string persnr); Vill vi ha andra sätt att finna instanser av EJB så kan vi lägga till fler find-metoder. Dessa metoder måste ha prefixet find (men lämpligen findby) och implementeras genom att lägga till EQL-satser 22 i deployment descriptor (mer om find-metoder och EQL i senare avsnitt). Dessa frivilliga find-metoder kan returnera en instans av EJB, eller en samling av EJB, som matchar ett visst kriterium d.v.s. dessa metoder bör ha returtypen Collection. Vilket dessa kriterium är avgörs av vilka parametrar som skickas till metod, vi kan alltså ha en eller flera parametrar för metod. I EJB Person så kanske vi vill ha en metod för att hitta personer med ett visst efternamn samt ett visst för- och efternamn. Vi kan då definiera metoder med namn som findbyefternamn() och findbyforochefternamn() med en respektive två strängar som parametrar till metoderna: Collection findbyefternamn(string enamn); 20 Denna typ av metoder kallas callback-metoder. 21 Bean-klassen behöver endast innehålla tomma metoder, d.v.s. metoderna måste finnas men behöver inte innehålla någon kod. 22 Enterprise JavaBeans Query Language ett frågespråk som starkt påminner om SQL /83

15 Collection findbyforochefternamn(string fnamn, String enamn); Create-metoder Om vi vill kunna skapa en ny instans av entity bean så måste vi även ha en eller flera createmetoder. Som parameter till create-metoder skickas värden för EJB:s attribut minst en parameter för varje kolumn i tabell som har restriktionen NOT NULL. 23 Returtyp för createmetoder är (liksom findbyprimarykey()) EJB:s remote-gränssnitt. Create-metoder definieras i EJB:s home-gränssnitt men implementeras av ejbcreate-metoder i EJB:s beanklass (se nedan). Om vi i EJB Person vill kunna skapa en instans genom att skicka personnummer samt för- och efternamn (vilka bör var NOT NULL i databas ) så kan createmetod ha följande definition: Person create(string persnr, String enamn, String fnamn); För varje create-metod i home-gränssnittet så måste vi alltså definiera en ejbcreate-metod, men även ejbpostcreate-metod, i EJB:s bean-klass. Parametrar till ejbcreate- och ejbpostcreate-metoder måste vara av samma typ och antal som create-metod i homegränssnitt. Men returtyp för ejbcreate-metoder ska vara primärnyckelsklassen och för ejbpostcreate-metoder void. I ejbcreate-metoder så anropar vi set-metoder för de attribut som metods parametrar motsvarar. ejbpostcreate-metoder innehåller främst implementation då EJB är relaterad till andra EJB (se kapitel Relationer mellan EJB för exempel på implementation av ejbpostcreate()). I bean-klass för EJB Person så skulle vi kunna lägga till nedanstående ejbcreate- och ejbpostcreate-metoder för att matcha create-metod ovan: String ejbcreate(string persnr, String enamn, String fnamn) setpersonnummer(persnr); setefternamn(enamn); setfornamn(fnamn); //ejbcreate(string, String, String) void ejbpostcreate(string persnr, String enamn, String fnamn) //Ingen impl. För att kunna ta bort en instans av EJB så används (oftast 24 ) metoden remove() i EJB:s remote-gränssnitt, d.v.s. vi behöver inte lägga till en egen remove-metod. Observera att när remove() anropas så tas även motsvarande post i databas bort! Kompilera och testa EJB Som nämnt tidigare så öka komplexiteten, både kodmässigt och miljön som koden ska exekvera i. När vi kompilerar kod så meddelar kompilator eventuella syntaxfel, men inte logiska fel i koden. Andra saker som kompilatorn missar är avsaknad av en del metoder eller, enligt EJB-specifikationen (men inte enligt Java-syntax), felaktiga metoder. Dessa missar är något som inte kompilatorn kan (eller ska?) fånga, utan de upptäcks först när EJB installeras i EJB-server eller instanser av EJB skapas och metoder i instans anropas. Ett 23 Om en kolumn i tabell är av typen räknare så behövs ingen parameter för attributet i EJB värdet genereras oftast när post i tabell skapas. 24 Vi kan om vi vill även använda metoden remove() i EJB:s home-gränssnitt och bifoga instansens handle som parameter. En handle är ett unikt värde som EJB-server genererar för att kunna unikt identifiera instanser av EJB EJB-server kan frågas om en handle för instans (för bl.a. detta syfte). Men eftersom vi antagligen oftast vill ta bort en instans av en EJB som vi har en referens till så är det lättare att anropa remove() i remote-gränssnittet /83

16 problem är att fel kan finnas i någon av de två/fyra gränssnitten, en/två klass/klasser eller deployment descriptor, d.v.s. det finns flera ställen att felsöka i Entity beans exempel Dags att titta på ett enkelt exempel på hur en implementation av en entity bean ser ut. Vi ska skapa en EJB Bil med attributen regnr (registreringsnummer) och marke (märke). För detta exempel krävs en tabell med följande utformning: CREATE TABLE bilar( regnr char(6) PRIMARY KEY, marke varchar(25)); Koden i detta exempel bygger på att vi använder Resin (från Caucho) som EJB-server (men även servlet-server ). D.v.s. om en annan EJB-server används så behöver kanske en del justeringar göras för att exempel ska fungera. Resins konfigurationsfil WEB.XML måste (bl.a.) innehålla en datakälla (jdbc/test i exempel nedan) samt konfiguration för EJB-containers datakälla (ejb i exempel). Spara filen i mappen WEB-INF för webbapplikationen (eller lägg till i en redan existerande fil). Observera: EJB-server behöver tillgång till databashanterarens drivrutiner. Dessa kan placeras i EJB-servers LIB-mapp (eller under webbapplikationens WEB-INF\lib). Om flera jobbar i samma webbapplikation så måste ni ersätta paketnamnet i exempel (bpn) med t.ex. er egen användaridentitet i nätverket. Steg i exempel 1. Konfigurera datakälla (i t.ex. MySQL, punkt 1a, eller Oracle, punkt 1b). Denna punkt behöver endast göras en gång för varje webbapplikation. 2. Definiera remote-gränssnitt (eller local-gränssnitt eftersom vi ska testa EJB lokalt). 3. Definiera home-gränssnitt (eller local home-gränssnitt eftersom vi ska testa EJB lokalt). 4. Implementera bean-klass. 5. Skapa (eller hitta ) primärnyckelsklass. 6. Skapa deployment descriptor. 7. Skapa servlet-klass för att testa EJB. 1 (a). Konfigurera datakälla för MySQL Att använda MySQL som databas är praktiskt då databashanteraren är gratis och relativt enkel att konfigurera, d.v.s. en databas ni kan ladda ner och installera hemma. 25 Nedan konfigureras en datakälla med JNDI-namnet jdbc/test (för just databasen test 26 i MySQL) samt datakälla för CMP med JNDI-namnet ejb. <web-app> <!-- *** START: Konfiguration av databas ******************************** --> <database> <jndi-name>jdbc/test</jndi-name> <driver> 25 Som klient mot MySQL kan man använda MySQL Front eller MySQL:s Administrator och Query Browser. 26 När MySQL installeras så brukar just databasen test skapas /83

17 <type>org.gjt.mm.mysql.driver</type> <url>jdbc:mysql://localhost:3306/test</url> <user>username</user> <password>password</password> </driver> </database> <!-- *** SLUT: Konfiguration av databas ********************************* --> <!-- *** START: Konfiguration databas for CMP *************************** --> <ejb-server jndi-name="ejb"> <data-source>jdbc/test</data-source> <config-directory>web-inf</config-directory> </ejb-server> <!-- *** SLUT: Konfiguration databas for CMP **************************** --> </web-app> 1 (b). Konfigurera datakälla för Oracle Oracle är en av de mest använda kommersiella databashanterare, därför är den val två som databas. Den enda skillnaden mellan konfiguration av datorkällor för MySQL och Oracle är drivrutinen (taggen <type>) och sökvägen (taggen <url>). <web-app> <!-- *** START: Konfiguration av databas ******************************** --> <database> <jndi-name>jdbc/test</jndi-name> <driver> <type>oracle.jdbc.driver.oracledriver</type> <url>jdbc:oracle:thin:@julia:1521:orc1</url> <user>username</user> <password>password</password> </driver> </database> <!-- *** SLUT: Konfiguration av databas ********************************* --> <!-- *** START: Konfiguration databas for CMP *************************** --> <ejb-server jndi-name="ejb"> <data-source>jdbc/test</data-source> <config-directory>web-inf</config-directory> </ejb-server> <!-- *** SLUT: Konfiguration databas for CMP **************************** --> </web-app> 2. Definiera remote-gränssnitt Remote-gränssnittet (eller local-gränssnittet som i detta exempel) är gränssnittet med de publika (affärs-)metoderna i EJB. Detta gränssnitt motsvarar klasser i klassdiagram vi tar fram i analysfasen. Skillnaden mellan remote- och local-gränssnitt är vilket gränssnitt som vi utökar (EJBObject respektive EJBLocalObject) samt att metoder i local-gränssnitt inte behöver slänga java.rmi.remoteexception. Eftersom detta är en entity bean så är våra affärsmetoder accessmetoder för EJB:s attribut, d.v.s. bilens registreringsnummer (regnr) och märke (marke). Eftersom vi inte vill att primärnyckeln för tabellen (bilar i detta fall) ska kunna ändras så definierar vi inte en setmetoden för primärnyckelattributet (d.v.s. metoden setregnr()). package bpn.j2eeexempel; //Paketnamn - ersätt med egen användaridentitet import javax.ejb.ejblocalobject; public interface Bil extends EJBLocalObject public String getregnr(); public String getmarke(); public void setmarke(string marke); /83

18 //interface Bil 3. Definiera home-gränssnitt Home-gränssnittet använder vi för att styra en EJB:s livscykel, bl.a. skapande av nya instanser. För att skapa nya entity beans så använder vi create-metoder. Create-metoder används istället för det reserverade ordet new, och därmed konstruktorer, för att avgöra hur en entity bean ska skapas. (Vi får för övrigt inte ha några konstruktorer i bean-klassen!) Hur många create-metoder som entity bean ska innehålla samt vilka parametrar som createmetoder ska ha beror på hur vi vill kunna skapa instanser av entity bean. Det är viktigt att komma ihåg att när vi skapar en ny instans av entity bean med create-metoder, så skapas även en motsvarande post i tabell (i relationsdatabas). Om vi vill använda redan existerande instanser av entity bean (eller snarare poster i tabell) så används find-metoder. Home-gränssnittet behöver innehålla en find-metod för varje sätt vi vill hitta en entity bean. Parameter (eller parametrar) till find-metoder används i WHEREklausul i EQL-satser (mer om dessa senare). En entity bean måste ha minst en find-metod, findbyprimarykey(), som har primärnyckelklassen som parametertyp. Eftersom vi ska använda ett local-gränssnitt (för affärslogiken) så måste vi skapa ett motsvarande local home-gränssnitt. Alla create-metoder måste även slänga javax.ejb.createexception liksom find-metoder slänger javax.ejb.finderexception. Men eftersom det är ett local home-gränssnitt (och inte ett remote home-gränssnitt) så behöver dessa metoder inte slänga java.rmi.remoteexception. package bpn.j2eeexempel; //Paketnamn - ersätt med egen användaridentitet import javax.ejb.ejblocalhome; import javax.ejb.finderexception; import javax.ejb.createexception; public interface BilHome extends EJBLocalHome Bil create() throws CreateException; Bil create(string regnr, String marke) throws CreateException; Bil findbyprimarykey(string regnr) throws FinderException; //interface BilHome 4. Implementera bean-klass Bean-klassen implementerar metoderna i remote- och home-gränssnitten (eller local- och local home-gränssnitt). Varför jag satt implementera inom citattecken beror på att beanklassen inte implementerar (implements) gränssnitten utan endast metoder med samma (eller liknande namn 27 ) som i gränssnitten. Tabellen innehåller två attribut två attribut som vi vill använda och därför behövs accessmetoder (en set- och en get-metod) för de två attributen. 28 I.o.m. EJB v.2.0 så ska dessa metoder vara abstrakta (och därmed även klassen). 29 Klassen måste innehålla både set- och get-metod (för att göra ett attribut endast läsbart för klient så definierar vi inte en set-metod i remote-gränssnittet, enligt ovan). 27 Med liknande menar jag att home-gränssnitt innehåller create-metoder (t.ex. create()) medan bean-klassen innehåller ejbcreate-metoder (d.v.s. ejbcreate()). Därav liknande namn 28 Vi behöver inte använda alla attribut i en tabell i en EJB om vi inte vill. 29 Metoderna implementeras av klasser som EJB-container genererar automatiskt /83

19 Med två create-metoder i home-gränssnitt (create() och create(string, String)) så måste vi skapa två ejbcreate-metoder (med samma antal och typ på parametrar) i beanklassen. Metodernas returtyp ska vara primärnyckelsklassen, d.v.s. String i detta exempel. I den första ejbcreate-metoden så returnerar vi bara null. 30 Men i den andra metoden anropar vi även set-metoderna för de två attributen och skickar vidare create-metodens parametrar. För varje ejbcreate-metod så måste vi ha en motsvarande ejbpostcreate-metod. ejbpostcreate-metoderna ska ha samma (typ på och antal) parametrar som ejbcreate-metod samt ha returtyp void. Dessa metoder används främst när vi har relationer (se nästa kapitel) eller om vi använder bean managed persistence. Vi behöver inte skapa några motsvarande metoder till find-metoder i home-gränssnittet. 31 Sist av allt implementerar vi metoderna i gränssnittet EntityBean. Metoderna behöver inte innehålla någon kod men måste finnas i klassen eftersom de finns i gränssnittet EntityBean som klassen implementerar. package bpn.j2eeexempel; //Paketnamn - ersätt med egen användaridentitet import javax.ejb.entitybean; import javax.ejb.entitycontext; import javax.ejb.createexception; public abstract class BilBean implements EntityBean /*** Accessmetoder för attribut i tabell **********************************/ public abstract void setregnr(string regnr); public abstract String getregnr(); public abstract void setmarke(string marke); public abstract String getmarke(); /*** ejbcreate- och ejbpostcreate-metoder *********************************/ public String ejbcreate() throws CreateException return null; public void ejbpostcreate() public String ejbcreate(string regnr, String marke) throws CreateException setregnr(regnr); setmarke(marke); return null; public void ejbpostcreate(string regnr, String marke) /*** Implementera gränssnittet EntityBean *********************************/ public void ejbremove() public void ejbactivate() public void ejbpassivate() public void ejbstore() public void ejbload() public void setentitycontext(entitycontext sc) public void unsetentitycontext() //class BilBean 5. Skapa (eller hitta ) primärnyckelsklass För detta exempel så är skapande av primärnyckelsklassen enkelt klassen String finns redan. 30 För att vara kompatibel med EJB v. 1.x så ska Create-metoder returnera primärnyckelklassen. I.o.m. EJB v. 2.0 så behöver inte primärnyckeln returneras utan vi returnerar bara null (eftersom vi måste returnera något ). 31 Vi använder EJB Query Language (EQL) i deployment descriptor för detta, utom för findbyprimarykey() som EJB-server skapar åt oss automatiskt /83