1 / 19

C ommon O bject R equest B roker A rchitecture

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“

neveah
Download Presentation

C ommon O bject R equest B roker A rchitecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. C ommonO bjectR equestB rokerA rchitecture

  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. ObjectManagementArchitecture • Abstrakte Beschreibung der Objektwelt • Bestandteile: • Object Request Broker (ORB) • CORBAservices • CORBAfacilities • Domain Interfaces • Application Objects

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

  5. 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)

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

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

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

  9. Ü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)

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

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

  12. 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)

  13. GeneralInter-ORB-Protocoll (2) • Die Architektur einer verteilten CORBA-Anwendung:

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

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

  16. 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)

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

More Related