analyse og implementasjon

Transkript

1 Accenture J2SE basert batch system analyse og implementasjon Anders Finnerud & Dennis Lundh

2 Innhold 1 INTRODUKSJON FORORD BESKRIVELSE AV OPPGAVEN Bakgrunn Målsetning INTRODUKSJON AV FREMGANGSMETODIKK FOR DOKUMENTET EN INNFØRING I BATCHSYSTEMER BATCH GENERELT Effektivisering Concurrency Jobb skedulering Kritiske avsnitt Exclusions låsing DESIGN AV BATCHSYSTEMER Tidsstyring og Transaksjonsflyt LOGGFØRING OG FEILDETEKSJON Feilhåndtering(retry) BESKRIVELSE AV TESTAPPLIKASJON (PROOF OF CONCEPT) INTRODUKSJON Utgangspunkt beskrivelse av Nøkkel Komponenter og funksjonalitet Beskrivelse av testens komponenter TESTSCENARIO BESKRIVELSE AV KOMPONENTER OG FUNKSJONALITET SYSTEMBESKRIVELSE OG RESULTAT AV IMPLEMENTASJON ENKEL BATCH PROSESSERING MED BRUK AV HIBERNATE IMPLEMENTERING AV QUARTZ Bakgrunn initiering Cron Bryter Implementasjon av Enkel bryter IMPLEMENTERING AV BATCH SYSTEMET Kontroll av batchsystemet VURDERING AV MÅLOPPNÅELSE BAKGRUNN FOR MÅL ANALYSE KONKLUDERENDE ANALYSE AV PROBLEMSTILLING Mulighet for implementering av automatisering og skedulering Takle feilsituasjoner Håndtere flertrådskjøring Isolert logikk

3 6 VURDERING AV FREMGANGSMÅTE PROSESSBESKRIVELSE Prosessen utvikling i forhold til prosjektets mål Bestemmelse av scenario UTFORDRING OG PROBLEMLØSNING I FORHOLD TIL VERKTØY Installasjon/Initiering av Quartz: Bruk av Subversion(vii) Bruk av Maven(vi) HVA ER NESTE SKRITT Ett brukervennlig grensesnitt Alternative løsninger KONKLUSJON VERKTØY KILDER APPENDIKS KLASSEDIAGRAMMER SEKVENSDIAGRAM FOR BATCH JOBB

4 1 INTRODUKSJON 1.1 FORORD Datateknologi er noe som mange forbinder med et konsept som er fremtidsrettet og har alltid hatt en enorm utvikling de siste år. Men en essensiell grunn til at datateknologien har fått den status den har i dag kan sies å ha tatt utgangspunkt i krav til automatisering og forenkling av arbeidsoppgaver i produksjons industrien. Automatisering av oppgaver ble ett konsept så tidlig som i industrien på starten av 1900 tallet. For å effektivisere produksjon kom begreper som masseproduksjon og serieproduksjon, begreper som ble allmenn kjent etter at Ford Motor Company revolusjonerte industrien. Produksjon av T Ford bilene foregikk på samlebåndslinjer noe som kuttet ressursbruk og kostnader betraktelig, og derfor tillot masseproduksjon av det legendariske bilmerket. Da datamaskinen gjorde sin introduksjon, var dens funksjonalitet og etter hvert programvare basert på seriell prosessering. Det vil si at elementer/algoritmer blir behandlet som en seriell strøm av instruksjoner, slik at første instruksjon må fullføres før neste kan begynne. Nye krav til effektivisering har etter hvert kommet til automatiserings industrien og tema som innebærer matematiske beregninger, blant annet parallell produksjon som er avhengig av datateknikk for å fungere. I databegrep er dette kjent som parallell prosessering. Parallell prosessering betyr at flere elementer behandles samtidig for å løse samme oppgave. I de siste årene har vi fått mange teknologiske fremskritt for å forenkle hverdagen. Vi fikk minibanker som forenklet pengeuttak ved at man de både kunne avløse bankene og ordne uttak raskt og automatisk. Etter hvert har også nettbanker blitt vanlig for flere og flere, da dette har kunnet gjøre mulig at du kan betale regninger fra din egen stue. En nettbank fungerer nesten som om du skulle gått i banken selv. Du kan overføre penger mellom kontoer, få en oversikt over dine siste transaksjoner og kontostatus og du skal kunne stole på att systemet gir deg rette opplysninger og ønskede transaksjoner. Banker og større selskaper har også i større grad blitt avhengig av å kunne ha systemer som tar av seg både faste og varierende kostnader. De faste kostnadene skal så automatisk betales til faste tidspunkt, samtidig skal det være mulig å i tilegg kunne gå inn i systemet på egen hånd for å betale de varierende kostnadene. Dette er bare ett av mange eksempler på anvendbarhet for denne typen teknologi. Et konsept som er gammelt, men også enormt anvendbart og gjennomgått en stor utvikling i årenes løp, har nå blitt til noe av den viktigste teknologien i dagens informasjonsteknologiske samfunn. Viktigheten av automatiserte system som samtidig er fleksible er et nøkkelelement i dagens drift av alle typer transaksjoner, fra enkle minibanksystem til internasjonale banksystemer. 1.2 BESKRIVELSE AV OPPGAVEN 4

5 1.2.1 BAKGRUNN Accenture lager ulike løsninger for bedrifter som av og til inneholder løsninger basert på Batchsystemer med mulighet for å starte ved bestemte tidspunkter og kunne benyttes av flere instanser til samme tid. De har benyttet seg av Java Enterprise Edition(heretter kalt J2EE) som utviklingsplatform da den støtter flertrådskjøring og flere andre egenskaper som er nødvendig for løsninger som de utvikler. I det siste har det blitt lagt fokus på enklere (lettvekt) løsninger for slike systemer i det internasjonale software samfunnet. muliggjøre lignende operasjoner i Java Standard Edition(heretter kalt J2SE). J2SE har blitt svært populært med enklere metoder for utvikling med alternative rammeverk for å muliggjøre krav for stabile løsninger. Fordelen med J2SE i forhold til J2EE er at det krever mindre ressurser, da J2EE inneholder mye ekstra kode for å fungere, uansett applikasjonens kompleksitet. Til nå har Accenture vært nødt til å programmere mye fra grunnen av i gjeldende systemer. Dette er fordi kundene har forskjellige forutsetninger og behov for hvordan løsningen skal fungere, og for hvilke systemer den skal kommunisere med. Accenture ønsker derved å gjøre det mulig å lage forskjellige løsninger tilpasset ulike prosjekter og scenarioer, der det benyttes et standardisert system, noe som vil være tid og ressurssparende. Accenture ønsker å finne ut mer om denne utviklingen og i hvilken grad dette kan hjelp til med å effektivisere bedriften ved utvikling av den type systemer Accenture utvikler. i den forstand at det vil kunne bli enklere å implementere og teste aktuelle løsninger MÅLSETNING Vi skal finne ut av i hvilken grad et system basert på J2SE tilfredsstiller kravene for et fungerende Batch/on line system. Det skal også analyseres problemstillinger ved Batch/on line systemer, for å få en oversikt og sammenheng av krav for slike system. Utviklingsprosessen skal analyseres når vi implementerer ny logikk, og vi konkluderer med en bedømmelse av hvordan prosessen har fortonet seg, hvordan problemer har blitt løst, og gjennomførbarhet ved valgte løsning. Det skal danne grunnlag i analysen av systemet. Vi tar utgangspunkt i ett J2SE basert system bestående av: Quartz(tidsstyring), Hibernate(Datatransaksjon og lagringshåndtering) og Java implementasjon(jobbkontrol). Ett viktig poeng for oppdragsgiver er at logikken er isolert. Det vil si at komponenter kan byttes ut, uten at det får konsekvenser for resten av systemet. Det vil gjøre applikasjonen mer fleksibel og anvendbar for andre prosjekter. Dette vil gjelde i hovedsak logikk som skedulering, arbeidsutførelse, database og eventuelle andre større logiske komponenter. Bedriften vil da få greie på i hvilken grad et system med denne sammensetningen av rammeverk vil fungere. De vil få en analyse av bakgrunn, eksempel på et fungerende system og få greie på eventuell kompleksitet i utviklingsprosessen. hvordan det ville være å benytte lettvektskomponenter (quartz, spring, hibernate osv.) utenfor J2EE miljøet til å kjøre batcher. De vil få en analyse av hva som ligger bak batch systemer, et eksempel på et fungerende system og eventuell kompleksitet under utviklingen. Disse kravene stiller systemet: Kunne implementere automatisering og skedulering Takle feilsituasjoner Håndtere flertrådskjøring Håndtere partisjonering, som er effektivisering ved kjøring av flere prosesser/tråder samtidig. 5

6 Applikasjonen skal tilby en standard grensesnitt for transaksjons og feilhåndtering Logikk skal i størst mulig grad være isolert Muligheter for statistikk, loggføring og overvåkning 1.3 INTRODUKSJON AV FREMGANGSMETODIKK FOR DOKUMENTET Batch prosessering av denne type er et meget stort og avansert tema. Vi vil derfor gå nøye igjennom grunnlaget for alle aspekter og definisjoner som er hensiktsmessige i forhold til dette prosjektet, før vi går løs på oppgavens mål. I kapittel 2. går vi igjennom en innføring i og grunnleggende problemstillinger for generelle Batchsystemer. I kapittel 3. beskriver vi i detalj testapplikasjonen som skal implementeres og analyseres. Før vi beskriver og argumenterer gradvis prosessen fra forståelse av systemet til implementering av logiske komponenter i kapittel 4. I kapittel 5 kommer vi med en konkluderende analyse og vurdering av mål oppnåenlse i forhold til prosjektets fastsatte mål. 6

7 2 EN INNFØRING I BATCHSYSTEMER 2.1 BATCH GENERELT Dette er en gjennomgang av batchsystemer slik vi i gruppen har forstått dem. Denne teksten har som mål å beskrive generelt, og finne typiske aspekter ved slike systemer. Som man kan se fra betydningen av ordet batch (se boks t.h.), så handler dette om noe som utføres på flere ting i en omgang. For eksempel baking av flere brød i en omgang. Deigen eltes for en viss mengde brød, for så å deles inn i brødemner og stekes sammen i ovnen. Etterpå pakkes brødene ned. Hvis dette settes i system som det for eksempel gjøres hos industrialiserte bakerier (for eksempel Bakers AS) Så er det fremdeles snakk om den samme jobben som gjøres med brødene. Men det er lagt til et automatiserings element som kan gjenta denne batch jobben til fastsatte tidspunkter. Betydningen av ordet batch Batch \Batch\, n. [OE. bache, bacche, fr. AS. bacan to bake; cf. G. geb["a]ck and D. baksel. See Bake, v. t.] 1. The quantity of bread baked at one time. 2. A quantity of anything produced at one operation; a group or collection of persons or things of the same kind; as, a batch of letters; the next batch of business. ``A new batch of Lords.'' Lady M. W. Montagu. Source: Webster's Revised Unabridged Dictionary (1913) (dictionary.net) EFFEKTIVISERING Ett batchsystem kan bli mer fleksibelt, effektivt og/eller risikofylt hvis du benytter deg av ulike metoder. Det enkleste eksempelet er at en baker blander ingredienser, elter, deler deigen, steker, og pakker brødet, og så gjentar den samme operasjonen for et bakeri, slik som beskrevet i forrige avsnitt. Dette fungerer uten problem så lenge man går ut i fra at det alltid er nok råvarer, men du kan bare bake ett brød om gangen. Men det er ikke spesielt lønnsomt hvis Batchsystemet stiller større krav. I dette tilfellet hvis bakeriet får større etterspørsel C ONCURRENCY Concurrent betyr konkurrerende. Konseptet concurrency står for nesten det samme som parallell prosessering, Forskjellen er den at parallell prosessering er et begrep for å dele et komponent i flere deler og prosessere de oppdelte komponentene uavhengig av hverandre til samme tid. Ett concurrent system går også ut på å prosessere i parallell, men prosesseringen behøver ikke å foregå samtidig eller være av samme type. Bakeri eksempel: Hvis bakeriet ansetter flere bakere som baker brød i batchsystemet vil det da kunne lages ferdig flere brød på kortere tid teoretisk. Ett batchsystem som benyttes av flere prosesser kaller vi ett concurrent batchsystem. 7

8 FIGUR 2 1 CONCURRENT BATCH Men vil man kunne bake flere brød til samme tid som det tar å lage ferdig ett brød med det gamle systemet? Alle bakere som jobber benytter den samme batchprosessen. Siden bakerne da også deler de samme ressurser(råvarer eller ovn) for å produsere så vil det kunne føre til at for eksempel mange brød er klare til steking samtidig, og hvis stekeovnen da er full, så er en eller flere av bakerne nødt til å vente til ovnen er har ledig plass. Når prosesser må vente på hverandre for å kunne utføres blir dette en flaskehals. Så lenge prosessene ikke jobber mot felles ressurser i ett batchsystem er ikke dette noe problem, og transaksjonen vil foregå uavbrutt. FIGUR 2 2 CONCURRENT BATCH MED FLASKEHALS JOBB SKEDULERING Siden ett Batchsystem utføres automatisk, trenger man et system som kan styre hvordan bakingen skal synkroniseres når flere jobber utføres over samme system. Et system som bestemmer når og hvilken oppgave som ska utføres kaller vi en planlegger(skeduler). En skeduler kan lage en kø ved at de forskjellige prosessene (bakerne) venter i en kø hvis en ressurs (ovn) ikke er ledig, og bestemme hvem som skal få bruke ressursen når det blir ledig. En enkel måte at dette utføres på er FIFO (First In First out). Det vil si at den som kommer først til køen slipper først til. En annen metode er SJF(Shortest Job First), som kjører den batch jobben i køen som tar minst tid å bli ferdig først. Det kan føre 8

9 til at flaskehalsen blir mindre, så lenge jobbene er like viktige(har lik prioritet). FIGUR 2 3 EKSEMPEL PÅ FIFO KØ 9

10 2.1.4 KRITISKE AVSNITT Hva hvis man skal ta hensyn til hvor mye råvarer man har tilgjengelig? Batchsystemet kan utføre en sjekk før bakeprosessen begynner, for å sørge for at bakerne har nok mel. En planlegger(heretter kalt Scheduler) vil da sørge for at det bestilles mel, hvis det ikke er nok for alle bakerne. Da vil vi ha et on line system, det vil si at en Scheduler tar et nytt valg hver gang batchprosessen utføres. Men det er slik at hver prosess (baker) har en identisk batchprosess, og som kan bli utført av flere prosesser(bakere) til samme/tilnærmet samme tid. Jobben med å sjekke og bestille mel i batchsystemet vil sjekkes/bestilles av den samme delen av batch jobben. Dette kalles et kritisk avsnitt, fordi to uavhengige prosesser (bakere) oppaterer en felles ressurs(sjekk/bestilling av mel). Kjernen av problemet oppstår når en jobb skal oppdatere eller skrive(gjøre endringer) på et delt system, ikke når man kun leser fra systemet RACE CONDITION Så hva om to prosesser (bakere) begynner batchprosessen til tilnærmet samme tid? Hvis det ikke er tilstrekkelig med mel vil den ene bakeren vil først sjekke om det er nok mel, før den andre bakeren sjekker det samme. Begge bakerne vil finne ut at det ikke er nok mel. Den første prosessen (bakeren) vil bestille mel, men det vil også den andre. Altså den andre prosessen (bakeren) vil da bestille mer mel selv om det er allerede bestilt.( Dette spesifikke problemet kaller vi en Race Condition ). Her er det kritiske avsnittet(mel bestilling) vist, med Race Condition problemet: Ett kanskje mer relevant scenario for hvor det samme problemet har større konsekvenser er ved transaksjoner i en bank eller annet økonomisk system. To on line henvendelser ønsker å overføre penger fra systemet. Systemet vil unngå å komme i minus, og har en total kapasitet på kr. Henvendelsen 1 undersøker om det er mulig å overføre kr, og får bekreftet at det er mulig. Transaksjonen blir derfor fullført. Men før denne transaksjonen får bekreftet at kapasiteten etter overføringen nå er 5000 kr( ), undersøker henvendelse 2(som også ønsker kr) den totale kapasiteten på systemet. Henvendelsen får da beskjed om at den totale kapasitet fortsatt er på kr, og vil derfor også få bekreftet at transaksjonen er mulig og vil overføre kr. Når begge overføringene er gjennomført er den totale kapasiteten 5000 kr. Her er en grafisk fremstilling av eksempelet med penge transaksjoner. T1 i blått er tidslinje for første transaksjon. T2 i rødt er tidslinje for andre transaksjon. Den totale kapasiteten for systemet er vist ved forskjellige tidspunkter under transaksjonene: 10

11 FIGUR 2 4 RACE CONDITION, BANK EKSEMPEL Av figuren kan vi se at totalsummen er fortsatt når transaksjon 2 sjekker om transaksjon summen er mindre enn totalsummen og at totalsummen har blitt 5000 før transaksjon 2 skal utføre transaksjonen. 11

12 D EADLOCK Ett eksempel: Fire biler kommer samtidig mot ett kryss fra 4 forskjellige retninger. Høyre regelen sier at man har vikeplikt for bilen til høyre for deg i lyskrysset, men det vil føre til at alle bilene må vente på hverandre siden alle har en bil til høyre i krysset. Dette kaller vi en Deadlock. FIGUR 2 5 DEADLOCK EKSEMPEL, BILER I KRYSS Når prosesser venter på hverandre vil ingen framdrift forekomme, og batchsystemet vil stoppe fullstendig opp. Sjansen for en Deadlock er som regel større i større systemer hvor flere prosesser utfører kritiske transaksjoner, da sannsynligheten for at flere transaksjoner ankommer ett kritisk avsnitt til samme tid også øker. I batchsystemer med mange transaksjoner kan det derfor være lurt å dele inn transaksjonene slik at man kjører et begrenset antall jobber om gangen. 12

13 2.1.5 EXCLUSIONS LÅSING Ett kritisk avsnitt problemet har flere løsninger, ut ifra hvilke krav man har til Batchsystemet. Men felles for problemene er at alle løsninger må være synkronisert. En helt enkel metode blir her presentert: Sjekker om en jobb som skal utføres er opptatt eller ledig før man kommer til en kritisk prosess i Batchsystemet (sjekk og bestilling av mel, eller bruk av ovn ). Ett Concurrent Batchsystem vil ved Mutual Exclusion fungere slik at man låser det kritiske avsnittet hvis den er tatt i bruk. Det vil si at alle andre prosesser som ønsker tilgang vil bli nektet og må vente. Ett eksempel er at bakeren må først sjekke om den kritiske prosessen er i bruk av en annen baker. Hvis prosessen er opptatt får prosessen (bakeren) beskjed om att jobben som skal utføres er låst (opptatt), og må vente. Når den prosessen som benytter seg av den kritiske prosessen er ferdig blir låsen endret slik at den er åpen. Bakeren som venter må hele tiden sjekke tilstanden til ovnen slik at han/hun kan se om tilstanden til prosessen er endret til åpen, og kan i så fall fortsette videre med batchprosessen. FIGUR 2 6 ENKEL LÅS 13

14 2.2 DESIGN AV BATCHSYSTEMER T IDSSTYRING OG T RANSAKSJONSFLYT Batch arbeider kan stort sett deles inn i to hovedformer. Forskjellen ligger i måten jobbens utstrekning defineres: som arbeid på en gitt mengde enheter, eller Quantity of Items (QoI) som arbeid på enheter i en gitt tidsperiode, eller Quantity of Time (QoT) (Merk: henholdsvis QoI og QoT benyttes heretter) KVANTITET AV TID BATCH (QOT) Et typisk senario for QoT batcher er fakturaproduksjon til en fastsatt fakturadato. Et firma samler faktura grunnlaget for alle sine kunder frem til for eksempel månedslutt. Grunnlagsdataene benyttes så for å kalkulere og produsere fakturabrev for alle kundene som har benyttet firmaets tjenester den måneden. Jobben utføres på varierende fakturagrunnlag (ordrer), men gjøres til fastsatt tid (fakturadato) Figur 2 7 prosessering av enheter samlet, med tidsstyring Utover dette så kan man igjen dele opp i to kategorier. Batchjobbens enheter kan betraktes som en gruppe av enheter som prosesseres som en samlet entitet. Dette kalles ofte for batching, og er illustrert i figur 2 7 og 2 9. Det motsvarende alternativet er såkalt de batching som vises på figur 2 8 og Denne metodikken innebærer at jobben utføres på en samling individuelle enheter. Det betyr at arbeidet utføres enkeltvis og uavhengig på hver og en av batchens enheter. 14

15 Quantity of Time de-batching Quantity of Time de-batching Enhet Motta enheter Mottar et ukjent antall enheter Koble sammen/lagre enheter i batch datastore Enheter Lagrer enhetene i påvente av tidspunkt for kjøring Mottar, prosesserer og sender enhetene enkeltvis Enhet Prosesser enhet Enhet Styrer tidspunkt for prosessering av en ukjent mengde enheter. F.eks et klokkeslett, hver time, hvert minutt osv. Tidsstyring (Timer) FIGUR 2 8 PROSESSERING AV ENHETER HVER FOR SEG, MED TIDSSTYRING M ENGDE ENHETER BATCH Den andre hovedformen for batchmetodikk er basert på at en viss mengde enheter mottas før kjøringen igangsettes Det betyr at en QoI batch ikke kjøres til et gitt tidspunkt, men starter først når jobbgrunnlaget er stort nok. Et eksempel: Forestill deg et opptakskontor til en kurstilbyder. Det er ikke lønnsomt å holde kurset når antall deltakere er under en viss grense. Derfor venter opptakskontoret frem til denne grensen er oversteget, for så å sende ut bekreftelse på opptak til kurset. På samme måte som for tidsstyrte batchjobber, så kan også mengdestyrte jobber komme i to hovedvarianter. Figur 2 9 viser samlet prosessering ut fra mengde. 15

16 FIGUR 2 9 PROSESSERING AV ENHETER SAMLET, MED MENGDE BASERT AVFYRING 2.3 LOGGFØRING OG FEILDETEKSJON Systemet skal kunne loggføre driften og de feil som oppstår. Samtidig skal feilene rulles tilbake på en slik måte at dataene i databasen ikke er endret i forhold til tilstanden de hadde før batchkjøringen. Det er viktig å merke seg at dette ikke innebærer at databasen skal se identisk ut. Kun at buisness objektene og tilknyttede data felter (kolonneverdier) er uendret. Radnummer og lignende tellevariable m.m. vil naturligvis ikke kunne gjøres like. 16

17 FIGUR 2 10 TENKT HENDELSESDIAGRAM FOR SYSTEMET. 17

18 2.3.1 FEILHÅNDTERING(RETRY) I visse tilfeller kan det være fornuftig å forsøke å kjøre prosessen på nytt når en batch feiler. Da vil man først rulle tilbake dataene, så man er sikret et likt utgangspunkt, for så å la jobben kjøre på nytt for den aktuelle batch partisjonen. Dette vil som regel innebære at også flere batch enheter som det ikke var noe problem med vil måtte kjøres på nytt. Dette er fordi transaksjonen som de var en del av ble rullet tilbake, og det vil alltid involvere alle medlemmene innenfor en transaksjon. For å unngå dette kan man sette transaksjonen til å kun strekke seg over ett element. Dette velger man allikevel oftest ikke å gjøre fordi det sjelden oppstår feil som krever mer tid til sammen enn den tidskostnaden en slik implementasjon tilfører. 18

19 3 BESKRIVELSE AV TESTAPPLIKASJON (PROOF OF CONCEPT) 3.1 INTRODUKSJON Prosessen med å lage et robust concurrent Batchsystem kan i noen tilfeller være vanskelig å få oversikt over og skjønne dybden av. Første del av utviklingen foregikk i form av studier av andre batchsystemer. Eksempler på batchsystemer finnes mange steder, og vi har tatt ideer fra prosess og automatiseringsindustrien, så vel som fra allerede eksisterende batchsystemer for databehandling. Med dette som grunnlag vil vi nå forklare Batchsystemet oppbygning, bit for bit separert i logiske komponenter. Modellen under viser denne inndelingen. Vi går igjennom de forskjellige delene av denne modellen i delkapittel U TGANGSPUNKT Vi har av våre veiledere fra Accenture blitt tildelt ett image av ett system på CD. Ett image er ett ferdig installert system som kan kjøres fra eksterne applikasjoner, som om det skulle være ett eget system. Dette bildet kjøres med hjelp av VirtualBox(ii), og inneholder ett Linux, Ubuntu (i) operativsystem med utviklingsplattformen Eclipse(iii) for Java implementering. Følgende rammeverk og ekstra funksjoner er ferdig installert: Hibernate ( ) Maven (vi) Postgresql (viii) Quantum(ix) 19

20 3.1.2 BESKRIVELSE AV NØKKEL KOMPONENTER OG FUNKSJONALITET INTRODUKSJON TIL HIBERNATE Hibernate er et rammeverk for kommunikasjon(mapping) mellom relasjons databaser og Java objekter. Det vil si at rammeverket støtter en forenklet kommunikasjon mellom Java objekter og databasetabeller. Hibernate har flere funksjoner for data kontrollering. Dette er bare en generell introduksjon til komponentene vi behøver i vårt batchsystem. For utfyllende dokumentasjon se: 20

21 V IKTIGE KONSEPTER OG FUNKSJONER I HIBERNATE Persistente objekter: Enkle Java objekter(pojo) som fungerer som ett konstant mellomlegg mellom en database og transaksjon implementering. Disse innholder all logikken for å skrive til og fra databasen, og befinner seg dermed i datalaget på applikasjonen. De representerer hver og en tabell i databasen, men skiller seg ved at de kan beskrive mange til mange, mange til en og en til mange forhold internt i klassen. Dermed er det ikke behov for egne klasser for assosiasjons tabellene som finnes i databasen. Session: En sesjon fungerer som en mellomlagring av objekter som er relatert til en mengde av enheter ( ) Session Factory: En tråd sikker versjon av en sesjon. Det vil si at sesjonen innebærer en for låsing som gjør at transaksjonen kan fungere med som flere tråder. Transaction: En eller flere jobber(legge til, slette, oppdatere) som skal utføres, samlet i en enhet. Tilhører en sesjon. Arbeidet som gjøres innenfor en transaksjon er atomisk for databasen. Dette betyr at databasen vil behandle innholdet i en transaksjon som en samlet enhet under lesing og skriving. Commit: Markerer enden av en transaksjon, og gjør den klar for synkronisering mot databasen. Når dataene skrives finnes det ikke noen garanti for, men data som blir lest eller lagt til etterpå vil få med endringer gjort etter commit. Forløpet mellom Commit og lagring kan altså betraktes som asynkront, styrt av interne ressursstyringsprosedyrer i Hibernate. Allikevel kan dette påvirkes ved å benytte metoden Session.flush() for å tvinge gjennom lagring av alle ventende persistente objekter. Rollback: Rollback() resetter en transaksjon(transaction) eller en tilkobling(connection) til en tidligere tilstand. Dette vil føre til at alt som er gjort mellom forrige og siste Commit blir tilbakestilt til den opprinnelige tilstanden. Unntaket er tellervariable og andre variable som man er avhengig av at er unike, og derfor må regenereres. Benyttes gjerne slik at en rollback automatisk utføres når det oppstår en feil i kjøringen. Caching/Second level cache: Benyttes for å minske belastningen på databasen ved å lagre data en periode etter lesing i minnet. På denne måten vil ikke påfølgende leseoperasjoner kontakte databasen. First level cache er alltid på. Second level cache skrus av i vårt tilfelle grunnet fare for data konflikter. 21

22 INTRODUKSJON TIL QUARTZ Ett job scheduling rammeverk med funksjoner for tidsbasert styring på objektnivå. Fungerer ved at man kan sette opp en scheduler(benytter seg av Quartz Frameworket) som utfører en aktuell oppgave. Rammeverk kan kjøre kode(java klasser) i flere runder, med en timer funksjon som kan angi tidsintervall for jobb kjøring. Quartz kan brukes med både J2EE og J2SE. 22

23 3.1.3 BESKRIVELSE AV TESTENS KOMPONENTER Den delen av rammeverket som setter i gang hele prosessen starte automatisk på et tidspunkt og gjentar et visst antall ganger. Startes av tidtaker, og fungerer som en kontroller for batchjobben som utføres. Disse to objektene inneholder forretningslogikk og nødvendig funksjonalitet til å kunne utføre denne på en sikker måte. Persistering av objekter til og fra databasen har som formål å representere en eller flere tabeller i en database med javaobjekter. De skal kunne instatieres slik at de representerer en rad i en tabell, og eventuelle referanser til rader i andre tabeller. FIGUR

24 3.2 TESTSCENARIO BESKRIVELSE AV KOMPONENTER OG FUNKSJONALITET For å forsøke å estimere de funksjonelle kravene systemet til applikasjonen så har oppdragsgiver gitt oss forslag til en prosedyre og et scenario den skal utføres på. Hensikten med scenarioet er å ha et statisk miljø som applikasjonen kjører i under test, som lar oss benytte et fast sett med komponenter som for eksempel databasen med sine tabeller, drivere, og java bibliotek. Ved at vi begge har benyttet samme image med en virtuell maskin for utviklingen og testingen sikrer vi at de praktiske fysiske parametrene i scenarioet er finnes og er statiske. Den andre delen av scenarioet er hva systemet skal gjøre. Dette har vi forsøkt å konkretisere på følgende måte Det skal utføres en del enkelt handlinger, heretter kalt skritt.. Handlingene skal startes av et tidsur og eventuelt gjentas med konfigurerbare intervaller/tider. Skrittene skal benytte persistente objekter for å lese og skrive til en underliggende database. Hvert skritt skal opptre som planlagt, eller melde fra om feil til systemet. Feil skal loggføres. Endringer i resultatet (feiltilstand), skal i forhold til forventet resultat (normaltilstand) skal være synlige og sporbare med feilmelding og loggføring som viser hvor, når og hvorfor systemet feilet. Endringer gjort mot databasen som er gjort når systemet har vært, eller har havnet i en feiltilstand skal tas vekk med en såkalt rollback, Denne fjerningen skal kun ta vekk endringer i databasen utført under feiltilstanden, og ikke påvirke arbeidet som like før er utført i normaltilstand I tilfelle feilen skulle være forbigående skal det være mulig, om ønskelig, å forsøke på nytt et spesifisert antall ganger de skritt som har vært utført under feiltilstand. Dette må loggføres. Vi har implementert sekvensen ovenfor på følgende måte: Det lages 1000 student objekter i en midlertidig metode kalt test() som ligger i klassen Batchsystem. Disse gis fornavn og etternavn allerede her, før de settes inn i køen for inngående arbeidselementer. Når alle de 1000 objektene er lagt inn i køen så iverksettes partisjonering. Her har vi valgt å forenkle utførelsen ved å la elementpartisjonen strekke seg over alle elementene som står i køen. Arbeidet som skal gjøres settes så i gang av batchsystemet. Det gjøres ved å instruere Elementpartisjonen om å utføre metoden IWork.doWork() i klassen InputWork som implementerer som så gjør kall på dowork i klassen OutputWork. Begge disse klassene skal implementere IWork interfacet, og må ligge i den underliggende pakken com.accenture.course.batch.job, i denne rekkefølgen, på hvert enkelt element. Vi deler inn scenarioet i to deler. 1. Utgående arbeid. Legger til studenter og lærere i databasen, for så å tilegne kurs for både studenter og lærere 2. Inngående arbeid: Vi finner ut hvem en spesifikk students lærer er. Databasemodell: 24

25 FIGUR 3 2 DATABASEMODELL OVER SYSTEMET Forklaring til aktuelle tabeller i databasen: T_COURSE inneholder kurs med tilhørende lærere T_STUDENT_COURSE inneholder hvilke studenter som tilhører ett kurs og da også hvilke kurs som tilhører en student. T_STUDENT inneholder studenter T_LECTURER inneholder lærere Start Avslutter med feil Arbeids klasse (IWork) save entity to db [ja] Prøve igjen? Database Objekt persist entity feil? (Exception e) [ja] Avslutter ved å returnere den lagrede entiteten kast (Exception e) [nei] transaksjon aktiv? [ja] rull tilbake feil? (Exception he) log the last exception 25

26 Helt enkelt kan det ut i fra databasemodellen sees at det både er lærere og studenter tilknyttet kurs tabellen. Følgende domeneobjekter er benyttet: Studenter(StudentDO) Kurs(CourseDO) Lærere(LecturerDO) 26

27 4 SYSTEMBESKRIVELSE OG RESULTAT AV IMPLEMENTASJON 4.1 ENKEL BATCH PROSESSERING MED BRUK AV HIBERNATE For å bli kjent med Hibernate s funksjonalitet, begynner vi med å lage en helt enkel transaksjon. Systemet vi jobber med inneholder flere persistente klasser som kommuniserer med systemets database. En type logikk som er implementert i disse klassene legger til en ny student i databasen, som vi nå tar i bruk i utviklingens første fase. <ref. hibernate grafisk> Vi begynte med en enkel kode som legger til en student, med navn og fornavn til databasen gjennom persistente Hibernate objekter. Dette er en grei måte å bli kjent med transaksjonskjøring, da det på forhånd er lagt inn persistente objekter med logikk for å kunne legge til en ny student til databasen. Før vi går igjennom eksempelet er det viktig å være klar over at database transaksjoner alltid er atomiske. Det vil si at en transaksjon kan ha kun to utfall, Enten blir den vellykket og lagres med en commit, ellers blir den mislykket og rullet tilbake. Noe som vises ved figuren: FIGUR 4 1 MULIGE UTFALL FOR EN DATABASE TRANSAKSJON 27

28 S LIK FOREKOMMER PROSESSEN I JAVA: S ESSION SESJON1 = HIBERNATEU TIL. GETSESSION(); T RANSACTION TRANSAKSJON = NULL; TRY { TRANSAKSJON = SESJION1.BEGINT RANSACTION(); S TUDENT STUDENT = NEW STUDENT(); STUDENT. SETF ORNAVN("JOHN"); STUDENT. SETE TTERNAVN("DOE"); SESJON1.SAVE( STUDENTDO); TRANSAKSJON. COMMIT(); } For å utføre en transaksjon trenger vi å opprette en sesjon. Deretter prøver vi å tilegne sesjonen med en tilhørende transaksjon. Hibernate er nå gjort klar for å begynne å jobbe på en enhet. Når en transaksjon er opptrettet prøver vi å opprette ett student objekt fra den implementerte logikken, der vi også setter verdier for navn og etternavn for aktuell student. Vi gjør den nye enheten(studenten) persistent ved å lagre student objektet til sesjonen. Deretter lagres det persistente objektet(student) i databasen med funksjonen commit. CATCH (EXCEPTION E) { IF (TX!= NULL) { TRY { TX. ROLLBACK(); } CATCH (HIBERNATEEXCEPTION HE) { THROW HE; } } THROW E; Hvis det forekommer feil/korrupt data under transaksjonen, vil systemet prøve å rulle tilbake alle transaksjoner som er gjennomført. Det vil si at ingen av operasjonene under denne sesjonen vil bli lagret: Hvis det oppstår en feil når transaksjonen skal rulles til bake blir feilen sendt til den kallende klassen. 28

29 FINALLY { TRY { SESJON1.CLOSE(); } CATCH(HIBERNATEE XCEPTION HE) { THROW HE; } } Uansett om transaksjonen var vellykket eller ikke vil sesjonen så prøve å lukkes. Hvis en feil oppstår ved lukking av sesjonen vil feilen bli sendt til den kallende klassen. Denne koden definerer grunnprinsippet for transaksjoner ved bruk av Hibernate. Tegningen under viser forholdet mellom sesjon og transaksjon i dette eksempelet. FIGUR 4 2 SESJON VS TRANSAKSJON Flere operasjoner i samme sesjon: Nå skal vi lage en funksjon som fungerer mer som en realistisk batch jobb da vi skal gjøre flere operasjoner. Vi kan ønske å legge til 5 studenter, noe som vil kreve like mange transaksjoner. Det vil si at vi har en batch størrelse på 5 da det er ingen hensikt å ha flere sesjoner.. Sesjonen opprettes, så lager vi en løkke som kjører try, catch og finally blokkene(fra forrige eksempel) 5 runder før sesjonen igjen lukkes. Forholdet mellom Sesjon og Transaksjoner(legge til student) er da som følger: FIGUR 4 3 FLERE TRANSAKSJONER I EN SESJON Tegnforklaring: C = Commit, T = Transaksjon, R = Rollback, J = Jobb start 29

30 4.2 IMPLEMENTERING AV QUARTZ BAKGRUNN Vi ønsker å kunne kjøre transaksjonene til fastsatte tidspunkt med eventuelle faste intervaller, og her kommer Quartz inn i bildet. Quartz er en planlegger som fungerer som en timeplan for når aktuell data skal bli kjørt. Hvis vi for eksempel har ett batchsystem som skal foreta automatisk lagring av sikkerhetskopiering av ett system. Vi kan da ønske at en sikkerhetskopi skal foretas fra kl på natten på hverdager, og fra kl ved helgedager slik at rutinen blir utført når det er minst sannsynlig at det er stor trafikk på systemet. En slik planlegging kaller vi skedulering( 2.1.3) INITIERING Quartz setter i gang system akkurat som en vekkeklokke som sier at nå er det på tide å jobbe. For at Quartz skal forstå hva som skal startes må det initieres. Det er hensiktsmessig å lage ett separat prosjekt i Java for Quartz, da det i vårt tilfelle er Batch logikk som skal startes. Batch logikken er som tidligere nevnt separert fra Quartz. Grunne til at vi separerer logikken er av den grunn at man kan ved enkelhet bytte ut Quartz eller Batch logikken hvis det er ønskelig. Dette vil gjøre løsningen vår fleksibel i forhold til gjenbruk av logikk for fremtidlige prosjekter. Vi begynner med å initiere ett Jobb Detail (heretter kalt Job Detail ) objekt som består av navn på jobben, eventuelt navn på jobbens gruppe(valgfritt) og til slutt bestemmer vi hvilken klasse som Quartz skal starte. I vårt tilfelle inneholder klassen batchsystem.class logikken vi ønsker å starte. Vi trenger nå en bryter som vi initierer til å skru seg på når vi ønsker at Batch logikken skal utføres. Dette gjøres at vi oppretter ett bryter(heretter kalt Trigger) objekt som vi initierer ved å gi det ett navn, samt en tid/tidsintervall for kjøring. Vi kan benytte oss av en Cron Bryter(Crontrigger) eller en Enkel Bryter(Simpletrigger). Beskrivelse og innstillinger for disse bryterne går vi igjennom under her i kapittel og Det som nå gjenstår er å opprette ett Sceduler objekt fra Quartz systemet som vi initierer med Job Detail og Trigger objektene. Scheduler objektet er en del av Quartz systemet, som starter en funksjon med navn execute som vi implementerer i den initierte klassen BatchSystem.class, i vårt tilfelle. FIGUR 4 4 SEKVENSDIAGRAM AV QUARTZ SYSTEMET C RON BRYTER En Cron bryter har meget avanserte muligheter for hvordan/når jobber skal startes. For å sette innstillinger for bryteren benytter man seg av Cron uttrykk. Cron utrykk er for noen mest kjent i sammenheng med skedulerings programmet Cron i operativsystemet Unix/Linux. Cron utrykk kan være vanskelig å forstå i begynnelsen, så vi vil her se noen eksempler for å gjøre uttrykkene klarere. 30

31 Eksempel: Vi kan se for oss 7 felter hvor det siste er valgfritt. Feltene er delt inn på denne måten: sekund, minutter, timer, dag i måneden, måned, dag i uken, år. Det kan settes opp intervaller eller enkel verdi. For eksempel: 0/5 i sekund feltet symboliserer at Quartz skal starte førstkommende hele sekund, og fortsette hvert 5te sekund. Ett annet eksempel: Vi ønsker å utføre jobben kl på den siste søndagen i månedene januar april. Utrykket vil bli seende slik ut: ( L 1 4 0L ). For å forstå bruk av tegn, og finne gode eksempler for å få en bedre forståelse er det en meget informativ side på: IMPLEMENTASJON AV ENKEL BRYTER I vårt tilfelle med aktuell oppgave ser vi kun hensikt i å bruke en Enkel brykter (heretter kalt Simpletrigger) da denne støtter den funksjonalitet vi ønsker. Men det er uansett viktig å være klar over en Cron Bryter siden den har en fleksibilitet som kan være anvendelig ved flere typer større Batch løsninger. Tid/tidspunkt som blir en bryter blir satt til er opprinnelig målt i millisekunder, Men ved å sette opp hjelpeklasser for beregning fra millisekunder til dager, timer, minutter og sekunder, gjør vi jobben enklere når vi ønsker å forandre innstillingene for en bryter. Vi begynner med å sette en starttid for når jobben skal begynne å kjøre, Vi finner ut dagens dato og tidspunkt med Java s innebygde funksjon Ctime og legger til hvor lang tid etter systemet er startet vi ønsker å utføre jobben. Deretter fastsetter vi hvor mange repetisjoner vi ønsker at jobben skal kjøres. Vi kan også sette ett intervall mellom hver kjøring, som også er beregnet i millisekunder. Til slutt kan vi fastsette ett tidspunkt for når vi ønsker at Quartz skal avslutte. Dette er mest hensiktsmessig hvis vi ikke har bestemt antall repetisjoner, eller vi ønsker en begrenset levetid for Quartz kjøringen. 31

32 4.3 IMPLEMENTERING AV BATCH SYSTEMET Ett funksjonelt og robust batchsystem krever en god struktur, og bør lages slik at det lett å gjøre endringer m.h.t. fremtidige situasjoner som kan oppstå, Dette er spesielt viktig når man snakker om batchsystemer programmert uten noen støtteprogramvare som J2EE, IBM WebSphere eller Jboss. Store deler av funksjonaliteten vil ikke være testet tidligere når man lager et system fra grunnen av, Utfordringen ligger i å kompensere for den tryggheten disse rammeverkene gir automatisk gir siden det er så utstrakt bruk av dem. Dets store brukermasse og den respons de gir på rammeverket er en meget god kvalitetsestimator, som man mister man når man skriver enkle Java objekter selv. Man kan tenke seg at enkelheten og oversiktligheten i koden til et Java program som er skreddersydd etter behov, kanskje vil kunne veie opp denne forskjellen. Det ble derfor bestemt følgende kriterier for systemets struktur og kode: Strukturen i prosjektet skal benytte en form for inndeling der databasen, persistering, batch logikk, og tidsstyring er uavhengige. Dette sikrer at det vil være lett å for eksempel skifte ut ett av komponentene hvis dette skulle bli nødvendig. Vi begynner med å implementere en struktur over batch systemet ved å opprette logiske klasser for inndeling av kode og dermed enklere holde orden på kildekoden. Siden vi benyttet Eclipse som utviklingsverktøy var det naturlig å dele inn i prosjekter i en flat struktur, siden det ikke er støtte for hierarkiske inndeling og arv i Eclipse. Vi benyttet Maven som er et avhengighets administrasjons verktøy til å definere avhengigheter mellom våre klasser, samt til eksterne klassebibiloteker som for eksempel Hibernate eller Quartz. Selv om Eclipse må ha flat prosjektinndeling, så kan man lage java pakkestruktur som er hierarkisk. I tabellen nedenfor kan man se prosjektnavnene og pakkefordelingen vi endte opp med, sammen med en kort beskrivelse av hva hver pakke gjør: Prosjekt navn i Eclipse Java pakke navn Inneholder studentproject batch quartz studentproject batch system course hibernatepersistence com.accenture.course.batch.quartz com.accenture.course.batch com.accenture.course.batch.job com.accenture.course.persistence com.accenture.course.persistence.hibernate com.accenture.course.persistence.hibernate.util Java kode for implementering av tidsstyring I form av Quartz. Konfigurasjonsfiler for logging og tidsstyring.. Hoveddelen av java koden til systemet. Konfigurasjonsfiler for logging. Java kode med forretningslogikken til aktuell jobb. Konfigurasjonsfiler for logging. Java interface for database objektene (DO) Implementasjon av persistering med interfacet ovenfor, der Database Objekter representerer f.eks studenter (StudentDO) v.hj.av Hibernate. Inneholder hjelpeklasse for å administrere Hibernates sesjoner, transaksjoner osv. Sikrer at disse brukes på en flertrådssikker (threadsafe) måte. course hibernate database com.accenture.course.persistence.database Inneholder databasen alene av sikkerhetshensyn. TABELL 4 1 OVERSIKT OVER FORHOLDET MELLOM ECLIPSE PROSJEKTER OG JAVA PAKKER KONTROLL AV BATCHSYSTEMET 32

33 Et batchsystem er meget avhengig av at rekkefølgen av hendelser foregår etter programmererens intensjon. Feiler dette så risikerer man alt ifra feil som kan oppdages (ved å fange opp Exceptions), til de mer skumle feilene, som ikke vises, som for eksempel regnefeil. Det er derfor veldig viktig at det er kun én klasse som dirigerer alt arbeidet som skal gjøres, og at dette utføres på en sekvensielt forutsigbarmåte. Vi har gjort dette ved å lage metoden run() i batchsystem, som igangsettes av execute(). execute er metoden Quartz kaller når den trigger igangsetting. Det har vært et poeng å lage selvforklarende navn på metoder, parametere og variable, siden dette letter forståelsen av hva som foregår. Det bør noteres at test() metoden ikke vil benyttes i en driftsituasjon. Den er der nå for å generere test data som vi kan benytte i batchen. I en reel driftsituasjon er det heller klassen InputWork som henter data fra en database, fil eller lignende, og legger disse inn i klassen jobcontainer sin InputQueue. JobContainer er for øvrig ment til å håndtere jobb spesifikke innstillinger og data, slik at samme batchsystem skal kunne lagre flere jobber, og så kjøre de samtidig eller uavhengig av hverandre. Det er derfor lagt vekt på å benytte køer av som implementerer BlockingQueue over alt i systemet etter som den er trådsikker, /** * Runs the batchjob (executes) Instantiates a job Work method from * batch.job.work This contains the business logic that is performed under * processing of the elements. Partition size given directly to maximum * (only 1 partition). */ public void run() { // Sets up a JobDefinition with work definition an partitionsize as // parameters setjob(new InputWork(), Integer.MAX_VALUE); // updates Job number updatejobno(); // Prints current job nr logger.info("!!!this is job number" BatchSystem.jobNo); // Runs test method to create input data to work on. test(); // Initiates batch partitioning while (true) { try { logger.info("input queue contains [" this.jobcontainer.inputqueue.size() "] elements"); ElementPartition ep = this.jobcontainer.packtopartition(); logger.info("created new partition for [ " ep.getqueue().size() " ] elements."); logger.info("will now begin processing elements in partition"); ep = this.jobcontainer.processpartition(ep); logger.info("processing finished, elements are now addedtooutputqueue"); this.jobcontainer.addtooutputqueue(ep); logger.info("elements in partition was added to output queue");... } if(this.jobcontainer.inputqueue.isempty()){ logger.info("no more elements in input queue!"); break; } } catch (Exception e) { logger.error("interrupted during execution", e); stop(1); // Stop execution 33

34 Implementering av persistens mot database Persistering av objekter til og fra databasen har som formål å representere en eller flere tabeller i en database med javaobjekter. De skal kunne instatieres slik at de representerer en rad i en tabell, og eventuelle refererte rader i andre tabeller. Den underliggende databasen skal være utilgjengelig for overliggende lag. Dette betyr at forretningslogikken og alle andre overliggende lag ser Java objekter med sine metoder, isteden for tabeller med kolonner og rader. Et objekt skal kunne håndtere en til mange,mange til mange og mange til en relasjoner mot andre persisterte objekter ved hjelp av samlinger som implementerer java.util.collection Objektene har kun en midlertidig levetid, da objektene skal sendes videre i systemet. Hvordan systemet skal reagere på feil i en transaksjon avgjøres her. Enkelte detaljer som konfigurering av kommunikasjonstrategi mot databasen gjøres også her. Siden oppgaven handler om batchsystemer og ikke persistens i detalj, så har vi etter forslag fra oppdragsgiver benyttet et allerede fungerende database oppsett med Hibernate som de allerede hadde. Det er hentet fra det utviklingsmiljøet (virtuell maskin) som vi har benyttet under hele utviklingen. HibernateUtilNoen av hjelpefunksjonene og de persisterbare domenedatabase objektene var laget, men metodene i disse var i stor grad ikke implementert på forhånd. Det har derfor også vært nødvendig med en del endringer i den delen som var implementert, som vi fikk fra oppdragsgiver KONFIGURASJON AV HIBERNATE For å persistere objekter benyttes Hibernate, men for at dette skal fungere i et batchsystem så må konfigurasjonen først endres. Hibernates dokumentasjon oppgir to kritiske innstillinger i sammenheng med batchsystemer. Man må skru av second level cache i Hibernate for å hindre database konflikter, og man må angi jdbc driverens batch størrelse. Sistnevnte påvirker hvor mange database operasjoner som Hibernate skal gi til JDBC av gangen. Dette gjøres i Hibernates konfigurasjonsfil, som i vårt tilfelle er hibernate.cfg.xml De oppgir at den ideelt bør ligge mellom 1 og 50 for å hindre at Java VM (Virtual Machine) skal gå tom for minne. Vi har valgt batch størrelse 20 som dere kan se nedenfor: I tillegg til disse innstillingene så viste det seg underveis i utviklingen at det var nødvendig med flere endringer enn de nevnt i Hibernates dokumentasjon. Disse er nevnt i sammenheng med de neste delkapitlene TILPASNINGER GJORT I HIBERNATEU TIL Siden vi ønsket at systemet i så stor grad som mulig skal kunne kjøres som et flertrådssystem, så var det nødvendig å sikre at vi kun har en sesjon, Hibernate.Session, av gangen. Flere sesjoner på samme tid ville kunne lede til database probemer som deadlock, race kondition eller stale (gammel)data. For å hindre feil lønner det seg å skru av konstruktøren ved å sette public class HibernateUtil { private HibernateUtil() { //avskrudd konstruktør }; For å sikre at det bare eksisterer en sesjon så implementerte vi ett Hibernate.SessionFactory statisk i Hibernate util. Legg merke til at bruken av static{ } som sikrer at det kun er et punkt man kan få et sessionfactory fra selv om man lager flere instanser av HibernateUtil. Keen ser slik ut: private static org.hibernate.sessionfactory sessionfactory; static { try { 34

35 } sessionfactory = new AnnotationConfiguration().configure().buildSessionFactory(); } catch (Throwable ex) { throw new ExceptionInInitializerError(ex); } Til slutt er det en viktig metode i denne klassen, getcurrentsession(). Denne metoden gir en sesjon fra sesjons kontekst. Hvis det ikke eksisterer noen sesjon der så lager den en ny, lagrer den i sesjons kontekst og returnerer den. Eksisterer det allerede en sesjon, så returneres denne. Dette gjør at man kan utføre flere transaksjoner i en sesjon. Denne metoden er avhengig av at følgende linje er lagt til i hibernate.cfg.xml filen: <property name="current_session_context_class">thread</property> H ÅNDTERING AV SESJONEN UNDER BATCH KJØRING Man kan kanskje tenke seg å kjøre i gang transaksjoner der man benytter en sesjon levert av getcurrentsession lagt metoden fra forrige avsnitt. Dette ville resultere i en java.io.outofmemoryerror etter et par hundre transaksjoner. Grunnet til dette er at Java Virtual Machines minne da ville være fylt opp med persistente objekter som venter på å bli inn i databasen. 35

36 F EILHÅNDTERING Hibernate s rollback funksjon vil kunne tilføre systemet funksjonalitet til å håndtere feil ved transaksjoner. En rollback har som oppgave å tilbakeføre alle databaseendringer som er gjort før siste commit. Det er ikke mulig å ta rollback mer enn 1 commit tilbake i tid. For å teste at dette fungerer må vi fremprovosere en feilsituasjon. En måte å provosere fram en feil på er å kaste en NullPointerException manuelt der vi ønsker at rollback skal utføres. På denne måten kan man altså simulere at en feil har inntruffet, og at det kastes en Exception slik det normalt skal gjøres ved denne typen feil. Arbeids klasse (IWork) Database Objekt Start save entity to db persist entity Avslutter ved å returnere den lagrede entiteten Avslutter med feil [ja] Prøve igjen? feil? (Exception e) [ja] kast (Exception e) [nei] transaksjon aktiv? [ja] rull tilbake feil? (Exception he) log the last exception FIGUR 4 5 FEILHÅNDTERINGSMEKANISME MED MULIGHET FOR NYTT FORSØK Systemet er lagt opp på en slik måte at det ved en feil i persistens laget vil kjøre rollback automatisk, loggføre feilen og kaste exception videre ut til den kallende arbeidsklassene. Disse kan da om ønskelig implementeres med funksjonalitet for automatisk nytt forsøk. Et aktivitetsdiagram for et slikt oppsett vises nedenfor. Legg merke til at også rollback kan feile og kaste en (Hibernate)Exception 36

37 PARTISJONERING Partisjonering er å dele opp en jobb bestående av mange elementer inn i flere jobber med mindre elementer. Det finnes flere motiver for å velge å gjøre dette. En kan være for å øke effektiviteten ved å prosessere jobben på flere uavhengige maskiner, for så å sammenføre resultatet til slutt. En annen motivasjon kan være fininnstilling av jobb størrelsen i forhold til hva som virker optimalt på det prosesserende systemet. Systemets struktur er lagt opp til å støtte partisjonering med hjelp av flere ElementPartitons fra den implementerte ElementPartition klassen i batchsystemet, hvor man kan skru ned partisjonsstørrelsen LOGGING Logging er viktig for å kunne få vite noe om hvordan systemet fungerer i produksjonstid. Det er også viktig ved feilretting og feilsøking både under utviklingsfasen og i produksjon. En viktig ting å merke seg her er at det er stor forskjell på mengden informasjon som behøves i disse to scenarioene. Under drift trenger man kun informasjon som bekrefter at systemet fungerer, samt advarsel om feil i utførelsen. En feilsøkingssituasjon har derimot behov for mer utfyllende informasjon om alle trinn i programutførelsen. For å få til dette har vi benyttet oss av to kjente java biblioteker: Apache Log4j ver heretter kalt bare Log4j og Apache Commons Logging versjon 1.1.1, heretter kalt commonslogging. Log4j står for grovarbeidet og tar data fra programmerte annotasjoner i klassene, og fra JavaVMs standard out og errorout kanaler. Disse data kan så sendes videre til en eller flere ut kanaler som Standard out, tekstfiler, html, xml, bitstrømmer m.fl. Vi har valgt å benytte tekstfiler og standard out konsollet som våre utdata kanaler. Det eksisterer mange populære logging rammeverk som minner om for eksempel log4j. Siden et program gjerne benytter kode fra andre prosjekter er det viktig at loggingen også vil fungere om en ekstern kilde skulle benytte et annet logrammeverk. Det er her Commons Logging kommer inn i bildet. Den definerer en generell programmeringsmodell for logging, og oversetter dette til forskjellige underliggende logger implementasjoner. All kode vi skriver er skrevet for commons logging. Dette sikrer at vi kan bytte underliggende rammeverk, eller legge til andre, uten å måtte endre noe kildekode. 37

38 5 VURDERING AV MÅLOPPNÅELSE 5.1 BAKGRUNN FOR MÅL ANALYSE Vi vil ta utgangspunkt i kravene som er stilt til systemet i kapittelet Mål(1.2.2). Vi vil ut ifra disse kravene konkludere med i hvilken grad, eller hva som må til for at systemet skal kunne tilfredsstille ønskede krav. 5.2 KONKLUDERENDE ANALYSE AV PROBLEMSTILLING MULIGHET FOR IMPLEMENTERING AV AUTOMATISERING OG SKEDULERING Automatisering og skedulering i systemet er ivaretatt av Quartz systemet. Quartz er som tidligere nevnt den delen av systemet som starter selve batchsystemet ved ferdig konfigurerte brytere(4.2.2). Etter at Quartz er initiert og startet vil batchsystemet kjøre så lenge vi har initiert det til, eller det vil fortsette å gå til evig tid hvis det ikke er satt noen bestemt slutt tid. Vi kan derfor konkludere med at systemet vårt støtter automatisering. Quartz bestemmer også når og hvordan systemet kjøres, ved at ett ønsket tidspunkt med eventuelle intervaller blir initiert og utført. Vi bestemmer også hvilken klasse(oppgave) som skal utføres. Det vil da si at systemet vårt ved hjelp av Quartz fungerer som en skeduler, som tidligere beskrevet(2.1.3) T AKLE FEILSITUASJONER Ved å fremprovosere en NullPointerException ved ett bestemt punkt i løpet av transaksjonene får vi svar på hvordan en feil blir behandlet. Utskriften fra(referanse) viser at vi får en logget feilmelding. I dette tilfellet har intet blitt lagt til databasen. For å håndtere feilsituasjoner på en mer effektiv måte burde vi ha implementer en kø hvor transaksjonene som mislykkes legges til. Fra denne køen burde vi hatt en funksjonalitet som prøver å få transaksjonen til å gjøre en commit på nytt. Det ville være lurt med en teller for transaksjonen som sier hvor mange mislykkede forsøk den har hatt, slik at transaksjonen forkastes etter ett gitt antall forsøk. Antall forsøk bør tilsi hvor stor sjanse det er for at det er korrupt data som gjør at transaksjonen foretar en rollback HÅNDTERE FLERTRÅDSKJØRING Det er gjennom hele systemet lagt til rette for flertrådskjøring med bruk av trådsikre samlinger som for eksempel LinkedBlockingQueue. Når denne typen kø er tom vil man ved bruk av metoden take() kunne la en tråd vente til det oppstår data. På samme måte kan man benytte metoden offer() til vente frem til køen kan ta imot data (er ledig og har ledig plass), for så å legge det til. Dette gjør at man hvis ønskelig, kan la JobContainer klassen ta imot data til Input og Output køer uavhengig av den pågående prosesseringen. En slik løsning kan for eksempel være nødvendig i pengetransaksjoner til og fra en kontoer, man vil jo ikke gå glipp av transaksjoner selv om de kommer under batchkjøringen ISOLERT LOGIKK 38

39 Vi har utviklet prosjektet i den grad at det skal benytte en struktur for inndeling, hvor vi ønsker isolasjon fra logikken i så stor grad det er mulig. Det kan være ønskelig å skifte ut ett logisk komponent eller eksternt verktøy med ett annet hvis vi i fremtiden ønsker å få nye egenskaper til systemet som ikke det nåværende batchsystemet støtter Det kan også være interessant i nær fremtid kunne bytte ut ett eller flere logiske komponenter med nye produkttyper eller teknikker som kan forbedre egenskapene til ett batchsystem i forhold til stabilitet, hastighet, sikkerhet, eller andre viktige parametere.. Dette sikrer at det vil være lett å for eksempel skifte ut av komponentene hvis dette skulle bli nødvendig. Vi kan i Tabell 4 1 tidligere i dokumentet se inndelingen av systemet hvor hver pakke er isolert fra hverandre. Det finnes i alt fire separerte pakker, og derfor fire komponenter som det er mulig å skifte ut ved behov: Pakke 1: Databasen Pakke 2: Persistering Pakke 3: Batch logikk Pakke 4: Tidsstyring 39

40 6 VURDERING AV FREMGANGSMÅTE 6.1 PROSESSBESKRIVELSE P ROSESSEN UTVIKLING I FORHOLD TIL PROSJEKTETS MÅL O PPRINNELIG KRAVSPESIFIKASJON/ MÅL Vi ble gitt en veldig fri oppgave opprinnelig. Det vil også si at vi har nødt til å ta mange antydninger på egenhånd for hvordan vi skal kunne måle ett systems anvendelighet og effektivitet. Det var meningen at vi skulle gå igjennom de rammeverk som var mulig å få til å fungere som en erstatning for det J2EE systemet som bedriften bruker nå for å så analysere disse, og deretter finne det mest egnete. Vi fant ut etter å ha blitt bedre kjent med problemstillinger i slike systemer, at det å sammenligne systemer på denne måten som også krever implementering i gjeldende system er urealistisk å gjennomføre på den tiden ett hovedprosjekt er tillagt. Her er ett utdrag fra forprosjektrapporten vår som definerer problemstillingen vi først ble gitt: Vi skal finne den kombinasjon av JavaSE baserte rammeverk som vil tilfredsstille kravene gitt av bedriften slik det kommer frem i forprosjektrapporten. Utviklingsprosessen skal analyseres når vi implementerer ny logikk, og vi konkluderer med en bedømmelse av fordeler, ulemper og gjennomførbarhet ved valgte løsning. Det skal danne grunnlag i analysen av systemet. Vi tar utgangspunkt i sammensetningen: Quartz(tidsstyring), Spring Batch(jobbkontroll) og Hibernate(Datatransaksjon og lagringshåndtering) Bedriften vil få greie på hvilken sammensetning av rammeverk og deres funksjonalitet, som vil gi best resultat. De får en analyse av styrker og svakheter ved et slikt system og grad av kompleksitet i utviklingsprosessen REVIDERT KRAVSPESIFIKASJON/ MÅL Vi har etter mye studering i våre kilder som bøker og internett har vi fått en mye bedre forståelse av hvor omfattelig og hvilke behov ett konkurrerende(concurrent) Batchsystem er. Etter diskusjon med våre veiledere kom vi fram til at det å analysere generelle batchsystemer og finne funksjonalitet i flere forskjellige rammeverk ville bli en meget tidkrevende prosess. Det innebærer at vi ikke bare må finne disse systemene og være klar over deres eksistens og funksjonalitet, men for å kunne teste hvilket system som var mest anvendelig er vi også nødt til å installere/sette opp og implementere scenario for de aktuelle systemer. Vi kom fram til at dette ville bli en prosess som var umulig å gjennomføre I løpet av den tid vi har til rådighet. Våre veiledere gav oss derfor klarere mål å gå ut I fra, slik at vi kunne konsentrere oss mer om implementasjon og studering av logikk, som vi lærte mer om underveis I prosjektets prosess. Den nye problemstillingen gikk ut på å sammenligne disse systemene: System 1: Quartz(tidsstyring), Spring Batch(jobbkontroll) og Hibernate(Datatransaksjon og lagringshåndtering). 40

41 System 2: Quartz(tidsstyring), Java implementasjon(jobbkontroll) og Hibernate(Datatransaksjon og Lagringshåndtering). Vi skal selv finne ut hvordan vi skal måle Batch systemene. Enten må vi finne standarder som er fastsatt, eller så må vi finne lignende hovedoppgaver ENDELIG KRAVSPESIFIKASJON Hvordan vi kom fram til endelig løsning: Vi vil bare benytte vårt eget alternativ til ett J2SE rammeverk uten Springbatch for kjøring og kontroll av systemet. Analysemålene er nå definert som følger: Vi skal finne ut om rammeverket Quartz(tidsstyring), Java implementasjon(jobbkontroll) og Hibernate(Datatransaksjon og Lagringshåndtering) kan fungere for avansert Batchprosessering. Begrunnelse: Vi kom med forklaring til våre veiledere om at det ikke er realistisk å få tid til implementere Spring Batch som tidligere tenkt. Dette er fordi det er kun kort tid igjen og resten av tiden trenges til å utarbeide rapporten. Mye av grunnen til dette er at oppgaven med å sette opp Hibernate tok langt mer tid enn først planlagt. Vår oppdragsgiver har god nytte av ett system som bare består av ett J2SE system også uten Spring Batch, da vi har begynt med logikk som Spring Batch ville kunne gjøre for oss i vårt nåværende system. Spring Batch er kun ett hjelpeverktøy, som i seg selv også kan være overflødig som tidigere nevnte alternative rammeverk (J2EE m.fl.) Vi skal derfor forsøke å implementere jobbkontrollen som Spring Batch ville tatt seg av i vårt eget J2SE baserte program. Vår oppdragsiver foreslo at vi kunne gjøre ferdig vårt oppsett av Batch styring med Hibernate, med de aktuelle funksjoner. Prosjektet dreier seg fortsatt om gjennomførbarheten i ett J2SE rammeverk, men uten noe konkret system å sammenligne med. Vi begynner å se viktigheten av å isolere logiske deler fra hverandre, da dette vil gjøre det mulig å enkelt bytte ut vår implementerte jobbkontroll med for eksempel Spring Batch. Fordelen med mer isolerte komponenter er at det vil lette utskifting til en rekke eksisterende eller fremtidige alternative metoder/verktøy som kan utføre lignende oppgaver innenfor vår systeminndeling. Dette vil gjøre systemet fleksibelt og gjenbrukbart, som jo er i tråd med ideologien bak objektorientert programmering. Hibernate kan være vanskelig å erstatte foreløpig, men vi ser viktigheten av å ha mulighet til å utvikle systemet med andre nåværende eller fremtidige verktøy. Da batchsystemer er benyttet i stor grad og er meget viktige i så mange forskjellige sammenhenger som de er til dags dato, ser vi det som sannsynlig at ny og bedre teknologi vil kunne ta over. 41

42 6.1.2 BESTEMMELSE AV SCENARIO Vi ble opprinnelig gitt en standard scenario som er gitt av oppdragiver og vi har oppgitt i forprosjektet. Men vår oppdragsgiver har gitt oss beskjed om at vi kan benytte hvilket scenario vi finner anvendbart. Da prosessen med å forstå batch logikk og verktøy som benyttes er tidkrevende, så har vi funnet ett noe enklere scenario å gå ut fra for å kunne disponere tiden riktig. Vi fant det nye scenarioet like anvendelig. 42

43 6.2 UTFORDRING OG PROBLEMLØSNING I FORHOLD TIL VERKTØY INSTALLASJON/INITIERING AV Q UARTZ: Problem: Quartz har ett stort bibliotek og må installeres manuelt for å fungere med Eclipse. Løsning: For å få Quartz til å fungere måtte vi først laste ned det aktuelle Quartz API et. Deretter laget vi ett nytt prosjekt i Eclipse, hvor vi har lagt til Quartz build filer(jar) til prosjektet. Mappen /lib som inneholder nødvendige bibliotek for Quartzsystemet ble kopier til i /src mappen i det nye prosjektet vi laget. For å kunne bruke Quartz må man initiere klassen som skal kjøres(i vårt tilfelle BatchSystem.java) til å være kjørbar for Quartz rammeverkets implementering som vi satte opp. Man er også nødt til å ha en fil med navn quartz.properties I class path, da denne inneholder regler for Quartz angående flere temaer, blant annet hvor mange tråder som maksimalt kan kjøres, og feilhåndtering ved feil av Quartz brytere. Det er lite vi trenger å bry oss med I vårt tilfelle, da vi har logikken utenfor Quartz. Uansett krever Quartz visse innstillinger konfigurert for å I det hele tatt kjøre. Problem: Quartz har ett bibliotek med navn common.jar som nekter Quartz å starte. Løsning: Etter noe søkning på internett etter lignende problemer, dukket det opp flere tilfeller av brukere I nettsamfunn som har funnet at det er feil med noen versjoner av common.jar biblioteket til Quartz. Den nyeste versjonen av common.jar(versjon 3.2.1) ble lastet ned og erstattet med den gamle. Og Quartz kunne så kjøres BRUK AV SUBVERSION(VII) Subversion er ett verktøy vi har benyttet oss av for å ivareta forskjellige versjoner av Java filene vi har implementert, og gir i tilegg muligheten til å dele versjonene med veiledere og internt i gruppa. Serveren til Subversion har sannsynligvis fått problemer da området vi var koblet opp mot sluttett å fungere. De hadde opplevd samme problem ved Accenture. Dette hendte helt i slutten av vår implementerings fase. Vi satte derfor opp vårt eget område i Google Space som støtter lagring og deling med Subversion. Da vi på denne tiden hadde også opplevd problemer med koden, kunne vi ikke nå tilbake til tidligere fungerende versjon slik vi ville ha ønsket. Vi har tatt flere sikkerhetskopier i VirtualBox, men da vi ikke hadde noen sikkerhets kopier fra nylig og derfor mistet derfor mye tid da vi måtte gå tilbake til ett tidligere stadium av implementeringsprosessen BRUK AV MAVEN(VI) 43

44 Vi brukte mye tid på å legge opp riktige baner for avhengigheter i Java da vi benytter oss av forskjellige rammeverk med flere prosjekter. Etter noe tid foreslo våre veiledere fra Accenture at vi burde bruke Maven til våre egne prosjekter i systemet. Maven er benyttet til prosjektene har ligget i POC et som vi fikk fra bedriften. Vi begynte med å bruke Maven for å legge inn avhengigheter i det nye systemet. Det har fungert brukbart for oss etter hvert som vi lærte det bedre. 6.3 HVA ER NESTE SKRITT ETT BRUKERVENNLIG GRENSESNITT For at produktet skal være mer trivielt å bruke kan vi gjøre det kjørbart fra kommandolinjen. Det vil da være hensiktsmessig å kunne gi det kjørbare programmet parametere for når jobben skal kjøres, som Quartz tar seg av. Ett eksempel: Batch(24,15,man), ville da kunne kjørt batchsystemet hver mandag kl 24:15. For at dette skal fungere måtte man ha en funksjon som denne: Batch(int time, int minutt, int dag). For å gjøre systemet brukervennlig kunne vi gitt ett grafisk grensesnitt hvor vi kan velge mellom forskjellige operasjoner som sk al utføres, slik som å legge til, fjerne eller oppdatere studenter lærere og kurs A LTERNATIVE LØSNINGER Da systemet er fleksibelt for endringer kan følgende deler av systemet byttes ut. Som tidligere nevnt er dette en stor fordel når vi ønsker å benytte andre løsninger, eller vil ha mulighet til å benytte nye løsninger som måtte komme. Dette vil være fornuftig langsiktig tankegang: PAKKE 1: DATABASEN. Det finnes en rekke typer databaser som kan erstatte Posgresql. PAKKE 2: PERSISTERING Det finnes få alternativer til Hibernate. P AKKE 3: BATCH LOGIKK Kan byttes ut med SpringBatch. P AKKE 4: TIDSSTYRING Kan byttes ut med for eksempel Struts eller Flux. 44

45 7 KONKLUSJON Det var visse ting som lå klart for oss i begynnelsen. Eksempler på dette er at batchsystemer håndterer en lang rekke med inndata av en type, utfører en handling på disse, og så sender de ut igjen. Dette kunne i begynnelsen høres trivielt ut. Vi lærte underveis at dette ikke nødvendigvis er tilfelle. Problemene som oppstår når man forsøker å la objekter representere flate todimensjonale tabeller i en database er komplekse, og vi mistenker at tiden vi brukte på få dette til å virke kunne like gjerne vært brukt på å skrive metoder for å hente data kun med vanlig JDBC driver. Det vi kom fra til alt i alt er at vi har muligheten til å få ett system slik som det vi har laget til å fungere med J2SE. Med mer tid enn vi har hatt, skal det være fullt mulig å implementere den logikken som trenges for å ha ett robust og fullt fungerende batch system. 45

46 8 VERKTØY i. U BUNTU 8.10 Ett Linux Operativsystem. Mer informasjon på: ii. V IRTUALB OX Ett program som kan opprette og kjøre image med virtuelle operativsystem. Støtter en rekke operativsystemer og har støtte for nettverk innenfor disse systemene. Mer informasjon på: iii. ECLIPSE Programmerings verktøy for blant annet Java språket med støtte for en rekke hjelpe verktøy (plugins). Mer informasjon på: iv. H IBERNATE TOOLS( ) Mer informasjon på: v. Q UARTZ( ) Ett skedulerings verktøy for tilknytning til Java prosjekter. Mer informasjon på: vi. M AVEN 2 Verktøy og plugin for Eclipse. Fungerer som et administrasjons verktøy for å definere og vedlikeholde avhengigheter mellom klasser og eksterne klassebiblioteker. Mer informasjon på: vii. S UBVERSION 46

47 Ett verktøy som kan fungere som ett plugin for Eclipse. Kan benyttes til å ivareta forskjellige versjoner av Java filer på en ekstern server. Fungerer også slik at det er mulig å dele filer/klasser med andre som har tilgang til serveren. Vi benytter oss av Subclipse versjonen til Subversion. Mer informasjon på: viii. P OSTGRESQL 8.3 (PGADMIN3) Ett objekt-relasjons database system. Mer informasjon på: ix. Q UANTUM Plugin for Eclipse for å få tilgang til databaser. Støtter blant annet Postgresql. Mer informasjon på: x. M ICROSOFT OFFICE VISIO 2007 Ett verktøy som kan lage UML og sekvensielle diagrammer. Vi har hovedskalig brukt "Uml 2.0 stencils" som standard innad i systemet. Mer informasjon på: no/visio/ha aspx 47

48 9 KILDER ANSI/ISA. (2002). S88 Batch Standard General Overview. Philadelphia: ISA The Instrumentation, Systems, and Automation Society. Bauer, C. (2004). Hibernate in Action. Manning Publications. Burgess, M. (2001, 10 3). A Short Introduction to Operating Systems. Buttazzo, G. C. (2004). Hard Real Time Computing Systems: Predictable Scheduling Algorithms and Applications. Springer. Goetz, B., Peierls, T., Bloch, J., Bowbeer, J., Holmes, D., & Lea, D. (2006). Java Concurrency in Practice. Addison Wesley Professional. Haugerud, H., & Begnum, K. (2008). Operativsystemer og Unix notater. Forelesningsnotater H08. HiO. Intel. (2009). Process Scheduling & Concurrency Introduction to Embedded Systems. OpenSymphony. (2009). Quartz Enterprise Job Scheduler. Hentet 2009 fra Open Symphony Quality Components: Red Hat Middleware LLC. (2009). Hibernate. Hentet 2009 fra Richards, M. (2006, 05 31). Java Transaction Design Strategies. InfoQ. SpringSource. (n.d.). Spring Batch. Retrieved 2009, from batch/trunk/ Sun Microsystems, Inc. (u.d.). Sun Developer Network (SDN). Hentet 2009 fra ANSI/ISA. (2002). S88 Batch Standard General Overview. Philadelphia: ISA The Instrumentation, Systems, and Automation Society. Bauer, C. (2004). Hibernate in Action. Manning Publications. Burgess, M. (2001, 10 3). A Short Introduction to Operating Systems. Buttazzo, G. C. (2004). Hard Real Time Computing Systems: Predictable Scheduling Algorithms and Applications. Springer. Goetz, B., Peierls, T., Bloch, J., Bowbeer, J., Holmes, D., & Lea, D. (2006). Java Concurrency in Practice. Addison Wesley Professional. Haugerud, H., & Begnum, K. (2008). Operativsystemer og Unix notater. Forelesningsnotater H08. HiO. Intel. (2009). Process Scheduling & Concurrency Introduction to Embedded Systems. OpenSymphony. (2009). Quartz Enterprise Job Scheduler. Hentet 2009 fra Open Symphony Quality Components: Red Hat Middleware LLC. (2009). Hibernate. Hentet 2009 fra Richards, M. (2006, 05 31). Java Transaction Design Strategies. InfoQ. SpringSource. (n.d.). Spring Batch. Retrieved 2009, from batch/trunk/ Sun Microsystems, Inc. (u.d.). Sun Developer Network (SDN). Hentet 2009 fra

49 APPENDIKS 9.1 KLASSEDIAGRAMMER com.accenture.course.batch.quartz Schedule * logger : Logger = Logger.getLogger(Schedule.class.getName( )) main (String args[]) TimeToMillis * * * * * Schedule::TimeToMillis days (long amount) hours (long amount) minutes (long amount) seconds (long amount) currenttime () : long : long : long : long : long testrun * logger : Logger = Logger.getLogger(testRun.class.getName( )) main (String args[]) 49

50 com.accenture.course.batch.job IWork (batch) dowork (Element element) : Element InputWork * logger : Logger = Logger.getLogger(InputWork.class.getName( )) OutputWork * logger : Logger = Logger.getLogger(OutputWork.class.getName( )) <<Implement>> dowork (Element element) : Element curelement currentlecturerdo currentcoursedo Element (batch) LecturerDO (domain) CourseDO (domain) persistence Persistence (persistence) addstudentdo (StudentDO studentdo) addcoursedo (CourseDO coursedo) addlecturerdo (LecturerDO lecturerdo) batchupdatestudentdos (Queue<StudentDO> studentdos) batchsavestudentdos (Queue<StudentDO> studentdos) batchgetstudentdos () findcoursedolist (String name, String code) finddepartmentdolist (DepartmentDO departmentdo) getcoursedo (Integer courseid) getlecturerdo (Integer lecturerid) getstudentdo (Integer studentid) removestudentdo (StudentDO studentdo) updatecoursedo (CourseDO coursedo) updatelecturerdo (LecturerDO lecturerdo) updatestudentdo (StudentDO studentdo) : StudentDO : CourseDO : LecturerDO : ScrollableResults : ScrollableResults : List<DepartmentDO> : CourseDO : LecturerDO : StudentDO : CourseDO : LecturerDO : StudentDO 50

51 com.accenture.course.batch quartz job ElementPartition * * # # # # # logger queue maxsize serial VersionUID id worktodo <<Constructor>> : Logger : LinkedBlockingQueue<Element> : int : long : int : IWork worktodo = Logger.getLogger(ElementPartition.class.getName( )) = null = L = 0 = null ElementPartition (int size, IWork WorkDefinition) getid () getmaxsize () getqueue () getworktodo () performworktodo (Element element) setqueue (LinkedBlockingQueue<Element> partitionqueue) setworktodo (IWork worktodo) workonelements () : long : int : LinkedBlockingQueue<Element> : IWork : Element : ElementPartition parentpartition worktodo IWork dowork (Element element) : Element * # logger elementobject lastid id done parentpartition <<Constructor>> : Logger : Object : int : long : boolean : ElementPartition Element = Logger.getLogger(Element.class.getName( )) = null = 0 = false = null Element (Object object) getdone () getelementobject () getid () setdone () setelementobject (Object elementobject) setid (long elementid) getparentpartition () setparentpartition (ElementPartition ep) : boolean : Object : long : ElementPartition * # # - - # # logger inputqueue outputqueue worktodo partitionsize <<Constructor>> : Logger : LinkedBlockingQueue<Element> : LinkedBlockingQueue<Element> : IWork : int JobContainer getpartitionsize () setpartitionsize (int partitionsize) JobContainer (IWork work, int partsize) offertoinputqueue (Element e) packtopartition () processpartition (ElementPartition ep) takefinishedelement () addtooutputqueue (ElementPartition finishedpartition) = Logger.getLogger(JobContainer.class.getName( )) = new LinkedBlockingQueue<Element>() = new LinkedBlockingQueue<Element>() = null = 0 : int : boolean : ElementPartition : ElementPartition : Element jobcontainer BatchSystem <<Unresolved Interface>> Job (quartz) * - - logger jobcontainer jobno : Logger : JobContainer : int getjobno () updatejobno () execute (JobExecutionContext context) getjob () run () setjob (IWork w, int i) stop (int errorcode) test () = Logger.getLogger(BatchSystem.class.getName()) = null = 0 : int : JobContainer 51

52 com.accenture.course.persistence.hibernate util Persistence (persistence) addstudentdo (StudentDO studentdo) addcoursedo (CourseDO coursedo) addlecturerdo (LecturerDO lecturerdo) batchupdatestudentdos (Queue<StudentDO> studentdos) batchsavestudentdos (Queue<StudentDO> studentdos) batchgetstudentdos () findcoursedolist (String name, String code) finddepartmentdolist (DepartmentDO departmentdo) getcoursedo (Integer courseid) getlecturerdo (Integer lecturerid) getstudentdo (Integer studentid) removestudentdo (StudentDO studentdo) updatecoursedo (CourseDO coursedo) updatelecturerdo (LecturerDO lecturerdo) updatestudentdo (StudentDO studentdo) : StudentDO : CourseDO : LecturerDO : ScrollableResults : ScrollableResults : List<DepartmentDO> : CourseDO : LecturerDO : StudentDO : CourseDO : LecturerDO : StudentDO - - * - batchsize current logger : int : int : Logger <<Implement>> <<Implement>> <<Implement>> <<Implement>> <<Implement>> <<Implement>> <<Implement>> <<Implement>> <<Implement>> <<Implement>> <<Implement>> <<Implement>> <<Implement>> <<Implement>> <<Implement>> PersistenceHibernateImpl = 20 = 0 = Logger.getLogger(PersistenceHibernateImpl.class... flushcounter () addstudentdo (StudentDO studentdo) addcoursedo (CourseDO coursedo) addlecturerdo (LecturerDO lecturerdo) batchupdatestudentdos (Queue<StudentDO> studentdos) batchsavestudentdos (Queue<StudentDO> studentdos) batchgetstudentdos () findcoursedolist (String name, String code) finddepartmentdolist (DepartmentDO departmentdo) getcoursedo (Integer courseid) getlecturerdo (Integer lecturerid) getstudentdo (Integer studentid) removestudentdo (StudentDO studentdo) updatecoursedo (CourseDO coursedo) updatelecturerdo (LecturerDO lecturerdo) updatestudentdo (StudentDO studentdo) : StudentDO : CourseDO : LecturerDO : ScrollableResults : ScrollableResults : List<DepartmentDO> : CourseDO : LecturerDO : StudentDO : CourseDO : LecturerDO : StudentDO 52

53 com.accenture.course.persistence.hibernate.util HibernateUtil - sessionfactory : org.hibernate.sessionfactory - - <<Constructor>> <<staticinitializer>> HibernateUtil () _STATIC_INITIALIZER () close () getcurrentsession () getinstance () getsession () opensession () : Session : SessionFactory : Session : Session 53

54 com.accenture.course.persistence.domain CourseDO getcourseid () setcourseid (Integer courseid) getversion () setversion (int version) getlecturerdo () setlecturerdo (LecturerDO lecturerdo) getdepartmentcode () setdepartmentcode (String departmentcode) getcode () setcode (String code) getname () setname (String name) getdescription () setdescription (String description) getcredits () setcredits (Integer credits) getexamdate () setexamdate (Date examdate) getstudentdos () setstudentdos (Set<StudentDO> studentdos) tostring () equals (Object other) hashcode () : Integer : int : LecturerDO : String : String : String : String : Integer : Date : Set<StudentDO> : String : boolean : int lecturerdo getlecturerid () setlecturerid (Integer lecturerid) getversion () setversion (int version) getfirstname () setfirstname (String firstname) getlastname () setlastname (String lastname) getcoursedos () setcoursedos (Set<CourseDO> coursedos) tostring () equals (Object other) hashcode () LecturerDO : Integer : int : String : String : Set<CourseDO> : String : boolean : int StudentDO getstudentid () setstudentid (Integer studentid) getversion () setversion (int version) getfirstname () setfirstname (String firstname) getlastname () setlastname (String lastname) get () set (String ) getcoursedos () setcoursedos (Set<CourseDO> coursedos) tostring () equals (Object other) hashcode () : Integer : int : String : String : String : Set<CourseDO> : String : boolean : int <<Unresolved Interface>> Serializable (io) DepartmentDO FacultyDO getfacultycode () setfacultycode (String facultycode) getversion () setversion (int version) getname () setname (String name) tostring () equals (Object other) hashcode () : String : int : String : String : boolean : int getdepartmentcode () setdepartmentcode (String departmentcode) getversion () setversion (int version) getfacultycode () setfacultycode (String facultycode) getname () setname (String name) tostring () equals (Object other) hashcode () : String : int : String : String : String : boolean : int 54

55 10.2 SEKVENSDIAGRAM FOR BATCH JOBB SCHEDULE:SCHEDULE SIMPLETRIGGER :BATCHSYSTEM JOB:JOBCONTAINER :ELEMENTPARTITION ELEMENT:ELEMENT INPUTWORK:IWORK OUTPUTWORK:IWORK SCHEDULE WAIT 10S FIRST EXECUTE LOOP CREATE AND CONFIGURE SCHEDULE CREATE {AS SCHEDULED} CREATE EXECUTE LOOP {UNTIL EMPTY} <<ELEMENT>> CREATE JOB ELEMENTS END LOOP {UNTIL FULL QUEUE} <<ELEMENT>> FILL PARTITION LOOP {ALL ELEMENTS} PERFORM WORK INPUT WORK OUTPUTWORK <<ELEMENT>> MOVE TO OUTPUTQUEUE <<ELEMENT>> FINISH TO PARTITION END(JOB) END