Einführung in CORBA Fachseminar Informations- und Kommunikationssysteme SS99 MartinVogt, IIIC, 8. Semester.

Präsentation zum Thema: "Einführung in CORBA Fachseminar Informations- und Kommunikationssysteme SS99 MartinVogt, IIIC, 8. Semester."—  Präsentation transkript:

1 Einführung in CORBA Fachseminar Informations- und Kommunikationssysteme SS99 MartinVogt, IIIC, 8. Semester

2 Martin VogtCORBA2 Object Management Group (OMG) Standartisierungsgremium. Im Mai 1989 durch acht Firmen gegründet. Heute: über 800 Mitglieder. –Ausnahme: Microsoft mit Konkurrenzprodukt DCOM. Aufgabe: Sammeln und Aufarbeiten von technologischem Know-how für Entwicklung verteilter, aus Objekten aufgebauter Software. 1991: CORBA 1.0 –IDL, Language-Mapping und Schnittstellen zum ORB. 1994: CORBA 2.0 –IIOP: Zusammenspiel zwischen ORBs verschiedener Hersteller. 1998: CORBA 3.0 –Java und Internet-Integration. –QoS Managment.

3 Martin VogtCORBA3 Interface Definition Language (IDL) Mittel zur Beschreibung der Interfaces: –Betriebssystem- und sprachunabhängig. –Spezifiziert Parameter, Rückgabewerte. An C++ angelehnt: –Preprozessing: include, define –Kommentare: /* */, // –Basistypen: boolean, char, double, float, Object, string, short,... –Strukturen: struct, union, enum, array,... –Exceptions –Vererbung –keine Pointer, kein Überladen von Operationen,... Enthält keine Implementierungsdetails. Language Mapping: IDL-Konstrukten durch Precompiler äquivalente Konstrukte einer Programmiersprache zuordnen.

4 Martin VogtCORBA4 IDL: Ein Beispiel module Bank { interface Account { exception NoFunds {}; exception NonZeroBalance {}; void Deposit(in long amount); void Withdraw(in long amount) raises(NoFunds); long GetBalance(); void Close() raises(NonZeroBalance); }; },

5 Martin VogtCORBA5 Objektreferenz Eindeutiger Name oder Kennung in einem verteilten ORB-System. Wird dem Objekt bei dessen Kreierung vom ORB zugewiesen und bleibt solange gültig, bis das Objekt explizit gelöscht wird. Implementierung von Objektreferenzen nicht durch Spezifikation festgelegt. CORBA 2.0: Interoperable Object Reference (IOR): –Muss von Anbietern benutzt werden, um Objektreferenzen über heterogene ORBs weiterzugeben. Isolation von Implementation und Objektreferenz: –Referenz ist nicht einfach eine Netzwerk- oder Speicheradresse des Objekts. –ORB ist dafür verantwortlich, für eine gegebenen Referenz die jeweilige Implementierung zu lokalisieren (z. B. über das Implementation Repository).

6 Martin VogtCORBA6 Object Management Architecture Object Request Broker (ORB) Application Objects CORBAfacilities Vertical Common Facilities Horizontal Common Facilities CORBAservices Naming Trader Life Cicle Transaction Concurrency Licensing Telecommunication User Interface

7 Martin VogtCORBA7 Eigenschaften des ORBs Statische und dynamische Methodenaufrufe: –Methodenaufrufe statisch beim Kompilieren definieren oder dynamisch zur Laufzeit entdecken. Freie Wahl von Programmiersprachen: –Aufrufe durch Sprache Ihrer Wahl unabhängig von Implementationssprache des Servers durch Trennung von Schnittstelle und Implementierung. –Sprachenunabhängige Datentypen. Selbstbeschreibendes System: –Interface Repository als Verzeichnis der Schnittstellen, die von Servern angebotene Methoden und deren Parameter beschreiben (in IDL). Ortstransparenz: –Vermittelt Aufrufe zwischen Objekten innerhalb eines Prozesses oder Prozessen, die an verschiedenen Orten im Netz unter verschiedenen Betriebssystemen laufen vollkommen transparenz.

8 Martin VogtCORBA8 Aufbau des ORBs Object Request Broker (ORB) Core Dynamic Invocation Client IDL Stub Static Skeletons ORB Interface Dynamic Skeleton Interface Repository Implementation Repository Client Object Implementation Object Adapter

9 Martin VogtCORBA9 Interface Repository Enthält alle Metadaten über Objekte, Services und den ORB selbst (in IDL). Laufzeitdatenbank mit IDL-generierter Information, die sich abfragen lässt und aktualisierbar ist. Als Satz von Objekten implementiert, die die Information in sich tragen. Schnittstelle für die IDL-Strukturen: –ModuleDef: logische Gruppierung von Schnittstellen (Namensraum). –InterfaceDef definiert Schnittstelle der Objekte. –OperationDef definiert Methode eines Objekts. –ParameterDef definiert Argument einer Methode. –AttributeDef definiert Attribut einer Schnittstelle. –ConstantDef definiert eine benannte Konstante. –ExceptionDef definiert eine Exception, die bei einer Operation auftreten kann. –TypeDef definiert die benannten Typen, die Teil der IDL-Definition sind.

10 Martin VogtCORBA10 Implementation Repository Enthält Information über die von einem Server unterstützten Klassen, den Objektinstanzen und ihren Referenzen. Gemeinsamer Speicher für zusätzliche Information, z. B. mit welchem Kommando ein bestimmter Server zu aktivieren ist. Wird vom ORB verwendet, um aktive Objekte zu lokalisieren. Hängt stark von der jeweiligen CORBA-Plattform ab. Implementation Repository

11 Martin VogtCORBA11 Objektadapter Objektadapter sind verantwortlich für: –Registrieren von Implemenationen im Implementation Repository. –Generieren und Interpretieren von Objektreferenzen. –Zuordnen von Objektreferenzen zu ihren jeweiligen Implementationen. –Aktivieren und Deaktivieren von Objektimplementationen. –Aufruf von Methoden via Skeleton oder DSI und Übergabe von Parametern. Basic Object Adapter (BOA): –4 Aktivierungsverfahren: BOA-Shared-Server: Mehrere Objekte laufen als Threads im selben Prozess. BOA-Unshared-Server: Für jedes Objekt wird ein eigener Prozess gestartet. BOA-Server-per-Method: Für jede Anfrage wird ein neuer Prozess gestartet. Server laufen nur für die Dauer einer bestimmten Methode. Es können gleichzeitig mehrere Prozesse für dasselbe Objekt aktiv sein. BOA-Persistent-Server: Prozesse werden von ausserhalb des BOA aktiviert (von Hand). Arbeitet danach als Shared-Server.

12 Martin VogtCORBA12 Statischer Aufruf: IDL Stub und Skeleton Durch IDL-Compiler generiert. Abhängig von Implementierung und OS. Stub: –Statisches Interface für Objektdienste auf Klientenseite. –Marshalling/Demarshalling. –Lokaler Proxy: Akzeptiert Aufrufe von Klients für entfernte Objekte, als ob es lokale Aufrufe wären. Skeleton: –Statisches Interface: Nimmt Methodenaufrufe für Serverobjekt entgegen. –Marshalling/Demarshalling. Vorteile gegenüber dynamischem Aufruf: –Leichter zu programmieren: Aufruf über Namen mit Parameter. –Robustere Prüfung der Datentypen beim Compilieren des Klienten. –Bessere Performance: nur ein einziger API-Aufruf.

13 Martin VogtCORBA13 Dynamic Invocation Interface (DII) Ermöglicht es dem Klienten, sich irgendein Zielobjekt zur Laufzeit auszuwählen und dann dynamisch seine Methode aufzurufen. Keine vorkompilierten Stubs nötig. Klient entdeckt schnittstellenrelevante Informationen zum Zeitpunkt des Aufrufes. Klient muss sich zuerst Objektreferenz verschaffen. Name der Schnittstelle verschaffen: get_interface() Methodenbeschreibung verschaffen: lookup_name() describe() Argumentliste erzeugen: create_list() add_item()... add_item()... add_item() Anfrage erzeugen: create_request(Object Reference, Method, Argument List) Entfernte Objektmethode aufrufen: synchron:invoke() verzögert synchron:send_deferred() get_response() oneway:send_oneway() Objekt Interface Repository 3 Möglichkeiten für entfernte Aufrufe

14 Martin VogtCORBA14 Dynamic Skeleton Interface (DSI) Gegenstück zu DII auf der Serverseite. Bietet Laufzeit-Verknüpfungsmechanismus für Server, die eingehende Methodenaufrufe für Komponenten bearbeiten müssen, die keine IDL-basierten kompilierten Skeletons haben. Das dynamische Skeleton analysiert die Parameterwerte in einer ankommenden Nachricht, um herauszufinden, für welches Objekt und welche Methode sie gedacht ist. Anwendungsbeispiele: –Nützlich für Implementierung von Bridges zwischen verschiedenen ORBs. –Von Interpretern und Script-Sprachen dazu verwendet, um dynamisch Objektimplementierungen zu erzeugen.

15 Martin VogtCORBA15 ORB Interface Einige wenige API-Funktionen für lokale Dienste: z. B. –ORB_init: Gibt eine Referenz zum ORB zurück, um nachher Methoden des ORB- Pseudoobjekts aufrufen zu können. –Object_to_string: Wandelt eine Objektreferenz in einen String um, um diese z. B. in Festspeicher ablegen zu können.. –String_to_object: Wandelt einen String in eine Objektreferenz um. –Get_service_information: Wird gebraucht, um Information über CORBAfacilities und Dienste zu erhalten, die von diesem ORB unterstützt werden. –List_initial_services: Gibt eine List mit Namen zurück von verfügbaren Diensten. –Resolve_initial_references: Gibt zu einem Servicenamen die entsprechende Objektreferenz zurück. –u. a.

16 Martin VogtCORBA16 Inter-ORB Architektur General Inter-ORB Protocol (GIOP): –Spezifiziert eine Menge von Nachrichtenformaten und Datendarstellungen für die Kommunikation zwischen den ORBs. –Kann direkt über jedes verbindungsorientierte Transportprotokoll arbeiten. –Definiert sieben Nachrichtenformate, die die gesamte request/response-Semantik der ORBs abdecken. –Mittels Common Data Representation (CDR) werden Datentypen, die in IDL definiert wurden, in eine einfache Nachrichtendarstellung für Netzwerke abgebildet. Internet Inter-ORB Protocol (IIOP): –Legt fest, wie GIOP-Nachrichten über ein TCP/IP-Netzwerk ausgetauscht werden. –Ermöglicht, das Internet selbst als Backbone-ORB zu verwenden, durch das mehrere ORBs verbunden werden können.

17 Martin VogtCORBA17 CORBA Services (1) Der Naming Service bildet von Menschen vergebene Namen auf Objektreferenzen ab. Der Life Cycle Service stellt Operationen zur Erzeugung, zum Kopieren, Verschieben und Löschen von Objekten bereit. Der Event Service ermöglicht es Objekten, ihr Interesse an bestimmten Ereignissen dynamisch registrieren zu lassen. Der Trader Service stellt Gelbe Seiten für Objekte zur Verfügung. Er erlaubt Objekten, ihre Dienste zu veröffentlichen. Der Transaction Service ermöglicht es verschiedenen verteilten Objekten, an einer atomaren Transaktion teilzunehmen. Er unterstützt auch verschachtelte Transaktionen. Der Concurrency Control Service ermöglicht Objekten den Zugriff auf gemeinschaftlich genutzte Ressourcen mit Hilfe von Sperren (Locks). Ein Objekt muss eine entsprechende Sperre des Dienstes besitzen, bevor sie auf eine geteilte Ressource zugreift. Der Security Service stellt einen ganzen Satz von Sicherheitsmechanismen bereit. Er unterstützt z. B. Authentifizierung und Zugriffskontrolle.

18 Martin VogtCORBA18 CORBA Services (2) Der Persistent Object Service ermöglicht es Objekten, auch dann dauerhaft zu existieren, wenn die Applikation, die das Objekt erzeugt hat, beendet wurde. Der Externalization Service definiert Schnittstellen, um Objekte in einen Datenstrom umzuwandeln und sie aus einem Datenstrom zurückzuholen. Der Query Service definiert Operationen für Objektabfragen mit SQL3 und OQL ähnlichen Sprachen. Der Collection Service ermöglicht es, Objekte in Gruppen zu manipulieren. (Arrays, Bäume, Stacks,...) Der Relationship Service ermöglicht die Definition von Beziehungen zwischen Objekten. Der Time Service stellt z. B. Interfaces zur Verfügung, um sich in einer verteilten Umgebung miteinander zu synchronisieren oder zeitabhängige Ereignisse zu definieren. Der Licensing Service lässt Sie z. B. die Nutzungsdauer von Komponenten messen und entsprechend abrechnen. Der Property Service erlaubt es, einem Objekt dynamisch eine Eigenschaft zuzuweisen (z. B. einen Titel oder ein Datum).

19 Martin VogtCORBA19 CORBAfacilities Sind Sammlungen von IDL-definierten Komponenten, die Dienste anbieten, die für Applikationsobjekte von direktem Nutzen sind. Sie werden unterteilt in horizontale und vertikale Komponenten. Horizontale Komponenten werden in vier Bereiche gegliedert: –User Interface: Komponenten, die ein Informationssystem zugänglich machen für die User, z. B. Präsentation von Objekten am Bildschirm, GUI. –Information Management: Komponenten für das Modellieren, Definieren, Speichern, Managen und Austauschen von Informationen. –System Management: Komponenten für das Managen von komplexen Informationssystemen. –Task Management: Komponenten für das Automatisieren von Arbeitsprozessen, sowohl System- wie auch Benutzerprozessen. Verschiedene Gruppen arbeiten an den sogenannten Vertical Market Facilities: –Geldwesen/Banken, Öl und Gas, Telekommunikation, Gesundheitswesen, etc.

20 Martin VogtCORBA20 CORBA 3.0 Neue Spezifikationen in CORBA 3.0: –Java und Internet Integration: Ein Java-zu-IDL-Mapping für die automatische Generation von IDL stubs und skeleton aus Java-Objekten. Firewall-Spezifikation für Aufrufe von CORBA-Objekten durch Firewalls. –QoS-Kontrolle: Erlaubt Klienten und Objekten verschiedene QoS-Parameter zu kontrollieren: Prioritäten, Deadlines, Time-To-Live. –CORBAcomponents: Umgebung definierbar, in der alle Komponenten persistent, transaktional und sicher sind. –Asynchronous and Messaging Invocation (AMI): Diese Spezifikation definiert eine Anzahl von asynchronen Aufruf-Modi für CORBA. (z. B. Warteschlangen) –Minimum, Fault-Tolerant and Real-Time CORBA. –Objekte, die by value übergeben werden können.

21 Martin VogtCORBA21 Referenzen Bücher: –Siegel J., CORBA Fundamentals and Programming, John Wiley & Sons, Inc., New York, 1996. –Redlich J.-P., Corba 2.0: Praktische Einführung für C++ und Java, Addison- Wesley, Bonn, 1996. –Orfali R., Harkey D., Edwards J., Instant CORBA, Addison-Wesley, Bonn, 1998. –Orfali R., Harkey D., Edwards J., Client/Server Survival Guide, John Wiley & Sons, Inc., New York, 3. Auflage, 1999. Papers: –Siegel J., An Overview Of CORBA 3.0, Object Management Group. –Kàhkipuro P., Object-Oriented Middleware for Distributed Systems, September 1998. WWW: –OMG-Homepage: www.omg.org www.omg.org/corba/beginners.html –CORBA-Homepage: www.corba.org