PM 01 En jämförelse av två analysmodeller för val av komponentteknik

Transkript

1 MÄLARDALENS HÖGSKOLA Institutionen för Ekonomi och Informatik v PM 01 En jämförelse av två analysmodeller för val av komponentteknik Eskilstuna, EI0230 Komponentbaserad applikationsutveckling PM01 version 3 Grupp 2 Blomqvist Maria Eriksson Daniel

2 MÄLARDALENS HÖGSKOLA Institutionen för Ekonomi och Informatik v Innehållsförteckning 1 Inledning Bakgrund Problematisering Syfte Beskrivning av modeller Modell 1 - A comparison of multimedia application development platforms towards the object web, Av A. Michalas, V. Zoi, N. Sotiropoulos, N. Mitrou, V. Loumos, E. Kayafas Modell 2 - Performance comparison of CORBA and RMI, Av M. B. Juric, I. Rozman and M. Hericko Analys Slutsatser Källförteckning

3 MÄLARDALENS HÖGSKOLA Promemoria 2 (13) 1 Inledning Vi har funnit att det finns många modeller för att välja vilken komponentteknik som lämpar sig bäst i ett specifikt informationssystems utvecklingsprojekt. Att ta beslut om vilken komponentteknik som är bäst lämpad för ett visst informationssystems utvecklingsprojekt är svårt. Svårigheten består till stor del av att denna typ av teknik avviker betydligt från den teknik som används för att implementera systemet i övrigt. Vi tror även att ett annat problem kan vara att informationssystemsutvecklare inte alltid har den kompetens som krävs för att ta beslut om komponentteknik. I detta PM jämförs två analysmodeller för val av komponenttekniker i ett utvecklingsprojekt. Likheter och olikheter samt för- och nackdelar med de olika modellerna påvisas och sedan presenteras slutsatser som dragits ifrån detta material. 1.1 Bakgrund Från början var Internet ett envägsmedium för att publicera statiska dokument. Senare utvecklades mer interaktiva medium i och med införandet av klient/server HTTP 1 /CGI 2 modellen. Detta medium var dock svårt att använda, inte speciellt snabbt och hade ett tillståndslöst protokoll som inte var lämpligt för moderna klient/server applikationer. Mjukvarutillverkare försökte därför komma förbi de hinder som fanns hos HTTP/CGI genom att utveckla olika CGI-utökningar, men dessa kan inte helt täcka de nya krav som finns. (Michalas m.fl. 2000) Idag erbjuder Internet nya sätt att kommunicera, många multimediaapplikationer som erbjuder tjänster har vidareutvecklats och Internet håller på att bli den huvudsakliga plattformen för att bygga kommersiella applikationer. Nätverkstillväxten och den globala kommunikationen via nätverk har idag nått gränserna för traditionell objektorienterad programmering. De mest kritiska aspekterna som inte stöds av dem är kommunikation och interaktion mellan klient och server. Dessa två aspekter är viktiga när det gäller att bygga den nya generationen av distribuerade informationssystem som kräver kommunikation mellan beräknande entiteter. Det finns ett behov för en klient att direkt kunna anropa ett serverobjekt som kan innehålla klientens tillstånd under ett besök på en webbplats, när användaren hoppar mellan olika sidor på en applikation. Detta nya tillvägagångssätt leder till vad som kan kallas objekt web, och detta koncept är resultatet av försök att integrera objektorienterade tekniker för att låta olika objekt i ett nätverk kommunicera med varandra med hjälp av komponenttekniker. (Michalas m.fl. 2000) 1 HyperText Transfer Protocol 2 Common Gateway Interface

4 MÄLARDALENS HÖGSKOLA Promemoria 3 (13) Det finns flera olika komponenttekniker. Vår arbetsgrupp har läst två artiklar som handlar om olika sätt att analysera vilken komponentteknik som är lämpligast att använda under vissa förutsättningar. En av de mest välkända teknikerna är CORBA 3. I artiklarna jämförs denna teknik med ASP 4 och Java RMI 5 som är två andra lösningar för att kommunicera mellan nätverksobjekt. I artiklarna presenteras två analysmodeller för val av komponentteknik som vi i detta PM jämfört med varandra. 1.2 Problematisering Det finns flera olika modeller för val av komponentteknik. Problemet ligger i att olika komponenttekniker kan vara bra att använda beroende på olika förutsättningar. Tar olika modeller hänsyn till olika förutsättningar, d.v.s. vilken typ av krav som finns på det färdiga systemet avseende till exempel prestanda (svarstider och hanterad datamängd)? Finns det likheter mellan de olika analysmodellerna, eller är det rentav samma modell i olika utförande? 1.3 Syfte Syftet med denna undersökning är att beskriva två olika modeller för val av komponentteknik och jämföra dessa modeller med varandra. 3 Common Object Request Broker Architecture 4 Active Server Pages 5 Remote Method Invocation

5 MÄLARDALENS HÖGSKOLA Promemoria 4 (13) 2 Beskrivning av modeller Här följer en kort presentation av de modeller som ligger till grund för våra analyser och slutsatser. 2.1 Modell 1 - A comparison of multimedia application development platforms towards the object web, Av A. Michalas, V. Zoi, N. Sotiropoulos, N. Mitrou, V. Loumos, E. Kayafas Den första modellen (se figur 1) grundas på innehållet i artikeln A comparison of multimedia application development platforms towards the object web. I artikeln beskrivs två olika objektorienterade implementationsmodeller: HTTP/ASP kontra Java/CORBA. Dessa jämförs experimentellt i ett verkligt scenario för att ta fram fördelar och nackdelar med respektive komponentteknik. I artikeln har vi försökt utröna författarnas analysmodell över jämförelsen av de olika teknikerna. Denna analysmodell anser vi är den som författarna till artikeln menar skulle kunna ligga till grund för vilken teknik som bör väljas i olika situationer. Verkligt scenario Analysmodell för val av komponentteknik Flera klienter En klient Enstaka sökobjekt Generell sökning Distribuering av resurser Svarstid Stabilitet arkitektur Lätthet att utveckla Prestanda Kännetecken Val av teknik Figur 1 Analysmodell 1 för val av komponentteknik. Källa: Michalas m.fl 2000, egen bearbetning. Undersökningen och jämförelsen av de två teknikerna gjordes på en verklig webbapplikation som innehåller information om barnprogram i Europa. Målet med modellen är att den ska leda fram till ett lämpligt val av komponentteknik.

6 MÄLARDALENS HÖGSKOLA Promemoria 5 (13) Valet av teknik baseras på tre huvudsakliga kriterier: Lätthet att utveckla Artikelförfattarna anser att det är lämpligt att utvecklare baserar sitt val av utvecklingsverktyg och tekniker på sådana de redan behärskar. De anser även att vissa tekniker kan vara lättare att lära sig, tex. så underlättas utvecklingsprocessen för ASP genom dess intrinsic objects som automatiskt hanterar vissa uppgifter och genom API 6 kan hålla vissa servicekomponenter i minnet (på serversidan) under klientsessioner. Kännetecken Java/CORBA har t.ex. arv, men det saknar HTTP/ ASP. En annan sak som påverkar kännetecknen för en teknik är arkitekturen, ASP är plattformsberoende vilket ses som en nackdel i vissa fall. CORBA är mer komplex och gör att komponenter skrivna i olika programmeringsspråk och som körs på olika plattformar kan kommunicera med varandra. Prestanda Det kriterium som tonvikten läggs på i denna modell. Utvärderingen och jämförelsen mellan teknikerna baseras i huvudsak på teknikernas påverkan på systemets prestanda. Prestandajämförelsen i analysmodellen baseras i sin tur på tre olika kriterier: Distribuering av resurser Java/CORBA möjliggör skalbar servertill-server infrastruktur, där serverobjekt kan köras på olika servrar för att få lastbalansering för inkommande klientförfrågningar. Stabilitet Robustheten hos tekniken anses vara bäst hos Java/CORBA. Svarstid Artikelns undersökning visar entydigt på bättre svarstider för Java/CORBA. Skillnaden kan delvis förklaras av att för HTTP/ASP kan klienten inte direkt nå/starta ett serverobjekt, utan det måste gå via HTTP och en webbserver, och av att hela sidor överförs. Java/CORBA å andra sidan överför bara metodsignaturer och parametrar. Svarstiden jämförs efter anrop från flera klienter som även via möjlighet att få distribuering av resurser påverkar prestandan. Svarstiden jämförs även efter anrop från en klient som baserar sin sökning på webbapplikationen på olika sökkriterier: Enstaka sökobjekt I detta fall sökte de tex efter tv-program producerade i ett visst land. Generell sökning I detta fall söktes information som passade in på många olika sökkriterier, och gav därmed fler träffar i databasen. 6 Application Programming Interface

7 MÄLARDALENS HÖGSKOLA Promemoria 6 (13) Kontentan av denna analysmodell ska bli att modellen leder fram till rekommendationer för val av olika tekniker beroende på vissa omständigheter. Jämförelsen av dessa komponenttekniker resulterar i två rekommendationer: Java/CORBA: Rekommenderas för stora krävande applikationer eftersom resultaten i undersökningen visar att systemets prestanda, med tanke på svarstid, stabilitet och förmåga att distribuera resurser, är väldigt bra. HTTP/ASP: Rekommenderas för små/medelstora applikationer eftersom de då erbjuder acceptabla svarstider och även i viss mån underlättar utvecklingsprocessen.

8 MÄLARDALENS HÖGSKOLA Promemoria 7 (13) 2.2 Modell 2 - Performance comparison of CORBA and RMI, Av M. B. Juric, I. Rozman and M. Hericko Den andra modellen (se figur 2) beskriver den teori som ligger till grund för artikeln Performance comparison of CORBA and RMI, i vilken prestandaskillnaderna mellan CORBA och Java RMI kartläggs genom att testa prestandan hos de båda teknikerna i ett fiktivt scenario. Modellen är en grafisk återgiving av hur man enligt artikelförfattarna bör gå till väga när man ska göra ett val av komponentteknik för ett projekt. Analysmodell för val av komponentteknik Fiktivt scenario Antal Klienter Klientens placering Datamängd Primitiva datatyper String Analys av multitrådstrategier Kodanalys Tidskrävande metoder Komplexitet Svarstid arkitekturen Lätthet att utveckla Stöd för legacy systems Prestanda Mognad Kännetecken Val av teknik Figur 2 Analysmodell 2 för val av komponentteknik. Källa: Juric m.fl 2000, egen bearbetning. Förenklat uttryckt bör valet baseras på hur det framtida systemet kan beskrivas i följande fem avseenden: Lätthet att utveckla Denna aspekt avser de utvecklingsverktyg och tekniker som ska användas under utvecklingen. Artikelförfattarna menar att det ofta kan vara vettigt att basera sitt val på vilka tekniker man som utvecklare redan behärskar, istället för att behöva lära sig nya programmeringsspråk och utvecklingsverktyg. Stöd för legacy systems Med legacy systems menas i detta fall gamla system som det nya systemet kommer att behöva kommunicera med, men som inte är utvecklade enligt de komponentbaserade principer som kommer att gälla för det nya systemet. Eftersom CORBA är både plattforms och språkoberoende är det mycket som talar för denna teknik om det nya systemet i framtiden ska kommunicera med äldre, redan driftsatta system. Detta gäller speciellt då de gamla systemen inte är skrivna i Java, eftersom Java RMI förutsätter att all kod är skriven i just Java.

9 MÄLARDALENS HÖGSKOLA Promemoria 8 (13) Mognad Artikelförfattarna menar att utvecklaren även bör se till de respektive teknikernas mognad. Med det menar de att CORBA, som funnits längre än Java RMI är mer genomtänkt och välutvecklat. Detta talar för att använda CORBA om komplexa funktioner behöver implementeras. Kännetecken Vidare bör utvecklaren ha i åtanke att de båda teknikerna har olika arkitektur. CORBA är en komplex teknik som möjliggör kommunikation mellan komponenter skrivna i olika programmeringsspråk som körs på olika plattformar. Tekniken innehåller komplexa funktioner för att översätta datatyper mellan dessa olika plattformar och programmeringsspråk, så kallad marshalling. Ingenting av detta finns i Java RMI som enbart är en teknik för att möjliggöra för ett Javaobjekt att kommunicera med ett annat Javaobjekt Prestanda Hos ett system innebär prestanda flera olika saker, och har därför delats in i underpunkterna tidskrävande metoder, komplexitet, och svarstid. Prestandajämförelsen i analysmodellen baseras i sin tur på tre olika kriterier: Svarstiden Enligt artikelförfattarna påverkas svarstiden av antalet klienter, klientens placering, datamängden och vilken typ av data (primitiva datatyper eller strängar) som ska överföras mellan olika komponenter. Komplexitet CORBA är till sin natur en komplex komponentteknik som ska klara av alla datatyper på ett effektivt sätt. Java RMI däremot är inte lika komplext uppbyggt och saknar många av de funktioner som gör CORBA språk och plattformsoberoende. Prestandan vid små datamängder blir lidande när CORBA används, eftersom de mekanismer som ska säkerställa kommunikationen vid kraftig belastning eller vid kommunikation mellan olika plattformar fortfarande kräver samma mängd overhead som om belastningen vore maximal. Även för kommunikation över nätverk och mellan system skrivna i olika språk har CORBA komplexa mekanismer för t.ex. marshalling, som ger en högre overhead än hos Java RMI vid små datamängder. Sammanfattningsvis talar detta för att CORBA är att föredra när mycket data ska överföras mellan olika komponenter, när systemet ska serva många klienter som kommunicerar över ett nätverk och när icke primitiva datatyper, som t.ex. strängar ska överföras. Tidskrävande metoder Författarna anser att man bör analysera den kod som utgör de mest tidskrävande metoderna, liksom analysera den multitrådsstrategi som avses användas i systemet, detta för att maximera prestandan.

10 MÄLARDALENS HÖGSKOLA Promemoria 9 (13) När det framtida systemet sedan har analyserats efter de föreslagna kriterierna ska resultatet av denna analys leda till ett val av komponentteknik. Författarna av artikeln hade två hypoteser som utgångspunkt för sitt arbete. Dessa var: 1. Java RMI används med fördel för småskaliga projekt där stöd för andra system kan ske via specialbyggda bryggor och där lätthet att använda är viktigare än prestanda. 2. CORBA är passande för stora system som kräver kompatibilitet med gamla system samtidigt som goda prestanda under hög belastning är ett krav. Resultatet av undersökningen visar att båda dessa hypoteser stämmer, och att man ska utgå ifrån dessa när man gör sitt val av komponentteknik.

11 MÄLARDALENS HÖGSKOLA Promemoria 10 (13) 3 Analys För att åskådliggöra skillnader och likheter mellan de båda modellerna har vi nedan valt att kombinera de två modellerna till en gemensam modell (se figur 3). För att visa vilka kriterier som är gemensamma respektive olika hos de två analysmodellerna har vi valt att färgkoda de olika kriterierna. Vit färg markerar kriterier som är gemensamt hos de båda modellerna. Ljusgrå färg symboliserar kriterier som endast återfinns i modell 1 medan mörkgrå färg motsvarar kriterier som endast finns i modell 2. Gemensam Analysmodell analysmodell för för val val av av komponentteknik Fiktivt Scenario scenario String Klientens placering Datamängd Primitiva datatyper En klient Enstaka sökobjekt Generell sökning Antal Klienter Analys av multitrådstrategier Tidskrävande metoder Kodanalys Komplexitet Svarstid Stabilitet Distribuering av resurser arkitekturen Lätthet att utveckla Stöd för legacy systems Prestanda Mognad Kännetecken Val av teknik Bildförklaring: Kriterier med denna bakgrundsfärg är gemensamma för båda modellerna Kriterier med denna bakgrundsfärg finns bara i modell 1 Kriterier med denna bakgrundsfärg finns bara i modell 2 Figur 3 Analysmodell 3, sammanslagning av analysmodell 1 och 2. Egen bearbetning. Modell 1 är mindre utförlig, den grundas på ett verkligt scenario med givna förutsättningar. Modell 2 siktar istället på att ta alla möjligheter i beaktande genom ett fiktivt scenario som har som mål att få ett så detaljerat beslutsunderlag som möjligt oavsett vilka förutsättningar som gäller för projektet.

12 MÄLARDALENS HÖGSKOLA Promemoria 11 (13) Det finns ett antal kriterier som är gemensamma hos de båda modellerna: kännetecken, prestanda, lätthet att använda, svarstid, arkitekturen, antal klienter. Prestandan är alltså gemensam i modellerna, men definitionen för prestandakriteriet skiljer sig åt. I modell 1 innefattar prestanda stabilitet och distribuering av resurser, medan man i modell 2 istället har valt att lägga tonvikten på kriterier som komplexitet och tidskrävande metoder. De tidskrävande metoderna har undersökts djupare genom analys av kod och analys av den multitrådsstrategi, vilket innebär att modell 2 gör en mer djupgående analys av uppbyggnaden av komponenterna och hur detta påverkar prestandan. Svarstiden är ett gemensamt kriterium för båda modellerna som ligger under prestanda och den har en central roll i båda modellerna. Definitionen av svarstider skiljer sig dock även den åt, men båda modellerna indikerar att datamängden och antalet anslutna klienter har betydelse för svarstiderna, dock benämns de som olika kriterier i de olika modellerna. I modell 2 går in mer på djupet genom att undersöka vilken typ av data som sänds mellan komponenterna och hur detta påverkar prestandan. Vidare undersöks hur svarstiden påverkas av var klienten är fysiskt placerad och vad det innebär i fråga om overhead för kommunikation över till exempel ett nätverk eller mellan olika plattformar. Modell 2 innehåller förutom ovan nämnda kriterier även stöd för legacy systems och mognad. Detta tyder ytterligare på att modellen är mer heltäckande eftersom det ofta finns till exempel gamla system som det nya systemet måste kunna kommunicera med. Mognaden avser komponenttekniken. En äldre teknik är mer mogen och innehåller därmed färre buggar och/eller mer funktioner som kan användas i utvecklingen av det nya informationssystemet Modell 2 undersöker mer grundligt och utförligt effekten av hur olika kriterier inverkar på valet av teknik. Modell 1 är dock ändå heltäckande i grunden i och med att den innehåller alla de kriterier som är centrala i ett utvecklings projekt, så som prestanda, svarstider, det faktum att man klarar av att genomföra utvecklingsarbetet, mängden data som skall överföras samt antalet klienter som kommer att vara anslutna till systemet samtidigt. Målet med att vara heltäckande uppnås utan att blanda in detaljer som t.ex. analys av kod och analys av vilka datatyper som kommer att sändas mellan systemets olika delar.

13 MÄLARDALENS HÖGSKOLA Promemoria 12 (13) 4 Slutsatser Vi anser att de båda analysmodellerna som presenterats i detta PM mycket väl kan tillämpas på ett verkligt utvecklingsprojekt, och kan då underlätta vid valet av komponentteknik. Båda dessa modeller innehåller de huvudsakliga kriterier som även vi ser som de viktigaste att ta i beaktande när valet av komponentteknik ska göras. Det är dock viktigt att komma ihåg att ingen av dem är heltäckande, eftersom båda modellerna innehåller delar som saknas i den andra modellen och vice versa. Det finns även aspekter som vi anser har glömts bort i båda dessa modeller, exempel på sådana är dokumentation, underhåll av informationssystemet och support av detsamma. Även om dessa aspekter inte är lika centrala som de delar modellerna tar upp är de ändå aspekter som vi anser bör tas i beaktande vid valet av komponentteknik. Modellerna kan sägas vara två varianter på samma synsätt, då båda modellerna betonar samma delar när de analyserar komponenttekniker, men de har också samma svagheter, då de har liknande luckor i hur de analyserar komponentteknikerna. I grund och botten kan man säga att de bygger på samma grundkoncept men att de samtidigt ser lite olika på hur man bör förhålla sig till detaljerna, eftersom den ena är mer djupgående än den andra. De som använder sig av en modell har ett stort ansvar då de väljer de kriterier som skall analyseras. Valet av kriterier har avgörande inverkan på valet av teknik. För att en korrekt och rättvis jämförelse mellan tekniker skall vara möjlig anser vi att det skulle behövas ett standardiserat ramverk. Detta skulle underlätta för informationssystemsutvecklare då viktiga aspekter och kriterier inte skulle riskeras glömmas bort. Om ett fördefinierat ramverk och scenarier fanns tror vi att det skulle det gå snabbare att komma fram till vilka tekniker som kan vara bäst lämpade att välja beroende på givna förutsättningar.

14 MÄLARDALENS HÖGSKOLA Promemoria 13 (13) Källförteckning Artiklar Michalas, A., & Zoi, V., & Sotiropoulos, N., Mitrou, N., & Loumos, V., & Kayafas, E A comparison of multimedia application development platforms towards the object web, Computer Standards & Interfaces, vol. 22 nr. 1, s Juric, M.B., & Rozman, I., & Hericko, M. 2000, Performance comparison of CORBA and RMI., Information and Software Technology, vol. 42 nr.13, s