Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

1 C ommon O bject R equest B roker A rchitecture.

Ähnliche Präsentationen


Präsentation zum Thema: "1 C ommon O bject R equest B roker A rchitecture."—  Präsentation transkript:

1 1 C ommon O bject R equest B roker A rchitecture

2 2 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

3 3 Object Management Architecture Abstrakte Beschreibung der Objektwelt Bestandteile: – Object Request Broker (ORB) – CORBAservices – CORBAfacilities – Domain Interfaces – Application Objects

4 4 CORBA 1.x und 2.x Versionen: – Dezember 1990: CORBA 1.0 – Anfang 1991: CORBA 1.1 – Später: CORBA 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

5 5 Object Request Broker (1) Hauptaufgabe: – Bereitstellung von Diensten einer Komponente, die von einer anderen Komponente genutzt werden sollen – Ablauf: 1. Erlangen der vom Dienst zur Verfügung gestellten Objektreferenz durch den ORB 2. 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)

6 6 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

7 7 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

8 8 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

9 9 Objektzugriff (1) 1. Ü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: 1. Allgemeiner Teil Unabhängig von Netzwerkverbindungsart Beschreibung durch GIOP 2. Netzwerkspezifischer Teil Beschreibung durch spezifisches Inter-ORB- Protocoll

10 10 Objektzugriff (2) 2. Übergabe durch Werte - Kopieren des Objektstatus zum Zielprozess - Anlegen einer neuen Instanz des Objekts - Methodenausführung auf Objektkopie - Keine Änderung des Originals

11 11 Objektadapter Objektadapter: - Schnittstelle zwischen Objektimplementierung und zugehörigem ORB - Arten: 1. Basic Objectadapter (BOA) 2. Library Objectadapter 3. Object-Oriented Database Adapter Strategien zur Serveraktivierung: - Strategie der gemeinsam verwendeten Server - Strategie der nicht gemeinsam verwendeten Server - Strategie der Server-pro-Methode - Strategie der permanenten Server Funktionsbereiche des BOA: - Registrierung von Objektimplementierungen - Server-Aktivierung und -Deaktivierung - Erzeugung von Objektreferenzen für Implementierungen - Authentifizierung und Zugriffskontrolle

12 12 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: CORBA-Anwendung Inter-ORB-ProtokollIIOPDCE-CIOP TransportschichtTCP/IPDCE Physikalische Schicht

13 13 General Inter-ORB-Protocoll (2) Die Architektur einer verteilten CORBA-Anwendung:

14 14 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

15 15 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

16 16 Stubs und Skeletons (1) 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

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

18 18 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

19 19 Zusammenfassung 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


Herunterladen ppt "1 C ommon O bject R equest B roker A rchitecture."

Ähnliche Präsentationen


Google-Anzeigen