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

Transkript

1 D CORBA D.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 D.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 nur Funktionalität CORBA fordert Interoperabilität verschiedener Implementierungen Anbindung an Altsysteme (Legacy) CORBA-Anwendungen sollen mit Altsystemen interagieren D.3 3 Object Management Architecture, OMA Komponenten der OMA Anwendungsobjekte Vertical Facilities Horizontal Facilities ORB Naming Properties Con- Collec- Security currency tions Persistence Life Cycle Trader Externalization Events Transactions Query Relationships Time Change Licensing Management CORBA Services D.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 D 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 Objektimplementierung Implementation Repository DII IDL Stubs ORB Interf. Static Skeleton DSI POA ORB Core GIOP D.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 D 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,... D.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 D.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 D.10

6 5 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 D.11 5 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 D.12

7 5 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 D IDL-Typen 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 D.14

8 5.1 IDL-Typen (2) Komplexe Datentypen Typdefinition: typedef type name name wird für den evtl. zusammengesetzten Typ type definiert Strukturen: struct name { memberdef } memberdef definiert einzelne Variablen innerhalb der Struktur 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) D IDL-Typen (3) 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! D.16

9 5.2 Exceptions und Operationen 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 D Exceptions und Operationen (2) 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 keinen Rückgabewert bei Operationen D.18

10 5.3 Weitere IDL-Konstrukte 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 D Weitere IDL-Konstrukte (2) 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.) D.20

11 5.3 Weitere IDL-Konstrukte (3) Lokale Objekttypen Schnittstellen mit local-schlüsselwort Spezifikation von lokalen Systembestandteilen z.b. ORB-Interface früher Pseudo-Objekte D 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 D.22

12 5.4 Vererbung (2) Vererbung (fortges.) Diamond-Shape-Inheritance möglich Beispiel: interface A { long opa(); A interface B : A {... interface C : A {... interface D : B,C {... B D C Objekte vom Typ D besitzen eine Operation opa Schnittstellen erben automatisch von Object Basisoperationen von CORBA definiert D 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 D.24

13 5.5 Namensräume (2) 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 D Sprachabbildung 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 );... D.26

14 5.6 Sprachabbildung (2) Umsetzung von IDL in Sprachkonstrukte (z.b. Java) module MyModule IDL { 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 ); );... D Sprachabbildung (3) 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 D.28

15 6 CORBA-Objekte Systeminitialisierung in jedem Knoten muss eine ORB-Instanz initialisiert werden implementiert ORB-Interface Initialisierung ist sprachabhängig Beispiel Java: ORB orb = ORB.init(args, null); statische Initialisierungsfunktion bekommt Argumentliste und Menge von Properties erlaubt Einstellungen und Konfigurationen verschiedenster Art erlaubt die Unterscheidung mehrerer ORB-Instanzen D 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 D.30

16 6.1 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 D 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) implizite Umwandlung in Objektreferenz Übergabe einer Referenz auf den Servant als Parameter führt zur Umwandlung in 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 D.32