Ett distribuerat system för automatisk värdepappershandel arkitektur och modell

Ett distribuerat system för automatisk värdepappershandel arkitektur och modell Mattias Moltkesson TRITA-NA-E03152

NADA Numerisk analys och datalogi Department of Numerical Analysis KTH and Computer Science 100 44 Stockholm Royal Institute of Technology SE-100 44 Stockholm, Sweden Ett distribuerat system för automatisk värdepappershandel arkitektur och modell Mattias Moltkesson TRITA-NA-E03152 Examensarbete i datalogi om 20 poäng vid Programmet för datateknik, Kungliga Tekniska Högskolan år 2003 Handledare på Nada var Björn Eiderbäck Examinator var Stefan Arnborg

Sammanfattning Ett distribuerat system för automatisk värdepappershandel arkitektur och modell TradeLab är ett dotterbolag till E. Öhman J:or Fondkommission AB, som även äger NordNet, en av Sveriges största Internetmäklare. TradeLabs affärsidé är att utveckla ett system som kan användas av Internetmäklare för att automatiskt köpa och sälja värdepapper i vinstsyfte, s.k. trading. TradeLab har utvecklat en första version av ett sådant system. Systemet har dock flera brister som gör det svårt att vidareutveckla och olämpligt för installation hos externa användare. Man har därför beslutat utveckla ett nytt system som ger TradeLab större möjligheter att vidareutveckla verksamheten. I detta examensarbete presenteras en modell av de centrala delarna i det nya systemet. Det nya systemet ska vara objektorienterat och distribuerat och kommer därför att vara baserat på en arkitektur för distribuerade objektorienterade system. En del av examensarbetet är att avgöra vilken arkitektur som passar detta system bäst. Rapporten innehåller en utredning som jämför de tre arkitekturerna CORBA, Java RMI och Enterprise JavaBeans. Utredningens slutsats är att Java RMI är det bästa alternativet. Abstract A Distributed System for Automatic Trading Architecture and Model TradeLab is a subsidiary of E. Öhman J:or Fondkommission AB, a company that also owns NordNet, one of Sweden s largest Internet stockbrokers. TradeLab s mission is to create a system to be used by Internet stockbrokers for automatically buying and selling financial instruments for profit, known as trading. TradeLab has developed a first version of such a system. However, this system has several shortcomings that makes it difficult to improve and unsuitable for installation at other locations. It has been decided that this system shall be replaced by a new system that better suits TradeLab s needs. This thesis presents a model of the central components in the new system. The new system should be object oriented and distributed and will consequently be based on an architecture for object oriented distributed systems. Part of my master s project is to find the most suitable architecture for the new system. In this thesis I compare the three architectures CORBA, Java RMI, and Enterprise JavaBeans, concluding that Java RMI is the best alternative. 3

4

Förord Denna rapport redovisar mitt examensarbete i datalogi vid institutionen för numerisk analys och datalogi. Examensarbetet avslutar min civilingenjörsutbildning vid Kungliga Tekniska högskolan i Stockholm. Handledare på Nada var Björn Eiderbäck. Arbetet utfördes hos TradeLab AB. Handledare på TradeLab var Jon Malmsäter. Jag vill passa på att tacka mina handledare och alla andra som har hjälpt mig genomföra mitt examensarbete. Jag vill också tacka TradeLab för att ha givit mig förtroendet att designa ett nytt system åt dem, och jag hoppas att mitt system kommer att passa TradeLabs fortsatta verksamhet väl. Mattias Moltkesson Stockholm, januari 2001 5

6

Innehållsförteckning KAPITEL 1 Inledning...9 KAPITEL 2 Bakgrund...11 2.1 TradeLabs affärsidé... 11 2.2 Aktietrading... 12 2.3 Optionstrading... 13 2.4 Det befintliga systemet... 14 KAPITEL 3 Problembeskrivning...17 KAPITEL 4 Distribuerade objektorienterade system...19 4.1 CORBA... 22 4.2 Remote Method Invocation... 26 4.3 Enterprise JavaBeans... 28 4.4 Sammanfattning... 33 4.5 Rekommendation... 34 KAPITEL 5 Det nya systemet...37 5.1 Systemets komponenter... 39 5.2 Systemkonfigurationer... 45 5.3 Tekniska risker... 47 KAPITEL 6 Sammanfattning och utvärdering...49 6.1 Utredningens resultat... 49 6.2 Uppfylls kraven?... 49 Källförteckning...51 7

8

KAPITEL 1 Inledning TradeLab är ett dotterbolag till E. Öhman J:or Fondkommission AB, som även äger NordNet, en av Sveriges största Internetmäklare. TradeLabs affärsidé är att utveckla ett system som automatiskt kan köpa och sälja värdepapper i vinstsyfte. Systemet är tänkt att användas av Internetmäklare och har därför tillgång till de order kunderna lägger via Internet. Det ger ökade möjligheter att tjäna pengar på kortsiktiga affärer. TradeLab har utvecklat en första version av ett sådant system. Genom ett samarbete med NordNet har man tillgång till order från NordNets kunder, och systemet används idag av TradeLab själva för handel i aktier och optioner. Systemet har dock flera brister som gör det svårt att vidareutveckla och olämpligt för installation hos externa användare. Man har därför beslutat utveckla ett nytt system som ger TradeLab större möjligheter att vidareutveckla verksamheten. Mitt uppdrag är att skapa en modell av de centrala delarna i detta system. Det befintliga systemet är baserat på CORBA, en arkitektur för distribuerade objektorienterade system. CORBA gör det möjligt för systemets komponenter att på ett enkelt sätt kommunicera med varandra trots att de befinner sig på olika datorer. Även det nya systemet ska använda en distribuerad arkitektur, men det är inte självklart att CORBA är det bästa alternativet. En viktig del av min uppgift är därför att utreda några olika arkitekturer och rekommendera en av dem för det nya systemet. Rapportens disposition Kapitel 2 ger en bakgrund till uppdraget. Här förklaras kort några strategier systemet kan använda för att uppnå vinst. Det befintliga systemet beskrivs också här. Kapitel 3 specificerar mitt uppdrag och de egenskaper det nya systemet ska ha. Kapitel 4 innehåller en utredning av ett antal distribuerade arkitekturer samt en rekommendation av ett av dem. Kapitel 5 presenterar min modell av det nya systemet. 9

10

KAPITEL 2 Bakgrund Handeln med aktier på Stockholmsbörsen har under de senaste tio åren genomgått en explosionsartad utveckling. Under perioden har antalet avslut ökat med i snitt 38 % årligen (se figur 2-1). Samtidigt har intresset för sparande i aktier ökat kraftigt bland privatpersoner. En anledning till detta är de nya möjligheter som Internet givit. Mäklartjänster som låter sina kunder lägga order via Internet har gjort handeln med aktier både enklare och billigare för privatpersoner. Internetmäklarna har idag över 400 000 depåkunder [1] och de står för cirka 14 % av avsluten på Stockholmsbörsen [2]. Intresset för optioner har också ökat. Vid utgången av 1999 fanns omkring 62 000 privatpersoner registrerade som derivatkunder hos OM Stockholmsbörsen, en ökning med 20 % från året innan [3]. 2.1 TradeLabs affärsidé Att köpa och sälja värdepapper i stor omfattning brukar kallas trading. För att verksamheten ska bli lönsam strävar man naturligtvis efter att sälja värdepapperen till ett högre pris än man köpte dem för. TradeLabs affärsidé är att utveckla ett system för högt automatiserad trading av aktier och optioner. Systemet ska i första hand användas av Internetmäklare, och kommer därför att ha tillgång till depåkundernas order innan de skickas till börsen. Man har då möjlighet att agera 14 12 10 8 6 4 2 0 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 Figur 2-1 Antal avslut (miljoner) på Stockholmsbörsen [3]. 11

motpart till ordern (köpa de värdepapper kunden vill sälja eller vice versa). Affärerna görs normalt på mycket kort sikt, i storleksordningen minuter. Genom att systemet är automatiserat kan det genomföra ett stort antal affärer och sammanlagt skapa en betydande vinst trots att vinsten per affär är relativt liten. Systemet ska dels användas av TradeLab för att genom tradingen generera en vinst åt bolaget, dels säljas för att installeras hos andra Internetmäklare. För att illustrera hur systemet är tänkt att fungera ges i de följande två avsnitten några exempel på strategier som TradeLabs system kan använda för sin trading. Sannolikt kommer även andra strategier att användas, men dessa exempel räcker för att ge en uppfattning om vilka krav som ställs på systemet. 2.2 Aktietrading Syftet med handeln med aktier är som sagt att sälja aktierna till en högre kurs än man köpte dem för. Så långt fungerar TradeLabs system som en automatisk daytrader. Men eftersom systemet är installerat hos en Internetmäklare kan det få tillgång till de order kunderna lägger innan ordern skickas till börsen, och kan då agera motpart till ordern. För att förstå hur TradeLab kan utnyttja detta till sin fördel måste man veta hur aktiehandeln på börsen i stora drag fungerar. För varje instrument som handlas på börsen finns en orderbok. I orderboken registreras köp- och säljorder, rangordnade efter pris. Finns flera order med samma pris har de först registrerade företräde (se figur 2-2). Om det finns köp och säljorder med samma pris sker en matchning, och värdepapper och pengar byter ägare. Kunden får naturligtvis aldrig förlora på att avslutet sker mot TradeLab; det pris TradeLab ger får inte vara sämre än vad kunden kunnat få på börsen. Priset behöver å andra sidan inte heller vara bättre än marknadens. Studera exemplet i figur 2-2. Om en kund i detta läge lägger en säljorder med priset 543 kr, kan TradeLab agera motpart och köpa aktierna för 543 kr. Köper man aktierna på börsen måste man betala 544 kr för att vara säker på att affären omedelbart går igenom. I det här fallet kan man alltså säga att TradeLab har sparat en krona per aktie genom att slippa stå i den kö av köporder som finns i börsens orderbok. Kunden har däremot inte förlorat någonting, han skulle ju ha fått samma pris på börsen. Har man tur vill en annan kund strax därefter köpa aktier för 544 kr, men man kan också hoppas på att marknadspriset stiger och sälja aktierna på börsen. Helst ska systemet bara agera på kundernas order när sannolikheten för en gynnsam kursrörelse är stor. I figur 2-2 kan man t.ex. se att det bara finns 100 aktier till salu för 544 kr, men köporder på 700 aktier för 543 kr. Detta kan tyda på att kursen är på väg att stiga, och att det därför är lämpligt att köpa aktien nu. Köporder 300 st á 543 kr (kl 10.03) 400 st á 543 kr (kl 10.05) 200 st á 542 kr (kl 10.01) 500 st á 540 kr (kl 9.55) Säljorder 100 st á 544 kr (kl 10.04) 300 st á 545 kr (kl 10.02) 100 st á 545 kr (kl 10.03) 400 st á 546 kr (kl 10.06) Figur 2-2 Exempel på orderbok för en aktie. Klockslaget anger när ordern registrerades. 12

Systemet måste i hög grad vara automatiskt, eftersom kunderna inte skulle acceptera en lång fördröjning innan deras order når börsen. Därför är det inte möjligt att låta en människa fatta beslut i varje enskilt fall. Tanken är istället att systemet utifrån prisinformation från marknaden och generella parametrar från operatören, t.ex. om den förväntade prisutvecklingen, själv ska kunna fatta ett snabbt beslut när en kund har lagt en order. Blankning När man sparar i aktier brukar man först köpa aktier, för att vid en senare tidpunkt sälja dem. Detta förutsätter naturligtvis en stigande aktiekurs för att någon vinst ska uppstå. För en trader är det också möjligt att göra tvärtom, d.v.s. först sälja en aktie man inte äger för att sedan köpa tillbaka den. De aktier man säljer lånas av en annan aktieägare, som erhåller en viss ränta för besväret. Detta förfarande kallas blankning. Möjligheten till blankning är viktig för ett företag som livnär sig på trading, eftersom det blir möjligt att tjäna pengar även på aktier som sjunker i värde. Man är därför inte beroende av stigande börskurser för att kunna göra vinst. 2.3 Optionstrading Optioner är standardiserade kontrakt som ger innehavaren rätt att köpa eller sälja en underliggande vara till ett visst pris (lösenpriset). Utfärdaren av optionskontrakt påtar sig motsvarande skyldighet, och erhåller en premie för den risk det innebär. Eftersom innehavaren själv avgör om han vill utnyttja sin rättighet kommer det i praktiken bara att ske när det är gynnsammare än att köpa varan direkt på marknaden, d.v.s. när lösenpriset för en köpoption ligger under marknadspriset, eller när lösenpriset för en säljoption ligger över marknadspriset. Genom att kontrakten är standardiserade kan man bedriva handel i börsform, och det görs i Sverige av OM Stockholmsbörsen. Där handlas optioner där de underliggande varorna är aktier eller OMX-index, som i detta sammanhang betraktas som en fiktiv aktie. Kontrakten gäller under en viss löptid, och rättigheten att köpa eller sälja kan beroende på optionens typ utnyttjas under hela löptiden eller endast på sista dagen i löptiden, slutdagen. Optionskontrakt av den förra typen kallas amerikanska medan den senare typen kallas europeiska. Detta är dock bara benämningar, båda typerna handlas på båda sidor av Atlanten. I Sverige är aktieoptioner av amerikansk typ och indexoptioner av europeisk typ. Värdering Sex faktorer påverkar priset på en aktieoption [4]: Den nuvarande aktiekursen. Optionens lösenpris. Tid kvar till slutdagen. Aktiens volatilitet under löptiden. Ränteläget. Utdelningar under löptiden. Volatiliteten är ett mått på hur stora kursrörelserna är i en aktie. Eftersom det är den framtida volatiliteten som avgör optionens värde måste man göra en uppskattning, t.ex. genom att beräkna historisk volatilitet. Europeiska optioner kan värderas analytiskt med Black-Scholes formel. För amerikanska optioner måste däremot numeriska metoder 13

användas. Numeriska värderingsmetoder är mer beräkningsintensiva och ställer därför högre krav på ett systems prestanda. Handel Handeln med optioner skiljer sig något från aktiehandeln. Den mindre omsättningen och det relativt stora antalet optioner gör att skillnaden mellan köp- och säljkurs ofta är stor. Ibland saknas t.o.m. köpare eller säljare av en option. Här kan TradeLabs system hjälpa kunden genom att i vissa fall erbjuda ett bättre pris (närmare det teoretiska värdet) än marknaden. För att bestämma ett rimligt pris gör systemet en värdering av optionen, baserat på de faktorer som räknades upp ovan. Efter en sådan affär blir man ägare till eller utfärdare av ett antal optioner, som för tillfället inte kan handlas på marknaden till ett bra pris (det var ju anledningen till att affären gjordes). För att undvika att värdet på positionen förändras allt för mycket innan den kan avvecklas kan man använda en strategi som kallas hedging. Hedging innebär att man minskar positionens risk genom att göra kompletterande affärer. I detta fall kan man köpa eller sälja ett visst antal av den underliggande aktien för att få en portfölj av optioner och aktier vars totala värde är nästan konstant även om aktiekursen ändras. I figur 2-3 visas hur värdeförändringen i ett innehav av säljoptioner (som sjunker i värde när aktiekursen stiger) kan kompenseras genom att köpa en post i den underliggande aktien. Vid små kursförändringar ändras det sammanlagda värdet mycket lite, men eftersom värdet av optionerna inte är en linjär funktion av aktiekursen måste antalet aktier justeras vid större kursrörelser. Med denna metod elimineras bara de värdeförändringar som uppstår p.g.a. att den underliggande aktiens kurs förändras, man riskerar fortfarande att optionernas värde förändras av de övriga faktorer som styr optionspriset. I de flesta fall dominerar dock kursrisken varför denna metod oftast är tillräcklig. När systemet beräknar vilket pris det är villigt att handla vid måste det ta hänsyn till de kostnader, t.ex. avgifter för aktieaffärer, som hedgingen medför. Syftet är ju att det till slut ska bli en liten vinst över. 2.4 Det befintliga systemet Idag har TradeLab ett system som kan göra en del av det som beskriv- Optioner Värdeförändring Totalt Aktier Kursförändring Figur 2-3 Eliminering av kursrisk i ett optionsinnehav. 14

its ovan. Systemet har varit i drift i ungefär ett år. Det konstruerades från början för optionstrading, men har sedan byggts ut för att också klara aktietrading. Systemet tar emot optionskurser och kurser för underliggande aktier från Stockholmsbörsens optionshandelssystem, samt kundorder från NordNets Internettjänst. Baserat på kursinformationen och ett antal parametrar från operatören ställs kontinuerligt priser på optionerna. Om detta pris ligger inom kundens limit kommer systemet att agera motpart till ordern. Aktietradingen fungerar på ett liknande sätt. Teknik Systemet består av ett tiotal komponenter som körs i olika processer. För kommunikationen mellan komponenterna används CORBA. CORBA används också för att kommunicera med användargränssnittet och i gränssnittet till NordNet. För att skicka meddelanden asynkront mellan komponenterna används CORBAs Event Service. Gränssnittet till optionsmarknadens API OMnet (som är anpassat för C) är programmerat i C++, och körs på en UNIX-maskin. Denna komponent tar emot orderböcker och avslut från marknaden och översätter informationen till CORBA-strukturer som skickas vidare med Event Service. Övriga delar av systemet körs på NT-maskiner och är skrivna i Java. Enda undantaget är de numeriska optionsvärderingsrutinerna, som av prestandaskäl också implementerats med C++. Dessa rutiner anropas med Java Native Interface (JNI). Systemet kan närmast beskrivas som en prototyp, mest avsedd att visa hur automatisk trading kan fungera. Både design och dokumentation är bristfälliga, vilket gör systemet mycket svårt att förstå och att vidareutveckla. Det är också krångligt att installera och administrera, vilket gör det närmast omöjligt att sälja till externa användare. 15

16

KAPITEL 3 Problembeskrivning TradeLab står inför utmaningen att skapa en system som kan säljas som en produkt, och som därför måste kunna installeras och användas av andra än TradeLab själva. Man vill också införa nya och förbättrade funktioner i systemet. På grund av de brister som finns hos det befintliga systemet har man valt att utveckla ett nytt system som från grunden anpassats till de nya kraven. För att uppnå en högre grad av flexibilitet och skalbarhet ska det nya systemet, liksom det gamla, vara uppbyggt kring en distribuerad arkitektur. Det är dock inte självklart att den nuvarande arkitekturen, CORBA, passar bäst. Därför är det intressant att utreda ett antal distribuerade arkitekturer som kan komma ifråga. En given förutsättning är att det nya systemet så långt det är möjligt ska implementeras i Java, eftersom TradeLab anser att Java är det mest lämpliga språket med hänsyn till utvecklarnas produktivitet och slutresultatets kvalité. Dessutom ger det ett plattformsoberoende system som kan installeras på valfri server oavsett operativsystem. Kravspecifikation Det nya systemet ska ha följande egenskaper: Flexibilitet: Systemet måste kunna användas i olika konfigurationer, och nya funktioner ska lätt kunna införas. Händelsestyrt: Systemet måste kunna reagera på externa händelser, exempelvis kursförändringar och inkommande order från mäklarsystem. Det ska därför vara händelsestyrt: varje händelse startar en kedjereaktion i systemet som leder till att nödvändiga åtgärder vidtas. Korrekthet: Eftersom systemet helt självständigt gör aktie- och optionsaffärer är det mycket viktigt att de beslut som fattas är korrekta. Felaktigheter i systemet kan lätt orsaka stora förluster. Tillgänglighet: Om systemet är nere tjänar man naturligtvis inga pengar. Det är dock den enda konsekvensen, Internetmäklarnas kunder märker inte om detta system är i drift eller ej. Tillgängligheten behöver därför inte vara extremt hög, och det är acceptabelt att stänga av systemet tillfälligt om det skulle behövas. Prestanda: Att förutsäga vilka prestanda som krävs i systemet är mycket svårt eftersom belastningen kommer att variera beroende på var det är installerat och hur det används, men också från dag till dag beroende på hur aktiv marknaden är. Det är dock viktigt att hela tiden hålla fördröjningen i systemet nere, eftersom det krävs aktuella data för att kunna fatta korrekta beslut. Ett baskrav är därför att systemet själv kan upptäcka när det blir överbelastat och 17

då åtgärdar detta, om inte annat så genom att stänga av sig själv för att undvika att göra dåliga affärer. Mina uppgifter Min första uppgift var att utreda ett antal distribuerade arkitekturer och försöka avgöra vilken som passar det nya systemet bäst. Systemet har i huvudsak tre olika kommunikationsbehov: Mellan de olika komponenterna i systemet. Mellan systemets komponenter och användargränssnitten. Mellan systemet och externa system, t.ex. börser och mäklares datasystem. I det sistnämnda fallet är det ofta inte möjligt att välja hur kommunikationen ska gå till. Till exempel brukar börserna erbjuda ett eller flera gränssnitt som man måste anpassa sig till. Min utredning gäller därför främst vilken arkitektur som ska användas i de två första fallen. Utredningen redovisas i kapitel 4. Min andra uppgift var att skapa en modell av de centrala komponenterna i det nya systemet. För modellen ska Unified Modeling Language (UML) användas. Modellen presenteras i kapitel 5. 18

KAPITEL 4 Distribuerade objektorienterade system Objektorienterade system är uppbyggda kring objekt, en programkonstruktion som innehåller både data och programkod. Detta sätt att konstruera datasystem har blivit mycket populärt under det senaste decenniet, och det används nästan alltid i nya system. Ett distribuerat datasystem kan definieras som ett system av flera självständiga processorer som inte delar primärminne, men som samarbetar genom att skicka meddelande över ett nätverk [5]. Distribuerade objektorienterade system kombinerar dessa två tekniker, och låter objekt spridda över flera datorer kommunicera med varandra för att tillsammans lösa en uppgift. Anledningarna till att flera datorer används istället för en enda varierar. Ofta är det för att en ensam dator inte har tillräcklig kapacitet. I vissa fall beror det på att system som använder olika hårdvaruplattformar ska integreras. Man kan också uppnå högre driftsäkerhet genom att ha flera datorer som utför samma uppgifter, då systemet som helhet kan fortsätta fungera även om någon dator skulle haverera. Men distribuerade system medför också många problem [6]: Anrop till objekt över ett nätverk tar mycket längre tid än anrop till lokala objekt. Därför är det önskvärt att begränsa antalet anrop till objekt på andra datorer. Minneshanteringen blir svårare när flera datorer är inblandade. Klienter kan ha referenser till objekt på andra datorer. Om klienten avslutas normalt kan den tala om att den inte behöver det aktuella objektet längre, men skulle klientdatorn krascha fungerar inte denna metod. Att avgöra vilka objekt som kan tas bort är därför mer komplicerat i distribuerade system [7]. Om någon dator slutar fungera, eller det uppstår fel i kommunikationen mellan datorerna, hamnar systemet i ett svårdefinierat tillstånd där vissa delar av det blir otillgängliga. Därför krävs en mer omfattande felhantering i distribuerade system. Gränssnitt och implementationer En viktig del i den objektorienterade paradigmen är separationen av gränssnitt och implementationer. Ett gränssnitt är en överenskommelse mellan klient och objekt om hur objektet fungerar och ska användas. Syntaktiskt består gränssnittet av ett antal metoder med specificerade parametertyper och resultattyper. Denna del av gränssnittet skrivs i något programmeringsspråk och blir därför exakt definierad på ett sätt som även datorer kan förstå. En programmerare kan därför inte bryta denna del av överenskommelsen utan protester från systemet. Gräns- 19

public interface SimpleMath { Semantik // Returns the sum of two integers public int add(int term_a, int term_b); } Syntax Figur 4-1 Syntax och semantik i ett gränssnitt. snitt består också av en semantisk del, som beskriver vad metoderna gör och vilka regler som gäller för att använda objektet. Denna del av gränssnittet beskrivs med naturliga språk, t.ex. svenska eller engelska (se figur 4-1). För att kunna använda ett objekt måste man ha tillgång till en korrekt och fullständig beskrivning av det semantiska gränssnittet. Naturliga språk innehåller dock tvetydigheter, och därför finns det alltid en risk för misstolkningar. En implementation av ett gränssnitt består av programkod som motsvarar gränssnittets syntaktiska del (annars går den inte att kompilera) och förhoppningsvis också den semantiska delen. För ett givet gränssnitt kan det finnas flera implementationer. De olika implementationerna kan var och en välja en egen metod för att uppfylla den överenskommelse som gränssnittet innebär (se figur 4-2). Klienter använder gränssnitt och programmeras inte för att utnyttja en viss implementation. Det innebär att vilken implementation som helst kan användas, utan att klienten behöver ändras. Därför kan man när som helst ersätta en implementation med en annan som löser de uppgifter som gränssnittet ålägger den på ett annat sätt. Denna flexibilitet är en viktig anledning till att objektorienterad programmering blivit så populär. class Implementation1 implements SimpleMath { // Returns the sum of two integers public int add(int term_a, int term_b) { int sum = 0; while (term_a!= 0 term_b!= 0) { if (term_a > 0) { sum++; term_a--; } if (term_a < 0) { sum--; term_a++; } if (term_b > 0) { sum++; term_b--; } if (term_b < 0) { sum--; term_b++; } } return sum; } } class Implementation2 implements SimpleMath { // Returns the sum of two integers public int add(int term_a, int term_b) { return term_a + term_b; } } class Implementation3 implements SimpleMath { // Returns the sum of two integers public int add(int term_a, int term_b) { return 2 + 2; } } Den här implementationen är korrekt men ineffektiv. En effektivare implementation. Här har programmeraren gjort en möjlig, men sannolikt felaktig, tolkning av gränssnittets semantik. Figur 4-2 Tre olika implementationer av samma gränssnitt. 20

Det distribuerade dilemmat Normalt kan objekt bara anropa varandra om de ligger i samma adressrymd. En adressrymd är det minne som är tillgängligt för ett exekverande program. Program som körs på olika datorer kan inte dela en adressrymd eftersom datorerna inte har tillgång till varandras minneskretsar. I moderna operativsystem har av säkerhetsskäl ofta varje process en egen adressrymd. Därför kan objekt som ligger i samma dators minne ändå tillhöra olika adressrymder. I detta kapitel används ofta uttrycket objekt i annan dator, men det kunde alltså lika gärna stå objekt i annan adressrymd. Att anropa ett objekt som ligger inom samma adressrymd är enkelt. Parametrar och returvärde läggs på en överenskommen plats i minnet och själva anropet är en enkel hoppinstruktion. När ett objekt i en annan adressrymd ska anropas kan denna metod inte användas. Den viktigaste uppgiften för en arkitektur för distribuerade system är att göra det möjligt för objekt att anropa varandra även om de inte finns inom samma adressrymd, helst på ett sätt som ur programmerarens synvinkel liknar lokala anrop så mycket som möjligt. Objektkataloger Innan en klient kan anropa ett objekt i en annan dator måste den hitta objektet. Därför finns i alla distribuerade arkitekturer något sätt att registrera objekt i en gemensam katalog. I katalogen är varje objekt förknippat med ett namn. Om klienten känner till objektets namn kan den med katalogens hjälp få en referens till objektet. En objektreferens i ett distribuerat system är en lokal representant för ett objekt i en annan adressrymd. Oftast är det ett lokalt objekt med samma gränssnitt som det objekt det representerar, men med en implementation som vidarebefordrar anrop till moderobjektet. Tack vare separationen mellan gränssnitt och implementation kan alltså objekt i en annan adressrymd ersätta ett lokalt objekt, i princip utan att klientkoden måste ändras alls. I distribuerade arkitekturer är denna separation därför särskilt viktig. Protokoll För att vidarebefordra anrop över nätverket används något protokoll som specificerar hur parametrar, returvärde etc. ska överföras. Protokollet sätter gränserna för vad som är möjligt att göra i en arkitektur och är därför en central del i varje arkitektur. Det är en fördel om protokollet är standardiserat, eftersom system från olika tillverkare då kan fungera tillsammas. Objektöverföring I stället för att skicka en objektreferens till en annan dator kan vissa arkitekturer kopiera objekt från en dator till en annan. Det innebär att ett objekts tillstånd (dess instansvariabler) överförs och ett nytt objekt med samma tillstånd skapas på den mottagande datorn. En förutsättning för att detta ska fungera är att binärkoden för objektets implementation är tillgänglig och körbar på den dator som tar emot objektet. Det nya objektet är oberoende av sitt moderobjekt; ändringar i endera objektets tillstånd kommer inte att avspeglas i det andra. Fördelen med metoden är att det överförda objektet är ett lokalt objekt. Anrop till lokala objekt går mycket snabbare än anrop som måste skickas till en annan dator. Man behöver heller inte ta hänsyn till de fel som kan uppstå vid anrop till distribuerade objekt. Alla objekt kan dock inte utan vidare överföras till en annan dator. Objekt som på något sätt 21

representerar eller har referenser till lokala resurser, t.ex. en fil, en databasanslutning eller liknande, kan inte återskapas på den mottagande datorn. Avancerade middleware-funktioner I de flesta större distribuerade system räcker det inte att bara kunna anropa objekt på andra datorer, det behövs också mer avancerade funktioner, t.ex.: Transaktionshantering. Ändringar av objekts tillstånd ska kunna ingå i transaktioner. Transaktionen ska helst kunna omfatta flera objekt, på flera datorer. Persistens. Vissa objekt ska finnas kvar även om systemet stängs av och åter finnas tillgängliga när systemet startas igen. Säkerhet. Endast auktoriserade klienter ska ha rätt att utföra vissa åtgärder. Många arkitekturer försöker därför tillhandahålla sådana här tjänster på ett mer eller mindre integrerat sätt. Utredning I min uppgift ingick att undersöka ett antal arkitekturer för att konstruera distribuerade objektorienterade system. Jag valde att titta närmare på tre arkitekturer: CORBA Java RMI Enterprise JavaBeans I detta kapitel ges en kort beskrivning av var och en av dem. En av dem kommer jag att rekommendera för implementationen av TradeLabs nya system. Någon kanske saknar Microsofts DCOM i listan. Tradelab valde tidigt bort DCOM för sitt system, främst för att implementationer saknas till andra operativsystem än Microsofts egna. 4.1 CORBA CORBA (Common Object Request Broker Architecture) [8] är en standard för distribuerade objektorienterade system. Standarden definierar en objektbuss som, oberoende av plattform och språk, låter objekt anropa andra objekt [5]. Dessa objekt kan vara lokala men också finnas på en annan dator än det anropande objektet. Standarden fastställs av Object Management Group (OMG), en organisation med både mjukvaruföretag och slutanvändare som medlemmar. Antalet medlemmar är idag över 700 och inkluderar alla ledande företag i branschen utom Microsoft, som istället marknadsför sin egen standard DCOM. CORBA är därför en öppen standard, och CORBA-system levereras av många olika tillverkare. Idag finns CORBA-implementationer för de flesta operativsystem och programmeringsspråk. Historik Object Management Group (OMG) bildades 1989 av åtta stora företag med uppgiften provide a common architectural framework for objectoriented applications based on widely available interface specifications [9]. För att nå detta mål har OMG skapat Object Management Architecture (OMA). CORBA är den centrala delen i OMA. Den första versionen, CORBA 1.0, fastställdes i december 1990. I början av 1991 kom nästa version, CORBA 1.1, som bl.a. introducerade Interface Definition Language och ett API för att kommunicera med en Object 22

Request Broker (ORB), den komponent i CORBA som sköter kommunikationen mellan objekt i distribuerade system. Den största begränsningen i de tidiga versionerna av CORBA var att de inte innehöll något standardprotokoll för kommunikationen från en ORB till en annan. Därför kunde inte ORB-implementationer från olika företag kommunicera med varandra, vilket allvarligt begränsade användbarheten av CORBA-standarden. CORBA 2.0, som introducerades i december 1994, rättade till detta genom att införa protokollet Internet Inter-ORB Protocol (IIOP). För att kunna kalla sig CORBA 2.0- kompatibel måste alla ORB-implementationer använda sig av detta protokoll, och därmed kan ORB:ar från olika tillverkare samarbeta. Som namnet antyder använder detta protokoll TCP/IP, det nätverksprotokoll som används på Internet. Därför kan CORBA-anrop också göras över Internet. Gränssnitt CORBA är en objektorienterad arkitektur. Det innebär att objekt i CORBA har många likheter med objekt i objektorienterade språk, t.ex. polymorfism och gränssnittsarv. Dessa egenskaper kan användas även när CORBA används tillsammans med icke objektorienterade språk, men CORBA passar bäst tillsammans med objektorienterade språk som C++ och Java. En central del i CORBA-standarden är dess Interface Definition Language (IDL). CORBA IDL är ett C++-liknande språk för att definiera objekts gränssnitt, d.v.s. vilka metoder som finns och deras parametrar och resultattyper (se figur 4-3). IDL kan bara användas för att definiera gränssnitt, objekten måste implementeras i ett annat språk, t.ex. C++ eller Java, eller vilket språk som helst som någon har utvecklat CORBA-stöd för. Genom att ha ett eget språk för att definiera gränssnitt blir CORBA inte beroende av ett visst implementationsspråk. Nackdelen är förstås att alla programmerare som använder CORBA måste lära sig CORBA IDL. OMG definierar exakt hur IDL ska översättas till olika implementationsspråk. Själva översättningen görs automatiskt av utvecklingsverktygen. Eftersom översättningen är standardiserad går det att byta utvecklingsverktyg utan att behöva skriva om sin kod. Objekt i CORBA En objektreferens i CORBA kallas Interoperable Object Reference (IOR). En klient som vill anropa ett CORBA-objekt måste ha objektets IOR. Den kan t.ex. hämtas från CORBAs egen Naming Service, som beskrivs nedan. CORBA kan bara skicka referenser till objekt, aldrig objektet självt. Det innebär att alla anrop som görs med hjälp av en IOR måste skickas tillbaka till det ursprungliga objektet. Detta beror främst på CORBAs oberoende av språk, operativsystem och maskinvara. Om ett objekt ska skickas till en annan programmiljö måste det finnas en implementation interface SimpleMath { }; // Returns the sum of two integers long add(in long term_a, in long term_b); Figur 4-3 Exempel på gränssnitt definierat med CORBA IDL. 23

av objektet (d.v.s. körbar programkod) i den mottagande miljön, något som CORBA inte generellt kan garantera. Eftersom alla anrop till ett objekt på en annan dator måste skickas över nätverket bör man vara försiktig när systemet designas så att inte alltför många anrop görs till icke-lokala objekt, då detta kan ge dåliga prestanda. Vill man överföra strukturerade data till en annan dator har man möjlighet att istället för objekt använda C-konstruktionen struct. Eftersom en struct till skillnad från objekt inte har någon tillhörande programkod är de oberoende av språk och hårdvara och kan lätt kopieras till en annan dator. Man går dock miste om de fördelar som objektorienterad programmering ger. Object Request Broker I CORBA ansvarar en Object Request Broker (ORB) för kommunikationen med andra datorer (se figur 4-4). Ett anrop till ett objekt på annan dator går via en lokal ORB, som kontaktar den ORB som sköter det anropade objektet. Information om vilken ORB som ska kontaktas finns i objektens IOR. Normalt göms objektets IOR i en stub. En stub är ett objekt som har samma gränssnitt som det objekt som ska anropas, men där implementationen innehåller kod för att anropa det riktiga serverobjektet med hjälp av en ORB (se figur 4-5). På så vis kan ett anrop till ett CORBA-objekt göras på samma sätt som till ett lokalt objekt. Stub-filer skapas av utvecklingsverktyget utifrån informationen i serverobjektets IDL-fil. CORBA Services CORBA erbjuder en begränsad basfunktionalitet, som relativt lätt kan implementeras även på mindre kraftfull hårdvara. I större system krävs dock ofta fler funktioner. OMG har försökt standardisera ett antal sådana funktioner, så att de kan erbjudas som tilläggstjänster i ett Figur 4-4 Schematisk skiss över ett distribuerat CORBA-system. 24

CORBA-system. De kallas tillsammans CORBA Services. Idag har 15 tjänster standardiserats [5]. För varje tjänst gäller att den löser en specifik uppgift, och gör det väl, samt att tjänsten är generellt användbar i datasystem. Precis som med övriga delar av CORBA har OMG bara specificerat hur tjänsterna ska fungera, men inte implementerat dem. Det är valfritt för leverantörer av CORBA-system att tillhandahålla implementationer av dessa tjänster, och även om det knappast finns någon som implementerat alla tjänster brukar de viktigaste finnas med i varje CORBA-system. Eftersom tjänsternas gränssnitt definierats med CORBAs IDL kan de anropas på samma sätt som andra CORBA-objekt, och de kan användas av alla klienter oavsett programmeringsspråk. Standardiseringen gör även att implementationer från olika tillverkare kan kombineras. Några av de viktigaste tjänsterna är: Naming Service, som gör det möjligt att associera objekt med logiska namn, vilket underlättar konfigurationen av stora distribuerade system. Naming Service arbetar med naming contexts, som kan betraktas som listor med namn och tillhörande objekt. Ett namn kan också associeras med ett annat naming context, för att på så vis bygga upp ett hierarkiskt system av namn, på samma sätt som i ett filsystem. Transaction Service hanterar transaktioner i vilka flera CORBAobjekt deltar. Tjänsten stödjer både nästlade och onästlade transaktioner, och kan koordinera transaktioner även mellan objekt som använder olika tillverkares ORB:ar. Security Service kan identifiera användare och kontrollera att de bara använder objekt de har rätt att använda. Tjänsten kan bl.a. också kryptera kommunikationen mellan objekt. Figur 4-5 Anrop till ett objekt i CORBA. 25

Event Service ger tillgång till asynkrona meddelandeköer. Tjänsten är uppbyggd kring händelsekanaler. Till en kanal hör ett antal producenter, som sänder händelser, och konsumenter, som tar emot dem. Event Service är en enkel meddelandetjänst utan stöd för t.ex. persistenta köer (d.v.s. köer där meddelanden finns kvar efter systemkrasch) och transaktioner, men är trots det ofta användbar. För- och nackdelar Den avgjort största fördelen med CORBA är dess oberoende av programmeringsspråk och operativsystem. Detta kommer bäst till sin rätt i stora, heterogena system, men innebär också att man inte blir bunden till en viss utvecklingsmiljö om man använder CORBA i sitt system. CORBA har också med tiden hunnit bli en relativt etablerad och mogen standard, och de flesta barnsjukdomar är avhjälpta. Genom CORBA Services kan CORBA erbjuda även avancerade middlewaretjänster. Att skriva program som utnyttjar dessa tjänster kräver dock mycket av utvecklaren, som måste lära sig ett antal komplicerade programmeringsgränssnitt. Till nackdelarna hör att stöd för att skicka objekt saknas. Detta innebär att ett objekt aldrig kan flyttas från en dator till en annan. Därför går det inte att använda objekt för att på ett effektivt sätt flytta strukturerade data i systemet. För den som utvecklar ett system i ett enda språk innebär anpassningen till CORBA och dess IDL en del extra arbete, samt att en del kompromisser sannolikt måste göras för att gränssnitten ska passa både CORBA och implementationsspråket. 4.2 Remote Method Invocation Java Remote Method Invocation (RMI) [10] är Javas egen teknik för enkel, men ändå kraftfull, nätverkskommunikation. Det ingår som standard i Java fr.o.m. version 1.02, och kostar därför inget extra. RMI gör det möjligt att skriva distribuerade objekt i Java och låter objekt kommunicera även om de befinner sig i olika virtuella maskiner [11]. Arkitektur Inom RMI kallas ett objekt som kan anropas från en annan virtuell maskin remote object. Ett remote object implementerar minst ett gränssnitt för distribuerade objekt, som i RMI kallas remote interface. Eftersom RMI till skillnad från CORBA bara stödjer Java behövs inget speciellt språk för att beskriva objektens gränssnitt. Istället används den befintliga språkkonstruktionen för gränssnitt, interface (se figur 4-6). Ett remote interface måste implementera gränssnittet java.rmi.remote. Detta gränssnitt definierar inga metoder; dess enda syfte är att markimport java.rmi.*; public interface SimpleMath extends Remote { } // Returns the sum of two integers public int add(int term_a, int term_b) throws RemoteException; Figur 4-6 Exempel på gränssnitt i Java RMI. 26

era att ett gränssnitt är ett remote interface. Dessutom måste varje metod som ska kunna fjärranropas kasta undantaget java.rmi.remote- Exception. Detta undantag kastas av RMI-systemet om något problem uppstår vid ett anrop. Anrop till distribuerade objekt görs på nästan exakt samma sätt som vanliga anrop. För att åstadkomma detta använder RMI en stub, ett lokalt objekt som ansvarar för att lokala anrop tas emot och skickas vidare till det faktiska objektet. Den enda skillnaden mot vanliga anrop är att man på något sätt måste hantera java.rmi.remoteexception. Varje gränssnitt måste ha sin egen stub-klass eftersom en stub måste ha samma metoder som de objekt den representerar. Därför finns ett program, rmic (RMI Compiler), som skapar stub-klasser för de gränssnitt man vill använda med RMI. På den mottagande sidan finns ett skeleton som tar emot anrop över nätverket (från en stub) och i sin tur anropar det avsedda objektet lokalt. Även här blir effekten att nätverket blir osynligt för objekten. Serialisering För att skicka metodparametrar och resultat över nätet använder RMI Javas serialiseringsteknik. Serialisering innebär att objekt omvandlas till en vektor av bytes som lätt kan överföras till en annan dator. Om objektet innehåller referenser till andra objekt måste de också serialiseras och skickas till den mottagande datorn. Processen upprepas rekursivt tills hela objektgrafen serialiserats. På den mottagande datorn sker en omvänd process som återskapar objektgrafen i dess adressrymd. Detta innebär att metodanrop med RMI skapar kopior av objektparametrarna på den mottagande datorn; om objekten ändras där kommer orginalobjekten förbli oförändrade. Vid lokala anrop skickar Java referenser till objekt, och de ändringar som görs av den anropade metoden påverkar samma objektinstans som skickades. I vissa situationer är denna skillnad av avgörande betydelse och man måste ha den i åtanke när man använder RMI. Man bör också tänka på att en objektgraf kan vara mycket stor i serialiserad form, och därför ta lång tid att överföra. Objekt som implementerar gränssnittet java.rmi.remote, och alltså är ett remote object, särbehandlas av RMI. Istället för att serialisera objektet själv serialiseras en stub för objektet, som överförs till den mottagande datorn. Eftersom alla anrop till en stub skickas vidare till dess moderobjekt simuleras Javas normala beteende. Det går också relativt snabbt att överföra en stub, oavsett hur stort objektet det representerar är i serialiserad form. Å andra sidan måste varje anrop till objektet från den mottagande datorn skickas tillbaka över nätet, något som också kan ta oacceptabelt lång tid. Vilken metod som passar bäst måste alltså avgöras från fall till fall. Distribuerad skräpsamling En viktig finess i Java är dess system för automatisk skräpsamling. Skräpsamlingen innebär att objekt som det inte längre finns några referenser till kastas bort ur minnet. Därmed slipper programmeraren, som i t.ex. C++, själv hålla reda på när ett objekt ska tas bort, något som är besvärligt och ofta blir fel. När det, som när man använder RMI, kan finnas referenser till objekt på andra datorer blir en automatisk skräpsamling mycket svårare att implementera. Till exempel kan datorer som har referenser till objekt krascha när som helst, och nätverket kan oväntat sluta fungera. På något sätt måste man ändå hålla reda på om det finns referenser till ett objekt på andra datorer, eftersom objektet då 27

måste finnas kvar. I RMI har problemet lösts genom att varje stub med jämna mellanrum skickar ett meddelande till orginalobjektet för att tala om att det fortfarande finns någon som kan vilja använda det. Om inget meddelande mottagits på ett tag (exakt hur länge kan ställas in), kan man anta att inga referenser finns kvar och att objektet kan tas bort, förutsatt att det inte finns några lokala referenser givetvis. Med denna metod spelar det ingen roll varför referenserna försvinner, förr eller senare kommer man i alla fall att upptäcka att objektet inte längre behövs. Överföring av implementationer Tack vare att Java använder en gemensam s.k. bytekod som tolkas av en virtuell maskin vid exekvering kan samma programkod köras av alla datorer, oavsett vilken hårdvara och operativsystem som används. Detta gör det möjligt för RMI att inte bara överföra objekts data till en annan dator utan också den kod som implementerar objekten. Därför kan RMI skicka objekt till en annan dator även om inte klassens programkod har installeras där på förhand. Ett system som använder RMI kan därför uppdateras mycket enkelt: den nya koden behöver bara installeras på en server och kan därefter hämtas automatiskt av de klienter som behöver den. RMI over IIOP RMI:s eget protokoll för metodanrop över nätverk heter Java Remote Method Protocol (JRMP). Detta protokoll är utvecklat speciellt för RMI och stödjer alla dess funktioner. Istället för JRMP kan man i senare versioner av RMI använda CORBAs nätverksprotokoll, IIOP [11]. Det gör det möjligt för CORBA-klienter att anropa RMI-objekt och vice versa. Alltså blir det möjligt att, med hjälp av CORBA, blanda olika programmeringsspråk i ett system trots att man använder RMI för de delar som skrivs i Java. Priset för detta är att inte alla funktioner i RMI kan användas, eftersom IIOP inte är anpassat för Java på samma sätt som JRMP. Bland annat fungerar inte den distribuerade skräpsamlingen, utan man måste själv hålla reda på när objekt inte längre används av någon klient [11]. För- och nackdelar RMIs största fördel är att det är så väl integrerat med Java. Man behöver inte lära sig ett nytt språk för att definiera gränssnitt, och man måste inte kompromissa för anpassa sina program till begränsningar i gränssnittsspråket. Att RMI kan överföra hela objekt i ett distribuerat system gör att programmen kan utnyttja den objektorienterade paradigmen fullt ut. Att även objektens implementationer kan överföras är en stor fördel eftersom det kan förenkla administrationen i ett distribuerat system avsevärt. Eftersom RMI ingår som standard i Java krävs inte heller att extra programvara köps in och installeras. Man måste dock komma ihåg att RMI är ett enkelt system, och att avancerade middleware-funktioner saknas. Vill man använda t.ex. transaktioner med RMI måste man implementera dem själv, vilket blir mycket komplicerat om transaktionerna involverar flera distribuerade objekt. 4.3 Enterprise JavaBeans Enterprise JavaBeans är en del av Java 2 Enterprise Edition (J2EE), Suns plattform för att utveckla serverapplikationer i Java-miljö. Syftet 28

med J2EE är att erbjuda en miljö för serverapplikationer som är plattformsoberoende, portabel, säker och standardiserad. J2EE är en utvidgning av Java 2 Standard Edition (J2SE), och består av J2SE tillsammans med en samling av tekniker som är användbara i serverapplikationer. I J2EE version 1.2 ingår förutom J2SE dessa komponenter [12]: Java Database Connectivity (JDBC) 2.0. JDBC är ett standardiserat gränssnitt till relationsdatabaser. RMI-IIOP 1.0. En utvidgning av RMI som ger interoperabilitet med CORBA och dess protokoll IIOP. Enterprise JavaBeans (EJB) 1.1. Den komponentarkitektur för distribuerade system som beskrivs i detta avsnitt. Servlets 2.2. En komponentarkitektur speciellt anpassad för request/response-protokoll, t.ex. HTTP. Java Server Pages (JSP) 1.1. En standard för att skriva java-kod i HTML-sidor. Java Messaging Service (JMS) 1.0. JMS ger tillgång till asynkrona meddelandetjänster. Java Naming and Directory Interface (JNDI) 1.2. Ett standardiserat gränssnitt till katalogtjänster. Används t.ex. för att hitta EJBkomponenter. Java Transaction API (JTA) 1.0. Ett gränssnitt för transaktionshantering. JavaMail 1.1. Ett gränssnitt för att skicka e-post. JavaBeans Activation Framework (JAF) 1.0. Används av JavaMail. Precis som CORBA är J2EE är en specifikation, inte en produkt. Implementationer av J2EE levereras av en mängd olika tillverkare. Sun tillhandahåller en referensimplementation, men den ska ses mer som ett sätt att undanröja tvetydigheter i specifikationen snarare än en riktig produkt, och dess funktioner och prestanda duger knappast för verkliga system. Sun har också en uppsättning testprogram som ska garantera att en implementation är felfri och följer specifikationen. Enterprise JavaBeans Enterprise JavaBeans är den viktigaste delen av J2EE. Det är en komponentarkitektur som låter utvecklare enkelt skapa skalbara distribuerade affärssystem med Java [13]. En Enterprise JavaBean (kallas nedan bean eller EJB-komponent) är en återanvändbar programvarukomponent som kan användas som en del i ett större system. Programmerare som använder EJB ska inte själva behöva implementera komplexa middleware-funktioner som transaktioner och hantering av persistenta objekt. Precis som andra Java-tekniker är EJB plattformsoberoende. Det ska också vara möjligt för komponenter som utvecklats med verktyg från olika leverantörer att fungera tillsammans. Roller EJB-specifikationen utgår från en definition av sex olika roller i utvecklingen av ett system [13]. Varje roll kan utföras av olika aktörer. EJBarkitekturen säkerställer att varje aktörs produkt ändå fungerar tillsammans med de andras. Ofta antar en aktör flera roller, t.ex. kan en programmerare vara både bean-leverantör och applikationsutvecklare. Bean-leverantören skapar återanvändbara mjukvarukomponenter (beans) som kan användas som delar i ett system. Server-leverantören och Container-leverantören tillhandahåller den exekveringsmiljö som behövs för att köra applikationerna och 29