.NET Component Overview

.NET Component Overview Martin Søgaard og Erik K. Aarslew-Jensen 10. april 2005 1

Indhold 1 Indledning 3 2.NET Framework Overview 4 2.1 Common Language Runtime (CLR)................ 4 2.1.1 Common Language Specification.............. 4 2.2 Assemblies............................... 5 2.2.1 Assembly manifest...................... 6 2.2.2 Versions styring........................ 6 2.3 Side-by-Side Eksekvering....................... 7 2.4 JIT Compilation............................ 7 2.5 Garbage collection.......................... 8 3 Komponenter i.net 8 3.1 Komponent Class Characteristics.................. 8 3.2 Komponent Livscyklus........................ 9 3.2.1 Initialisering og Destruktion................ 9 3.3 Komponent Bestandele........................ 10 3.3.1 Konstruktører......................... 10 3.3.2 Metoder............................ 10 3.3.3 Hændelser........................... 10 3.3.4 Egenskaber.......................... 10 3.3.5 Attributter........................... 11 3.4 Sikkerhed............................... 11 4 Konklusion 12 2

1 Indledning Komponent baseret sofware er et moderne emne indenfor udvikling af større systemer. Der er dog ikke fuld enighed om hvordan man skal definere og bruge komponenter, og hvert nyere programeringssprog har sin egen indgangsvinkel på området. En generel koncensus er dog at en komponent udgør en form for blackbox, hvor metadata er påkrævet for at beskrive komponentens egenskaber og funktionaliteter. Tilsvarende skal komponenterne også angive hvilke services og/eller andre komponenter de kræver for at virke. Vi har til denne opgave valgt at se nærmere på komponenter i.net. Men eftersom komponenter er en integreret del af.net Framework et, kan man ikke beskrive komponent arkitekturen uden også at beskrive de grundlæggende elementer i.net Framwork et. Rapporten indeholder derfor primært en gennemgang af komponent infrastrukturen i.net framework et. Dokumentationen som har dannet baggrund for rapporten kan findes inde på hjemmesiden for Microsoft Developer Network (MSDN) - http://msdn.microsoft.com. 3

2.NET Framework Overview 2.1 Common Language Runtime (CLR) Common Language Runtime kontrollere hukommelse, trådeksekvering, sikkerhed, kompilering og andre system services. Det vil sige at CLR er det afviklingsmiljø (eng: runtime enviroment) som man afvikler sine appliklationer i. Fælles for alle CLR applikationer er, at de er kompileret til mellemkode, Microsoft Intermediate Language (MSIL). Da CLR eksekverer mellemkode, kan man bruge forskellige sprog til at skrive sine applikationer og komponenter. De mest udbredte sprog er C++,C# og VB. Mellemkode-filerne kaldet portable executable (PE) indeholder metadata som beskriver typer, tilhørsforhold og referencer. Da indholdet i disse PE filer er mellemkode, kan koden i teorien eksekveres på enhvert platform, da mellemkoden er platforms uafhængig. Tidligere var registrerings- og tilstandsinformation gemt i Windows registreringsdatabase, hvilket gjorde det besværligt at vedligeholde og bruge. Dette er nu flyttet til metadataen, hvor information om typer og deres afhængighed nu ligger. Dette gør det meget nemmere at udskifte komponenter og applikationer, og dette gør det også nemmere at flytte en applikation fra en maskine til en anden. Da man bare skal sørge for at have sine metadata filer med, og ikke skal bekymre sig om at finde ting i registreringsdatabasen. Som en del af metadaten ligger også informationer om hvilke andre komponenter og ressourcer, samt versioner af disse, som komponenten blev bygget sammen med. Vi beskriver mere om metadata og versions styring senere. 2.1.1 Common Language Specification For at fuldt ud kunne interagere med objekter på tværs programmeringssprog, er det nødvendigt at objekterne kun blotter kode som er kompatibelt med alle programmeringssprog. Til det formål har man defineret Common Language Specification (CLS). Komponenter der overholder disse reglerne i CLS siges at være CLS-complient. Størstedelen af.net reference biblioteket er CLS-complient. 4

2.2 Assemblies Assemblies er byggestenene i.net applikationer, og udgør de fundamentale enheder i.net, med versions kontrol, genbrug og sikkerhed. En assembly er en kollektion af typer og ressourcer som er bygget til at arbejde sammen og udgør en logisk enhed af funktionalitet. En assembly formidler informationer om indlejrede type til Common Language Runtime. De indeholder koden som eksekveres af Common Language Runtime (CLR). MSIL kode i en portabel eksekverbar fil (PE) kan ikke eksekveres, hvis det ikke har en associeret assembly manifest. De udgør en sikkerhedsmæssig barriere og er den enhed for hvilket rettigheder er givet eller nægtet. De udgør en type grænseflade. De udgør et reference scope og manifestet indeholder metadata som bruges til at afgøre type og ressource forespørgsler. De specificerer typerne og ressourcerne som er blottet udenfor en assembly. De udgør en versionsenhed. De er de mindste versionsstyrede enheder i CLR. De udgør den mindste distributionsenhed. De tillader side-by-side eksekvering af forskellige versioner af samme assembly. En assembly kan indeholde op til 4 forskellige ting. Assembly manifest, som indeholder metadata typemetadata Microsoft Intermediate Language (MSIL) kode En mængde af ressourser, som f.eks bitmap billeder eller andre filer. Figur 1: Indeholdet af en assembly Figur 2: En opdelt assembly Et assembly manifest er det eneste der skal være, de andre elementer kan være der. I den simpleste form er et manifest gemt i en enkelt fil. Men man kan sagtens dele det op i flere filer, så man f.eks har ressourcerne i en fil, og resten i en anden. Dette kan være en god ide, hvis man har nogle store filer, som man ikke bruger så tit. Da filerne kun er referance tilknyttet, og derfor først hentes når de skal bruges. 5

2.2.1 Assembly manifest Et assembly manifest indeholder informationer om metadataen, og hvordan elementer i metadaten relatere til hinanden. Derudover holder manifestet styr på versions styring, andre assemblies og sørger for at beskrive hvad den indeholder til omverdenen. Som tidligere beskrevet så kan manifestet enten gemmes i en fil for sig, i en samlet fil (.dll eller exe) eller sammen med de andre filer som normalt findes i en assembly. 2.2.2 Versions styring En af de primære mål for assemblies er versions styring. Mere specifikt udgør assemblies en måde for udviklere at specificere versionsregler mellem forskellige software komponenter, som vil blive håndhævet af køretids miljøet. Fordi assemblies er byggesten i.net applikationer, er de et logisk udgangspunkt for at specificere og håndhæve informationer om versioner. Hver enkelt assembly har et specifikt versionsnummer som er en del af dets identitet. Den simpleste assembly er en enkelt eksekverbar fil som indeholder alle informationer nødvendigt for distribution (eng: deployment) og versions styring. Versionsnummeret er placeret i et manifest for en assembly sammen med andre informationer om identitet. Det faktum at versionsnummeret er en integreret del af identititen for en assembly er grundstenen i versions styring. 2 assemblies med forskelligt versionsnummer behandles som to forskellige entiteter, selvom der tale om samme komponent, i to forskellige versioner. 6

2.3 Side-by-Side Eksekvering Side-by-side eksekvering er som udtrykket siger, en måde hvorpå man kan kører flere instanser samtidig ved siden af hinanden. Der ligger dog mere i det, man kan nemlig på en enkelt maskine have flere samtidige køretids miljøer, hvis der er behov for dette. Der er pt. to versioner af.net, 1.0 og 1.1. på figur 3 fremgår dette. Figur 3: Forskelling kørselsmiljø Side-by-side eksekvering kan også håndtere den samme komponent i flere versioner. Dette giver en stor fleksibilitet i forbindelse med udskiftning og opdatering af komponenter. Tidligere ville en opdatering ske ved at man overskrev en dll fil, og dette kunne nemt få et system til at bryde sammen. Men side-by-side gør at man kan have begge versioner kørende på samme tid, og nemt i sine applikationer skifte mellem dem. Eller beholde den gamle version til en applikation, og bruge den nye til andre applikationer. Figur 4: Komponenter i forskellige versioner 2.4 JIT Compilation For at kunne eksekvere Microsoft intermediate language (MSIL) er det nødvendigt at konvertere det til maskinspecifik kode med.net framework just-in-time kompileren. I stedet for at bruge tid og ressourcer på at kompilere MSIL, som måske aldrig vil blive benyttet, konverterer JIT kompileren den nødvendige MSIL kode, når der opstår et behov for det og gemmer maskinkoden til efterfølgende kald. Det fungerer ved at loaderen opretter en proxy til alle metoder og ved det første kald til metoden videregives kontrollen til JIT kompileren, som så konverterer koden til maskinkode og ændrer proxien til at pege på den genererede maskinkode. Efterfølgende kald bliver derfor videresendt direkte til maskinkode, hvilket reducerer kompileringstid og ressourceforbrug fro JIT kompileren. 7

I.NET Framework et er også muligt at benytte sig af install-time kompilering, som kompilerer komplette assemblies til maskinkode, ganske som traditionelle kompilere. Dette resulterer i mere effektiv maskinkode og dermed mindre indlæsningsog opstartstid på bekostning af tidsforbruget for en traditionel kompilering. Før MSIL kode kan blive kompileret til maskinkode, skal det gennemgå en verificeringsproces som kontrollerer at koden ikke forsøger at tilgå beskyttede ressourcer, såsom beskyttede hukommelsesområder. 2.5 Garbage collection Til forskel fra COM så benytter Common Language Runtime (CLR) sig ikke af reference tælling for at bestemme levetiden for et objekt. Dette bliver istedet for klaret af systemets garbage collection som undersøger objekt referencer (eng: trace) og identificerer objekter som ikke længere kan nås fra den eksekverbare kode. Dette forenkler komponent programmering, da man ikke behøver at bekymre sig om cirkulære referencer. Hvis en gruppe af objekter indeholder indebyrdes referencer til hinanden, men ingen af disse objekter bliver refereret til direkte eller indirekte fra stakken eller delte variable, så vil garbage collection automatisk frigøre hukommelsen. Derudover er fordelen ved traced garbage collection - fremfor reference tælling - at allokering af objekter sker væsentligt hurtigere og man eliminerer helt behovet for en mekanisme som COM AddRef and Release mechanism, hvilket betyder mindre hukommelses fodaftryk. Den eneste ulempe forbundet med traced garbage collection er intervallen mellem frigørelsen af den sidste reference og det øjeblik hvor garbage collection opdager det. På et mindre belastet system med meget hukkommelse kan der passere et betydeligt tidsrum inden destruktøren kaldes. 3 Komponenter i.net.net komponenter er pakket i assemblies - selvbeskrivende byggesten i.net applikationer. Det som adskiller en komponent fra en klasse i.net er, at en komponent skal opfylde en standard for komponent interaktion. Denne standard er i.net givet ved interfacet System.ComponentModel.IComponent. Måden hvorpå komponenter til Common Language Runtime (CLR) interagerer med hinanden er beskrevet i Common Language Specification (CLS). En sådanne standard gør det muligt for udviklere at sammensætte komponenter til større programmer, hurtigt og smertefrit. Derudover kan alle.net kompomenter automatisk benyttes i et Rapid Application Development (RAD) miljø, som Visual Studio.NET. Denne design-time support er indbygget i.net Framwork et. 3.1 Komponent Class Characteristics Klasser, som indgår i.net komponenter, bør overholde følgende retningslinjer. 8

Komponent klasse navne bør være korte, beskrivende og sammensat af komplette ord. Man skal såvidt muligt undgå forkortelser, da de kan virke forvirrende, især overfor andre kulturer. Klasser defineret som private/friend er ikke tilgængelige udenfor en assembly og er derfor kun beregnet til interne hjælpeklasser.klasser defineret som public er tilgængelige udenfor en assembly og dermed for brugerne af komponenten. Det er også muligt at definere konstruktøren som privat og dermed forhindre brugerne i at oprette instanser af komponenten. Alle komponent klasser skal enten implementere System.ComponentModel.IComponent interfacet eller nedarve fra en klasse der har implementeret det, som eksempelvis System.ComponentModel.Component. Enhver komponent er indeholdt i et navnerum, som brugerapplikationer skal importere hvis de ønsker at brug af komponenten. 3.2 Komponent Livscyklus En komponent bliver initialiseret af dens kontruktør og ødelagt igen af destruktøren. Destruktøren kaldes lige inden komponenten bliver ødelagt af garbage collection og hukommelsen bliver frigjort. 3.2.1 Initialisering og Destruktion Common Language Runtime (CLR) kalder komponentens destruktør når garbage collection afgør at komponenten ikke længere kan nås af den eksekverbare kode. Hvilket sker når alle referencer til komponenten er frigivet. Fordi der er en betydelig forsinkelse mellem det øjeblik at brugeren frigiver referencer til en komponent og dette opdages af garbage collection, har man introduceret et ekstra trin i livstidscyklen for.net komponenter. Hvis komponenten har reserveret nogle system ressourcer, såsom database forbindelser eller Windows system objekter, bør man implementere IDisposable interfacet, som giver brugerne mulighed for at frigive ressourcer gennem Dispose metoden defineret i dette interface, inden brugeren frigiver sine referencer til komponenten. Livstids cyklus: Initialisering af statiske medlemmer : når den første instans af komponenten oprettes. Initialisering af instans medlemmer : hver gang en stans af komponenten oprettes. Frigørelses af ressourcer : når brugeren kalder Dispose metoden, inden referencen frigøres. Destruktion af instansen : når garbage collection opdager at der ikke er flere aktive referencer til komponenter og derefter kalder komponentens destruktør. 9

3.3 Komponent Bestandele En komponent tilbyder funktionalitet gennem dens egenskaber (eng: properties), metoder, konstruktører og hændelser (eng: events). Egenskaber og offentlige variable er data som kan aflæses og manipuleres af brugeren, metoder er funktionalitet som udføres, mens hændelser er meddelelser som asynkront informerer brugeren om at en hændelse af interesse har forekommet. 3.3.1 Konstruktører Udviklere har mulighed for at begrænse adgangen til konstruktøren for en komponent og dermed kontrollere måden hvorpå brugeren opretter instanser af komponenten. Dermed kan man eksempelvis forhindre brugeren i at oprette mere end x instanser af komponenten, eller for at komme med et eksempel fra MSDN, så kan man sikre sig at en bog bliver tilføjet til et bibliotek i det øjeblik at man opretter en instans af bogen. 3.3.2 Metoder Metoder er den primære måde at implementere funktionalitet i.net komponenter, ligesom det er tilfældet for størstedelen af objekt orienteret programmering. Komponenter er i bund og grund stadigvæk bare en klasse i.net, som implementerer et specifikt interface. Det er tilsvarende også muligt at benytte sig af overloading for at tilbyde flere variationer af en given funktionalitet, uden at skulle variere navngivningen. 3.3.3 Hændelser Til forskel fra grafiske elementer i.net, såsom System.Windows.Forms.Control, så er hændelser i komponenter ikke forbundet med en grafisk overflade, eks. museklik, men benyttes istedet primært til at signalere tilstandsændringer til andre komponenter, som har ytret interesse overfor en given hændelsestype. Udover naturen af hændelserne er der ikke yderligere forskel på almindelige hændelser og hændelser i komponenter. 3.3.4 Egenskaber Egenskaber (eng: properties) gør det muligt for ens komponent at gemme, manipulere og huske data som er påkrævet for at eksekvere funktionalitet i komponenten. Egenskaber minder meget om offentlige variable, men er en væsentlig mere robust måde at tilgå informationerne på. Egenskaber tilgås via. specielle indlejerede metoder - Get og Set - der muliggør validering af data samt yderligere kode eksekvering når en egenskab sættes eller hentes. Egenskaber er som standard læs/skriv, hvilket betyder at værdien både kan læses og skrives. Tilsvarende kan man også hvis behovet opstår have egenskaber som kun er enten læs eller skriv. Dette opnås ved at undgå at implementere den indlejrede metode for den uønskede funktionalitet. En komponent kan også fungere som en beholder for andre objekter, eksempelvis andre komponenter. Hvis man ønsker at gøre egenskaber af andre komponenter indeholdt i en anden komponent er man nødt til at blotte disse egenskaber. Det opnår man ved at implementere en tilsvarende egenskab for 10

beholder komponenten og lade dens læs/skriv metoder tilgå den indlejrede komponents egenskab. 3.3.5 Attributter Attributer er nøgleords-lignende deskriptive deklarationer, som kan vedhæftes signaturen for klasser, variable, metoder og egenskaber. Disse informationer kompileres og gemmes sammen med resten af de metadata som genereres for en komponent og kan bruges til at beskrive eller påvirke ens kode på kørselstidspunktet. Et eksempel herpå er design-time attributter, der er essentielle for at formidle informationer om komponents egenskaber til et RAD miljø. Den såkaldte DescriptionAttribute formidler eksempelvis en kort beskrivelse af en egenskab til property inspector en i Visual Studio.NET. Tilsvarende findes der også en designtime attribut, som beskriver hvilken kategori den enkelte egenskab tilhører. Attributter er i princippet en videreudviklet af modifier konceptet. Men istedet for at være begrænset af et par prædefinerede nøgleord - såsom private, public osv. - så kan man i.net også designe og udbrede sine helt egne attributter, idet attributterne i princippet bare er en klasse som nedarver fra System.Attribute. Man kan bruge attributter til at beskrive ens kode i praktisk talt enhver tænkelig måde, samt bruge dem til at påvirke køretids funktionaliteten uden at skulle omskrive ens kompiler. 3.4 Sikkerhed Sikkerhed er altid en varm kartoffel når man taler om udvikling og brugen af 3. parts komponenter. At sikre ens kode mod uautoriseret og ondsindet brug, mens på samme tid at tillade brug af komponenten for autoriserede brugere er et vigtigt aspekt af komponent udvikling. Tilladelser (eng: permissions) er måden hvorpå komponenter interagerer med.net framework ets sikkerheds politik, og kan tillade en komponent at udføre en række handlinger, der er potentielt skadelige, og normalt forhindret af sikkerheds politikken. Gennem en assembly kan man forespørge på diverse tilladelser via. sikkerheds attributter, som defineres i metode- og klassesignaturer og kompileres ned i de metadata som gemmmes i manifestet til en assembly. Disse tilladelser bliver så undersøgt af CLR og sammenlignet med sikkerheds politikkerne på den enkelte maskine. Hvis denne politik tillader den ønskede handling så får den givne assembly lov til at eksekvere. 11

4 Konklusion I ovenstående gennengang af komponent infrastrukturen i.net framework et har vi observeret forskellige features som vi gerne vil fremhæve i konklusionen. Assemblies metadata overflødigør behovet for et specifikt Interface description language (IDL). Side-by-side execution er en smart måde at tillade samtidig eksekvering af forskellige versioner af samme komponent. Hvilket gør udvikling og opgradering væsentligt nemmere. Kompilering af komponenter til mellemkode (MSIL) gør at man uden problemer kan benytte komponenterne på tværs af programeringssprog, og i teorien på tværs af platforme..net frameworket sørger automatisk for at frigøre ressourcer når de ikke længere bliver brugt vha. den indbyggede garbage collection. Komponenter udstyres automatisk med design-time support, hvilket gør at de uden videre kan anvendes i et.net baseret RAD miljø. Konceptet om attributter er en stærk feature i.net, da man har mulighed for at påvirke køretids funktionaliteten direkte vha. metadata. Selvom.NET framework et i teorien er platforms uafhængingt er der på nuværende tidspunkt kun en implementation til windows platformen hvilket begrænser udbredelsen af ens komponenter. Derudover virker.net framework et som et meget omfattende framework, der til fulde opfylder størstedelen af de komponent definitioner vi har set på. 12