CORBA = Common Object Request Broker Architecture. plattformunabhängige Middleware-Architektur für verteilte Objekte

Transkript

1 CORBA 1 1 Standard CORBA = Common Object Request Broker Architecture plattformunabhängige Middleware-Architektur für verteilte Objekte OMG = Object Management Group Standardisierungsorganisation mit etwa 1000 Mitgliedern Teilbereiche der Standardisierung CORBA UML XMI... Formaler Standardisierungprozess Standard-Dokumente Definition von CORBA -Kompatibilität 2

2 2 Motivation Verteilte objektbasierte Programmierung verteilte Objekte mit definierter Schnittstelle Heterogenität in Verteilten Systemen verschiedene Hardware-Architekturen verschiedene Betriebssystem-Architkturen verschiedene Programmiersprachen Freiheitsgrade bei der Middleware-Implementierung CORBA schreibt keine Implementierung vor sondern Funktionalität CORBA fordert Interoperabilität verschiedener Implementierungen Anbindung an Altsysteme (Legacy) CORBA-Anwendungen sollen mit Altsystemen interagieren 3 3 Object Management Architecture, OMA Komponenten der OMA Anwendungsobjekte Vertical Facilities Horizontal Facilities ORB Naming Con- currency Persistence Life Cycle Properties Collections Security Trader Externalization Events Transactions Query Relationships Time Change Licensing Management CORBA Services 4

3 3.1 Anwendungsobjekte Verteilte CORBA-Objekte bilden eine Anwendung Kommunikation zwischen den Objekten über ORB monolithischer Ansatz: Objekt immer auf einem bestimmten Rechner interne Implementierung über Stellvertreterobjekte Aufrufer muss nicht unbedingt CORBA-Objekt sein Legacy-Anwendungen können Objektaufrufe durchführen Object Non-Object Knoten ORB Object Request Broker vermittelt Methodenaufrufe von einem zum anderen Objekt Rückgrat einer CORBA-Middleware mehrere interne Komponenten (teilweise nicht für Anwender sichtbar) z.b. Stellvertreterobjekte Interface Repository Aufrufer IDL DII Stubs ORB Interf. Objektimplementierung Static Skeleton DSI POA Implementation Repository ORB Core GIOP 6

4 3.3 CORBA-Services ORB-Erweiterungen Services bieten weitergehende Dienstleistungen an allgemein brauchbare und standardisierte Dienstleistungen z.b. Namensdienst (zum Auffinden von Objekten) z.b. Zeitdienst (zum Synchronisieren der Zeit) z.b. Sicherheistdienst (zur Zugriffskontrolle) CORBA-Services erscheinen als CORBA-Objekte Aufruf eines Dienstes über Methodenaufrufen System-API durch normale CORBA-Objekte CORBA-Facilities Facilities sind anwendungsorientierte Dienstleistungen im Gegensatz zu CORBA-Services (systemorientierte Dienstleistungen) Horizontale CORBA-Facilities Dienstleistungen über Anwendungsgebiete hinweg nutzbar z.b. Dokumentenbearbeitung, Druckdienst, Mobile Agenten,... Vertikale CORBA-Facilities Betrachtung einer Anwendungsdomäne (Domain Facilities) z.b. Dienste für Gesundheitswesen (Patientenverwaltung): CORBAmed, Produktmanagement, Telekommunikation, Finanzdienstleistungsgewerbe,... 8

5 3.5 CORBA-Implementierung OMA durch Funktionalität und Schnittstellen festgelegt Implementierung ist Sache eines CORBA-Herstellers (Vendor) CORBA-Implementierung muss nicht vollständige Spezifikation realisieren ORB-Core: ORB-Funktionen, Objektkommunikation Interoperabilität bei der Kommunikation mit ORBs anderer Hersteller Sprachunterstützung für mindestens eine Sprache keine Services oder Facilities vorgeschrieben Zertifizierung CORBA-Kompatibilität kann zertifiziert werden wird jedoch meist (noch) nicht gemacht 9 4 CORBA-Objekte Abstraktes objektbasiertes Programmiermodell Eigenschaften eines CORBA-Objekts verteilt aufrufbar Identität Zustand Attribute (von außen zugreifbare Instanzvariablen) Operationen (von außen zugreifbare Methoden) Wichtig CORBA-Objekt muss nicht identisch mit einem Objekt in einer Programmiersprache sein CORBA kann auch objektlose Programmiersprachen unterstützen, z.b. C 10

6 4.1 Interface-Definition-Language Schnittstelle von außen zugreifbare Attribute und Operationen müssen in Schnittstellendefinition deklariert werden Schnittstelle wird unabhängig von der benutzten Programmiersprache in einer Interface-Definition-Language (IDL) beschrieben Language-Mapping Abbildung von IDL-Konstrukten bzw. IDL-Typen auf unterstützte Programmiersprachen von CORBA unterstützte Sprachen Ada, C, C++, Java, Lisp, PL/I, Python, Smalltalk weitere inoffizielle Language-Mappings existieren,z.b. für Perl Interface-Definition-Language (2) IDL angelehnt an C++ geringer Lernaufwand eigene Datentypen Basistypen Aufzählungstyp zusammengesetzte Typen Module definieren hierarchischen Namensraum für Anwendungsschnittstellen und -typen Schnittstellen beschreiben einen von außen wahrnehmbaren Objekttyp Exceptions beschreiben Ausnahmebedingungen 12

7 4.1 Interface-Definition-Language (3) Beispiel: Kontoschnittstelle exception WrongAccountNumber { string errormsg; }; interface Account { readonly attribute double balance; }; double withdraw( in double amount ) raises WrongAccountNumber; double deposit( in double amount ) raises WrongAccountNumber; verteilte Objekte können Account-Schnittstelle implementieren Interface-Definition-Language (4) Basistypen Integer-Datentypen: short, unsigned short, long, unsigned long, long long, unsigned long long Zeichen: char, wchar Zeichensatz mehr oder weniger beliebig bei Parametertransport evtl. Umwandlung notwendig Fließkomma-Datentypen: float, double, long double Boolescher Typ: boolean Byte-Typ: octet Rahmentyp für alle IDL-Typen: any kann Werte beliebiger Typen speichern 14

8 4.1 Interface-Definition-Language (5) Komplexe Datentypen Typdefinition: typedef type name name wird für den evtl. zusammengesetzten Typ type definiert Strukturen: struct name { memberdef } name kann wie Typname benutzt werden Diskriminierte Varianten: union name switch( switchtype ) { unionmemberdef } kann Komponenten verschiedenen Typs enthalten nur eine der Komponenten kann einen Wert haben mit switchtype wird Typ bestimmt, dessen Werte eine der Komponenten auswählt (z.b. Aufzählungstyp) Interface-Definition-Language (6) Aufzählungstyp: enum name { constantdef } Konstanten werden im gleichen Namensraum abgelegt Sequenztyp: sequence < basetype [, maxlength] > tatsächliche Länge wird in sprachabhängiger Form gesetzt und abgefragt Zeichenketten: string [< maxlength >], wstring [< maxlength >] Festkommazahlen: fixed < digits, comapos > Felder: name [ constant ] Konstante constant gibt Elementanzahl an mehrdimensionale Felder möglich Wichtig: alle komplexen Datentypen müssen erst als Typdefinition deklariert werden bevor sie benutzt werden können! 16

9 4.1 Interface-Definition-Language (7) Exception-Definition Definition einer Ausnahme: exception name { memberdef } Komponenten ähnlich wie in einer Struktur Operationen aufrufbare Methode: resulttype name ( parameters ) [ raises exceptionlist ] als Ergebnistyp auch void benutzbar: kein Ergebnis exceptionlist ist mit Komma getrennte Liste von Exception-Namen Parameterdeklaration mit Komma getrennte Liste von Parameterdeklarationen: [ in out inout ] type name eingehende, ausgehende Parameter und beides mehrere Ergebniswerte pro Operation möglich Interface-Definition-Language (8) Parameterdeklaration (fortges.) Beispiel: Kontoschnittstelle mit out-parametern interface Account { readonly attribute double balance; void withdraw( in double amount, out double balance ) raises WrongAccountNumber; }; void deposit( in double amount, out double balance ) raises WrongAccountNumber; Typ void für kein Rückgabewert bei Operationen 18

10 4.1 Interface-Definition-Language (9) Objekttypen Namen von Schnittstellen (Interfaces) stehen für Objekttypen Parameter und Attribute können Objekttyp haben z.b.: attribute Account bankaccount; bankaccount kann Referenzen auf CORBA-Objekte vom Typ Account speichern Parameterübergabesemantik Basistypen, komplexe Typen: Call-by-Value Objekttypen: Call-by-Object-Reference seit CORBA 2.3 auch Value-Types ähnlich Objekttypen aber Call-by-Value-Übergabe Interface-Definition-Language (10) Konstantendefinition Name wird mit konstantem Wert verbunden z.b. const double limit = ; Name limit kann dann als Konstante verwendet werden Moduldefinitionen Beispiel: module CORBA {... } Verschachtelung der Module möglich innerhalb der Moduldefinition können definiert werden: Module Exceptions Konstanten Schnittstellen Typen (typedef u.a.) 20

11 4.1 Interface-Definition-Language (11) Vererbung Schnittstellen können voneinander erben interface limitedaccount : Account { void setlimit( in double newlimit ); }; mehrfache Vererbung möglich (mehrere Basis-Schnittstellen mit Komma getrennt) kein Overriding gleicher Methodenname mit gleichen Parameterdeklarationen darf nicht mehrfach vorkommen kein Overloading gleicher Methodenname mit verschiedenen Parameterdeklarationen darf nicht mehrfach vorkommen Interface-Definition-Language (12) Vererbung (fortges.) Diamond-Shape-Inheritance möglich Beispiel: interface A { long opa(); }; interface B : A {... }; interface C : A {... }; interface D : B,C {... }; Objekte vom Typ D besitzen eine Operation opa Schnittstellen erben automatisch von Object Basisoperationen definiert von CORBA 22

12 4.1 Interface-Definition-Language (13) Namensräume Module, Strukturen, Exceptions, Varianten und Schnittstellen spannen neuen Namensraum auf innere Namen verdecken äußere Namen qualifizierte Namen Namen des umgebenden Modules etc. verknüpft mit lokalem Namen durch doppelten Doppelpunkt z.b. CORBA::BAD_PARAM (bestimmte System-Exception) z.b. ::Account (Name Account im obersten Namensraum) bei Vererbung werden Namensräume der Basis-Schnittstellen importiert doppelte Belegung von Namen führt zu Qualifizierungszwang: Name kann nur als qualifizierter Name angesprochen werden Interface-Definition-Language (14) Namen innerhalb eines Namensraums darf ein Name nur einmal benutzt werden gilt auch für verschiedene Schreibweisen mit Groß- und Kleinbuchstaben z.b. neben Account darf es kein account geben in IDL verbotene Namen (wg. Schlüsselworte) können durch Voranstellen eines Unterstrichzeichens verwendet werden z.b. _module oder _Object 24

13 4.1 Interface-Definition-Language (15) Umsetzung von IDL in Sprachkonstrukte (z.b. C++) module MyModule { interface MyInterface { attribute long lines; void printline( in string toprint ); }; }; IDL namespace MyModule { C++ class MyInterface :... { public: virtual CORBA::Long lines(); virtual void lines( CORBA::Long _val ); void printline( const char *toprint );... }; }; Interface-Definition-Language (16) Umsetzung von IDL in Sprachkonstrukte (z.b. Java) module MyModule { interface MyInterface { attribute long lines; void printline( in string toprint ); }; }; package MyModule; Java namespace MyModule { C++ public class MyInterface interface MyInterface :... { extends... { public: int lines(); public virtual void CORBA::Long lines( int lines(); ); public virtual void void printline( lines( CORBA::Long _val ); void java.lang.string printline( const toprint char *toprint ); );... }; }; IDL 26

14 4.1 Interface-Definition-Language (17) Vorteile Schnittstellenbeschreibung unabhängig von Implementierungssprache ermöglicht Unterstützung vieler Programmiersprachen Nachteile Objektschnittstelle muss in IDL und in der Implementierungssprache beschrieben werden (letzteres kann teilweise automatisiert werden) IDL ist sehr ausdrucksstark (z.b. sequence) Sprachabbildung für Konstrukte, die in einer Programmiersprache nicht direkt vorhanden sind, ist kompliziert Fähigkeiten einer Sprache, die nicht in IDL beschrieben werden können, können nicht genutzt werden Objekterzeugung Beschreibung der IDL-Schnittstelle Implementierung des Servant Servant realisiert ein (oder auch mehrere) CORBA-Objekt(e) Auswahl einer Programmiersprache Umsetzung der IDL-Schnittstelle in ein Skeleton IDL Definition Skeleton Servant Servant Code Precompiler Compiler Skeleton wird in der Regel ausgefüllt mit Implementierungscode Prä-Compiler wird häufig IDL-Compiler genannt 28

15 4.2 Objekterzeugung (2) Instanziieren des CORBA-Objekts Instanziieren der Servant-Implementierung Aktivierung des Servants am Object-Adaptor eine Aufgabe des OA: Generierung der Objektreferenz Beispiel: POA mindestens eine POA-Instanz pro Adressraum (Server-Prozess) Aufruf von activate_object am POA Server activate_object POA Servant Objekterzeugung (3) Herausgabe der Objektreferenz Aufruf von servant_to_reference am POA liefert Objektreferenz auf CORBA-Objekt (nicht Servant) Realisierung der Objektreferenz ist sprachabhängig z.b. in Java: Stellvertreterobjekt (lokaler Stellvertreter ist optimiert) einfacher Servant Nutzung des Servants bei Parameterübergabe übergibt letztlich Objektreferenz implizite Aktivierung Betriebsart des POA Übergabe des Servant als Parameter aktiviert automatisch den Servant, falls noch nicht geschehen Beachte: Aktivierung ist identisch zum Exportieren in Java RMI 30

16 4.3 Objektnutzung Erzeugung eines Stubs Auswahl einer Programmiersprache für die Client-Seite Umsetzung der IDL-Schnittstelle in einen Stub IDL Definition Stub Stub Code Precompiler Compiler Objektnutzung (2) Empfang eines Parameters mit Objekttyp automatische Erzeugung einer neuen Objektreferenz aus dem Stub-Code realisiert auch entfernte Objektreferenz Objekttyp ist zur Compile-Zeit bekannt: Stub-Code kann erzeugt werden Aufruf von Operationen gemäß Sprachanbindung z.b. Java: Aufruf von Methoden am Stellvertreterobjekt Parameterübergabe Objekttypen: Übergabe der Objektreferenz Basistypen: Übergabe des abgebildeten Sprach-Datentyps komplexere Typen: Übergabe sprachabhängig 32

17 4.3 Objektnutzung (3) Parameterübergabe (fortges.) Übergabe bei out und inout Parametern sprachabhängig Problem: Programmiersprachen kennen meist keine Möglichkeit mehrere Ergebnisse zurückzugeben z.b. Java: Einführung von Holder-Klassen z.b. AccountHolder: kann eine Objektreferenz auf ein Objekt vom Typ Account aufnehmen Java-Referenz auf AccountHolder-Objekt wird als out oder inout Parameter übergeben Ergebnisparameter kann aus Holder-Objekt ausgelesen werden Objektnutzung (4) Typumwandlung 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 narrow-operation: sprachabhängige Umsetzung z.b. Java: Helper-Klasse pro Objekttyp z.b. AccountHelper Aufruf der statischen Methode narrow mit Objektreferenz als Parameter erzeugt neue Objektreferenz vom Typ Account Umwandlung in weniger spezifischen Typ: immer möglich z.b. von Typ D nach A (Beispiel aus der Vererbungsfolie) Umwandlung in spezifischeren Typ: nur möglich wenn tatsächlich vorhanden (laufzeitabhängig) z.b. von Typ A nach B 34

18 4.3 Objektnutzung (5) Sprachabhängige Code-Generierung z.b. in Java wird aus IDL-Beschreibung neben Stub und Skeleton auch Holder- und Helper-Klasse generiert IDL Definition Skeleton Servant Servant Code Precompiler Stub Compiler Stub Code Hilfsklasse Hilfsklassen Code Initialisierung der Anwendung Initiale entfernte Objektreferenzen Namensdienst für Registrierung und Anfragen von Objektreferenzen Woher bekommt man die Referenz auf den Namensdienst? ORB-Interface: Anfrage nach initialen Referenzen 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... 36

19 5 Object-Adaptor Aufgaben des Objektadapters Generierung der Objektreferenzen Entgegennahme eingehende Methodenaufruf-Anfragen Weiterleitung von Methodenaufrufen an den entsprechenden Servant Aktivierung und Deaktivierung von Servants Authentisierung des Aufrufers (im Security-Service) Obligatorischer Adapter: Portable-Object-Adaptor definierte Funktionalität für die häufigsten Aufgaben Alternative Adapter: z.b. für objektorientierte Datenbank verbindet Datenbank mit CORBA Adapter exportiert Objekte der Datenbank als CORBA-Objekte und sorgt für Vermittlung Portable-Object-Adaptor (POA) Jeder Servant kennt seine POA-Instanz POA-Instanz kennt die an ihm angemeldeten Objekte POA stellt Kommunikationsplattform bereit und nimmt Aufrufe entgegen (für seine Objekte) Server POA Servant Skeleton ORB Core Aufruf 38

20 5.2 POA-Erzeugung Root-POA existiert in jedem ORB voreingestellte Konfiguration kann zur Aktivierung von Objekten verwandt werden Referenz auf Root-POA Anfrage am ORB mit: orb.resolve_initial_reference( RootPOA ); Weitere POAs mit unterschiedlichen Konfigurationen erzeugbar Erzeugung am RootPOA bzw. an untergeordnetem POA (Vater-POA) neuer POA bekommt eigenen Namen (String) baumförmige, hierarchische POA-Struktur mit Wurzel beim Root-POA POA-Instanzen teilen sich Kommunikationskanal Objektreferenz enthält POA-Name: POA kann ermittelt werden POA-Erzeugung (2) Policy-Objekte am POA-Interface zu erzeugen Angabe einer bestimmten Policy für eine Policy-Kategorie (entspricht Konfigurationsparameter) 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 40

21 5.3 Deaktivierung und Aktivierung mit POA Objekte können ihren Servant und ihre POA-Instanz überleben Servants können deaktiviert werden POA kann deaktiviert werden Serverprozess kann beendet werden POA kooperiert mit einem Implementation-Repository Implementation-Repository hält dauerhafte Information über das CORBA- Objekt insbesonder wie dieses wieder aktiviert werden kann z.b. Programmdatei für Neustart Aufrufe deaktivierter Objekte landen beim POA Neuinstanziierung des Servants falls POA deaktiviert: Aufrufe landen beim Root-POA Neuinstanziierung des POA Laden des persistenten POA-Zustands: Neuinstanziierung des Servants Deaktivierung und Aktivierung mit POA (2) falls Server deaktiviert: Aufrufe landen beim Implementation-Repository Starten eines neuen Servers Root-POA wird aktiviert Aufruf wird an neue Kommunikationsadresse weitergeleitet (Location Forward) Root-POA erhält Aufruf: Neuinstanziierung von POA und Servant Aktivierungsmechanismus Speicherung von Daten und Protokoll zwischen Implementation- Repository und POA ist herstellerspezifisch JDK 1.4: orbd-prozess Unterstützung im RPC-Protokoll Location-Forward: Stubs werten Weiterleitung aus und kontaktieren Objekt an angegebener Kommunikationsadresse solange möglich 42

22 5.3 Deaktivierung und Aktivierung mit POA (3) Konfiguration des POA LifeSpan-Policy: mögliche Policy-Objekte erzeugt mit create_lifespan_policy TRANSIENT für Objekte, die Servant nicht überleben PERSISTENT für Objekte, die POA und Servant überleben können im PERSISTENT-Modus wird Objekt automatisch aktiviert, falls notwendig POA-Konfiguration Weitere Konfigurationsmöglichkeiten Request Processing Policy nur aktivierte Objekte sind bekannt ein Default-Servant kann für alle nicht aktivierten Objekte einspringen ein Servant-Manager kann für unbekannte Objekte einen Servant generieren Servant Retention Policy bei Default-Servant- oder Servant-Manager-Betrieb wird Servant für unbekanntes Objekt aktiviert (intern in Tabelle aktiver Objekte eingetragen) Thread Policy: multi-threaded oder single-threaded Aufrufbearbeitung pro Objekt ID Uniqueness Policy: eindeutige IDs über alle Zeit oder nicht ID Assignment Policy: system- oder benutzervorgegebene Objekt-IDs 44

23 6 Value-Types CORBA-Objekte Parameterübergabe immer mit Call-By-Object-Reference-Semantik Weitere Objektklasse: Value-Types Parameterübergabe immer mit Call-By-Value-Semantik ähnlich wie struct, union, enum, sequence etc. aber: sind Objekte Definition in IDL Methoden private und öffentliche Zustandskomponenten (State Members) Konstruktordefinitionen zur Initialisierung 45 6 Value-Types (2) Beispiel valuetype AccountVal { public short accountnr; private double balance; private Instanzvariable }; double withdraw( in double amount ); double deposit( in double amount ); factory init( in short accountnr ); Konstruktor Varianten abstrakte Value-Types: nur Methoden keinen Zustand Definition mit abstract valuetype konkrete Value-Types: Methoden und Zustandskomponenten 46

24 6.1 Vererbung Vererbung bei Value-Types einfache Vererbung von einem konkreten Value-Type mehrfache Vererbung von abstrakten Value-Types z.b.: valuetype LimitedAccountVal : AccountVal { private double limit; void setlimit( double lim ); }; Parameterübergabe Lokale Übergabe von Valuetypes Call-By-Object-Reference Entfernte Übergabe, d.h. Übergabe bei Methodenaufrufen an CORBA- Objekten Call-By-Value Strukturerhaltende Übergabe Valuetypes können Referenzen auf andere Valuetypes besitzen nil-referenzen möglich Objektstruktur wird bei Übergabe erhalten vgl. Java Serialisierung z.b. verkettete Listen, Bäume, Graphen 48

25 6.2 Parameterübergabe (2) Realisierung Marshaling der Zustände Unmarshaling: Aufbau der Objektstruktur von Value-Types Heterogenes System Value-Type-Objekte aus C++ können in Java wieder aufgebaut werden Voraussetzung: Abbildung der IDL-Typen in Sprachtypen (hier C++- bzw. Java-Klassen) ist bekannt dynamisches Laden von Code möglich, falls von Sprache unterstützt Übertragung eines CodeBase-Objekts zur Rückfrage nach URLs von Codestücken Implementierung von Value-Types stark abhängig vom Language-Mapping Verknüpfung mit CORBA-Objekten Value-Types können CORBA-Interface unterstützen z.b. valuetype AccountVal supports Account {... }; mit Registrierung beim POA wird Value-Type-Implementierung zum CORBA-Objekt Übergabe einer Referenz auf das Value-Type-Objekt möglich (Call-By-Value) Übergabe einer Referenz auf das CORBA-Interface möglich (Call-By-Object-Reference) 50

26 6.4 Abstract-Interfaces Spezielle Art von CORBA-Interfaces nicht zu verwechseln mit abstrakten Klassen und abstrakten Value-Types letztere definieren Klassen, Value-Types, die nicht instanziierbar sind CORBA s Abstract Interfaces kapseln Value-Types und CORBA-Objekte Value-Type implementiert (supports) abstraktes Interface CORBA-Objekt erbt von abstraktem Interface beide Varianten können als Parameter übergeben werden, die mit abstraktem Interface deklariert sind Entscheidung für Call-By-Value oder Call-By-Reference zur Laufzeit Value-Types mit Call-By-Value CORBA-Objekte mit Call-By-Reference Abstract-Interfaces (2) Beispiel abstract interface AbstractAccount { double withdraw( in double amount ); double deposit( in double amount ); }; valuetype AccountVal supports AbstractAccount {... }; interface Account : AbstractAccount {... };... void method( in AbstractAccount acc );... 52

27 7 Dynamic-Invocation-Interface (DII) Typ eines Objekts zur Entwicklungszeit einer Anwendung nicht bekannt z.b. Name-Server-Implementierung, Verzeichnisdienst etc. Wie aufrufen? Abfrage der Objektschnittstelle Methode get_interface() bei jedem CORBA-Objekt liefert Referenz auf CORBA-Objekte, die Schnittstelle eines Objekts beschreiben Methoden, Parameter und deren Typen können erfragt werden Dynamische Konstruktion der Aufrufparameter generische Aufrufschnittstelle create_request() bei jedem CORBA- Objekt Benennung der Methode als String Übergabe der Parameter eingepackt in Typ any 53 7 Dynamic-Invocation-Interface (2) Aufruf wird durch Request-Objekt realisiert CORBA::Object is_nil duplicate release get_interface create_request erzeugt... Request invoke send_oneway send_deferred get_response poll_response MyInterface eigentlicher Aufruf wird durch invoke() am Request-Objekt ausgeführt 54

28 7.1 Interface-Repository Verzeichnisdienst für Schnittstelleninformationen IDL-Konstrukte werden jeweils als CORBA-Objekt realisiert Zusammenhänge zwischen den Repository-Objekttypen: Repository ConstantDef TypeDef ModuleDef ExceptionDef InterfaceDef ConstantDef TypeDef ModuleDef ExceptionDef InterfaceDef AttributeDef ExceptionDef ConstantDef TypeDef ExceptionDef AttributeDef OperationDef Interface-Repository (2) Repräsentation von Typen durch TypeCode-Objekte Repräsentation der Basistypen: int, float, boolean Repräsentation zusammengesetzter Typen: union, struct, enum, sequence, string, array Repräsentation von Objekttypen: Interface-Repository-ID TypeCode-Objekte repräsentieren Typ und Struktur durch IDL-Typen TypeCode-Objekte haben Operation für Typvergleich TypeCode-Objekte haben Operationen zur Strukturerkundung (z.b. welchen Elementtyp hat eine sequence) 56

29 7.2 Aufrufarten Normaler Aufruf Aufruf von invoke am Request-Objekt kehrt zum Aufrufer zurück, wenn eigentlicher Aufruf durchgeführt Asynchroner Aufruf Aufruf von send_deferred am Request-Objekt eigentlicher Aufruf wird angestoßen Aufrufer kann weiterarbeiten Ergebnissynchronisation durch get_response Ergebnisabfrage (Polling) mit poll_response Aufrufarten (2) Datagramm-Aufruf Aufruf von send_oneway am Request-Objekt Aufruf wird angestoßen es wird nicht auf Ergebnis gewartet (Methode darf kein Ergebnis liefern) Aufruf muss nicht sicher durchgeführt werden ( May-be-Once-Semantik ) oneway-methoden werden mit dem Schlüsselwort oneway in IDL markiert 58

30 8 Objektschnittstelle Vorgegebene Methoden in CORBA::Object werden an alle CORBA-Objekte vererbt create_request erzeugt dynamischen Aufruf get_interface ermittelt Beschreibungsobjekt für Schnittstelle des Objekts (aus dem Interface-Repository, vom Typ CORBA::InterfaceDef) is_nil prüft, ob Referenz mit Objekt verbunden (Nil-Referenz ist nicht verbunden) duplicate erzeugt neue Objektreferenz zum selben Objekt release gibt erzeugte Objektreferenz frei (darf nicht mehr benutzt werden) 59 9 Kommunikationsprotokolle Innerhalb einer ORB-Instanz können Objekte mit herstellerspezifischem Protokoll kommunizieren Zwischen ORBs verschiedener Herstellern GIOP General Inter-ORB Protocol (standardisiert in CORBA) Basisprotokoll für RPC-basierte Objektaufrufe Common Data Representation (CDR) definiert Marshalling und Unmarshalling von IDL-Typen IIOP Internet Inter-ORB Protocol GIOP über TCP/IP Unterstützung durch den ORB für CORBA-Kompatibilität vorgeschrieben GIOP-Implementierungen über andere Protokolle möglich 60

31 9 Kommunikationsprotokolle (2) ESIOP Environment Specific Inter-ORB Protocols z.b. DCE/ESIOP Inter-ORB-Protokoll auf der Basis von DCE RPC 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 jedes Protokoll eigenes Profil möglich Objekt kann theoretisch mehrere Protokolle unterstützen z.b. IIOP und herstellerspezifisches Protokoll 61 9 Kommunikationsprotokolle (3) IOR-Profil für IIOP Eintragung eines Profils Typ des Objekts: Interface-Repository-ID Hostname des POA TCP/IP-Portnummer des POA Name des POA ObjektID: eindeutiger Bezeichner innerhalb des POA Gängige Implementierung in Standard-ORBs Nutzung von IIOP auch innerhalb des ORBs IOR wird immer als eindeutiger Objektbezeichner benutzt 62

32 10 Naming-Service CORBA-Spezifikation eines Namensdienstes hierarchischer Namensraum (baumförmig ähnlich Dateisystem) Namen bestehen aus mehreren Silben z.b. < "usr"; "home"; "myobject" > (Entsprechung im Dateisystem wäre "/usr/home/myobject" ) Schnittstelle des Namensdienstes ist in IDL beschrieben ansprechbar als CORBA-Objekte Naming-Service (2) Beispiel eines Namensbaums Objekt des Namensdienstes usr NamingContext services system NamingContext NamingContext Object home www ftp NamingContext Object Object myobject Object Kontextobjekte wirken wie Verzeichnisse im Dateisystem 64

33 10 Naming-Service (3) Schematische Schnittstelle eines Naming-Context-Objekts und des Binding-Iterators NamingContext resolve list destroy new_context unbind bind rebind bind_context rebind_context bind_new_context BindingIterator next_one next_n destroy beliebige Objekte können gebunden (bind) und mit Namen wieder gesucht werden (resolve) Auflistung erfolgt durch Iterator-Pattern (list) Vergleich mit Anforderungen CORBA hat ein monolithisches Objektmodell Eindeutige Objektbezeichner für Parametertransport IOR mit jeweiligen Profilen IIOP: Hostname, Portname und ObjektID identifizieren Objekt Erzeugung neuer verteilter Objekte Erzeugung eines Servants, Aktivieren des Servants implizites oder explizites Aktivieren Factory-Objekt mit create-methode (Factory Pattern) 66

34 11 Vergleich mit Anforderungen (2) Schnittstellenspezifische Stellvertreterobjekte Stubobjekte pro IDL-Interface implementieren Methoden und Attribute aus der IDL-Beschreibung RPC-basiertes Kommunikationsprotokoll GIOP bzw. IIOP standardisiertes Inter-ORB-Protokoll beliebige eigene Protokolle verwendbar Codierung der Adressen in IOR-Profilen Parameterübergabe IOR wird als Objektbezeichner bei Parameterübergabe übermittelt ein ausgewähltes Profil bestimmt Typ der zu instanziierenden lokalen Stub- Implementierung Vergleich mit Anforderungen (3) Automatische Generierung der Stellvertreter IDL-Compiler (eigentl. Präcompiler) erzeugt Stellvertreter und Skeletons Namensdienst zum Finden von Objekten konfigurierter Namensdienst über ORB-Interface erreichbar resolve_initial_reference( NamingService ); 68

35 11.1 Zusätzliche Eigenschaften Aktivierung und Deaktivierung nicht im Detail spezifiziertes Konzept zur Aktivierung und Deaktivierung persistente Objektreferenzen durch POA-Konfiguration Implementierung des Aktivierungsmechanismus ist herstellerabhängig Flexibler Objektadapter POA ServantManager für dynamisch erzeugte Servants DefaultServant für Anbindung an große Objektmengen (z.b. Datenbankzugang) RMI über IIOP Verknüpfung von RMI und CORBA Verwendung von Java-RMI Kommunikation über IIOP statt JRMP über IIOP ansprechbare RMI-Objekte werden RMI/IDL-Objekte genannt Interoperabilität mit der CORBA-Welt RMI/IDL-Objekte von CORBA aus ansprechbar kein IDL erforderlich Java-to-IDL-Mapping (umgekehrte Abbildung) Tool (rmic -idl) kann IDL-Datei aus Java-Klasse erzeugen (für CORBA-Umgebungen) Einsatzgebiet unter anderem bei Enterprise Java Beans (EJB) 70

36 12.1 Einschränkungen Einschränkungen des Java-to-IDL-Mappings Konstanten in Remote-Interfaces müssen primitiven Typs oder vom Typ String und zur Compile-Zeit auswertbar sein keine gleich benannten Methoden in zwei gemeinsam geerbten Interfaces Methodennamen keine Namen erlaubt, die mit IDL-Namenskonvertierung kollidieren (Name Mangling), z.b. Methodenname object und _object keine Methoden mit Namen, die sich nur in Groß-, Kleinschreibung unterscheiden nicht auf Sharing von Stub-Objekten verlassen (==-Operator) keine Garbage-Collection möglich Parameterübergabe Übergabe von Referenzen auf RMI/IDL-Objekte Übergabe bei Kommunikation mit Standard-RMI-Objekt Kommunikation über JRMP RMI-IIOP-Stub wird serialisiert und deserialisiert Übergabe bei Kommunikation mit RMI/IDL-Objekt IOR wird übergeben spezielle Tagged-Component enthält Codebase für Stubklasse (für Java) Stubs müssen bereitgestellt werden (für andere Sprachen) Übergabe bei Kommunikation mit Standard-CORBA-Objekt per IIOP (z.b. bei CORBA-Objekten in Java) IOR wird übergeben Stub wird statisch bereitgestellt 72

37 12.2 Parameterübergabe (2) Übergabe von Referenzen auf Standard-RMI-Objekte Übergabe bei Kommunikation mit Standard-RMI-Objekt Deserialisieren der Stubobjekte Übergabe bei Kommunikation mit RMI/IDL-Objekt nicht möglich theoretisch realisierbar innerhalb von Java: serialisierter Stub in ein IOR- Profile codieren Übergabe bei Kommunikation mit Standard-CORBA-Objekt per IIOP (z.b. bei CORBA-Objekten in Java) nicht möglich Parameterübergabe (3) Übergabe von Referenzen auf Standard-CORBA-Objekte Übergabe bei Kommunikation mit Standard-RMI-Objekt nicht möglich Übergabe bei Kommunikation mit RMI/IDL-Objekt IOR wird übergeben Stub wird statisch bereitgestellt Übergabe bei Kommunikation mit Standard-CORBA-Objekt per IIOP (z.b. bei CORBA-Objekten in Java) IOR wird übergeben Stub wird statisch bereitgestellt 74

38 12.2 Parameterübergabe (4) Übergabe von Java-Datentypen Umwandlung in primitive IDL-Typen umgekehrte Abbildung Übergabe von Java-Objekten Objekte müssen serializable oder externalizable sein Umwandlung in IDL-Value-Types (Objekte, die per Call-by-Value übergeben werden) Transport als marshalled Data der Objekte Klassen müssen lokal verfügbar sein (für Java wird Codebase übermittelt) Umwandlung gilt auch für Arrays Erzeugen eines RMI-IIOP-Objekts Übliches Vorgehen Implementierungsklasse erbt/implementiert mind. ein Remote-Interface Implementierungsklasse erbt von javax.rmi.portableremoteobject vorbereitet für entfernte Aufrufe: exportiert Alternative Implementierungsklasse erbt/implementiert mind. ein Remote-Interface manuelles Vorbereiten für entfernte Aufrufe: Exportieren Aufruf von javax.rmi.portableremoteobject. exportobject( obj,... ) Objekt kann sowohl über IIOP als auch über JRMP exportiert werden mind. ein expliziter Export notwendig 76

39 12.3 Erzeugen eines RMI-IIOP-Objekts (2) Erzeugung der Stub- und Tie-Klassen Tie-Klasse dient als Server-Stub / Skeleton rmic-aufruf mit Option -iiop automatische Aktivierung Referenzweitergabe (Implicit Activation) Alternative: explizites Aktivieren z.b. an bestimmtem POA wg. Konfiguration (z.b. persistente Referenzen) Holen einer Instanz der Tie-Klasse spezielle Tie-Klasse: rmic -iiop -poa statische Methode an Utility-Klasse erzeugt konfigurierte Tie-Instanz Aktivieren des Objekts durch Übergabe des Tie-Klassen-Objekts an POA (activate_object) Typumwandlung Narrow-Operation auf RMI/IDL-Objekte statische Methode narrow an javax.rmi.portableremoteobject Beispiel: obj= ns.resolve( MyAccount ); // Namensdienst acc= (Account)PortableRemoteObject.narrow( obj, Account.class ); interner Ablauf: narrow-methode erzeugt neuen Stub, passend zum Interface Account Rückgabe als Java-Object (wg. generischer Implementierung) muss noch gecastet werden 78

40 13 Fault-Tolerant-CORBA CORBA-Erweiterung für fehlertolerante Objekte seit CORBA 3.0 im Standard integriert Middleware-Erweiterung (monolithischer Ansatz) für Objektgruppen- Referenzen Fehlertoleranz Ausfälle sollen toleriert werden Replikation des verteilten Objekts mehrere Instanzen der Objektimplementierung (Servants) in unterschiedlichen Ausfallbereichen (Orten, Rechnern) transparentes Aufrufen fehlertoleranter Objekte (Replikationstransparenz) transparentes Umschalten auf Alternativ-Servant (Fehlertransparenz) Fault-Tolerant-CORBA (2) Fault-Tolerance-Domains administrativer Bereich, in dem fehlertolerante Objekte etabliert werden können gekennzeichnet durch eindeutigen Identifikator und zentrale Verwaltungsinstanzen Objekt-Factory Replikationsmanager Objektgruppen-Manager Property-Manager 80

41 13 Fault-Tolerant-CORBA (3) Objektgruppe Menge von normalen CORBA-Objekten (Replikate), die fehlertolerantes Objekt bilden Standard-Objektreferenz und Standard-IOR für Replikate Objektgruppenreferenz und IOGR (Interoperable Object Group Reference) für Gruppe Fault-Tolerant-CORBA (4) Replikationsstrategien STATELESS: Objekt hat keinen Zustand (einfach) COLD_PASSIVE: mehrere Replikate, eines ist Primärreplikat (Primary) Primary beantwortet Anfragen periodische Zustandsspeicherungen des Primary plus Logging von Aufrufen bei Fehler: Sekundärreplikat (Secondary) wird auf letzten Stand gebracht; fehlende Aufrufe werden nachgeholt ; wird neuer Primary WARM_PASSIVE: wie COLD_PASSIVE aber Secondaries werden periodisch auf Stand gebracht schnellere Fehlererholung 82

42 13 Fault-Tolerant-CORBA (5) Replikationsstrategien (fortges.) ACTIVE: alle Replikate führen jeden Aufruf aus erfordert deterministische Aufrufbearbeitung (evtl. Einschränkung von Nebenläufigkeit) bei Fehlererholung Zustandstransfer ACTIVE_WITH_VOTING: zusätzliche Abstimmung über Ergebnis (zur Zeit noch nicht standardisiert) Fault-Tolerant-CORBA (6) Konsistenzstrategien CONS_INF_CTRL: Kontrolle der Konsistenz durch Infrastruktur (ORB) FT-ORB führt Zustandssicherung (Checkpointing) und Logging von Aufrufen durch FT-ORB führt Fehlererholung durch strenge Konsistenz der Replikate CONS_APP_CTRL: Kontrolle der Konsistenz durch Anwendungsobjekt Konsistenz kann schwächer sein Logging und Erholung muss durch Anwendung erfolgen 84

43 13 Fault-Tolerant-CORBA (7) Gruppenverwaltung MEMB_INF_CTRL: Gruppenverwaltung durch FT-ORB (Infrastruktur) automatisches Nachstarten von Replikaten durch den FT-ORB MEMB_APP_CTRL: Gruppenverwaltung durch das Anwendungsobjekt neue Replikate müssen durch Anwendungsobjekt erzeugt werden Objektgruppen-Manager verwaltet Mitglieder Fault-Tolerant-CORBA (8) Architekturüberblick ReplicationManager GenericFactory PropertyManager ObjectGroupManager Rechner 1 ORB, Logging, Recovery Rechner 2 ORB, Logging, Recovery IOGR Servant Factory Servant Factory 86

44 13.1 Erzeugung eines fehlertoleranten Objekts Zentrale Instanz pro FT-Domäne: Generic-Object-Factory Aufruf create_object erzeugt neues FT-Objekt Properties bestimmen Strategien Property-Manager nimmt Properties entgegen Anwendung von Properties als Default-Properties, typabhängige Properties, Properties zur Generierungszeit oder Laufzeitproperties z.b. CONS_INF_CTRL Angabe von möglichen Orten (weitere Factories zur Erzeugung der Replikate) Angabe von Mindestgrößen für Replikatmenge automatische oder anwendungsabhängige Erzeugung der ersten Replikate evtl. Einrichtung der Logging- und Checkpointing-Mechanismen Erzeugung der Objektgruppen-Referenz und der IOGR IOGR und Objektaufrufe Spezielle IOR mit zusätzlichen Profilen ein IIOP-Profile für jedes bekannte Replikat Kennzeichnung der Profile als Objektgruppe (Tagged Component TAG_FT_GROUP enthalten) Benennung der Objektgruppe eindeutiger Objektgruppenbezeichner Version der IOGR laufende Nummer für IOGR-Versionen Aufruf über IOGR Stub wählt IIOP-Profil eines Primary aus (Tagged Component TAG_FT_PRIMARY enthalten) ansonsten beliebiges IIOP-Profil 88

45 13.2 IOGR und Objektaufrufe (2) Verhalten im Fehlerfall Ausprobieren aller vorhandenen Profile bis Aufruf fehlerfrei durchgeführt werden kann falls kein Profil funktioniert: Ansprechen des Replication-Managers und Anfordern einer neueren IOGR Wiederholung des Prozederes Erneuern der IOGR neue Replikate und fehlerhafte Replikate lassen IOGR-Information veralten jeder ORB überprüft Version der verwendeten IOGR bei Aufrufen Versionsnummer wird beim Aufruf als Kontextinformation mitgegeben spezieller Location-Forward sendet neue IOGR zurück IOGR und Objektaufrufe (3) Verhalten von Legacy-ORBs können Objekt ansprechen besitzen aber nicht die Fehlererholungseigenschaften auf Client-Seite keine alternative Profile, keine Erneuerung der IOGR Aufrufsemantik strikte Einhaltung der At-Most-Once-Semantik auch im Fehlerfall Übermittlung von zusätzlichen Kontextinformation pro Aufruf Aufruf-Identifikator, Client-Identifikator kann dazu benutzt werden, mehrfache Aufrufe auch an mehreren Replikaten zu erkennen 90

46 13.3 Fehlererkennung Fehlererkennung mehrere Komponenten in einer FT-Domäne zur Fehlererkennung (Fault Detector, Fault Notifier) Überprüfung der Replikate periodisches Prüfen (Pull) periodisches Rückmelden durch Replikate (Push) Stellvertreterprüfung (ein Stellvertreter wird für eine Menge von Objekten an einem Ort geprüft) Fehleranalyse Zusammenfassung von erkannten Fehlern Fehlermeldung Meldung an den Replikations-Manager Einleitung der Fehlererholung z.b. Primary wechseln Proprietäre Protokoll FT-CORBA-Standard basiert auf IIOP Einfügen von proprietären Protokollen durch Gateway-Server Gateway nimmt IIOP-Anfrage an und leitet sie mit anderem Protokoll weiter Beispiel: Gateway für Multicast-Protokolle Anfrage wird an alle Replikate mittels Multicast verschickt (interessant bei aktiver Replikation) evtl. Totally-Ordered Multicasts für deterministische Bearbeitung der Aufrufe mehrere Gateways für Fehlertoleranz notwendig jeder Gateway wird durch eigenes IIOP-Profil adressiert Gateways sind für Aufrufer transparent 92

47 13.5 Fehlererholung: Fallstudie Konfiguration Replikationsstrategie WARM_PASSIVE oder COLD_PASSIVE Konsistenzstrategie CONS_INF_CTRL Mehrere Replikate eines ist Primary und beantwortet Aufrufe alle Replikate implementieren Interface Checkpointable oder Updateable über Interfaces kann gesamter Replikatzustand ausgelesen oder gesetzt werden Checkpointing FT-ORB liest periodisch Zustand des Primaries aus und speichert diesen lokal Fehlererholung: Fallstudie (2) Logging FT-ORB protokolliert alle Aufrufe seit dem letzten Checkpoint Fehlererkennung Primary stirbt Fault-Detector erkennt Fehler Fehler wird schließlich an den Replication-Manager gemeldet dieser leitet Recovery ein, d.h. bestimmt neuen Primary evtl. neues Replikat erzeugen und einfügen IOGR wird neu erzeugt (neuer Primary rein, alter Primary raus) 94

48 13.5 Fehlererholung: Fallstudie (3) Recovery Umschalten nach Fehlererkennung auf alternativen Primary neuer Primary wird auf letzten Zustand initialisiert alle fehlenden Aufrufe werden eingespielt Anfragen aus dem Netz werden beantwortet Vergleich mit Anforderungen FT CORBA hat wie CORBA ein monolithisches Objektmodell Eindeutige Objektbezeichner für Parametertransport IOGR mit jeweiligen Profilen Objektgruppenbezeichner, FT-Domänenname IIOP-Profile für jedes Replikat (für jeden Primary, für jedes Gateway) Erzeugung neuer verteilter Objekte Factory-Objekt (Generic-Factory am Replication-Manager) mit create-methode (Factory Pattern) anwendungsspezifische Replikaterzeugung: Servant-Erzeugung anwendungsspezifisches Gruppenmanagement 96

49 14 Vergleich mit Anforderungen (2) Schnittstellenspezifische Stellvertreterobjekte Stubobjekte pro IDL-Interface implementieren Methoden und Attribute aus der IDL-Beschreibung RPC-basiertes Kommunikationsprotokoll IIOP-Zugang zu Replikaten IIOP-Zugang zu Gateways, die mit eigenen Protokollen (z.b. Totally- Ordered-Multicast) weiterleiten eigene Protokollimplementierungen in Stellvertretern Parameterübergabe IOR/IOGR wird als Objektbezeichner bei Parameterübergabe übermittelt Vergleich mit Anforderungen (3) Automatische Generierung der Stellvertreter IDL-Compiler (eigentl. Präcompiler) erzeugt Stellvertreter und Skeletons Namensdienst zum Finden von Objekten konfigurierter Namensdienst über ORB-Interface erreichbar resolve_initial_reference( NamingService ); 98

50 14.1 Zusätzliche Eigenschaften Unterstützung von Fehlertoleranz transparente Integration von Objektgruppenreferenzen Integration von Replikations- und Konsistenzstrategien Zustandssicherung, Logging von Aufrufen Konzept für Fehlererkennung und Verwaltung einer FT-Domäne Replikationsmanager 99