Ingress: Distribuert objekt-orientert databehandling letter kanskje litt på programvarekrisen. Vi skal se på hvordan CORBA-teknologien lar objekter sende meldinger til hverandre gjennom et nettverk.
(c) Anders Fongen 1996
Distribuert databehandling byr på en rekke fordeler: Man kan utnytte knipper av billige maskiner fremfor å investere i store skapmaskiner, man kan oppnå en feiltolerans gjennom å dublisere tjenerfunksjoner i nettet, og man kan oppnå en total ytelse som ikke er mulig å oppnå i en enkelt prosessor.
På den annen side har de programmeringsverktøyene vi har utviklet ikke i særlig grad fanget opp behovet for distribusjon. Når et C- program kompileres og lenkes blir alle referanser til data og funksjoner statisk bundet, og den endelige plasseringen i internminnet blir fastlagt allerede da. Dette står i kontrast til distribuert behandling, hvor vi ønsker at programmet skal lete frem ressursene idet programmet utføres, gjerne ved at de andre komponentene i nettverket betegnes med navn, og letes frem gjennom kataloger.
Altså: Om vi har en databasetjener et annet sted i nettverket som vi ønsker å benytte, kan vi kalle den "DBSERVER" og benytte et katalogoppslag for å få vite nettverksadressen til maskinen. Katalogtjenesten kan gjerne holde rede på om DBSERVER er ute av drift, og i så fall henvise til en reservertjener istedet. Dette er ingen kunst dersom man godtar at DBSERVER kalles gjennom helt spesielle funksjonskall, og hvor protokollen mellom klienten og tjeneren er utviklet med nettopp denne anvendelsen for øye. Om man heller ønsker å benytte vanlige funksjonskall til tjenester som ligger ute i nettverket må vi benytte helt andre metoder.
Remote procedure calls
Disse problemstillingene er kjent og gammelt nytt for et prosedyreorientert språk som f.eks C. Der har vi hatt "Remote Procedure Calls" (RPC), som lar et klientprogram kalle en funksjon i en tjener et annet sted i nettverket. Dette foregår ved at tjenerens funksjon lar seg representere hos klienten ved en "Stub Procedure", som kalles av klientprogrammet, og oversetter funksjonskallet (med parametre m.m.) til en nettverksprotokoll mot tjenerens "Stub Procedure" i andre enden. En slik Stub Procedure kan genereres automatisk basert på en spesifikasjon av funksjonsparametrene i et såkalt "Interface Definition Language" (IDL). Stub Procedure'ne lenkes inn i programmet med den vanlige linkeren, og det hele er klart til bruk.
Vel, det er ikke riktig så enkelt. I tillegg til selve dataoverføringene må Stub Procedures også glatte ut forskjeller mellom programmeringsspråk og maskinarkitekturer. Pascal og C har helt ulik organisering av "call stack", og dette må håndteres slik at de rette parametrene kommer på rett sted. Dessuten må det sørges for at forskjeller i ordlengde, byteorganisering (bigendian/littleendian) og flyttallsformat ikke skaper feil dataoverføring. For dette formålet benytter RPC et "eksternt" dataformat under overføringen, som den lokale maskinen så konverterer til sitt egen representasjon.
Fordelen med RPC er bl.a. at man ikke trenger å utvikle applikasjonsprotokoller for nettverket i hvert enkelt tilfelle. Design av en protokoll er vanskelig, og RPC dekker dette behovet en gang for alle. Dessuten kan RPC utnytte "asynkrone" funksjoner, dvs. funksjoner som utføres samtidig med hovedprogrammet, slik at man i motsetning til vanlige funksjonskall ikke venter på returverdien før programmet fortsetter. RPC kan dermed også utnytte de mulighetene for parallell utføring som oppstår i et databehandlingsmiljø med flere uavhengige maskiner.
Legg forøvrig merke til at det bare er funksjonsnavnet hos tjeneren som det blir referert til. Kun parametre og returverdier blir overført i nettverket, og variabler (globale) hos klientene er ikke synlige for tjeneren, og vice versa.
Fordelene med distribuert objektorientering
Lenge ble objektorientert (OO) programmering fremholdt som den endelige løsning og garanti mot SW-sykdommene. OO skulle tilby gjenbruk, mindre vedlikehold og separat testing og bedre kvalitet på programmene. Nå har det i praksis vist seg at forventningene var overdrevet (tenk det!). Måten objektene knyttes sammen under lenkingen av et program skrevet i C++ innebærer at alle referanser ersattes med binære adresser, og at selv de minste endringer medfører kompilering og deretter lenking av hele programmet.
En annen ting er at de mulighetene du har til å utnytte innkjøpte klasser til bruk i egen utvikling. Ulike klasser kan komme i konflikt med hverandre i måten de utnytter felles ressurser (f.eks. skjermsystem og minneallokering), og dermed er mye av fordelene med oppdeling og modularisering brutt.
Man har med distribusjon sett for seg muligheten av å tilby "fysisk innkapsling" gjennom å lagre og behandle objektet i en tjenermaskin, på vegne av en klient et annet sted i nettverket. Man ser da for seg en sterkere grad av adskillelse mellom objektene, og at dette medfører større grad av uavhengighet mellom de ulike delprosjektene under programutviklingen og vedlikeholdet.
Man har derfor ønsket å tilby RPC-liknende teknologi tilpasset OO-miljøet. Da ønsker vi på tilsvarende måte å sende meldinger til objekter som befinner seg på en tjenermaskin i nettverket. Men i motsetning til RPC referer vi da til datavariabler (objekter) som befinner seg et annet sted i nettverket, og dette betyr at ikke bare kode blir lagret hos tjeneren, men også data, og at lagringen skjer på vegne av en bestemt klient. Dette betyr bl.a. at forholdet mellom klient og tjener befinner seg i en eller annen tilstand. At klienten og tjeneren er enige om hvilke objekter som er lagret hos tjeneren, og at tjeneren vet om hvilke objekter som tilhører hvem, slik at det kan ryddes opp etter krasjede klienter.
OO-programmering tilbyr dessuten at datatypene (klassene) inndeles i et hierarki, og at vi i et distribuert miljø kan skape avledede klasser som delvis skal benytte metodene som hører til denne klassen, delvis til "stamklassen".
Komponentene i CORBA
CORBA er et nøkkelord innenfor nettopp dette som vi nå snakker om. Ordet er et akronym for "Common Object Request Broker Architechture", og er et rammeverk av spesifikasjoner for produkter som ønsker å tilby distribuerte objekter.
CORBA er et resultat av et standardiseringsarbeid innenfor et konsortium som kalles Object Management Group. OMG ble dannet i 1989 med 8 deltagere. I dag har de mer enn 500 medlemmer og er et av verdens største programkonsortier.
Hovedkomponentene i CORBA er:
IDL - Interface Definition Language. Dette er et C++-lignende språk som angir den klassen som skal tilbys av en tjenermaskin. CORBA tilbyr sitt eget klassehierarki, og den klassen som spesifiseres av en IDL-tekst må ligge innenfor dette hierarkiet, dvs. være avledet av en CORBA-klasse. I tillegg til klassespesifikasjonen skal IDL-teksten angi hvilke metoder (meldinger) som skal brukes med denne klassen, og hvilke parametre og returverdier som skal brukes med de forskjellige. Basert på IDL-tekst vil IDL-kompilatoren generere kildeteksten til "Stub Procedure" i det ønskede programmeringsspråket.
ORB - Object Request Broker. Dette er ingen "komponent" i nettverket, men et sett av funksjoner og tjenester. Når en klient ønsker å lage et objekt som er "håndtert" gjennom CORBA, vil den benytte koden i "Stub Procedure" som er laget med IDL-kompilatoren. Stub Procedure vil gjennom ORB-mekanismene finne ut hvor i nettverket tjeneren for dette objektet befinner seg, og vil gjennom ORB også sende meldinger og parametre til dette objektet. ORB er altså den komponenten som under kjøringen megler mellom klient og tjener i det objekt-orienerte kjøremiljet. Legg merke til at det ikke er bestemt om ORB skal være et sett av biblioteksrutiner, en egen tjenerprosess eller tjenermaskin i nettverket.
PROXY - Også kalt IDL Stubs. Den koden som hos klienten opptrer "på vegne" av de objektene som lagres hos tjenerprosessen. Den mottar meldinger og paramerte fra klienten, og overfører dem til tjeneren gjennom en egen nettverksprotokoll. Den mottar også returmeldingene fra tjeneren og sender videre til klienten.
På tjenersiden kalles proxy for "IDL Skeleton". Dette er den koden som knyttes til tjenerens kode for implementasjon av objektet, og tar i mot meldinger og parametre fra nettverket, og på vegne av klienten sender meldinger til tjenerens programkode. Legg merke til at IDL Stubs (på klientsiden) ikke tar i mot andre meldinger enn dem den har bedt om, men at IDL Skeletons må ta imot meldinger "asynkront". For at det skal være et program tilstede som er lastet i minnet og klart til bruk for klienter trengs det en annen komponent: Object Adaptor.
OA - Object Adaptor. Dette er en komponent som på tjenersiden sørger for å initialisere tjenerkoden slik at IDL skeleton kan ta imot meldinger fra klienter. Den er ikke involvert i behandlingen av selve meldingene.
Interoperabilitet
Med disse mekanismene skal det altså for klienten være uten betydning om objektet er implementert lokalt eller hos en tjener. Den syntaktiske behandlingen, dvs. måten meldinger sendes til objektet på vil være den samme. Det vil likeledes være uten betydning hvilket programmeringsspråk objektet er programmert med. Det finnes binding fra CORBA til språkene C, C++ og Smalltalk, dvs. kode i disse tre språkene kan samarbeide gjennom CORBA-mekanismene. Og et objekt i en tjener kan naturligvis være sammensatt av objekter som igjen befinner seg i andre tjenere. Det nettverket som oppstår av forbundede objekter er altså ikke et stjernenettverk med klienten i midten og tjenerne i stjernearmene, men et nettverk med forgreninger fra tjener til tjener i et mange-til-mange forhold. En programkomponent som er tjener i én forbindelse kan altså være klient i en annen.
I dette nettverket må vi forutsette at ett CORBA-produkt skal snakke med et annet, f.eks. der historisk forskjellige CORBA-baserte produkter skal koples sammen. Tidlige CORBA-spesifikasjoner hadde ikke lagt tilstrekkelig vekt på dette aspektet, og hadde tillatt ulikheter i implementasjonen som kan gjøre slikt samarbeid vanskelig. Et standardiseringsarbeid som omfattet mer enn 500 firmaer (Open Management Group) resulterte altså i teknologi som ikke tillot samarbeid mellom produkter fra forskjellige produsenter!
I desember 1994 fikk vi derimot CORBA 2.0, som hadde lagt mer vekt på det de kaller "Inter-ORB communication". Mange hadde ønsket seg en obligatorisk støtte til OSF's "Distributed Computing Environment" (DCE), men det fikk de ikke. Forholdet mellom CORBA og DCE er derfor fortsatt av frivillighet: De som ønsker det kan benytte DCE's mekanismer for katalog- og overføringstjenester, andre kan finne på noe annet. Obligatorisk er derimot støtten til protokollen "General Inter-ORB Protocol" (GIOP), som mangler de navne- og sikkerhetstjenestene som tilbys i DCE. Mange oppfattet valget av GIOP som et taktisk trekk overfor Microsoft, som sammen med Digital og Candle Corp. baserer sin COM-teknologi (Common Object Model) på DCE.
Dette berører noe av kjernen i den kritikken som blir reist mot OMG og CORBA: At CORBA er laget av en komité med mye annet enn felles interesser. CORBA er ikke en strømlinjeformet teknologi som baserer seg på et entydig bilde av hvordan distribuerte objekter kan lages, men er så full av kompromisser og "hilsener" fra forskjellige konkurrerende leverandører at interoperabilitet i praksis blir vanskelig, og at produktene blir større dyrere og senere enn hva som ellers kunne ha vært tilfelle.
Tror vi på dette?
Et spørsmål som klart melder seg er om dette vil bli varig eller glemt teknologi. Vi ser hvordan teknologi fra de merkeligste kilder ta av som en brann, fordi den representerer det riktige ambisjonsnivå til rett tid. Det finnes mye teknologi som har feilet fordi den har vært "overspesifisert" eller "overambisiøs", f.eks. OSI-protokollene. Netscape, derimot, har vært et produkt som har tilbudt et riktig løsnings"nivå" på rette tidspunkt, og har derfor blitt enormt populært på kort tid.
Når en teknologi går rundt i årevis og ender opp som en "gammel jomfru", slik vi ser CORBA gjør (OMG ble dannet i 1989) er det grunn til å spørre om den noensinne vil ta av, eller om vi må vente på noe helt nytt. Vi kan gjerne tenke oss at en teknologi som ikke baserer seg på å slepe rundt på gammel programmeringsarv viser seg å bli vel så populær.
Vi har som mange andre undret oss over den enorme interessen rundt Sun's Java-teknologi, til tross for at den slett ikke tilbyr noen bakoverkompatibilitet eller interoperabilitet. Kanskje vi også på området rundt distribuerte objekter skal vente på at tiden blir modem for å akseptere helt ny teknologi?
Figurer:
