190 likes | 294 Views
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“
E N D
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
ObjectManagementArchitecture • Abstrakte Beschreibung der Objektwelt • Bestandteile: • Object Request Broker (ORB) • CORBAservices • CORBAfacilities • Domain Interfaces • Application Objects
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
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 Grundlegender Bestandteil von CORBA (SW-Komponente zur Erleichterung der Kommunikation) ObjectRequestBroker (1)
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 ObjectRequestBroker (2)
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 InterfaceDefinitionLanguage
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 Entfernte Objekte (Remote Objects)
Übergabe durch Referenz 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 Objektzugriff (1)
Übergabe durch Werte Kopieren des Objektstatus zum Zielprozess Anlegen einer neuen Instanz des Objekts Methodenausführung auf Objektkopie Keine Änderung des Originals Objektzugriff (2)
Objektadapter • Objektadapter: • 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 • Strategien zur Serveraktivierung: • Strategie der gemeinsam verwendeten Server • Strategie der nicht gemeinsam verwendeten Server • Strategie der Server-pro-Methode • Strategie der permanenten Server
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: GeneralInter-ORB-Protocoll (1)
GeneralInter-ORB-Protocoll (2) • Die Architektur einer verteilten CORBA-Anwendung:
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 Clients und Server in CORBA (1)
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 Clients und Server in CORBA (2)
Statische Schnittstelle: 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 Stubs und Skeletons (1)
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: • 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
Geschichte 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 Zusammenfassung