Flaskehalsen i model 2 og for den sags skyld også model 1 er helt klart SQL-spaces. SQL-spaces er anvendt fordi de er en del af KLAIM implementeringen og de er nemme at anvende. Det vil derfor være en fordel at fjerne tupel spaces, da indlæsning og udtrækning af tupler/data er askehalsen i systemet. I stedet for at anvende SQL-spaces kan man bruge Storms kommunikationsvej. Hvis vi udelukkende gør brug af Storm, så vil systemet yde bedre og derfor behandle ere tupler pr. minut. I Storm sendes data fra en komponent til en anden via forbindelserne i en topologi. I model 1 anvendte vi denne forbindelse til at sende et hashmap i mellem hver bolt i topologien. Den nye idé til udvidelsen af systemet ville være, hvor man sløjfer SQL-spaces og ikke anvender ekstern hukommelse til at lagre data/tupler. I stedet anvender man udelukkende Storms forbindelser til at sende tupler fra en bolt til en anden. I gur 3.20 ses det nuværende system og en udvidelse af det, hvor der er taget udgangspunkt i et udklip af en topologi. På venstre side ses det hvordan en tupel sendes fra en bolt til et space, og hvordan den næste bolt udtrækker den fra et SQL-space. På højre side ses en illustration af det nye system, hvor alle forbindelser til SQL-space er fjernet og i stedet anvendes Storms forbindelse mellem to bolts til at sende data. Udvidelsen af det nuværende system er ikke implementeret pga. manglende tid, men da jeg løbende har haft idéer til hvordan en udvidelse og forbedring kunne se ud har jeg valgt at fremlægge ideen.
IN_tbolt
Det nuværende system Udvidelse af det nuværende system
Figure 3.20: Illustration af forskellen på det nuværende system og det udvid-ede system, hvor der ikke anvendes SQL-spaces.
I den første model af det nye system bliver oversætningen af et KLAIM program ikke ændret, hvor vi beholder oversættelses forholdet på 1 til 1. Data skal stadig yde rundt i systemet i form af tupler, men vi vil gerne have styr på den, på samme måde som da vi anvendte SQL-spaces. Det betyder, at det skal være muligt stadig at have en form for lager, hvor man kan gemme bestemte tupler og hvor KLAIM syntaksen holdes intakt. Grunden til at vi gerne vil have denne lagring af data, skyldes at det er rart at have styr på data. For at gør implementeringen nemmere, skal en lagring, holdes så tæt på KLAIM syntaksen som muligt. Der tænkes at man skal lagre dataen i en Arrayliste
af tupler. Og det betyder, at hvis vi outputter en tupel til @main, så er den nye idé at man danner ArrayList < T uples > og kalder den main. Denne liste indeholder alle tupler der outputtes til main. Ligeledes fjernes en tupel fra listen - på samme måde som den normalt blev fjernet/udtrukket fra et SQL-space. Pattern-matching algoritmen vil i denne løsning være noget man selv skal implementere, da vi skal have en måde at udtrække tupler på. Det er dog ikke særlig kompliceret at lave en matching algoritme, da den der anvendes for SQL-space blot udtrækker en random tupel der matcher størrelsen og søge kriterierne - se afsnit 2.1.6. Det vil dog være den mest avancerede del at implementere i denne model.
Man kan ikke have en model 1 uden også at have en model 2. Den sidste idé bygger på at man danner færre bolts, og går væk fra ideen med at oversætte i et forhold på 1 til 1. Grunden til at jeg har valgt at oversætte i et forhold fra 1 til 1, skyldes at vilkårlige KLAIM programmer kan oversættes. Brugeren der modulerer programmerne behøver ikke, at tænke på hvordan systemet laver oversættelsen, og det er i sig selv også en fordel. Dog kunne man anvende ideen med at gruppere output og input operationer, hvis de har en form for relation.
Med den første model kan vi ende med at der skal sendes meget data i mellem de forskellige bolts i en topologi. Det er ikke et problem at sende meget data, men det er et problem at sende udnødvendig meget data der ikke skal bruges.
I gur 3.21 ses et udsnit af en topologi, hvor den første topologi er et eksempel på at man sender udnødvendig data i mellem bolts. I topologi 1, tilføjes der en tupel til s1 ArrayListen i den første bolt, hvor efter den videresendes til næste bolt. I den sidste bolt skal vi igen bruge s1 til at udtrække en tupel.
Det havde været meget smartere hvis den første og den sidste bolt var direkte forbundet efter hinanden i topologien, fordi de anvender samme lager. Da de ikke er direkte forbundet bliver ArrayListen s1 udnødvendigt videresendt til anden bolt før den ankommer til den sidste bolt. Topologi 2 i gur 3.21 viser en bedre sammensætning, hvor data bliver behandlet på samme måde, men rækkefølgen er ændret. Vi får ikke sendt, ArrayListen med data, udnødvendigt fra den ene bolt til den anden. Topologi 3 viser et eksempel, hvor vi ikke behøver at sende s1 ArrayListen mellem to bolts, fordi operationerne er grupperet og behandles i den samme bolt.
Topologi 2 fra 3.21 vil være en optimering af den første model. Den vil være lige til at implementere, da man blot skal implementere en sorterings algoritme som sorterer operationerne. Alle topologier der anvender samme tupel space forbindes lige efter hinanden. Topologi 3 vil være en ret stor udfordring, da bolt typerne skal ændres meget for at gøre det muligt at udtrække og inputte tupler i samme bolt. Det vil klart være en fordel at vi undgår at ytte data og minimerer antallet af bolts i en topologi.
Out(”Klaim”)@s2 Out(”Storm”)@s1
In(!x)@s1
Analyseret In(!x)@s1
Out(”Storm”)@s1
Out(”Klaim”)@s2
Optimal
Out(”Klaim”)@s2 Out(”Storm”)@s1
In(!x)@s1
Topologi 1 Topologi 2 Topologi 3
Figure 3.21: Tre forskellige topologier, men af den samme KLAIM beskrivelse.
Hvor topologierne bliver bedre og bedre fordi der yttes mindre og mindre data.
Chapter 4
Gennemgang af en use case
I dette kapitel gennemgås hele det udviklede system, så det giver indblik i hvor-dan systemet oversætter et KLAIM program for til sidst at ende med at have en Storm topologi til behandling af data. Først forklares en use case der giver et godt billede af, hvad man vil bruge systemet til. Systemet opdeles i 3 dele:
1. KLAIM programmet 2. Oversættelsen 3. Storm topologien
Det skal lige siges, at der tages udgangspunkt i model 2 for dannelse af Storm topologien.
4.1 Use casen
Use casen der vil blive brugt i denne afhandling, tager udgangspunkt i søgninger fremsendt til et rma via email. En ansøger fremsender sin joban-søgning via email til adressen: jobanjoban-søgning@rma.dk. Email adressen bruges
udelukkende til modtagelse af jobansøgninger. Job opslaget ndes på rmaets hjemmeside, hvor ansøgeren bliver gjort opmærksom på, hvordan ansøgning skal fremsendes. Hvert jobopslag har et unikt nummer der anvendes til at referere til et bestemt jobopslag. En ansøger skal i email feltet angive 'job' og nummeret på det job, der søges. Yderligere er det vigtigt at der vedhæftes tre forskellige ler:
• Ansøgning - ansøgerens personlige ansøgning.
• CV - en levnedsskildring der oplyser om uddannelses- og erhvervsmæssige kvalikationer.
• Formular - en formular rmaet har opstillet.
I jobopslaget ndes en formular der skal udfyldes, for at søge jobbet. I for-mularen skal ansøgeren blandt andet angive hvad id'et er til hans Facebook og Linkedin proler. Firmaet er meget interesseret i at kunne bruge Facebook og Linkedin til at søge ere informationer om ansøgerne. Systemet der ønskes udviklet skal anvende en ansøgers Facebook id for at undersøge, hvor mange venner og billeder han har på sin prol. På samme måde anvendes også linkedin id'et til at se hvor mange forbindelser ansøgeren har. De nye informationer fra Facebook og Linkedin bliver samlet i to nye pdf-ler med navnene hhv. Face-book og Linkedin. De fem pdf ler arkiveres til sidst i en database sammen med ansøgerens navn og nummeret på jobopslaget. Dette system er rimelig simpelt, men det tænkes at man kan udvide disse services til mere avancerede teknikker.
F.eks. kan man undersøge, om ansøgeren er tilhænger af nogle bestemte grupper på Facebook, som rmaet ikke kan acceptere.
Systemet udvikles i Storm, hvor der tænkes at man har en spout, der er koblet op til at lytte på en mail box. Hvis der indkommer en email bliver den udtaget af spouten, og de vigtige informationer videresendes i form af en tupel med fel-terne <navn, job-nummer, ansøgning, formular, CV>. En topologi bestående af seks forskellige bolts dannes, hvor der haves to service bolts. Den først ser-vice bolt anvender facebook id'et til at nde ansøgerens facebook prol for at se hvor mange venner og billeder ansøgeren har - i praksis vil et screenshot være tilstrækkeligt at gemme. De fundne oplysninger fra facebook anvendes til at berige tuplen med informationer om ansøgeren. Den anden service bolt anvender linkedin id'et til at nde linkedin prolen, hvor der undersøges hvor mange forbindelser ansøgeren har. Den resulterende tupel kan nu dannes og den har følgende felter: <navn, job-nummer, ansøgning, formular, CV, face-book, linkedin>. Den videresendes til den sidste bolt, som gemmer den i en database/tupelspace.