Johan.Sall.2535 Thomas.Wahlsten.1711 Distribuerade System HT 2002
Sammanfattning Vår uppgift har varit att skriva en rapport om CORBA, en av de tidigaste och mest använda arkitekturerna för distribuerade objekt. Rapporten tar upp allmänna delar om CORBA så som dess tillkomst, utformning av CORBA, användningsområden. Detta följs av en teknisk beskrivning av CORBA, vad är ORB, ORB i jämförelse med RPC, IDL:er, vilket protokoll används för kommunikation mellan ORB:ar osv. I rapporten finns även små kod-exempel för att belysa vissa elementära grunder med CORBA.
Innehållsförteckning 1. Introduktion... 4 1.1 Vad är CORBA?... 4 1.2 Vad är middleware?... 4 1.3 Användningsområden... 4 1.4 OMG (Object Management Group)... 5 2. Tekniska detaljer om CORBA... 5 2.1 Object Request Broker (ORB)... 5 2.2 Vad är skillnaden mot RPC?... 5 2.3 Transparens och kommunikation... 6 2.3.1. Följande mål har tagit hänsyn till vid utveckling av GIOP:... 7 2.4 Argument och marshalling... 7 2.5. Interface Definition Language (IDL)... 7 2.5.1. Erhålla objektreferens:... 8 2.5.2. Klientmodell för skapande av objekt:... 8 2.5.3. Exeptions:... 8 2.6 Statiskt eller dynamiskt metodanrop?... 8 2.6.1. CORBA Statiskt metodanrop... 9 2.6.1.1 Översikt av statiskt metodanrop... 10 2.6.2. CORBA Dynamiskt metodanrop... 11 3. Referenser... 12
1. Introduktion 1.1 Vad är CORBA? CORBA är en förkortning för Common Object Request Broker Architecture, framtaget av OMG (Object Management Group) för att kunna möta det behov som finns för att det enorma antal mjukvaror och hårdvaror som finns på marknaden skall kunna kommunicera sinsemellan. Tanken är alltså att CORBA ska möjliggöra kommunikation mellan olika applikationer över ett nätverk, oavsett programspråk och dataplattform. Med hjälp av CORBA kan metoder exekveras på en annan maskin, men även ren dataåtkomst möjliggörs, dvs. åtkomst av objekt över ett nätverk. CORBA är ett exempel på en middleware - en programvara som fogar samman andra programvaror - och fungerar som brygga mellan dessa. [OMG01] 1.2 Vad är middleware? Inom dataindustrin är middleware en generell beskrivning av all slags programmering som siktar till att limma samman eller medla mellan två separata och ofta redan existerande program. En vanlig tillämpning med middleware är att tillåta program skrivna för att accessa en viss databas att kunna få access även till andra databaser. Vanligtvis tillhandahåller middleware program meddelandetjänster så att olika applikationer kan kommunicera. Det systematiska sammanbindandet av olika applikationer, oftast genom användning av middleware, benämns som EAI(Enterprise Application Integration). Det skall påpekas att det naturligtvis krävs att gränssnittet mellan middleware och de komponenter som finns runt om den är tydligt specificerade för att det hela skall kunna fungera väl. 1.3 Användningsområden Möjligheterna med CORBA är nästan obegränsade, och det finns en uppsjö med exempel på tillämpningar som använder sig av CORBA. Några exempel är e-handelslösningar, webbservrar och fönsterhanteraren gnome, men CORBA är även populärt inom finansvärlden för banktjänster, aktiehandel m.m. Till exempel använder Handelsbanken CORBA tillsammans med sitt aktiesystem för att kontinuerligt hålla sig uppdaterade med de senaste aktiekurserna. CORBA lämnar möjligheterna öppna för framtida utbyggnader och plattformar. [OMG02]
1.4 OMG (Object Management Group) Object Management Group (OMG) grundades i april 1989 av elva företag, bestående av 3Com Corporation, American Airlines, Canon, Inc., Data General, Hewlett-Packard, Philips Telecommunications N.V., Sun Microsystems and Unisys Corporation. OMG:s huvudkontor finns i Needham, Massachussets i USA och mindre kontor i ett 10 tal länder runtom i världen. I oktober 1989 på började OMG sitt oberoende arbete som ett non-profit företag. Företaget uppstod i en tid när många mjukvarutillverkare såg ett enormt behov av att kunna kunna ta fram gemensamma specifikationer för samexistens mellan olika mjukvaror. OMG: s uppgift är alltså att vara ett oberoende organ som lägger upp och håller i specifikationerna för CORBA. Tack vare sitt målmedvetna utvecklingsarbete och det faktum att specifikation och implementation är åtskilda har gjort att OMG idag har över 1000 medlemmar världen över. [OMG01] 2. Tekniska detaljer om CORBA 2.1 Object Request Broker (ORB) ORB, Object Request Broker, är en distribuerad service som implementerar förfrågning till fjärrobjektet. ORB har till uppgift att lokalisera fjärrobjektet, skicka förfrågan till fjärrobjektet och invänta svar samt skicka svaret tillbaka till klienten. ORB implementerar lokaliserings transpararens, vilket innebär att samma förfrågningsmekanism används oberoende om objektet är lokaliserat lokalt eller som fjärrobjekt. ORB, erbjuder programmeraren stor flexibilitet såsom att fritt välja bästa lämpliga: Operationsystem, programspråk för varje komponent. Men viktigast av allt är att ORB möjliggör integration av existerande komponenter. Språkkopplingar finns definierade för alla populära programspråk. Specifikationen för detta definieras i IDL:en, Interface Definition Language. [Sun01] 2.2 Vad är skillnaden mot RPC?
RPC och ORB är ganska nära besläktade, men det finns några viktiga skillnader. Den stora skillnaden är att ORB är objektorienterat vilket RPC inte är. Med RPC anropar en specifik funktion medan man med ORB:en anropar en metod inom ett specifikt objekt. En av fördelarna med objektorientering är att man kan få olika objektklasser att uppträda annorlunda med samma metodanrop genom så kallads polymorfism. Eftersom varje objekt har hand om sina egna privata data, så blir metoden implementerad på just dessa specifika data. I ORB ligger objektet instansierat hos servern och klienten har en referens till objektet, medan i RPC ligger data hos klienten och servern använder sig bara av inskickade argument. CORBA erbjuder objektabstraktioner och dynamisk invokation, vilket inte RPC erbjuder. Dessutom kan man ärva interface i CORBA. 2.3 Transparens och kommunikation Som vi tidigare nämnt så implementerar ORB lokaliserings transpararens. Vilket betyder att exekveringen är den samma om objektet exekveras lokalt på användarens maskin eller på en fjärrmaskin. Som användare märker man ingen skillnad förutom att det eventuellt tar längre tid att exekvera fjärrobjektet. Transpararensen kan man uppnå genom att man implementerar ett interface mellan ORB:n och klienten/servern, ett så kallat stubbe och skelett. Client Object Client Object Stub Skel Stub Skel ORB 1 IIOP ORB 2 Protkoll ORB till ORB kommunikation Protokoll för att kommunicera och sköta felhantering sker generellt med GIOP, General Inter-ORB Protocol. Protokollet har åtta definierade meddelanden: Request, Reply, CancelRequest, LocateRequest, LocateReply, CloseConnection, MessageError, Fragment. GIOP kan mappas för till de flesta anslutningsorienterade transportprotokoll bara de följer ett mindre antal förutsättningar. Specifiering av GIOP som körs direkt över TCP/IP kallas IIOP, Internet Inter-ORB Protocol.
2.3.1. Följande mål har tagit hänsyn till vid utveckling av GIOP: Största möjliga användbarhet GIOP och IIOP är baserat på TCP/IP och definierar ett minimalt extra protokollager som är nödvändiga för att överföra CORBA förfrågningar mellan ORB:er. Enkelhet Målsättningen är att GIOP ska vara så enkelt som möjligt, vilket är bästa målet för att säkerställa en mängd olika oberoende och kompatibla implementationer. Skalbarhet - GIOP och IIOP ska stödja ORB:er och nätverk med bryggade ORB:er, till storleken av dagens och framtidens Internet. Låg kostnad Att lägga till stöd för GIOP och IIOP till en existerande eller ny ORB design ska kräva små tekniska investeringar. Generellitet Medan IIOP är definierad för TCP/IP, Så är GIOP:s designat för att användas med alla transport lager som uppfyller ett minimalt antal förutsättningar. Arkitektisk neutralitet GIOP specifikationen gör ett minimalt antal antaganden om hur arkitekturen måste vara uppbyggd för att det ska fungera. [Sun01], [STD01], [OMG01] 2.4 Argument och marshalling Vid en förfrågan så läses först argumenten för förfrågan in vid stubben. Sedan anpassas de där enligt CDR, Common Data Representation, och processen kallas marshalling. Efter detta skickas förfrågan vidare till fjärrobjektets skelett. I skelettet sker en återanpassning, så kallad unmarshalling, av argumenten så de passar objektet. Klienten och objektet kan ha olika programspråk och man är vidare fri att utveckla klient och objekt i de flesta programspråk. Följande argument stöds av CORBA: Grundläggande datatyper som long, short, string, float osv., konstruerade datatyper som struct, union, enum, sequence, objektreferenser (objekt-id), any-typen, som är ett dynamiskt typat värde. Man kan t ex inte använda sig av pekare som argument! 2.5. Interface Definition Language (IDL) CORBA bygger på ett väl definierat gränssnitt som komponenterna måste följa. Detta görs med IDL, Interface Definition Language. Ett objektinterface indikerar vilka operationer som objektet stödjer, men inte hur de implementeras. Implementationen av CORBA objekt stöds av objektorienterade språk såsom Java eller C++. IDL interfacen är programneutrala. IDL definierar språkbindningar till många olika programspråk. Detta innebär att man kan välja lämplikt språk för objektet samt har valfrihet att utveckla klienten i det mest lämpliga språket. OMG har standardiserat bindningar till C, C++, Java, Ada, COBOL, Smalltalk, Objetive C och Lisp.
2.5.1. Erhålla objektreferens: Det finns som kanske bekant tre olika sätt att få ett stycke kod att erhålla objektreferens: Det kan bli sänt till sig som en parameter Det kan returneras som resultat från en förfrågan. Det kan erhållas genom konvertering av en sträng till en objektreferens. 2.5.2. Klientmodell för skapande av objekt: Ibland vill man kanske ge det distribuerade objektsystemet möjlighet att skapa objekt. Detta kan göras genom att man definierar en factory för objektet. Factories är inget annat än distribuerade objekt som skapar andra distribuerade objekt. Det finns inget standard interface för en factory. Nedan ges ett exempel på hur det kan gå till. interface StockFactory { Stock create_stock( in string symbol, in string description ); }; För att skapa ett objekt av typen Stock så gör klienten en förfrågan på StockFactory. [Sun01] 2.5.3. Exeptions: Undantag, exeptions, i CORBA är mycket likt undantag i Java. När man använder undantag i CORBA så måste man använda try och catch precis som i Java. Det finns två typer av CORBA undantag, system- och användarundantag. Exempel: StockFactory factory =... Stock thestock =... try { thestock = factory.create( "GII", "Global Industries Inc."); } catch (Throwable e) { } [Sun01] 2.6 Statiskt eller dynamiskt metodanrop? Med CORBA kan man göra statiskt eller dynamiska metodanrop. Fördelen med det statiska är att det är enkelt, typsäkert och effektivt. Det dynamiska är då av naturliga skäl mer komplicerat och mindre typsäkert. Fördelen är dock att man kan anropa operationer på objekt som inte är kända vid kompileringen.
2.6.1. CORBA Statiskt metodanrop 1. Definiera serverinterfacen i Interface Definition Language (IDL). IDL-filen innehåller de operationer på objekten som finns tillgängliga för potentiella klienter, och hur de kan anropas. IDL-definitionen innehåller typer för objekt, deras attribut, vilka metoder de exporterar och metodparametrar med tillhörande typer. 2. Kör IDL-filen genom en precompiler. Detta skapar språkskelett för implementation av server klasser. 3. Lägg till impementationskoden, som skapades vid förkompileringen, till skeletten. 4. Kompilera koden. Detta görs med den vanliga kompilatorn. CORBA kompilatorn kan generera fyra typer av filer. Import filer beskriver objekt för Interface Repository. Klientstubbar Anropas av klientprogrammet. Serverstubbar Anropar metoder på servern. Kod som implementerar serverklasserna. 5. Bind interfacedefinitionerna till Interface Repository. 6. Instansiera objekten på servern. Object Adapter kan instansiera serverobjekt som tjänstgör vid metodanrop på fjärrobjekt. 7. Registrera run-time-objekten hos Implementation Repository. Object Adapter registrerar objektreferens och vilken objekttyp som den instansierar på servern. Registreringen sker i Interface Repository. 8. Implementera klientkoden. Klienten lägger till CORBA-anrop, som är språkberoende, i koden. Stubbarna tar hand om marshalling och unmarshalling. 9. Kompilera klientkoden. Detta görs med den vanliga kompilatorn. [SMI01]
2.6.1.1 Översikt av statiskt metodanrop Figur 1: En översikt av statiskt metodanrop, jmf bilden med den steg för steg beskrivning som ges i kapitel 2.6.1.
2.6.2. CORBA Dynamiskt metodanrop Med Dynamic Skeleton Interface kan man göra dynamiska metodanrop. Interfacet finns istället för stubben men utåt sett så märks ingen skillnad. 1. Erhåll metodbeskrivning från Interface Repository. CORBA anrop lokaliserar och beskriver objekt i Interface Repository. 2. Skapa en argumentationslista. Datastruktur för att skicka parametrar (NamedValueList). 3. Skapa ett tomt requestobjekt. Specificerar objektreferens, metodnamn och argumentationslista. 4. Anropa requestobjektet. 5. Frigör requestobjektet. [DMI01]
3. Referenser [OMG01] OMG: Hemsida för CORBA http://www.corba.org/ [OMG02] En översikt av CORBA http://www.infosys.tuwien.ac.at/research/corba/omg/arch2.htm#446864 [OMG03] OMG: OMG's CORBA FAQ http://www.omg.org/gettingstarted/corbafaq.htm [Sun01] Kort om Corba på Suns hemsida http://developer.java.sun.com/developer/onlinetraining/corba/corba.html [STD01] CORBA specification http://cgi.omg.org/docs/formal/99-10-07.pdf [SMI01] Statiskt metodanrop, steg för steg http://ei.cs.vt.edu/~wwwbtb/fall.96/presentations/corba/tsld024.htm http://oopsla.snu.ac.kr/corba/tp_note/corba-chap2.ppt [DMI01] Dynamiskt metodanrop, steg för steg http://ei.cs.vt.edu/~wwwbtb/fall.96/presentations/corba/tsld027.htm http://oopsla.snu.ac.kr/corba/tp_note/corba-chap2.ppt