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, 2002-12-12
EI0230
Komponentbaserad applikationsutveckling
PM01 version 3
Grupp 2
Blomqvist Maria
Eriksson Daniel
MÄLARDALENS HÖGSKOLA
Institutionen för Ekonomi och Informatik
v
Innehållsförteckning
1
Inledning .................................................................................................. 2
1.1
Bakgrund............................................................................................... 2
1.2
Problematisering .................................................................................. 3
1.3
Syfte ....................................................................................................... 3
2
Beskrivning av modeller ......................................................................... 4
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 ....................................... 4
2.2 Modell 2 -” Performance comparison of CORBA and RMI”, Av M.
B. Juric, I. Rozman and M. Hericko............................................................ 7
3
Analys ..................................................................................................... 10
4
Slutsatser ................................................................................................ 12
Källförteckning
MÄLARDALENS HÖGSKOLA
Promemoria
Institutionen för Ekonomi och Informatik
2002-12-12
1
2 (13)
ver.3
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 HTTP1 /CGI2 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
2
HyperText Transfer Protocol
Common Gateway Interface
MÄLARDALENS HÖGSKOLA
Promemoria
Institutionen för Ekonomi och Informatik
2002-12-12
3 (13)
ver.3
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 CORBA3. I artiklarna jämförs denna teknik med ASP4 och Java
RMI5 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
Active Server Pages
5
Remote Method Invocation
4
MÄLARDALENS HÖGSKOLA
Promemoria
Institutionen för Ekonomi och Informatik
2002-12-12
2
4 (13)
ver.3
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.
Analysmodell för val av komponentteknik
Verkligt scenario
Flera klienter
En klient
Enstaka sökobjekt
Distribuering av resurser
Lätthet att utveckla
Svarstid
Prestanda
Generell sökning
Stabilitet
arkitektur
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.
MÄLARDALENS HÖGSKOLA
Promemoria
Institutionen för Ekonomi och Informatik
2002-12-12
5 (13)
ver.3
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 API6 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.
•
6
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.
Application Programming Interface
MÄLARDALENS HÖGSKOLA
Promemoria
Institutionen för Ekonomi och Informatik
2002-12-12
6 (13)
ver.3
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.
MÄLARDALENS HÖGSKOLA
Promemoria
Institutionen för Ekonomi och Informatik
2002-12-12
2.2
7 (13)
ver.3
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
Analys av
multitrådstrategier
Klientens placering
Primitiva
datatyper
String
Kodanalys
Tidskrävande metoder
Lätthet att utveckla
Datamängd
Komplexitet
Stöd för
”legacy systems”
Svarstid
Prestanda
Mognad
arkitekturen
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.
MÄLARDALENS HÖGSKOLA
Promemoria
Institutionen för Ekonomi och Informatik
2002-12-12
8 (13)
ver.3
•
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.
MÄLARDALENS HÖGSKOLA
Promemoria
Institutionen för Ekonomi och Informatik
2002-12-12
9 (13)
ver.3
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.
MÄLARDALENS HÖGSKOLA
Promemoria
Institutionen för Ekonomi och Informatik
2002-12-12
3
10 (13)
ver.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.
GemensamAnalysmodell
analysmodellför
förval
valavavkomponentteknik
komponentteknik
Fiktivt
scenario
Scenario
En klient
Primitiva
String Klientens placering Datamängd datatyper
Enstaka sökobjekt
Generell sökning
Antal Klienter
Analys av
multitrådstrategier
Tidskrävande metoder
Kodanalys
Svarstid
Komplexitet
Distribuering av resurser
Stabilitet
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.
MÄLARDALENS HÖGSKOLA
Promemoria
Institutionen för Ekonomi och Informatik
2002-12-12
11 (13)
ver.3
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.
MÄLARDALENS HÖGSKOLA
Promemoria
Institutionen för Ekonomi och Informatik
2002-12-12
4
12 (13)
ver.3
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.
MÄLARDALENS HÖGSKOLA
Promemoria
Institutionen för Ekonomi och Informatik
2002-12-12
13 (13)
ver.3
Källförteckning
Artiklar
Michalas, A., & Zoi, V., & Sotiropoulos, N., Mitrou, N., & Loumos, V., & Kayafas,
E. 2000. A comparison of multimedia application development platforms towards
the object web, Computer Standards & Interfaces, vol. 22 nr. 1, s.13-26.
Juric, M.B., & Rozman, I., & Hericko, M. 2000, Performance comparison of
CORBA and RMI., Information and Software Technology, vol. 42 nr.13, s. 915-933.
