C ommon O bject R equest B roker A rchitecture

Einleitung 1989 Gründung der Object Management Group (OMG) Ziel: „...gemeinsames architekturbezogenes Gerüst für objektorientierte Anwendungen zur Verfügung zu stellen, das auf weit verbreiteten Schnittstellenspezifikationen basiert“ Ergebnis: Object Management Architecture (OMA) Funktion von CORBA: Implementierung der ORB-Funktionen Liefert Standard des architektonischen Grundgerüsts anhand dessen Anwendungen entwickelt werden OMG: Ursprünglich 8 Mitglieder darunter HP, Sun Mikrosystems und American Airlines Heute mehr als 780 Mitglieder OMA: ORB Objektdienste (CORBAservices) Gemeinsame Einrichtungen (CORBAfacilities) Domänenschnittstellen (Domaininterfaces) Anwendungsobjekte (Application Interfaces)

Object Management Architecture Abstrakte Beschreibung der Objektwelt Bestandteile: Object Request Broker (ORB) CORBAservices CORBAfacilities Domain Interfaces Application Objects ORB: Zur Verfügungstellung einer Infrastruktur für transparenten Informationsaustausch Unabhängig von Plattformen und Techniken der Implementierung Serverobjekte können auch Clients weiterer Objekte sein CORBAservices: Fundamentale Schnittstellen zur Realisierung von CORBA-Anwendungen Flexible Kombination miteinander möglich Zur Erleichterung und Vereinfachung der Anwendungsentwicklung Beipiele: Naming Service Event Service Transaction Service Life-Cycle-Service CORBAfacilities: Schnittstellen auf höherer Anwendungsebene als die der CORBAservices Endnutzerorientiert Horizontale Einrichtungen (branchenunabhängig) Benutzeroberflächen Systemverwaltungseinrichtungen Vertikale Einrichtungen (branchenabhängig) Hauptbuch- und Amortisierungsfunktionalität beim Buchhaltungswesen Automatische Werkstattsteuerung bei der Fertigungstechnik Domain Interfaces: Auf ähnlicher Ebene wie CORBAfacilities Branchenspezifische Schnittstellen Application Objects: Von Anwendung angebotene Schnittstellen

CORBA 1.x und 2.x Versionen: Dezember 1990: CORBA 1.0 Anfang 1991: CORBA 1.1 Später: CORBA 1.2 1. Schritt zur Objektinteroperabilität Möglichkeit zur Kommunikation zwischen Rechnern mit unterschiedlichen Architekturen und Sprachen Dezember 1994: CORBA 2.0 September 1997: CORBA 2.1 Kommunikation zwischen ORB´s verschiedener Anbieter durch GIOP Zielsetzung der OMG: selbst keine Realisierung von CORBA-Plattformen – stellen nur Standard zur Verfügung CORBA 1.1: Definition von IDL Definition von API für Anwendungen zur Kommunikation mit einem ORB CORBA 2.0: Definition eines Standardprotokolls zur Kommunikation von verschiedenen ORBs miteinender General-Inter-ORB-Protocol (GIOP) Herstellung echter Interoperabilität zwischen Produkten verschiedener Anbieter Basierend auf TCP/IP auch als Internet-Inter-ORB-Protocol (IIOP) Käufliche Plattformen: Distributed Smalltalk von ParcPlace Digitalk Orbix (C++, Smalltalk) und OrbixWeb (Java) von IONA DSOM (C++) von IBM Freie Plattformen: JacORB ILU DOME

Object Request Broker (1) Grundlegender Bestandteil von CORBA (SW-Komponente zur Erleichterung der Kommunikation) Hauptaufgabe: Bereitstellung von Diensten einer Komponente, die von einer anderen Komponente genutzt werden sollen Ablauf: Erlangen der vom Dienst zur Verfügung gestellten Objektreferenz durch den ORB Aufruf von Methoden der Komponente bzw. Zugriff auf deren Dienste Auflösung der Anfragen von Objektreferenzen Herstellung der Konnektivität der Komponenten Leistungsmerkmale: Auffinden von Remote-Objekten bei vorhandener Objektreferenz Übertragung des Formats von Parametern und Rückgabewerten, die bei Remote-Methodenaufrufen gesendet bzw. empfangen werden

Object Request Broker (2) Formatübertragung: Umsetzung der Parameter in ein über das Netzwerk übertragbares Format (Marshaling) Rückumsetzung des Übertragungsformat (Unmarshaling) Vorteile des ORB: Plattformunab-hängigkeit Übertragungs-format ist plattformunab-hängig Umwandlung des Übertragungs-formats beim (Un)Marshaling in plattform-spezifische Formate Formatübertragung: Bei Methodenaufruf: Übergabe von Eingangsparametern Rückgabe von Ausgangsparametern

Interface Definition Language Teil der Standard CORBA-Spezifikation Zur Definition der von CORBA-Objekten verwendeten Schnittstellen zwischen einzelnen Komponenten Sammlung der in IDL spezifizierten Schnittstellen im Interface Repository Programmiersprachenunab-hängigkeit durch Sprachabbildung Standard-Sprachabbildungen für C, C++, Cobol, Java und Smalltalk Wahl der für die Anwendung besten Sprache möglich Definition von Schnittstellen: Nicht zur Implementierung Nur zur Beschreibung Sprachabbildung: Language Mapping IR: Durch IR ist Erkennung der Schnittstellensignatur möglich Für Marshaling unerlässlich

Entfernte Objekte (Remote Objects) Definition: Objekte außerhalb eines räum-lich streng abgegrenzten Bereichs Auf jedem Rechner auffindbar, zu dem eine Verbindung existiert (Verständigung über CORBA) Eigenschaften: Zugriff nur über Kommuni-kationsprotokolle Keine direkte Manipulation möglich Verfügen über Attribute und Methoden Zugriff: Entfernter Zugriff ist transparent (wirkt wie naher Zugriff) Verwendung naher Proxy-Objekte mit der gleichen Signatur wie das entsprechende entfernte Objekt Zugriff: Weiterleitung der Aufrufe an entfernte Objekte Rückgabe der Antworten der entfernten Objekte

Objektzugriff (1) Übergabe durch Referenz Interoperable ObjektReferenz Objekt bleibt an Ort und Stelle Methodenaufrufe nur über Referenz Kein direkter Zugriff Interoperable ObjektReferenz Ziel: weltweit eindeutige Referenzierung eines Objekts Aufbau: Allgemeiner Teil Unabhängig von Netzwerkverbindungsart Beschreibung durch GIOP Netzwerkspezifischer Teil Beschreibung durch spezifisches Inter-ORB-Protocoll Zugriffsarten: Übergabe durch Referenz Übergabe durch Werte Übergabe durch Referenz: Weitergabe einer IOR von Prozess A an Prozess B Bei Aufruf einer Methode dieses Objekts durch Prozess B: Ausführung dieser Methode durch Prozess A Prozess A ist Eigentümer vom Objekt Prozess B hat nur Sicht auf das Objekt und kann Methoden von Prozess A ausführen lassen

Objektzugriff (2) Übergabe durch Werte Kopieren des Objektstatus zum Zielprozess Anlegen einer neuen Instanz des Objekts Methodenausführung auf Objektkopie Keine Änderung des Originals Übergabe durch Werte: Tatsächliche Weitergabe des Objektstatus In der Regel durch Serialisierung Bei Methodenaufruf durch Prozess B: Ausführung der Methode auf Prozess B Keine Statusänderung des ursprünglichen Objekts Nur Änderung der Kopie auf Prozess B

Objektadapter Objektadapter: Funktionsbereiche des BOA: Schnittstelle zwischen Objektimplementierung und zugehörigem ORB Arten: Basic Objectadapter (BOA) Library Objectadapter Object-Oriented Database Adapter Funktionsbereiche des BOA: Registrierung von Objektimplementierungen Server-Aktivierung und -Deaktivierung Erzeugung von Objektreferenzen für Implementierungen Authentifizierung und Zugriffskontrolle Arten: Grundlegender Objektadapter Bibliotheksobjektadapter Objektorientierter Datenbankadapter Zum Zugriff auf Objekte im dauerhaften Speicher BOA: Zurverfügungstellung einer allgemeinen Gruppe von Methoden für den Zugriff auf ORB-Funktionen Strategien zur Serveraktivierung: Gemeinsame Nutzung eines Servers von mehreren Objekten Pro Server ein Objekt Automatisches Starten eines Servers bei Aufruf einer Objektmethode + automatischen Beenden dieses Servers beim Zurückgeben dieser Methode Manuelles Starten des Servers zB. Verwendung eins Servers von allen Clients zB. Starten einer eigenen Server-Instanz pro Client Strategien zur Serveraktivierung: Strategie der gemeinsam verwendeten Server Strategie der nicht gemeinsam verwendeten Server Strategie der Server-pro-Methode Strategie der permanenten Server

General Inter-ORB-Protocoll (1) GIOP als allgemeines Protokoll für die Kommunikation zwischen ORBs ab CORBA 2.0 Zusätzliche Protokolle zur Nutzung spezieller Transportprotokolle nötig: TCP/IP mit IIOP DCE mit DCE-CIOP Kompatibilität zwischen CORBA-Produkten verschiedener Hersteller Netzwerkmodell: Keine direkte Verwendung des GIOP Nur Standard Verwendung der daraus abgeleiteten Protokolle CORBA-Anwendung Inter-ORB-Protokoll IIOP DCE-CIOP Transportschicht TCP/IP DCE Physikalische Schicht

General Inter-ORB-Protocoll (2) Die Architektur einer verteilten CORBA-Anwendung: CORBA-Anwendung kann mehrere Inter-ORB-Protokolle verwenden Bridge zwischen TCP/IP und DCE möglich Keine Verdrängung von Netzwerkprotokollen

Clients und Server in CORBA (1) Server: Eine Komponente ist Server, wenn deren CORBA-Objekte Dienste enthalten, die anderen Objekten zur Verfügung stehen Clients: Eine Komponente ist Client, wenn sie auf Dienste eines anderen Objekts zugreift Komponente kann gleichzeitig Client und Server sein Stellt selbst Dienste zur Verfügung Nutzt auch Dienste anderer Objekte Server: Alle Komponenten, die Implementierungen für ein Objekt zur Verfügung stellen Wenn Komponente Objekt erstellt und Sicht auf dieses Objekt ermöglicht Wenn Komponente Vergabe von Objektreferenzen auf dieses Objekt ermöglicht Wenn Anfragen an dieses Objekt von Komponenten verarbeitet werden Client: Für sie werden Methoden durch Server-Komponenten ausgeführt

Clients und Server in CORBA (2) Bezeichnung: Komponente wird entweder Client oder Server genannt Client ist Komponente, die die meiste Zeit Dienste nutzt Server ist Komponente, die die meiste Zeit Dienste zur Verfügung stellt Client-Callback-Methode: Methodenrückruf Vom Client implementierte Methode, die vom Server aufgerufen wird Client ist kurzfristig beschränkter Server Client = Server: Komponente A erhält Objektreferenz für Objekt von Komponente B Komponente A ruft Methode für das Objekt auf A=Client und B=Server Weitergabe einer Objektreferenz von Komponente A als Parameter für den Methodenaufruf Komponente B ruft Methode für Objekt von Komponente A auf A=Server und B=Client Rollentausch ohne Wechsel der Anwendung Bezeichnung: Komponente A ist Client Komponente B ist Server

Stubs und Skeletons (1) Statische Schnittstelle: Client-Stub: Client-Stub bietet exakt die Operationen, die durch eine IDL-Spezifikation vorgegeben sind Static Invocation Interface (SII) Client-Stub: Kleiner Quelltextteil zur Ermöglichung des Zugriffs eines Clients auf eine Server-Komponente Stellt Client eine CORBA-Server-Schnittstelle zur Verfügung Kompilierung zusammen mit Client-Teil der Anwendung Server-Skeleton: Quelltextteile, die beim Implementieren eines Servers „ausgefüllt“ werden Client-Stub: Zur Verfügungstellung einer Pseudoimplementierung für jede Methode einer bestimmten Schnittstelle Kommunikation der Methoden mit dem ORB zur Durchführung einer Formatübertragung der benötigten Parameter Server-Skeleton: Gerüst auf dem der Server erzeugt wird Für jede Methode einer bestimmten Schnittstelle Generierung einer leeren Methode durch den IDL-Compiler Implementierung durch den Entwickler

Stubs und Skeletons (2) Nicht von Hand geschrieben Generierung bei der Kompilierung von IDL-Schnittstellendefinition Verbindung der sprachunabhängigen IDL-Spezifikation mit sprachspezifischem Implementierungsquelltext

DII und DSI Dynamische Schnittstelle: Client-Seite: (DII) Unterstützung der vollen Funktionalität zur dynamischen Konstruktion und Ausführung von Anfragen Dynamic Invocation Interface (DII) Client-Seite: (DII) Anbieten von Methoden zur Auswertung eines entfernten Operationsaufrufs durch Instanzen der Pseudo-Schnittstelle CORBA::Request Übertragung der notwendigen Informationen durch Anfrage selbst Ausführung der Anfrage über geeignete Methode zum Versenden eines Aufrufs an den ORB Server-Seite: (Dynamic Skeleton Interface (DSI)) Bearbeitung von Anfragen durch Server, die nicht statisch (durch IDL spezifiziert) implementiert sind Server erhält alle Informationen, die die Anfrage vom Client enthält Client: DII stellt diese Funktionalität zur Verfügung Server: Bearbeitung eingehender Anfragen durch Anwendung mittles DSI möglich Informationen: Zielobjekt in Form einer IOR Operationsname Parameter Wahrheitswert, ob Antwort erwartet wird

Zusammenfassung Geschichte Objektmodell Eckpfeiler Kommunikation OMG OMA CORBA-Versionen Eckpfeiler ORB IDL Objektmodell Entfernte Objekte Objektzugriff Objektadapter Kommunikation GIOP Clients und Server in CORBA Stubs und Skeletons DII und DSI