E CORBA. 1 Standard. 2 Motivation. 3 Object Management Architecture, OMA. 1 Architekturen für verteilte Objekte. 3 Architekturen für verteilte Objekte

Transkript

1 1 Standard CORBA 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 Motivation 3 Object Management Architecture, OMA Verteilte objektbasierte Programmierung Komponenten der OMA verteilte Objekte mit definierter Schnittstelle Heterogenität in Verteilten Systemen verschiedene Hardware-Architekturen verschiedene Betriebssystem-Architkturen verschiedene Programmiersprachen Anwendungsobjekte Vertical Facilities Horizontal Facilities Freiheitsgrade bei der Middleware-Implementierung ORB CORBA schreibt keine Implementierung vor sondern Funktionalität CORBA fordert Interoperabilität verschiedener Implementierungen Anbindung an Altsysteme (Legacy) CORBA-Anwendungen sollen mit Altsystemen interagieren Naming xternalization vents CORBA Services Relation- Time Change Licensing ships Management Life Properties Con- Collec- Security Cycle currency tions Trans- Query actions Trader Persistence 3 4

2 3.1 Anwendungsobjekte 3.2 ORB Verteilte CORBA-Objekte Object Request Broker bilden eine Anwendung Kommunikation zwischen den Objekten über ORB holistischer 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 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 DII Stubs ORB Interf. Objektimplementierung Static Skeleton DSI POA Implementation Repository ORB Core GIOP CORBA-Services 3.4 CORBA-Facilities ORB-rweiterungen Facilities sind anwendungsorientierte Dienstleistungen 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 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,

3 3.5 CORBA-Implementierung 4 CORBA-Objekte OMA durch Funktionalität und Schnittstellen festgelegt Abstraktes objektbasiertes Programmiermodell Implementierung ist Sache eines CORBA-Herstellers (Vendor) igenschaften eines CORBA-Objekts 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 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 wird jedoch meist (noch) nicht gemacht CORBA kann auch objektlose Programmiersprachen unterstützen, z.b. C Interface-Definition-Language 4.1 Interface-Definition-Language (2) Schnittstelle angelehnt an C++ 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 () beschrieben geringer Lernaufwand eigene Datentypen Basistypen Aufzählungstyp Language-Mapping Abbildung von -Konstrukten bzw. -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 zusammengesetzte Typen Module definieren hierarchischen Namensraum für Anwendungsschnittstellen und -typen Schnittstellen beschreiben einen von außen wahrnehmbaren Objekttyp xceptions beschreiben Ausnahmebedingungen 11 12

4 4.1 Interface-Definition-Language (3) 4.1 Interface-Definition-Language (4) Beispiel: Kontoschnittstelle Basistypen exception WrongAccountNumber string errormsg; interface Account readonly attribute double balance; double withdraw( in double amount ) raises WrongAccountNumber; double deposit( in double amount ); raises WrongAccountNumber; 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 -Typen: any kann Werte beliebiger Typen speichern verteilte Objekte können Account-Schnittstelle implementieren Interface-Definition-Language (5) 4.1 Interface-Definition-Language (6) Komplexe Datentypen Aufzählungstyp: enum name constantdef } Typdefinition: typedef type name Konstanten werden im gleichen Namensraum abgelegt name wird für den evtl. zusammengesetzten Typ type definiert Sequenztyp: sequence < basetype [, maxlength] > Strukturen: struct name memberdef } tatsächliche Länge wird in sprachabhängiger Form gesetzt und abgefragt name kann wie Typname benutzt werden Zeichenketten: string [< maxlength >], wstring [< maxlength >] 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) Festkommazahlen: fixed < digits, comapos > Felder: name [ constant ] Konstante constant gibt lementanzahl an mehrdimensionale Felder möglich Wichtig: alle komplexen Datentypen müssen erst als Typdefinition deklariert werden bevor sie benutzt werden können! 15 16

5 4.1 Interface-Definition-Language (7) 4.1 Interface-Definition-Language (8) xception-definition Parameterdeklaration (fortges.) Definition einer Ausnahme: exception name memberdef } Beispiel: Kontoschnittstelle mit out-parametern Komponenten ähnlich wie in einer Struktur Operationen interface Account readonly attribute double balance; aufrufbare Methode: resulttype name ( parameters ) [ raises exceptionlist ] als rgebnistyp auch void benutzbar: kein rgebnis exceptionlist ist mit Komma getrennte Liste von xception-namen Parameterdeklaration mit Komma getrennte Liste von Parameterdeklarationen: [ in out inout ] type name void withdraw( in double amount, out double balance ) raises WrongAccountNumber; void deposit( in double amount, out double balance ) raises WrongAccountNumber; eingehende, ausgehende Parameter und beides Typ void für kein Rückgabewert bei Operationen mehrere rgebniswerte pro Operation möglich Interface-Definition-Language (9) 4.1 Interface-Definition-Language (10) Objekttypen Konstantendefinition Namen von Schnittstellen (Interfaces) stehen für Objekttypen Name wird mit konstantem Wert verbunden Parameter und Attribute können Objekttyp haben z.b. const double limit = ; z.b.: attribute Account bankaccount; Name limit kann dann als Konstante verwendet werden bankaccount kann Referenzen auf CORBA-Objekte vom Typ Account speichern Parameterübergabesemantik Basistypen, komplexe Typen: Call-by-Value Objekttypen: Call-by-Object-Reference Moduldefinitionen Beispiel: module CORBA... } Verschachtelung der Module möglich innerhalb der Moduldefinition können definiert werden: Module seit CORBA 2.3 auch Value-Types ähnlich Objekttypen aber Call-by-Value-Übergabe xceptions Konstanten Schnittstellen Typen (typedef u.a.) 19 20

6 4.1 Interface-Definition-Language (11) 4.1 Interface-Definition-Language (12) Vererbung Vererbung (fortges.) Schnittstellen können voneinander erben Diamond-Shape-Inheritance möglich 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 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 Interface-Definition-Language (13) 4.1 Interface-Definition-Language (14) Namensräume Namen Module, Strukturen, xceptions, Varianten und Schnittstellen spannen neuen Namensraum auf innere Namen verdecken äußere Namen qualifizierte 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 Namen des umgebenden Modules etc. verknüpft mit lokalem Namen durch doppelten Doppelpunkt in verbotene Namen (wg. Schlüsselworte) können durch Voranstellen eines Unterstrichzeichens verwendet werden z.b. CORBA::BAD_PARAM (bestimmte System-xception) z.b. _module oder _Object 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 23 24

7 4.1 Interface-Definition-Language (15) 4.1 Interface-Definition-Language (16) Umsetzung von in Sprachkonstrukte (z.b. C++) Umsetzung von in Sprachkonstrukte (z.b. Java) module MyModule interface MyInterface attribute long lines; void printline( in string toprint ); namespace MyModule C++ class MyInterface :... public: virtual CORBA::Long lines(); virtual void lines( CORBA::Long _val ); void printline( const char *toprint );... 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 ); ); Interface-Definition-Language (17) 4.2 Objekterzeugung Vorteile Beschreibung der -Schnittstelle Schnittstellenbeschreibung unabhängig von Implementierungssprache ermöglicht Unterstützung vieler Programmiersprachen Nachteile Objektschnittstelle muss in und in der Implementierungssprache beschrieben werden (letzteres kann teilweise automatisiert werden) 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 beschrieben werden können, können nicht genutzt werden Implementierung des realisiert ein (oder auch mehrere) CORBA-Objekt(e) Auswahl einer Programmiersprache Umsetzung der -Schnittstelle in ein Skeleton Definition Precompiler Skeleton Compiler Code Skeleton wird in der Regel ausgefüllt mit Implementierungscode Prä-Compiler wird häufig -Compiler genannt 27 28

8 4.2 Objekterzeugung (2) 4.2 Objekterzeugung (3) Instanziieren des CORBA-Objekts Herausgabe der Objektreferenz Instanziieren der -Implementierung Aktivierung des s 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 Aufruf von servant_to_reference am POA liefert Objektreferenz auf CORBA-Objekt (nicht ) Realisierung der Objektreferenz ist sprachabhängig z.b. in Java: Stellvertreterobjekt (lokaler Stellvertreter ist optimiert) einfacher Nutzung des s bei Parameterübergabe übergibt letztlich Objektreferenz implizite Aktivierung Betriebsart des POA Übergabe des als Parameter aktiviert automatisch den, falls noch nicht geschehen Beachte: Aktivierung ist identisch zum xportieren in Java RMI Objektnutzung 4.3 Objektnutzung (2) rzeugung eines Stubs mpfang eines Parameters mit Objekttyp Auswahl einer Programmiersprache für die Client-Seite Umsetzung der -Schnittstelle in einen Stub Definition Stub Stub Code automatische rzeugung 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 Precompiler Compiler Parameterübergabe Objekttypen: Übergabe der Objektreferenz Basistypen: Übergabe des abgebildeten Sprach-Datentyps komplexere Typen: Übergabe sprachabhängig 31 32

9 4.3 Objektnutzung (3) 4.3 Objektnutzung (4) Parameterübergabe (fortges.) Typumwandlung Übergabe bei out und inout Parametern sprachabhängig Problem: Programmiersprachen kennen meist keine Möglichkeit mehrere rgebnisse zurückzugeben z.b. Java: infü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 rgebnisparameter kann aus Holder-Objekt ausgelesen werden Objektreferenz kann einen Typ aus der Vererbungshierarchie der Schnittstellen besitzen wahrer Objekttyp kann spezifischer in der Vererbungshierarchie sein rzeugung 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 Objektnutzung (5) 4.4 Initialisierung der Anwendung Sprachabhängige Code-Generierung Initiale entfernte Objektreferenzen z.b. in Java wird aus -Beschreibung neben Stub und Skeleton auch Holder- und Helper-Klasse generiert Definition Skeleton Code 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 Precompiler Stub Hilfsklasse Compiler Stub Code Hilfsklassen Code 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

10 5 Object-Adaptor 5.1 Portable-Object-Adaptor (POA) Aufgaben des Objektadapters Jeder kennt seine POA-Instanz Generierung der Objektreferenzen POA-Instanz kennt die an ihm angemeldeten Objekte ntgegennahme eingehende Methodenaufruf-Anfragen Weiterleitung von Methodenaufrufen an den entsprechenden POA stellt Kommunikationsplattform bereit und nimmt Aufrufe entgegen (für seine Objekte) Aktivierung und Deaktivierung von s Authentisierung des Aufrufers (im Security-Service) Server Obligatorischer Adapter: Portable-Object-Adaptor definierte Funktionalität für die häufigsten Aufgaben Alternative Adapter: z.b. für objektorientierte Datenbank POA ORB Core Skeleton Aufruf verbindet Datenbank mit CORBA Adapter exportiert Objekte der Datenbank als CORBA-Objekte und sorgt für Vermittlung POA-rzeugung 5.2 POA-rzeugung (2) Root-POA existiert in jedem ORB Policy-Objekte voreingestellte Konfiguration am POA-Interface zu erzeugen kann zur Aktivierung von Objekten verwandt werden Referenz auf Root-POA Anfrage am ORB mit: orb.get_initial_reference( RootPOA ); Angabe einer bestimmten Policy für eine Policy-Kategorie (entspricht Konfigurationsparameter) bei rzeugung eines POA werden vorab erzeugte Policy-Objekte als Konfiguration übergeben Weitere POAs mit unterschiedlichen Konfigurationen erzeugbar rzeugung am RootPOA bzw. an untergeordnetem POA (Vater-POA) neuer POA bekommt eigenen Namen (String) Beispiel: Policy für Implicit-Activation-Policy rzeugung am POA mit Aufruf von create_implicit_activation_policy() baumförmige, hierarchische POA-Struktur mit Wurzel beim Root-POA mögliche Policies (übergeben als Parameter) POA-Instanzen teilen sich Kommunikationskanal IMPLICIT_ACTIVATION für implizite Aktivierung Objektreferenz enthält POA-Name: POA kann ermittelt werden NO_IMPLICIT_ACTIVATION für explizite Aktivierung 39 40