Schematische Schnittstelle eines Naming-Context-Objekts und des Binding-Iterators. BindingIterator. next_one next_n destroy

Transkript

1 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 indeutige Objektbezeichner für Parametertransport IOR mit jeweiligen Profilen IIOP: Hostname, Portname und ObjektID identifizieren Objekt rzeugung neuer verteilter Objekte rzeugung eines Servants, Aktivieren des Servants implizites oder explizites Aktivieren Factory-Objekt mit create-methode (Factory Pattern) 66

2 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

3 11.1 Zusätzliche igenschaften 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) insatzgebiet unter anderem bei nterprise Java Beans (JB) 70

4 12.1 inschränkungen inschrä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 (equals-methode) 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

5 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

6 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 rzeugen 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: xportieren Aufruf von javax.rmi.portableremoteobject. exportobject( obj,... ) Objekt kann sowohl über IIOP als auch über JRMP exportiert werden mind. ein expliziter xport notwendig 76

7 12.3 rzeugen eines RMI-IIOP-Objekts (2) rzeugung 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

8 13 Fault-Tolerant-CORBA CORBA-rweiterung für fehlertolerante Objekte seit CORBA 3.0 im Standard integriert Middleware-rweiterung (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