Web Service Registry

Transkript

1 BACHELORPROSJEKT 21 Web Service Registry Prosjektpresentasjon Ola Hast og Eirik Kvalheim Dette dokumentet er en kort presentasjon av bachelorprosjektet Web Service Registry

2 Innhold 1. Om oppgavestiller Problemstillingen som skal løses Hvorfor ble denne oppgaven valgt Hvordan ble oppgaven løst Resultater Videre arbeid Kontaktinformasjon... 5

3 1. Om oppgavestiller Kantega AS er en bedrift som holder til både i Oslo og Trondheim. Den har 74 ansatte fordelt på disse kontorene med brorparten i Trondheim. Kantega driver med konsulentvirksomhet innen IT og forvaltning av tjenester for blant annet Sparebank 1 Gruppen. De er en av Norges ledende bedrifter innen tjenesteorientert arkitektur, sikkerhet og digital signering. 2. Problemstillingen som skal løses Prosjektet er knyttet til tjenesteforvaltningsdelen til oppgavestiller. Webtjenestene de forvalter ligger på en såkalt Enterprise Service Bus og det er ønsket å få en løsning som kan benyttes til å administrere livsløpet til tjenestene. Følgende funksjonalitet var ønsket: - Oversikt over avhengigheter mellom tjenester - Versjoner på tjenester - Produsenter av tjenester - Mulighet for konsumenter å søke i databasen etter tjenester og spesiell funksjonalitet - Varsling av konsumenter eller klienttjenester når en oppdatering av tjenesten rulles ut. - Mulighet for konsumentene selv kan vedlikeholde kontaktinformasjon og informasjon om hvilken tjenesteversjon de bruker. - SQL-database som persisterer avhengigheter. - Web applikasjon som presenterer sammenhenger og informasjon om tjenesten. - Scriptbasert masseoppdatering. Det ble lagt vekt på at dette kun var en prototype vi skulle utvikle, og ikke et ferdig produkt. 3. Hvorfor ble denne oppgaven valgt I vårt studieopphold i Australia ble vi bedre kjent med tjenesteorientert arkitektur og webtjenester. Derfor hadde vi et ønske om å finne en oppgave som omhandlet disse temaene. Vi var interessert i å se hvordan SOA og webtjenester ble brukt i den virkelige verden og utvide våre tekniske kunnskaper om emnet.

4 4. Hvordan ble oppgaven løst Etter at vi hadde ferdigstilt og fått godkjent forstudierapport og kravdokument begynte vi å lete etter eksisterende løsninger vi kunne bruke og modifisere. Av løsningene vi fant valgte vi et register kalt Membrane laget av ett tysk firma kalt Predic8. Denne løsningen var en åpen kildekodeløsning som vi kunne modifisere slik at den passet vår bruk. Løsningen er lagd i ett rammeverk som heter Grails som er basert på Spring, Hibernate og Groovy. Groovy er et scriptspråk som igjen er bygd på Java og kan operere sømløst med kode skrevet i Java. Vi begynte så å utvikle en datamodell og en modell for et XMLskjema som kunne brukes til å oppdatere registeret med en rekke tjenester fra tjenestebussen. Videre tilpasset vi systemet i henhold til de use case vi hadde beskrevet i kravdokumentet. Use casene er basert på ønskene til oppgavestiller som nevnt ovenfor. I utviklingsprosessen har vi benyttet Unified Process med følgende artefakter: - Kravdokument - Arkitekturdokument - Designdokument Kravdokumentet spesifiserer kravene som er på forhånd stilt til applikasjonen som skal utvikles. Arkitekturdokumentet beskriver den overordnede arkitekturen i systemet imens designdokumentet beskriver hvordan de enkelte use casene er realisert. I utviklingsfasen har vi benyttet IntelliJ IDEA på grunn av at IDEA har utmerket innebygd støtte for rammeverket Grails. 5. Resultater Applikasjonen oppfyller de fleste av ønskene som oppgavestiller oppga i oppgavebeskrivelsen. Registeret består av en database og et webgrensesnitt som benyttes både av Konsumenter og administratorer. Det er mulig å se på tjenester, informasjon om tjenestene og skjemaene en tjeneste benytter seg av. Det er også mulig som konsument å knytte seg til en tjeneste. Det er implementert en mulighet for å søke på tjenester, operasjoner og funksjonalitet som den aktuelle tjenesten tilbyr. Vi har laget en solid datamodell med tanke på utvidelser i framtiden, som gir en solid plattform å basere ett register på. Datamodellen inneholder i tillegg til tjenesten selv, metadata om tjenesten og alle XMLskjema som tjenesten benytter. En XML standard har blitt utviklet for å legge til tjenester i registeret. Den inneholder en adresse til tjenesten, avhengigheter og annen metadata som ikke kan hentes ut ifra WSDL. Noe vi ikke implementerte er muligheten til å knytte en produsent til en tjeneste. Dette ble delvis droppet/lagt på is siden det var uklarhet om hvor slik informasjon skulle komme fra. Forholdet mellom produsent og tjeneste ligger i datamodellen og i databasen, men det er ikke realisert i grensesnittet.

5 6. Videre arbeid Siden dette kun var en prototype har vi ikke vektlagt sikkerhet i forhold til kontoer, innlogging og lignende. Vi har kun tatt for oss grunnleggende funksjon i forhold til dataen som skal inn i systemet. Uansett om prototypen vår er noe som vil bli bygd videre på, mener vi at datamodellen vi har utarbeidet i dette prosjektet kanskje er det viktigste resultatet. Denne modellen danner et solid grunnlag for å utvikle applikasjonen videre. Den er enkel å utvide i tillegg til at den inneholder mye relevant informasjon. Kontaktinformasjon Prosjektets medlemmer kan kontaktes på følgende måte Ola Hast: Mail: ola.hast@gmail.com Telefon: Eirik Kvalheim: Mail: eirikkva@gmail.com Telefon: