K. CORBA. K.1.1 Standardisierung. OMG = Object Management Group. Teilbereiche der Standardisierung

Transkript

1 K. CORBA K.1.1 Standardisierung CORBA = Common Object Request Broker Architecture plattformunabhängige Middleware-Architektur für verteilte Objekte, aufgesetzt auf ein vorhandenes Betriebssystem, auch für heterogene verteilte Systeme. OMG = Object Management Group Standardisierungsorganisation mit etwa 1000 Mitgliedern, Publikation verschiedener Standard-Dokumente, Definition von CORBA Kompatibilität. Teilbereiche der Standardisierung CORBA Softwarearchitektur für Komponenten, UML Unified Modelling Language (textuell & graphisch), XMI XML Metadata Interchange zwischen UML und MOF Werkzeugen, MOF Meta Object Facility... Entwurf von Systemen mit hoher Komplexität... Verteilte Betriebssysteme, 2008/09, P. Schulthess,VS, Universität Ulm 6-1

2 K.1.2 Zielsetzung Verteilte objektbasierte Programmierung: verteilte Objekte mit definierter Schnittstelle Heterogenität in Verteilten Systemen: verschiedene Betriebssystem-Architekturen verschiedene Hardware-Architekturen verschiedene Programmiersprachen Anbindung an Altsysteme (Legacy): insbesondere C, Pascal und Visual Basic, CORBA-Anwendungen sollen mit Altsystemen interagieren. Freiheitsgrade bei der Middleware-Implementierung: CORBA schreibt keine Implementierung vor, sondern die Funktionalität, CORBA fordert Interoperabilität verschiedener Implementierungen, Partielle Implementierung zulässig. Obj Obj Obj Middleware OS OS OS OS Verteilte Betriebssysteme, 2008/09, P. Schulthess,VS, Universität Ulm 6-2

3 K.2 OMA - Object Management Architecture ORB als Softwarebus bzw. Komponentenbus : Anwendungsobjekte Vertikale Vertikale Vertical Facilities Facilities Facilities Horizontal Facilities ORB CORBA Services Verteilte Betriebssysteme, 2008/09, P. Schulthess,VS, Universität Ulm 6-3

4 K.2.1 Anwendungsobjekte Verteilte CORBA-Objekte Objekt immer auf einem bestimmten Rechner (holistischer Ansatz), Kommunikation zwischen den Objekten über ORB, bilden gemeinsam eine Anwendung. Implementierungsperspektive: interne Implementierung über Stellvertreterobjekte, Legacy-Anwendungen können Objektaufrufe durchführen, Der Aufrufer muss nicht unbedingt ein CORBA-Objekt sein: Verteilte Betriebssysteme, 2008/09, P. Schulthess,VS, Universität Ulm 6-4

5 K.2.2 CORBA-Services Bieten gewissermassen ein System API zum Middleware-OS. Mit Objektschnittstelle und Methoden zum Aufruf, Erscheinen als ORB-Erweiterungen. Services bieten weitergehende Dienstleistungen an allgemein brauchbare und standardisierte Dienstleistungen, Was man eben in einem Betriebssystem so erwartet. Konkret zum Beispiel: Namensdienst (zum Auffinden von Objekten), Zeitdienst (zum Synchronisieren der Zeit), Sicherheitsdienst (zur Zugriffskontrolle). Query, Relationships, Collections, Change Management, Life cycle, Externalisation, Persistence, Concurrency, Transactions, Events, Object properties, Trader, Licensing Verteilte Betriebssysteme, 2008/09, P. Schulthess,VS, Universität Ulm 6-5

6 K.2.3 CORBA-Facilities Facilities sind anwendungsorientierte Dienstleistungen: im Gegensatz zu CORBA-Services (systemorientierte Dienstleistungen), könnten auch vom Anwendungsprogrammierer erstellt werden. Horizontale CORBA-Facilities: über Anwendungsgebiete hinweg nutzbare Dienstleistungen, z.b. Dokumentenbearbeitung, Druckdienst, Mobile Agenten,... Vertikale CORBA-Facilities: Betrachtung einer Anwendungsdomäne (Domain Facilities) z.b. Dienste für Gesundheitswesen (Patientenverwaltung CORBAmed), Finanzdienstleistungsgewerbe, Produktmanagement, Telekommunikation,... Verteilte Betriebssysteme, 2008/09, P. Schulthess,VS, Universität Ulm 6-6

7 K.2.4 ORB - Object Request Broker Rückgrat einer CORBA-Middleware. Vermittelt Methodenaufrufe von einem zum anderen Objekt Interne Komponenten im ORB: Language Mapping, Dynamic Interfaces, Inter Orb Protocols, Objekt-Adapter Objekte (im Servant) Klient Skeleton DSI Interface Repository DII IDL Stubs ORB Intf. Object Adapter GIOP / IIOP ORB Core Implementation Repository Verteilte Betriebssysteme, 2008/09, P. Schulthess,VS, Universität Ulm 6-7

8 K.2.5 Kommunikationsprotokolle GIOP General Inter-ORB Protocol (standardisiert in CORBA): Basisprotokoll für RPC-basierte Objektaufrufe, Austauschformat zwischen ORBs verschiedener Hersteller, Common Data Representation (CDR) definiert Marshalling & Unmarshalling von IDL-Typen IIOP Internet Inter-ORB Protocol: GIOP über TCP/IP, GIOP-Implementierungen über andere Protokolle möglich, Unterstützung durch den ORB für CORBA-Kompatibilität vorgeschrieben. Innerhalb einer ORB-Instanz können Objekte mit herstellerspezifischem Protokoll kommunizieren. GIOP Request Typen: LocateRequest & LocateReply zum Auffinden eines Objektes, Request & Reply für einen Methodenaufruf, MessageError, Fragment, CloseConnection, CancelRequest. Verteilte Betriebssysteme, 2008/09, P. Schulthess,VS, Universität Ulm 6-8

9 K.2.6 OA bzw. Objekt-Adapter Sprachspezifische Objektschnittstelle an ORB-Kernfunktionen anpassen. Bestandteil des ORB. Servant: Grob gesehen ein Wrapper für ein oder mehrere Objekte, Für unsere Zwecke Unterschied Servant/Objekt ignorieren, Weiterleitung von Anfragen transparent möglich. Aufgaben eines Objektadapters Generierung der IOR-Objektreferenzen Aktivierung und Deaktivierung von Servants Allgemeine Kommunikationsplattform bereitstellen, Authentisierung des Aufrufers (im Security-Service) OA-Instanz kennt die an ihm angemeldeten Objekte/Servants. Skeleton: Entgegennahme eingehender Methodenaufruf-Anfragen Weiterleitung von Methodenaufrufen an den entsprechenden Servant Server OA ORB Core Servant Skeleton Aufruf Verteilte Betriebssysteme, 2008/09, P. Schulthess,VS, Universität Ulm 6-9

10 Portable-Object-Adaptor (POA): definierte Funktionalität für die häufigsten Aufgaben, Obligatorischer Adapter für alle ORBs. Root-POA existiert in jedem ORB: voreingestellte Konfiguration, Anfrage am ORB mit: orb.get_initial_reference( RootPOA ), kann zur Aktivierung von Objekten und weiteren OAs verwendet werden. Weitere POAs mit unterschiedlichen Konfigurationen erzeugbar: Erzeugung am RootPOA bzw. an untergeordnetem POA (Vater-POA), Objektreferenz enthält POA-Name: POA kann ausgewählt werden, POA-Instanzen teilen sich den Kommunikationskanal, neuer POA bekommt eigenen Namen (String). Verteilte Betriebssysteme, 2008/09, P. Schulthess,VS, Universität Ulm 6-10

11 K.2.7 Policy-Objekte Enthalten Konfigurationsparameter, Vorgaben & evtl. auch Methoden. Umständlich aber konsequent objektorientiert. Policy-Objekte können am POA-Interface erzeugt werden: Angabe einer bestimmten Policy für eine Policy-Kategorie, bei Erzeugung eines POA werden vorab erzeugte Policy-Objekte als Konfiguration übergeben Beispiel: Policy für Implicit-Activation-Policy Erzeugung am POA mit Aufruf von create_implicit_activation_policy(... ) mögliche Policies (übergeben als Parameter) IMPLICIT_ACTIVATION für implizite Aktivierung NO_IMPLICIT_ACTIVATION für explizite Aktivierung Verteilte Betriebssysteme, 2008/09, P. Schulthess,VS, Universität Ulm 6-11

12 K.3 Dynamic-Invocation-Interface (DII) Der Typ eines Objekts ist zur Compilierungszeit evtl. nicht bekannt. Interface-Repository: wird über den ORB abgefragt. hier müssen Schnittstellendefinitionen hinterlegt werden, Abfrage der Objektschnittstelle beim Interface Repository, Methoden, Parameter und deren Typen können erfragt werden, get_interface() liefert Beschreibung der Schnittstelle eines Objekts, Dynamische Konstruktion des Aufrufobjekts generische Schnittstelle create_request() bei jedem CORBA-Objekt, Aufruf wird durch dynamisches Request-Objekt repräsentiert, Benennung der Methode als String, vgl. textueller Aufruf in Plurix. Übergabe der Parameter gekapselt im Request-Objekt: eigentlicher Aufruf wird durch invoke() am Request-Objekt ausgeführt CORBA::Object Create_request MyInterface CorbaRequest:: Invoke() Verteilte Betriebssysteme, 2008/09, P. Schulthess,VS, Universität Ulm 6-12

13 K.3.1 CORBA Kompatibilität OMA legt nur Funktionalität und Schnittstellen fest: die Implementierung ist Sache eines CORBA-Herstellers (Vendor). CORBA-Kompatibilität kann zertifiziert werden, wird jedoch meist (noch) nicht gemacht. Implementierung muss nur Grundfunktionen zwingend realisieren: Interoperabilität bei der Kommunikation mit ORBs anderer Hersteller, ORB-Core: ORB-Funktionen, Objektkommunikation, Sprachunterstützung für mindestens eine Sprache, keine Services oder Facilities vorgeschrieben, nicht die vollständige Spezifikation, mindestens IIOP. Verteilte Betriebssysteme, 2008/09, P. Schulthess,VS, Universität Ulm 6-13

14 K.4 CORBA-Objekte Eigenschaften eines CORBA-Objekts Attribute (von außen zugreifbare Instanzvariablen), Operationen (von außen zugreifbare Methoden), Verteilt bzw. remote aufrufbar, Identität der Instanz, Zustand. Stub enthält GET- und SET-Routinen für exportierte Variablen. Zum Thema Objektorientierung : CORBA-Objekt muss nicht identisch mit einem Objekt in einer Programmiersprache sein, CORBA kann auch objektlose Programmiersprachen unterstützen, z.b. C. Verteilte Betriebssysteme, 2008/09, P. Schulthess,VS, Universität Ulm 6-14

15 K.4.1 IOR Interoperable Object Reference Darstellung einer Objektreferenz als IDL-Datenstruktur: muss verwendet werden für GIOP, Repräsentation als String möglich (object_to_string). Profile in der IOR: für jede Protokollfamilie eigenes Profil möglich, Objekt kann theoretisch mehrere Protokolle unterstützen, z.b. IIOP neben herstellerspezifischem Protokoll. Typ. Implementierung in Standard-ORBs: IOR wird als eindeutiger Objektbezeichner benutzt, Nutzung von IIOP auch innerhalb des ORBs. POA Identifier Object Identifier Server spec. Info IIOP Version Host ID Port number Object Key Components IOR Repository ID Profile ID Profile Data... Next Profile Verteilte Betriebssysteme, 2008/09, P. Schulthess,VS, Universität Ulm 6-15

16 K.4.2 Objekterzeugung für den Server Beschreibung der Objekt-Schnittstelle in IDL. Implementierung des Servant Servant realisiert ein oder auch mehrere CORBA-Objekte, Entscheidung für eine Programmiersprache, Umsetzung der IDL-Schnittstelle in ein Skeleton, Skeleton wird in der Regel ausgefüllt mit Implementierungscode, Prä-Compiler wird häufig IDL-Compiler genannt. Instanzieren des CORBA-Objekts (Servant) Aktivierung des Servants am Object-Adaptor, Generierung einer entfernten Objektreferenz im OA, Verteilte Betriebssysteme, 2008/09, P. Schulthess,VS, Universität Ulm 6-16

17 POA Beispiel: mindestens eine POA-Instanz pro Adressraum (Server-Prozess), Aufruf von activate_object am POA, Rückgabe der Referenz auf Servant: Aufruf von servant_to_reference am POA, Realisierung der Objektreferenz ist sprachabhängig liefert Objektreferenz auf CORBA-Objekt (nicht Servant) z.b. in Java: Stellvertreterobjekt (lokaler Stellvertreter ist optimiert) implizite Aktivierung Übergabe des Servant als Aufrufsparameter aktiviert automatisch den Servant, eine mögliche Betriebsart des POA. Verteilte Betriebssysteme, 2008/09, P. Schulthess,VS, Universität Ulm 6-17

18 K.4.3 Objektnutzung durch den Klienten Erzeugung eines Stubs Umsetzung der IDL-Schnittstelle in einen Stub, Auswahl einer Programmiersprache für die Client-Seite. Empfang eines Parameters mit Objekttyp Autom. Erzeugung einer neuen Objektreferenz mit Hilfe des Stub-Code: Objekttyp ist zur Compile-Zeit bekannt: Stub-Code kann erzeugt werden realisiert auch entfernte Objektreferenz Aufruf von Operationen gemäß Sprachanbindung z.b. Java: Aufruf von Methoden am Stellvertreterobjekt Verteilte Betriebssysteme, 2008/09, P. Schulthess,VS, Universität Ulm 6-18

19 K.4.4 Namensdienst. Woher bekommt man die Referenz auf den Namensdienst? Initiale entfernte Objektreferenz muss irgendwie beschafft werden, ORB-Interface: z.b. orb.resolve_initial_reference( NamingService ); Vorkonfiguration durch Systembetreiber. Alternative: Übergabe der Referenzen außerhalb des Systems ORB-Interface: Umwandlung in einen String: orb.object_to_string( objref ); Rückumwandlung: orb.string_to_object( str ); Referenz kann per String übermittelt werden, z.b. über Datei, TCP/IP, Standardeingabe, Kommandozeile... Verteilte Betriebssysteme, 2008/09, P. Schulthess,VS, Universität Ulm 6-19

20 K.4.5 Sprachabhängige Code-Generierung z.b. in Java wird aus IDL-Beschreibung neben Stub und Skeleton auch Holder- und Helper-Klasse generiert Verteilte Betriebssysteme, 2008/09, P. Schulthess,VS, Universität Ulm 6-20

21 K.4.6 Parameterübergabe Objekttypen: Übergabe der Objektreferenz Basistypen: Übergabe des abgebildeten Sprach-Datentyps komplexere Typen: Übergabe sprachabhängig Übergabe bei out und inout Parametern sprachabhängig. Typumwandlung / Cast: Objektreferenz kann einen Typ aus der Vererbungshierarchie der Schnittstellen besitzen, wahrer Objekttyp kann spezifischer in der Vererbungshierarchie sein, Erzeugung einer anderen Objektreferenz mit anderem Typ, Zusätzlicher Aufwand im Skeleton. Verteilte Betriebssysteme, 2008/09, P. Schulthess,VS, Universität Ulm 6-21

22 K.4.7 Ergebnisrückgabe und Vererbung Problem 1: mehrfache Ergebnisse Manche Programmiersprachen können nur schwer mehrere Ergebnisse zurückzugeben: => Holder-Klassen in Java: z.b. kann AccountHolder eine Referenz auf ein Account-Objekt aufnehmen, Java-Referenz auf AccountHolder-Objekt wird als out- oder inout-parameter übergeben, Ergebnisparameter kann aus Holder-Objekt ausgelesen werden. Problem 2: Vererbung narrow- & cast-operation benötigt sprachabhängige Umsetzung: Umwandlung in spezifischeren Typ ist nur möglich, wenn tatsächlich vorliegend,. Umwandlung in weniger spezifischen Typ ist immer möglich, z.b. Java Helper-Klassen pro Objekttyp: AccountHelper, SavingsAccHelper, CheckingAccHelper, anyaccount = AccountHelper.narrow( savingsaccinstance); Verteilte Betriebssysteme, 2008/09, P. Schulthess,VS, Universität Ulm 6-22

23 K.5.1 Schnittstellenkonzept K.5 Interface-Definition-Language Schnittstelle wird unabhängig von der benutzten Programmiersprache in einer Interface-Definition-Language (IDL) beschrieben von außen zugreifbare Attribute und Operationen müssen in Schnittstellendefinition deklariert werden. Language-Mapping: Abbildung zwischen Programmiersprache und IDL-Syntax, Abbildung zwischen Sprachcompiler und CDR (Common Data Representation) Skalare, Arrays, Strukturen, Objekte, Vererbung, Parameterübergabe und rückgabe. von CORBA unterstützte Sprachen Ada, C, C++, Java, Lisp, PL/I, Python, Smalltalk weitere inoffizielle Language-Mappings existieren,z.b. für Perl Verteilte Betriebssysteme, 2008/09, P. Schulthess,VS, Universität Ulm 6-23

24 K.5.2 IDL angelehnt an C++ geringer Lernaufwand für C++ Programmierer. Module definieren hierarchischen Namensraum für Anwendungsschnittstellen und -typen, z.b. Verantwortlichkeit für ein Modul an Programmierer zuordnen. Schnittstellen: beschreiben einen von außen wahrnehmbaren Objekttyp eigene Datentypen Basistypen Aufzählungstyp zusammengesetzte Typen Exceptions beschreiben Ausnahmebedingungen Verteilte Betriebssysteme, 2008/09, P. Schulthess,VS, Universität Ulm 6-24

25 K.5.3 Parameterübergabesemantik für IDL Basistypen, komplexe Typen: Call-by-Value, Wert wird kopiert Call-by-Object-Reference für Objekttypen: Hauptsächlich sinnvoll für IOR Referenzen, Referenz auf das Objekt wird kopiert. Seit CORBA 2.3 auch Value-Types: ähnlich wie Objekttypen, aber mit Call-by-Value-Übergabe, Der Parameter wird serialisiert ähnlich Java, Z.B. für struct, record, Instanz Valuetype in IDL: Valuetype wäre in C++ schwierig, auch Vererbung möglich, auch abstrakte valuetype AccountVal{ public short accoutnnr; private double balance; double withdraw( in double amount ) ; double deposit( in double amount ); } factory init( in short accountnr ); Verteilte Betriebssysteme, 2008/09, P. Schulthess,VS, Universität Ulm 6-25

26 K.5.4 Beispiel: Umsetzung von IDL in C++ Sprachkonstrukte I D L C + + Verteilte Betriebssysteme, 2008/09, P. Schulthess,VS, Universität Ulm 6-26

27 Beispiel: Umsetzung von IDL in Sprachkonstrukte (z.b. Java) I D L J a v a C + + Verteilte Betriebssysteme, 2008/09, P. Schulthess,VS, Universität Ulm 6-27

28 Vorteile Schnittstellenbeschreibung unabhängig von Implementierungssprache, ermöglicht Unterstützung vieler Programmiersprachen, IDL ist sehr ausdrucksstark (z.b. sequence). Nachteile Objektschnittstelle muss in IDL und in der Implementierungssprache beschrieben werden (letzteres kann teilweise automatisiert werden), Sprachabbildung für IDL-Konstrukte, die in einer Programmiersprache nicht direkt vorhanden sind, ist kompliziert, Einige besondere Fähigkeiten einer Sprache, können nicht genutzt werden. Verteilte Betriebssysteme, 2008/09, P. Schulthess,VS, Universität Ulm 6-28

29 K.6 CORBA Perspektive Verknüpfung mit RMI: RMI kann mit IIOP betrieben werden standardisierte Abbildung von Remote-Schnittstellen auf IDL (und zurück) CORBA-Objekt erscheinen als RMI-Objekte RMI-IIOP-Objekte können als CORBA-Objekte auftreten Fault-Tolerant-CORBA: CORBA-Erweiterung für fehlertolerante Objekte seit CORBA 3.0 im Standard integriert Middleware-Erweiterung (holistischer Ansatz) für Objektgruppen-Referenzen Quellen: Hauck F., Vorlesung «Verteilte Betriebssysteme», Weber M., Verteilte Systeme, 2002, Tanenbaum A., van Steen M., Distributed Systems, Prentics Hall 2002, Bengel G., Verteilte Systeme, Vieweg 2000, Verteilte Betriebssysteme, 2008/09, P. Schulthess,VS, Universität Ulm 6-29