Aufbau Integrierter Informationssysteme Verteilte Objektsysteme am Beispiel von CORBA Falk Ritschel, Stefan Springer, Falko Steponat Martin-Luther-Universität Halle-Wittenberg Informatikseminar - Halle - 22.01.2002 Gliederung 1. Einleitung 2. CORBA – Architektur (OMG) 3. Kommunikation zwischen den Objekten 4. CORBA in der Praxis 6. Fazit - Ausblick Verteilte Objektsysteme am Beispiel von CORBA 2 Gliederung 1. Einleitung Motivation Grundbegriffe OMG Einführung 2. CORBA – Architektur (OMG) 3. Kommunikation zwischen den Objekten 4. CORBA in der Praxis 6. Fazit - Ausblick Verteilte Objektsysteme am Beispiel von CORBA 3 1. Motivation • Softwareentwicklung in den letzten 15 Jahren Einzug des Paradigmas der Objektorientierung Zunehmende Vernetzung • Aufteilung von Software in Komponenten (Objekte) •Client-Server, Multi-Tier, Internet •Anwendungen verteilt über Rechner und Architekturen • Austauschbarkeit (wohldefinierte •Anwendungen kommunizieren über Schnittstellen ) und Wiederverwendbarkeit Middleware •bessere Administrierbarkeit, • Schnellere Implementierung von Software Skalierbarkeit, Ausfallsicherheit, Investitionsschutz •Zusammenarbeit heterogener Plattformen 1. 2. 3. 4. 5. CORBA 4 1. Motivation Logische Konsequenz: Vereinigung der Konzepte: Konkretisierung diesesin Referenzmodells: Funktionalität bereitstellen Form von Komponenten Verteilung der Komponenten auf beliebige Rechner ImplementierungCORBA in unterschiedlichen Sprachen (Common Object Request Broker Architekture) Standardarchitektur für verteilte Objektsysteme OMG (Object Management Group) Referenzmodell für verteilte Objektsysteme OMA (Object Management Architecture) 1. 2. 3. 4. 5. CORBA 5 1. Motivation Vorteile von verteilten, komponentenbasierten Anwendungen: Fehlerbehebung durch Austausch einer Komponente Verteilung der Arbeitslast auf mehrere Systeme Vorteile der Objektorientierung auch über Prozeß- und Maschinengrenzen hinaus Wiederverwendbarkeit von Komponenten optimale Strukturierung 1. 2. 3. 4. 5. CORBA 6 2. Grundbegriffe • Verteilte Anwendungen – Bestandteile (Objekte, Komponenten etc.) über mehrere Prozesse u./o. Computer verteilt • Heterogene Anwendungen – Bestandteile befinden sich auf Computern mit verschiedener Hardware, BS oder Programmiersprache • übliche OOP-Konzepte – Kapselung • Schnittstelle und Implementierung grundsätzlich getrennt • Schnittstelle wird sprachunabhängig in IDL (Interface Definition Language) beschrieben – Vererbung – Polymorphie 1. 2. 3. 4. 5. CORBA 7 3. Object Managemant Group • Die Object Management Group: 1989 als Industriekonsortium gegründet von: 3COM, American Airlines, Canon, Data General, Hewlett Packard, Philips Telecommunications, Sun Microsystems und Unisys Ziel: Verbreitung von OO-Technik und verteilter Verarbeitung Weg: Erarbeiten und Durchsetzen von Industriestandards Heute weit über 800 Mitglieder! weitaus größtes Industriekonsortium der IT-Branche 1. 2. 3. 4. 5. CORBA 8 3. Object Managemant Group Mitglieder: – viele Anbieter und Entwickler von Systemen – Forschungsinstitutionen – reine Anwender objektorientierter Technologien – Populärstes Nichtmitglied war jahrelang die Firma Microsoft • Distributed Component Object Model (DCOM) - Standard als Konkurrenz für CORBA • inzwischen auch passives Mitglied der OMG – Bekannte Produkte: CORBA und UML 1. 2. 3. 4. 5. CORBA 9 3. Object Managemant Group • Die OMG ist kein Gremium zur Standardisierung und kann somit nicht mit Institutionen wie dem “American National Standards Institute” (ANSI) ANSI oder der “International Standards Organisation” (ISO) ISO verglichen werden. Die OMG versteht sich als Organisation, die den Mitgliedern die Diskussion kontroverser Ansichten, den Austausch Austausch von von Ideen, Ideen die Suche nach einem Konsens und einer Übereinkunft bezüglich der Verwendung bestimmter Architekturen und Technologien erlaubt. 1. 2. 3. 4. 5. CORBA 10 4. Einführung Anforderungen an einen Komponentenstandard in heterogenen Netzen Programmiersprachenunabhängigkeit Plattformunabhängigkeit DerVerschiedene Client und das Der Client und das Serverobjekt Der Client muss nicht Instanz zwischen Client Datendarstellung Objekte verschiedener Serverobjekt können können auf durch wo das und wissen, Serverobjekt passt in verschiedenen Hersteller können Programmiersprache, verschiedenen Serverobjekt läuft (Lokal, unterschiedliche Programmiersprache zusammenarbeiten Hardware undan. Betriebssystemen LAN, WAN, Internet). Datenrepräsentation n geschrieben sein. Compiler vorgegeben laufen. Darstellungsunabhängigkeit Ortsunabhängigkeit Herstellerunabhängigkeit (nicht proprietär) 1. 2. 3. 4. 5. CORBA 11 4. Einführung Application Objects Geschichte von CORBA Die Geschichte von CORBA ist die Geschichte der OMG: 1989: Gründung der OMG Anfang 1990: Erste Ergebnisse: Object Request Broker Object Services • Vorstellung des Object Management Architecture (OMA) Referenzmodells • Wichtigster Bestandteil: Object Request Broker (ORB) Common Facilities Anfang 1991: Erste CORBA-Version •Genauere Spezifikation der ORB Komponente der OMA •Problem in der Praxis: Mangelnde Interoperabilität 1. 2. 3. 4. 5. CORBA 12 4. Einführung Geschichte von CORBA 1992: OMA 2.0 1995: CORBA 2.0 • Interoperabilität zwischen ORBs verschiedener Hersteller Ende 1995: Spezifikation der erweiterten Dienste Anfang 2001: CORBA 3.0 • Quality of Service, Unterstützung von Firewalls • „Spezielle“ CORBAs: Echtzeitanwendungen, Microcontroller, ... 1. 2. 3. 4. 5. CORBA 13 Gliederung 1. Einleitung 2. CORBA - Architektur (OMG) Services Facilities Domain Objekte Applikation Objekte 3. Kommunikation zwischen Objekten 4. CORBA in der Praxis 5. Zusammenfassung - Fazit - Ausblick CORBA 14 Object Management Architecture Gemeinsame Einrichtungen (CORBA Facilities) Domänenschnittstellen CORBA – Anwendungen Common Object Request Broker Architecture Objektdienste (CORBA Services) 1. 2. 3. 4. 5. CORBA 16 1. CORBA Services Weiten die Kernfunktionen von CORBA aus. Objekte erzeugen • Lifecycle • Persistence • Transaction 1. 2. Zugriff auf Objekte steuern • Naming • Trader • Query • Events 3. 5. 4. Beziehungen zwischen Objekten unterhalten • Security • Licensing • Time CORBA 17 1. CORBA Services Naming Service Objekt A = damit können Objekte in einer verteilten Umgebung allein anhand ihres Namens gefunden werden Registrierung Anfrage Adressierung im Internet: IP-Adresse Host-Rechner + TCP/UDP-Portnummer des Prozesses 1. 2. 3. 4. Adresse 5. Objekt B CORBA 18 1. CORBA Services Naming Service = damit können Objekte in einer verteilten Umgebung allein anhand ihres Namens gefunden werden Ohne diesen Service wäre die Ortstransparenz nicht gegeben. jedes Objekt, dessen Methoden aufgerufen werden sollen, müsste beim Aufrufer in allen technischen Details bekannt sein 1. 2. 3. 4. 5. CORBA 19 2. CORBA Facilities Gruppen von Komponenten die zusätzliche Funktionen bereitstellen. Funktionen • sind für anwendungsspezifische Aufgaben wichtig • z.B. Behandlung des Arbeitsablauf und Benutzeroberflächen • zusätzliche Unterstützung der Anwendungsentwicklung durch Bereitstellung von Funktionen auf höherer Ebene (E-Mail) 1. 2. 3. 4. 5. CORBA 20 2. CORBA Facilities Gruppen von Komponenten die zusätzliche Funktionen bereitstellen. Horizontal Facilities Vertical Market Facilities • User Interface • Internet Management • Information • Computer Integrated • Information Modelling Manufacturing • Verteilte Simulation • Öl und Gas Industrie 1. 2. 3. 4. • Systems Management • Finanzwelt • Task Management • Applikations-Entwicklung • Telekommunikation • Gesundheitseinrichtungen 5. CORBA 21 3. Domain Objekte Stellen Funktionen für die Entwicklung von Anwendungen in Speziellen Bereichen bereit. • Medizin, Telekommunikation, Finanzwesen Bieten Lösungen für immer wiederkehrende Problemstellungen aus den jeweiligen Bereichen, sind aber zu spezifisch um sie den CORBA Facilities zuzuordnen. 1. 2. 3. 4. 5. CORBA 22 4. Applikation Objekte Gruppen von Objekten oder Komponenten die speziell für bestimmte Anwendungen entwickelt worden. = nutzen den den ORB und die weiteren Dienste der CORBA-Architektur um verteilungstransparent miteinander zu kommunizieren Verschiedene Anwendungsprogrammierer erstellen 1. 2. Objekte 3. 4. 5. Verschiedene Hersteller verkaufen CORBA 23 Gliederung 1. Einleitung 2. CORBA – Architektur (OMG) 3. Kommunikation zwischen den Objekten RPC ORB IDL Kommunikation der Objekte 4. CORBA in der Praxis 6. Fazit - Ausblick Verteilte Objektsysteme am Beispiel von CORBA 24 Gliederung • Kommunikation zwischen den Objekten • RPC – Remote Procedure Call • ORB – Object Request Broker • • 1. • Komponenten des ORB • Anbieter IDL Interface Definition Language • Einführung • Sprachumfang • Vorteile einer eigenen Beschreibungssprache Kommunikation der Objekte 2. 3. 4. 5. CORBA 25 1. RPC – Remote Procedure Call • eine verbreitete Abstraktion für die Programmiersprache C • ermöglicht den Aufruf einer Prozedur auf einem anderen System • Aufrufschnittstelle der Prozedur ist unabhängig von einer Programmiersprache • Schnittstelle wird mit der IDL – Interface Definition Language beschrieben • 1. Prozeduraufruf Transparent zu gestalten 2. 3. 4. 5. CORBA 26 1. RPC – Remote Procedure Call Client Client Stub Network Transport Portmapper Server Stub Server 1 2 3 4 5,6 7 1. 2. 3. 4. 5. CORBA 27 2. ORB – Objekt Request Broker • zentrale Komponente der CORBA Architektur • verteilte Objekte transparent miteinander kommunizieren zu lassen • Server Objekt finden • Parameter übertragen • Ergebnis des Methodenaufrufs zurückliefern • ORBs müssen auf dem Client und dem Server laufen • Kommunikation zwischen den ORBs • GIIOP • IIOP 1. 2. 3. 4. 5. CORBA 28 2. ORB – Object Request Broker Dynamic Invocation Interface (DII) Server IDLDynamische Server- Skelettskelett schnittstelle IDLClientstub ORBSchnittstelle ORB – Kern 1. 2. ORBSchnittstelle IIOP/GIOP 3. 4. 5. Objektadapter Implement. Repository. Interface Repository. Client ORB - Kern CORBA 29 2. ORB – Object Request Broker IDL – Clientstub Dynamic Invocationvom Interface (DII) und Interface Repository (IFR) • wird automatisch IDL – Compiler erzeugt ••stellt die Verbindung zwischen d.h. Client und ORB her dynamischer Methodenaufruf Schnittstellen sind nicht bekannt ORB - Schnittstelle ••verpacken Methodenparameter in ein über das Netzwerk eigentlicheder Basisschnittstelle zum ORB • stellt eine Sammlung von Operationen zur Verfügung, die zur transportierbares Format • Interface Repository enthält Schnittstelleninformationen Realisierung von Clients notwendig sind • statischer Methodenaufruf d.h. Schnittstellen sindRückgabewert bekannt • Namen und Parameter (Anzahl, Datentyp), der • Zugriff auf die ORB – Schnittstelle auch für den Server möglich • normale Anwendungsprogramme Methoden • Operationen: • Service Programme und Utilities •Object_to_string(), string_to_object() • create_list(), create_operation_list() 1. 2. 3. 4. 5. CORBA 30 2. ORB – Object Request Broker IDL – Serverskelette Dynamic Skeleton Interface (DSI) • wird automatisch vom IDL – Compiler erzeugt ORB – Schnittstelle und Implementation Repository Gegenstück zumzum Dynamic Invocation Interface • •stellt Verbindung Objektadapter und Serverobjekt her Object Adapter •eingehende ORB – die Schnittstelle Analogdynamisch zur Client beantwortet Seite Anfragenist können werden d.h. ohne • •entpackt Methodenparameter von OMGalle wird ein Basic Object Adapter (BOA) spezifiziert • •verwaltet Server Objekte Spezifizierung • IDL ruft die Methoden im Serverobjekt auf •wird ist Verbindungsglied zwischen ORB und Serverobjekt genutzt wenn noch keine Instanz eines Server Objektes • •nutzt die Informationen die vomkorrekte DII kommen • Registrierung von Objektimplementierungen (Server) existiert • Server- Aktivierung und – Deaktivierung • Erzeugen von Objektreferenzen für Implementierungen • Authentisierung und Zugriffskontrolle • verantwortlich für die persistente Gültigkeit von Objektreferenzen 1. 2. 3. 4. 5. CORBA 31 2. ORB – Object Request Broker ORB - Kern GIOP – General Inter ORB Protocol • ist verantwortlich für die Kommunikation IIOP – Internet Inter ORB Protocol basiert aufdie dem Pyrotechnic Longitudinal ORB Protocol • •beinhaltet gesamte Infrastruktur basiert auf dem GIOP Kommunikation • •ist für zu jede CORBA •Basis Objekte identifizieren und zu lokalisieren Kommunikation inzuTCP/IP Netzwerke • •existiert seit CORBA 2.0 • Verbindungen verwalten ORBs müssen IIOP unterstützen um CORBA konform zu sein • •ist •netzwerkneutral Daten zu übermitteln 1. 2. 3. 4. 5. CORBA 32 2. ORB – Object Request Broker ORB - Anbieter MICO http://www.mico.org NEO und Joe: Sun Microsystems http://www.sun.com/sunsoft/neo ORBacus: Object-Oriented Concepts, Inc http://www.orbacus.com Orbix: IONA http://www.iona.com SOM: IBM http://www.software.ibm.com/objects/ somobjects VisiBroker: Visigenic 1. 2. http://www.visigenic.com/prod/ 3. 4. 5. CORBA 33 3. IDL – Interface Definition Language IDL – Interface Definition Language IDL – Compiler • ist die genormte Basis zur programmiersprachenunabhängigen C IDL – Schnittstellenbeschreibung C •CÜbersetzungvon der Beschreibung Objektschnittstellen Skeleton Stub C • Schnittstelle = alle C++ eines Objektes C++ exportierten Attribute und Methoden C++ IDLSyntax - Datei • orientiert sich an der C++ Skeleton Java Java • wichtiger Bestandteil ist der IDL- Compiler Java Skeleton Smaltalk Stub IDL - Compiler IDL - Stub ADA COBOL 1. 2. Server Smaltalk ORB Stub Client Stub Smaltalk Skeleton C++ Java Smaltalk IDL - Skeleton ADA Stub ADA Skeleton ADA COBOL Stub COBOL Skeleton COBOL 3. 4. 5. CORBA 34 3. IDL – Interface Definition Language Datentyp Beschreibung Java Mapping (Wert) C++ Mapping (Wert) Short Long long long unsigned short unsigned long unsigned long long Float double long double Char Wchar boolean Octet string wstring Any 16 bit Integer 32 bit Integer 64 bit Integer 16 bit vorzeichenlos 32 bit vorzeichenlos 64 bit vorzeichenlos 16 bit IEEE Gleitkomma 32 bit IEEE Gleitkomma 64 bit IEEE Gleitkomma 8 bit Zeichen 16 bit Zeichen (Unicode) TRUE oder FALSE einzelnes Byte Zeichenkette Zeichenkette (Unicode) Container für einen beliebigen Datentyp short int long short int long float double double char char boolean byte java.lang.String java.lang.String ? CORBA::Short CORBA::Long CORBA::LongLong CORBA::UShort CORBA::ULong CORBA::ULongLong CORBA::Float CORBA::Double CORBA::LongDouble CORBA::Char CORBA::WChar CORBA::Boolean CORBA::Octet CORBA::String CORBA::WString CORBA::Any 1. 2. 3. 4. 5. CORBA 35 3. IDL – Interface Definition Language Bezeichner Module • Zulässig sind beliebig lange Zeichenketten Interfaces • erzeugen einen neuen Namensraum, um Namenskonflikte zu vermeiden • nicht identisch zu einem IDL – Schlüsselwort Operationen deklariert diemit Daten und Operationen eines Objektes • •vergleichbar einem Packages bei Java • beginnt mit einem Buchstaben Attribute •entspricht eine Aktion die an einem<Modulname> Objekt durchgeführt einer bei Java oderwird C++ • •Schlüsselwort ist Klassendefinition module • kann Buchstaben, Ziffern und Unterstriche enthalten •entspricht Attribute sind vergleichbar mit nicht Variablen einer Elementefunktion beiimplementiert C++ oder einer Methode bei Java • •Attribute und Methoden werden • ist innerhalb eines Namensraum eindeutig •Rückgabetyp, nach demistcompilieren existieren get und set Methoden Identifizierer • •Vererbung möglich •Null optionales Schlüsselwort readonly oder mehrere Parameter (in, out, inout) • •Schlüsselwort ist interface <Interfacename> Schlüsselwort: readonly attribute <Attributsname> • •Optionales raisesSchlüsslewort fürDatentyp Exceptions • Schlüsselwort ist Rückgabewert Operationsname <Parameter> raises 1. 2. 3. 4. 5. CORBA 36 3. IDL – Interface Definition Language module Bank1 { // Deklaration einer eigenen Exception exception BankFehler { string info; }; interface IKonto1 { readonly attribute long nummer; double einzahlen (in double betrag) raises (BankFehler); }; // IGiroKonto erbt von IKonto1 interface IGiroKonto : IKonto1 { double leseKreditLimit(); }; interface ISparKonto : IKonto1 { double leseZinssatz(); }; // IGiroKonto erbt von ISparKonto und IGiroKonto interface IGiroSparKonto : ISparKonto, IGiroKonto { }; }; 1. 2. 3. 4. 5. CORBA 37 3. IDL – Interface Definition Language • Vorteile einer eigenen Beschreibungssprache • maschinelle Weiterverarbeitung • unabhängig von Programmiersprachen • Isolierung Systemspezifischer Eigenschaften 1. 2. 3. 4. 5. CORBA 38 4. Kommunikation der Objekte Client X ruft Methode M von Y auf Objekt Y Methode M Object Request Broker (Core) 1. 2. 3. 4. 5. CORBA 39 4. Kommunikation der Objekte Client Anwendung Server Anwendung Auspacken und Aufrufen Aufruf IDL - Stub Aktivieren IDL - Skeleton Weiterleiten an Schnittstelle Parameter einpacken und weiterleiten Objektadapter Transport über den ORB Implementation Repository Ermitteln der Implementierung Object Request Broker 1. 2. 3. 4. 5. CORBA 40 Gliederung 1. Einleitung 2. Konzeptionelle Architekturen 3. Wege zu integrierten Datenbanksystemen 4. CORBA in der Praxis Vorgehensmodell Beispielanwendung 5. Zusammenfassung - Fazit - Ausblick Verteilte Objektsysteme am Beispiel von CORBA 41 Gliederung • CORBA in der Praxis • Vorgehensmodell • Beispielanwendung • IDL - Dokumente • IDL – Stub, IDL – Client • Java Server • Java Client 1. 2. 3. 4. 5. CORBA 42 Kundenauftrag Problemanalyse uns Systemdesign Entwicklung der IDL- Beschreibung IDLDokumente Client Implemt. IDLStubs IDLSkeleton Java Compiler Server Implemen. C++ Compiler Kommunikation Client Server 2. Beispielanwendung IDL - Datei // Keine Parameterübergabe module Beispiel01 { interface Hello { // aber einen String als Returnwert String sagHallo(); }; }; 1. 2. 3. 4. 5. CORBA 44 2. Beispielanwendung Java - Files • Hello.java • _HelloStub.java (der Clientstub) • _HelloImplBase.java (das Server - Skeleton) • HelloHelper.java (einer Helper Klasse) • HelloHolder.java (eine Holder Klasse) 1. 2. 3. 4. 5. CORBA 45 2. Beispielanwendung Java - Interface //Package Definition package Beispiel01; //Interface Definition public interface Hello extends org.omg.CORBA.Object, org.omg.CORBA.portable.IDLEntity{ //Metoden Definition String sagHallo(); } 1. 2. 3. 4. 5. CORBA 46 //Package Definition package Beispiel01; //Import Anweisungen import org.omg.CosNaming.*; import org.omg.CosNaming.NamingContextPackage.*; import org.omg.Corba.*; import java.lang.*; //Class Definition public class HelloServer{ //Metoden Definition public static void main(String[] args){ try{ CORBA – Server - Objekt //Initialisierung des ORB anmelden ORB orb = ORB.init(args,null); HelloImpl hi = new helloImpl(); orb.connect(hi); org.omg.CORBA.Object objRef = orb.resolve_initial_references(“NamingService“;) NamingContext ncRef = NamingContextHelper.narrow(ObjRef); NameComponent nc = new NameComponent(“Hello“, ““) NameComponent path[] = {nc}; Interaktion mit ncRef.rebind (path, hi;) dem Name Server Object sync = new Object(); NamingContext vorbereiten synchronized (sync) Objekt den { richtigen sync.wait(); } Anbindung am Datentypen }//Ende try Name Server zuweisen catch(exception e){ (Objekte, Name) System.out.println(“Fehler“); e.exceptionStackTrace(); } }//Ende main() } 2. Beispielanwendung Java - Server //Die Methode die der Client aufruft public String sagHallo(){ System.out.println(“HelloImpl: sagHallo: return Hallo“); return Hallo; } 1. 2. 3. 4. 5. CORBA 48 Java - Client //Package Definition package Beispiel01; //Import Anweisungen import org.omg.CosNaming.*; import org.omg.CosNaming.NamingContextPackage.*; import org.omg.Corba.*; import java.lang.*; //Class Definition public class HelloClient{ //Globale Variable static Hello hi = null; //Metoden Definition public static void main(String[] args){ try{ //Initialisierung des ORB ORB orb = ORB.init(args,null); org.omg.CORBA.Object objRef = orb.resolve_initial_references(“NamingService“;) NamingContext ncRef = NamingContextHelper.narrow(ObjRef); NameComponent nc = new NameComponent(“Hello“, ““) NameComponent path[] = {nc}; org.omg.CORBA.Object o = ncRef.resolve((path); hi = HelloHelper.narrow(o); }//Ende try catch(exception e){ System.out.println(“Fehler“); e.exceptionStackTrace(); Objektreferenz } Aufruf der Server //Rufe Methode am Server auf vom Name Server System.out.println(hi.sagHallo) Methode gewonnen }//Ende main() }//Ende class HelloClient NamingContext Objekt den richtigen Datentypen zuweisen Gliederung 1. Einleitung 2. CORBA – Architektur (OMG) 3. Wege zu integrierten Datenbanksystemen 4. CORBA in der Praxis 5. Zusammenfassung - Fazit - Ausblick Vorteile - Nachteile Ausblick Zusammenfassung Verteilte Objektsysteme am Beispiel von CORBA 50 1. Vorteile und Nachteile – Vorteile • Ist vergleichsweise einfach • Die wichtigsten Sprachen können eingesetzt werden • Transparenz (Ort, Verteilung) • Statische und dynamische Aufrufe • Unabhängig von einer Programmiersprache • Vordefinierte Dienste • Trennung von Schnittstelle und Implementierung •Nachteile • Geringe Performance, insbesondere auf lokalem Rechner • Interoperabilität verschiedener ORBs in der Praxis nicht sicher gewährleistet • Geringe Bedeutung unter MS Windows 1. 2. 3. 4. 5. CORBA 51 2. Ausblick – durch neue Komponentenmodelle in die Defensive gedrängt • Enterprise Java Beans (EJB) des J2EE Frameworks • COM+ des .NET Framework • Web – Services (SOAP, WDSL, XML) – Ziel Brücken zwischen CORBA und neuen Technologien 1. 2. 3. 4. 5. CORBA 52 3. Zusammenfassung – OMG – Geschichte CORBA – CORBA Komponenten – ORB - Objekt Request Broker – IDL - Interface Definition Language – CORBA Kommunikation 1. 2. 3. 4. 5. CORBA 53