k. corba - Verteilte Systeme

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, 2009/10, P. Schulthess,VS, Universität Ulm
6-1
K.1.2 Zielsetzung
Verteilte objektbasierte Programmierung:
verteilte Objekte mit definierter Schnittstelle
Obj
Obj
Obj
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.
Middleware
OS OS
OS
OS
Freiheitsgrade bei der Middleware-Implementierung:
CORBA schreibt keine Implementierung vor, sondern die Funktionalität,
CORBA fordert Interoperabilität verschiedener Implementierungen,
Partielle Implementierung zulässig.
Verteilte Betriebssysteme, 2009/10, P. Schulthess,VS, Universität Ulm
6-2
K.2 OMA - Object Management Architecture
ORB als “Softwarebus” bzw. „Komponentenbus“:
Vertikale
Vertikale
VerticalFacilities
Facilities
Facilities
Anwendungsobjekte
Horizontal
Facilities
ORB
CORBA Services
Verteilte Betriebssysteme, 2009/10, P. Schulthess,VS, Universität Ulm
6-3
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, 2009/10, P. Schulthess,VS, Universität Ulm
6-4
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, 2009/10, P. Schulthess,VS, Universität Ulm
6-5
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, 2009/10, P. Schulthess,VS, Universität Ulm
6-6
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)
Interface
Repository
DII
IDL Stubs
GIOP / IIOP
Verteilte Betriebssysteme, 2009/10, P. Schulthess,VS, Universität Ulm
Skeleton
ORB Intf.
DSI
Object Adapter
ORB Core
Implementation
Repository
Klient
6-7
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, 2009/10, P. Schulthess,VS, Universität Ulm
6-8
K.2.6 OA bzw. Objekt-Adapter
Sprachspezifische Objektschnittstelle an ORB-Kernfunktionen anpassen.
Bestandteil des ORB.
Server
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.
Servant
OA
Skeleton
Aufruf
ORB Core
Skeleton:
Entgegennahme eingehender Methodenaufruf-Anfragen
Weiterleitung von Methodenaufrufen an den entsprechenden Servant
Verteilte Betriebssysteme, 2009/10, P. Schulthess,VS, Universität Ulm
6-9
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, 2009/10, P. Schulthess,VS, Universität Ulm
6-10
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, 2009/10, P. Schulthess,VS, Universität Ulm
6-11
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.
CORBA::Object
Create_request
MyInterface
CorbaRequest::
Invoke()
Übergabe der Parameter gekapselt im Request-Objekt:
eigentlicher Aufruf wird durch invoke() am Request-Objekt ausgeführt
Verteilte Betriebssysteme, 2009/10, P. Schulthess,VS, Universität Ulm
6-12
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, 2009/10, P. Schulthess,VS, Universität Ulm
6-13
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, 2009/10, P. Schulthess,VS, Universität Ulm
6-14
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.
Object
POA
Server
Identifier
Identifier
spec.
Info
IIOP Host Port
Version ID number
Object
Key
Components
IOR
Repository ID
Verteilte Betriebssysteme, 2009/10, P. Schulthess,VS, Universität Ulm
Profile
ID
Profile
Data
...
Next
Profile
6-15
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, 2009/10, P. Schulthess,VS, Universität Ulm
6-16
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, 2009/10, P. Schulthess,VS, Universität Ulm
6-17
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, 2009/10, P. Schulthess,VS, Universität Ulm
6-18
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, 2009/10, P. Schulthess,VS, Universität Ulm
6-19
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, 2009/10, P. Schulthess,VS, Universität Ulm
6-20
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, 2009/10, P. Schulthess,VS, Universität Ulm
6-21
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, 2009/10, P. Schulthess,VS, Universität Ulm
6-22
K.5 Interface-Definition-Language
K.5.1 Schnittstellenkonzept
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, 2009/10, P. Schulthess,VS, Universität Ulm
6-23
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, 2009/10, P. Schulthess,VS, Universität Ulm
6-24
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 AccountVal{
Valuetype in IDL:
public short accoutnNr;
Valuetype wäre in C++ schwierig,
private double balance;
auch Vererbung möglich,
auch abstrakte
double withdraw( in double amount ) ;
double deposit( in double amount );
factory init( in short accountNr );
}
Verteilte Betriebssysteme, 2009/10, P. Schulthess,VS, Universität Ulm
6-25
K.5.4 Beispiel: Umsetzung von IDL in C++ Sprachkonstrukte
ID L
C++
Verteilte Betriebssysteme, 2009/10, P. Schulthess,VS, Universität Ulm
6-26
Beispiel: Umsetzung von IDL in Sprachkonstrukte (z.B. Java)
ID L
Java
C++
Verteilte Betriebssysteme, 2009/10, P. Schulthess,VS, Universität Ulm
6-27
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, 2009/10, P. Schulthess,VS, Universität Ulm
6-28
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, 2009/10, P. Schulthess,VS, Universität Ulm
6-29