Jämförelse skalbarhet

Jämförelse av skalbarhet baseras på följande villkor:

• nätverket består inledningsvis av fler än en nod • samtliga noder opererar på likadana plattformar

• övrig mjukvara (ej OS) kan komma från skilda leverantörer • varje nod ska kunna tjänstgöra som klient såväl som server

Fråga ”administrativ insats” besvaras med en etta på båda om likartade insatser krävs. Skiljer sig insatserna åt ges den standard där minst insatser krävs en tvåa och den andra en etta.

Fråga \ Standard DCOM CORBA

begränsn. av nätverkstrafik 1 0

bibehållen prestanda 1 1

Tabell 2. Utfall skalbarhet Utvärdering administrativ insats

Standarderna bedöms som likvärdiga när det gäller administrativ insats vid utökning av antalet användare därför att i båda fallen krävs endast installation av mjukvara och nätverkskort i den nya noden för att kunna upprätta kommunikation med dess objekt. Övriga noder i nätverket behöver således inte uppdateras.

I ett CORBA-system krävs åtminstone installation av en ORB, en Portable Object Adapter (POA), se 5.2, samt ett nätverkskort som stödjer General Inter-ORB Protocol (GIOP) i varje ny nod. ORB måste dessutom ha tillgång till kompilerade IDL- instruktioner om existerande objekts gränssnitt.

I ett DCOM-system krävs installation av ett s.k. COM Library, se 5.3, samt ett nätverkskort som stöder protokoll enligt OSF DCE RPC specifikationen, se List of abbreviations. COM Library innehåller resurser för att definiera, skapa binär representation av och exponera aktuella objekts gränssnitt, dvs en COM-server, se 5.3. Dessutom ingår SCM för lokalisering av efterfrågade objekt samt lågnivårutiner för RPC-kommunikation, se 2.5, och minnesallokering.

Utvärdering av begränsning av nätverkstrafik

DCOM erhåller ett bättre betyg därför att ett DCOM-system utökat med MIDAS begränsar nätverkstrafiken på så sätt att regler för dataintegritet propageras tillsammans med efterfrågad data till klienten, se 5.3.1. Detta medför att validering av registrerad data sker på lokal nod vilket gör att endast korrekt data skickas över nätet. CORBA ges det sämre betyget därför att CORBA utökat med CBConnector inte har samma förtroende för klienter utan hanterar integritets- och andra kontroller centralt. Detta gör att hela end-to-end förbindelsen, se 2.6.1.1, trafikeras under hela kontrollförfarandet.

Utvärdering bibehållen prestanda

Standarderna bedöms som likvärdiga när det gäller rutiner för att bibehålla god prestanda vid utökning av antalet användare. Såväl CBConnector som MIDAS erbjuder balansering av last (eng. load balancing or workload management), se 5.2.1 och 5.3.1. Med detta avses att åtgärder vidtas för att sprida exekvering av efterfrågade tjänster på flera servrar så att varje server opererar optimalt.

5.6.2 Jämförelse återhämtningsförmåga

Villkor för jämförelse av återhämtningsförmåga är att efterfrågad funktionalitet finns distribuerad på fler än en server

Fråga \ Standard DCOM CORBA

tillgänglighet 2 1

transaktion 0 1

Tabell 3. Utfall återhämtningsförmåga Utvärdering tillgänglighet

DCOM tillskrivs bättre betyg när det gäller tillgänglighet därför att DCOM utökat med MIDAS erbjuder felhantering som består av såväl HRESULT, se 5.3, som fail-over safety, se 5.3.1. Den service som tillhandahålls via dessa funktioner syftar till att förhindra ofrivillig terminering av en server samt att överföra exekvering av en begäran från en felaktig server till en fungerande. Detta bidrar till ökad tillgänglighet på så sätt att det faktum att en server ej opererar korrekt kan observeras av omgivningen och därmed undvikas. Dessutom blir en klient alltid betjänad i och med att exekvering sker på eller överflyttas till en fungerande server.

CORBA får det sämre betyget därför att ett CORBA-CBConnecter-system erbjuder motsvarande service utom fail-over safety. Detta gör att klienten återfår kontrollen när en server returnerar ett felmeddelande och måste ånyo anropa ett serverobjekt. Eftersom CBConnector observerar och undviker felaktiga servrar, se 5.2.1, så bör ett upprepat anrop lyckas. Klienten måste dock aktivt bidra till att upprätta lika god tillgänglighet som i ett DCOM-MIDAS-system.

Utvärdering transaktion

CORBA får bättre betyg därför att CBConnector tillhandahåller stöd för transaktioner i en distribuerad miljö genom att utnyttja Two-Phase Commit Protocol, se 5.2.1. Data kan därmed flyttas mellan poster i en databas som endast involverar konsistenta tillstånd. Den tidpunkt där aktuell data hämtats från den ena posten men ännu ej införts i den andra kan således inte observeras av omgivningen och är därmed inget tillstånd. DCOM saknar stöd för transaktioner i en distribuerad miljö och ges därför betyg 0. Utvärdering felhantering

CORBA erhåller högst betyg när det gäller att reducera konsekvenser eller hantera andra fel än de som redovisas under tillgänglighet. Skälet är att den utvecklingsmiljö som CBConnector tillhandahåller innehåller en resurs som heter Application Adapter Framework och som automatiskt och vid lämplig tidpunkt aktiverar metoder som lagrar information på stabilt minne, se 5.2.1. Detta reducerar väsentligen konsekvenserna av en okontrollerad terminering av servrar eller hela system och bidrar därmed till snabbare återstart av terminerade systemdelar.

DCOM får betyg 1 därför att MIDAS tillhandahåller funktionalitet som gör det möjligt att lagra och bearbeta en mängd poster på lokal nod, se 5.3.1. Detta gör att en operatör kan få visst arbete utfört trots att förbindelsen mellan klient och server är tillfälligt bruten.

5.6.3 Jämförelse anpassningsförmåga

Villkor för den här jämförelsen är att en plattform eller ett system involveras som saknar tidigare anpassningar.

fråga \ standard DCOM CORBA

godtycklig plattform 1 2

Tabell 4. Utfall anpassningsförmåga Utvärdering godtycklig plattform

CORBA får det högre betyget därför att i ett CORBA-system är ORB plattformsoberoende samt att interaktivitet mellan CORBA- och DCOM-system beaktas i ett CORBA-CBConnector-system. En ORB görs plattformsoberoende genom att en Object Adapter (OA), se 5.2, byggs ovanpå ORB och tjänstgör som gränssnitt mellan ORB och den aktuella plattformens objekt. På en plattform där mappning mellan ORB och aktuella objekt inte sker korrekt med existerande OA behöver endast en rätt anpassad OA konstrueras. I ett IS kan dessutom flera implementationer av ORB existera. För att åstadkomma kommunikation mellan dessa krävs en Portable Object Adapter (POA), se 5.2, vilket också ingår i CORBA- specifikationen.

Kommunikation mellan CORBA och DCOM stöds mha Component Broker Toolkit vilket är en komponent som levereras tillsammans med CBConnector och är klar att på en DCOM-klient. Mha OA, POA och Component Broker Toolkit ges således ett gott stöd för att involvera en godtycklig plattform i systemet.

I ett DCOM-system behöver hela COM Library, se 5.3, anpassas för att interaktivitet ska kunna upprättas mellan godtyckliga plattformar. Betyget sätts till 1 därför att inte någon av de komponenter som ingår i COM Library stödjer kommunikation mellan godtyckliga plattformar. Ett COM Library måste därmed konstrueras för varje specifik plattform såsom Windows95, Windows/NT, Macintosh etc för att kommunikation ska kunna upprättas. Standarden har dessutom inte beaktat interaktivitet mellan DCOM- och CORBA-teknik.

Utvärdering anpassningar befintligt IS

Standarderna erhåller samma betyg därför att insatser vid integrering med befintliga system bedöms som likvärdiga.

I ett DCOM-system krävs att gränssnitten till de metoder eller procedurer som ett befintligt IS tillhandahåller definieras i MIDL och på så sätt representeras binärt i en COM-server, se 5.3. Definiering sker i en MIDL-fil som sedan kompileras. Implementering av den funktionalitet aktuella metoder och procedurer innehåller måste dessutom vara gjord i ett programspråk som stödjer hantering av pekare eftersom anrop sker via pekare. För att skapa en COM-server krävs tillgång till en MIDL- kompilator som är anpassad för aktuell plattform.

CORBA antar en likartad ansats, dvs gränssnitten till förekommande funktioner i ett befintligt IS måste definieras i OMG IDL för att efter kompilering exponeras i Implementation Repository, se 5.2. Dessutom måste en OMG IDL existera som är anpassad till det programspråk befintligt IS är skrivet i plus en giltig OA så att korrekt mappning mellan ORB och förekommande objekt kan upprättas.

5.6.4 Jämförelse underhållbarhet

Fråga \ Standard DCOM CORBA

säkerhet 1 2

Tabell 5. Utfall underhållbarhet Utvärdering säkerhet

CORBA får ett bättre betyg därför att ett CORBA-system utökat med de tjänster CBConnector erbjuder ger stöd inom alla tre områdena som ingår i faktorn säkerhet, dvs identitetskontroll, åtkomstkontroll och samtidighetskontroll. CBConnector utövar identitets- och åtkomstkontroll via en Security Server där loginförfarande och restriktioner beträffande åtkomst återfinns, se 5.2.1. Samtidighetskontroll utövas på så sätt att varje resurs kan fördela olika lås (eng. lock) till klienter. Varje resurs har dessutom tillgång till en tabell som anger vilka lås som kan kombineras. Har t.ex en klient ett skrivlås på en resurs medges inte några andra lås på den resursen. CORBA ger således ett gott stöd när det gäller säkerhet.

DCOM får betyg 1 därför att samtidighetskontroll i ett DCOM-MIDAS-system antar en optimistisk ansats. Med detta menas att man utgår ifrån att konflikter vid samtidig kommunikation är sällsynta och att de löses när de uppstår [Cel98]. I det här fallet krävs att en eller flera användare involveras vid lösning av en sådan konflikt. DCOM ger dock stöd för identitetskontroll och åtkomstkontroll. Identitetskontroll utövas på så sätt att vid anrop av en klient till en server anlitar servern en ID-funktion via ett gränssnitt som heter IServerSecurity varvid klienten genomgår ett loginförfarande med ID och lösenord. Åtkomstkontroll stöds på så sätt att tillgängliga objekt och vilka som har rätt till åtkomst listas i en Access Control List (ACL), se 5.3.

Utvärdering dataintegritet

CORBA får betyg ett därför att ett CORBA-CBConnector-system erbjuder integritetsskydd av överförda meddelanden. Detta gör att meddelanden som på ett otillåtet sätt ändrats på någon nod under överföring detekteras, se 5.2.1. Security Server ansvarar för hantering av dataintegritet.

DCOM erbjuder inte några rutiner för detektering av otilllåten ändring av meddelanden.

5.7 Analys

Vid en sammanräkning av resultaten av hela jämförelsen i avsnitt 5.6 erhåller ett CORBA-system siffran 12 och ett DCOM-system siffran 9, se tabell 6. Detta ska inte tolkas som att CORBA är ett bättre val eftersom informationssystem graderar de fyra kriterierna olika. Förklaringen i det här fallet är att CORBA på fler punkter än DCOM ger ett visst stöd.

Kriterie \ Standard DCOM CORBA

Skalbarhet 3 2

Återhämtn.förmåga 3 4

Anpassningsförmåga 2 3

Underhållbarhet 1 3

Tabell 6. Sammanställning av kriterier

Resultatet av det här projektet visar att när det gäller skalbarhet, dvs administrativ insats vid utökning av systemet, begränsning av nätverkstrafik och förmåga att

bibehålla god prestanda vid utökning av systemet så ger ett DCOM-system bäst stöd. Det som skiljer de båda standarderna åt är att ett DCOM-MIDAS-system erbjuder rutiner för begränsning av nätverkstrafik vilket CORBA saknar.

Beträffande återhämtningsförmåga ger ett CORBA-system bäst stöd. Återhämtningsförmåga visar i vilken omfattning aktuell standard bidrar till god tillgänglighet av systemet, om standarden ger stöd för transaktionshantering och om stöd ges för återhämtning från andra fel än de som sorterar under ovan nämnda punkter. CORBA vinner på att ett CORBA-CBConnector-system erbjuder en resurs som väver in instruktioner i aktuell implementation som medför att lagring på stabilt minne sker vid lämpliga tidpunkter samt att transaktionshantering erbjuds. DCOM saknar båda dessa egenskaper men utökad med MIDAS erbjuds fail-over safety, se 5.3.1.

Anpassningsförmåga, dvs de insatser som krävs för att involvera dels en godtycklig plattform och dels ett befintligt system, stöds bäst av CORBA. Det som skiljer standarderna åt är att involvering av en godtycklig plattform i ett CORBA-system kräver implementering av en Object Adapter medan DCOM kräver implementering av COM Library. Eftersom COM Library innehåller regler för minnesallokering, SCM, registry etc uppskattas den insatsen som mer omfattande.

Underhållbarhet, dvs identitetskontroll, åtkomstkontroll, samtidighetskontroll och dataintegritet, stöds bäst av ett CORBA-system. Standarderna skiljer sig åt när det gäller samtidighetskontroll genom att CORBA-CBConnector erbjuder en funktion som ger förekommande resurser möjlighet att fördela olika lås till klienter, se 5.2.1. Med resurs avses objekt, transaktion eller yttre enheter såsom skrivare, scanner m.m vars åtkomst regleras av en mjukvarukomponent.

6 Slutsatser

De IS som opererar i olika organisationer och företag existerar i omgivningar som å ena sidan kan vara praktiskt taget identiska eller å andra sidan variera enormt. Detta gör att de kravspecifikationer som ligger till grund för systemutveckling varierar på samma sätt. Det är således sannolikt att de fyra kriterier som ingår i den här jämförelsen tillskrivs varierande grad av betydelse vid projektering av nya IS. Beroende på denna gradering är avsikten att ett optimalt val av objektstandard för ett specifikt IS ska kunna göras med det här projektets resultat som underlag.

I återstoden av kapitlet sammanfattas resultat och slutsatser av jämförelsen samt att en diskussion om ämnet förs. Avslutningsvis diskuteras förslag på uppslag för fortsatta studier inom området.

6.1 Resultat

Tidigare undersökningar inom området har fokuserat på konkreta skillnader mellan objektstandarderna såsom specifikation av objekts gränssnitt, registrering av serverobjekt etc. Pga den detaljerade beskrivningen är dessa undersökningar inte lättillgängliga och kan inte tjänstgöra som underlag för ett utvecklingsprojekt vid val av standard. Det här projektet avviker dock från tidigare undersökningar på så sätt att s.k mittenlagerverktyg för respektive standard involveras i projektet, se 2.9. Detta gör att abstrakta krav såsom tillgänglighet, god prestanda, integrering med befintliga system etc kan beaktas, se 3.1. Tillgängligheten av resultatet bedöms därför som godtagbar eftersom dels fastställda kriterier och ingående faktorer sannolikt är relevanta för flertalet IS och dels att en gradering av kriterierna är ganska enkel att göra, se 6.1.5.

Avsikten med jämförelsen i det här projektet är att bidra med dels en beskrivning av hur ett mittenlagerverktyg utökar aktuell standard med funktionalitet och dels vilka generella krav en sådan kombination möter. Systemutveckling kan förenklas genom att ett optimalt val av implementationsmetod kan göras tidigt och på så sätt bidra till att installation och igångkörning av det nya systemet blir mera friktionsfritt.

Det man kan konstatera när man tar del av sammanställningen, se 5.7, är att IS som har höga krav på att systemet snabbt återhämtar sig från fel, lätt kan anpassas till nya omgivningar och erbjuder gott om tjänster för att förenkla systemunderhållet med fördel kan implementeras med CORBA-teknik. IS som prioriterar god prestanda även med stort antal användare blir sannolikt mest nöjd med ett DCOM-system. Det blir troligen ännu mer påtagligt om Internet utnyttjas eftersom överföringshastigheten är betydligt lägre där än i ett lokalt nätverk (eng. Local Area Network), se 2.1, samt att många fler användare ska dela på nätverksmediet. Vid kommunikation via Internet ökar dessutom sannolikheten att CORBA- och DCOM-teknik måste kunna interagera, se 3.2, vilket CORBA ger ett visst stöd för.