English web site
Scenario 2 - Fördjupning
Syfte
Scenariot ämnar hjälpa studenten att uppfylla följande mål.
Lärandemål - Gäller TDP024
Från kursplanen: Kursplan- redogöra för ramverk/mönster för att utveckla affärssystem (enterprise applications)
- redogöra för principerna för service-oriented architecture (SOA)
- reflektera över egen programutveckling inom området och diskutera alternativa lösningar
Programmål - Gäller IP
Från utbildningsplan: Utbildningsplan- ämne: principiell kunskap som ingår som en del i den vetenskapliga teoribyggnaden runt programmering och datorer, främst inom den datavetenskapen
- teknik: kunnande om den teknik som finns för programmering och datorer, med fokus på programmeringsspråk och plattformar.
Examensmål - Gäller Kandidatexamen
Från examensordning: Examensordning- visa förmåga att söka, samla, värdera och kritiskt tolka relevant information i en problemställning samt att kritiskt diskutera företeelser, frågeställningar och situationer
- visa förmåga att självständigt identifiera, formulera och lösa problem samt att genomföra uppgifter inom givna tidsramar
- visa förmåga att muntligt och skriftligt redogöra för och diskutera information, problem och lösningar i dialog med olika grupper
Scenarion
Grundläggade
Enhetstestning på testdatabas
Någon hade kod i sina enhetstester som "droppade" databasen, och Jenkins körde det mot produktionsdatabasen över natten. Alla konton är borta. Detta måste vi se till aldrig händer igen. Det är upp till dig att skapa ett system för hur man i sina tester kan köra mot en förutbestämd test-databas. Utöver detta är vi intresserade av att öka hastigheten på testerna, vår MySQL databas är för långsam...Tidsbaserade händelser
Det har visat sig att det väldigt ofta behövs köras kod mitt i natten, eller varje månad, eller varje heltimme etc. Vi vill gärna att utvecklarna skall kunna göra detta själva ifrån sin kod, men att det ändå skall ske på ett likartat sätt hos alla. Vi är medveten om att man måste på något sätt se till att alla inte kör kod hela tiden, det måste finnas någon kontroll på det hela. Det är upp till dig att standardisera hur detta skall göras i företaget.JSON vs parameterar och parameterar vs objekt
Vi har varit på utvecklar-konferens, det märks eftersom vi hänger runt utvecklarna och kommer med förslag. Den senaste snilleblixten var att ändra alla webbanrop så att man skickar hela JSON objekt istället för parameterar. Samtidigt undrar vi om man kan ändra i datalagret så att våra facades tar emot java objekt istället för parametrar, typ create(Car car) och inte create(int doors, String color). Gör en grundlig undersökning på dessa två saker, kanske har vi rätt i något fall, eller båda?Detaljerade Exceptions
Idag returnerar tjänsterna bara ett fel tillbaka till anropet. Detta är inte så användbart och hjälper inte klienten som anropar att förstå vad som behöver ändras för att lyckas med anropet eller vad som gått fel. Utveckla ett system för att kunna informera klienter om exakt vad som gått fel, detta skall minst inkludera input fel (t ex saknad av parametrar) och systemfel (t ex rollback eller connection errors).Vad innehåller Java EE mer ?
Det finns många fler bibliotek i Java EE, mest framstående är EJB. Gå igenom alla bibliotek och hitta intressanta delar som du kan presentera för oss. Titta noga på EJB och Bean Validation men också på andra bibliotek.Avancerade
Zero-Downtime
Det går bra nu, och kunderna rusar efter våra tjänster. Våra system behöver dock uppdateras men ingen vet hur man skall göra det utan att störa tjänsterna i drift. Vi vill veta hur vi ska uppdatera din nya tjänst utan att det påverkar någon, detta innebär att anrop som görs under tiden du uppdaterar inte på något sätt får påverkas, det är alltså Zero-Downtime som gäller. Presentera en lösning för oss hur detta kan göras, om möjligt skall den vara agnostisk och inte bunden till just Glassfish och Java.Säkerhet
Det var ganska uppenbart när du började här att säkerheten kom i andra hand. De existerande tjänsterna var helt öppna för omvärlden, och det är även den tjänst du skapade. Presentera en lösning för hur man kan säkra SOA tjänsten du byggt, men bibehålla de principer som SOA tjänster bygger uppe på (bland annat "stateless"). Presentera säkerhetsriskerna som finns idag och hur de kan lösas. Det absolut viktigaste är att vi ser till att endast behöriga har rätt att göra anrop, men också att vi vet vem som anropar.Business Layer Transaction
Det har varit noga med transaktioner i datalagret, allt kan återskapas i en transaktion om något går fel. Men hur är det i business lagret? Antag att man har ett anrop som först skickar en tweet till twitter, sedan ett inlägg på facebook, skickar en faktura med post till en kund och sist skriver till databasen. Men om databasen misslyckas, hur backar vi tweeten, inlägget och fakturan? Vi vill gärna ha ett enhetligt och stabilt sätt för att skapa transaktioner i business lagret.Redovisning
Välj ett scenario från ovanstående lista. De är uppdelade i två kategorier, grundläggande och avancerad. För att få betyg 5 i kursen måste ett avancerat ämne behandlats. Dock är det möjligt att få betyg 3 och 4 även om ett avancerat ämne har valts.
Ni skall hitta flera olika lösningar på ert valda scenario, och fördjupa er i den lösning ni tycker är bäst. Mät hur bra er lösning är med följande måttstockar:
- Hur pass bra löser den problemet beskrivet i scenariot?
- Hur mycket påverkar lösningen utvecklingsarbetet, dvs hur mycket extra arbete skapar man för utvecklarna?
- Påverkas våra SOA principer?
Ni lämnar in en skriftlig rapport, er valda lösning i kod och förbereder en muntlig presentation av ämnet. Presenationen görs i tvärgrupp och skall bestå av en presentation av det valda scenariot och demonstration av den valda lösningen. Presentationen bör ta ca 10 minuter.
Presentationen genomförs på seminarium den 15:e Oktober klockan 13:15, den 10:e Oktober klockan 10:00 är det deadline för allt skriftligt material.
OBS: Allt skriftligt material skall sparas som PDF och skickas i ett mejl till marbe92.liu@analys.urkund.se
I den skriftliga rapporten skall följande ingå:
- Abstrakt: 1/2 A4:a som sammanfattar hela arbetet inklusive problemställning och resultat.
- Motivering/Syfte: 1 A4:a som beskriver problemet tydligt och varför det är viktigt.
- Teori: Beskriv den befintliga kunskap som du använder för att hitta lösningar på problemet, t ex designmönster, prestanda tester, testning, databasdesign etc. Detta stycke skall hjälpa läsaren att förstå bakgrunden till era lösningar.
- Metod: Beskriv hur du gjorde för att skapa dina lösningar.
- Resultat: Beskriv de lösningar du hittat, problematisera dessa och välj en lösning du anser vara bäst. Förklara varför du valt just den lösning du valt. Att problematisera innebär här att man försöker hitta svagheter i sina lösningar.
- Slutsatser/Diskussion: Kortfattat summera arbetet, och redovisa för potentiella nya problem med systemet som ni kanske introducerat med er lösning.
- Referenser: Redovisa för era referenser, wikipedia kan vara ett bra plats att påbörja sin research, men får inte vara en referens.
Sidansvarig: infomaster
Senast uppdaterad: 2012-09-28
