CORBA: Interoperabilität? Common Object Request Broker ...eris.prakinf.tu-ilmenau.de/edu/va/folien/VL3.pdf · CORBA – Client/Implementierung/Server • CORBA-Clients sind CORBA-Objekte
Post on 28-Oct-2019
11 Views
Preview:
Transcript
138�������� �� ��� ���� ����� ��������� 138�������
CORBA:Common Object Request Broker Architecture
Middleware-Architektur-Spezifikation der Object Management Group (OMG)
Überblick:
• Die Object Management Group (OMG)
• Das Objektmodell der OMG
• Die Object Management Architecture (OMA)
• Die ORB - Architektur (CORBA)
• Das CORBA Component Modell (CCM)
• Der Implementierungsablauf
13��������� �� ��� ���� ����� ��������� 13��������
Interoperabilität?
� „There will never be consensus on hardware plattforms;there will never be consensus on operating systems;there will never be consensus on network protocols;there will never be consensus on application formats, so there must be consensus on interoperability!”
• Zur verteilten Nutzung von Ressourcen und Daten ist eine Interoperabilität auf höherer Ebene unabdingbar.
• Um diese zu erreichen bedarf es einer gemeinsamen Plattform, einer Middleware
• Als Middleware dient bei der OMA der Object Request Broker
1���������� �� ��� ���� ����� ��������� 1���������
CORBA – die Idee
„Die Vision der Object Management Group ist eine Gesamtarchitektur zu erstellen, in der verschiedene Softwarekomponenten möglichst transparent und in heterogener Umgebung miteinander kommunizieren können.“
• CORBA ist eine Spezifikation der OMG für eine Middleware-Architektur
• Daraus entstand eine objektorientierte Umgebung zur Entwicklung und Unterstützung verteilter Anwendungen
• Erste Spezifikation 10/91, erste Vollimplementierung 7/93
• Zur Zeit aktuell: CORBA 3.0 (die meisten Produkte impl. CORBA 2.3)
1�1�������� �� ��� ���� ����� ��������� 1�1�������
Die Object Management Group
• Die OMG wurde 4/1989 von 13 Mitgliedern gegründet.
Ziel OMG: Effektivierung des Software-Entwicklungsprozesses, insbesondere– Portabilität,
– Wiederverwendbarkeit
– Interoperabilität.
• Aktuell über 800 Mitglieder (Firmen aus der Industrie und Universitäten), davon über 100 „Corporate Members“
1���������� �� ��� ���� ����� ��������� 1���������
CORBA – technische Ziele
Parallel zu den ideellen Zielen treten eine Reihe technischer Ziele auf:- Ortstransparenz- Gutes Antwortverhalten für lokale wie entfernte Aufrufe- Die dynamische Evolution von Objekten- Zugriff auch über Objektattribute/ Objektbeziehungen (nicht nur Name)
- Parallelisierung (Nebenläufigkeit bei Anfragen durch mehrere Clients)
Es soll also- Ein gemeinsames Referenzmodell für die objektorientierte Softwareentwicklung in
heterogenen verteilten Umgebungen bereitgestellt werden, um
- dadurch kompatible technologische Plattformen zu erhalten und so
- mit gemeinsamen Protokollen auf gemeinsame Schnittstellen zugreifen zu können.
1�3�������� �� ��� ���� ����� ��������� 1�3�������
Problem der Komplexität
• Um die Komplexität bewältigen zu können Einführung der OMA:
• Abbildung realer Objekte und Dienstleistungen auf Software-Objekte
• Ein CORBA-Objekt ist eine gekapselte Einheit (Daten und Methoden), welche über eine wohldefinierten Schnittstelle angesprochen wird.
Aber: ein CORBA-Objekt muss nicht objektorientiert erstellt sein, monolithische Systeme können gekapselt als CORBA-Objekte eingesetzt werden
1���������� �� ��� ���� ����� ��������� 1���������
Objektmodell der OMG
• Orientierung an klassischer OO
� Aufgrund der Eigenschaften der OO vereinfachte Entwicklung:- Kapselung (ADT-Paradigma): ADT hat eine sichtbare Schnittstelle und verbirgt
seine Implementierung �Wiederverwendbarkeit, Lokalität von Änderungen
- Vererbung: zuverlässiger, sicherer und ökonomischer als erneute Erstellung
- Kommunikation über Botschaften: Aufrufsemantik lokale und verteilt gleich
Ein CORBA-Objekt ist eine identifizierbare gekapselte Instanz, welche über ein oder mehrere Interface(s) Dienste anbietet
Alle CORBA-Objekte („verteilte Objekte“ ) können als Dienstnutzer oder Dienst-erbringer auftreten � erweitertes Client/Server-Modell
(bei jeder Kommunikationsbeziehung gibt es allerdings einen Client und einen Server)
1���������� �� ��� ���� ����� ��������� 1���������
CORBA – Client/Implementierung/Server
• CORBA-Clients sind CORBA-Objekte welche Operationen auf anderen Objekten aufrufen und ausführen.
• Objekt-Implementierungen sind CORBA-Objekte welche auf einem CORBA-Server residieren und deren Methoden nach eine Anforderung ausgeführt werden können.
• CORBA-Server sind Software-Komponenten in denen Objekt-Implementierungen residieren und deren Methoden ausgeführt werden können (Container/RE-Semantik)
1���������� �� ��� ���� ����� ��������� 1���������
Objektimplementierung
• Die Objektimplementierung beschreibt das Objektes durch– die Datendefinition für die Objektinstanz und
– den Code für die Objektmethoden
• Die OMG spezifiziert vier Objektimplementierungen, wobei drei vom Object Adapter aktiviert werden:
– shared Server (mehrere Objekte je Server-Prozeß)
– unshared Server (ein Objekt je Server-Prozeß)
– Server per method (je Methodenaufruf ein Server-Prozeß gestartet, der nach Ausführung wieder terminiert)
• Der permanent Server, als vierte spezifizierte Objektimplementierung, wird unabhängig vom ORB gestartet und ist ständig aktiv.
1���������� �� ��� ���� ����� ��������� 1���������
Client
• Der Client hat Zugriff auf Objektreferenzen.
• Erst mit der Objektreferenz wird der Zugriff auf die Dienste (über Objektoperationen) möglich.
• Der Client kennt nur die logische Struktur des Objektes entsprechend dem Interface und kann auf das Verhalten des Objektes nur über Operationsaufrufe einwirken.
� Clients haben keine Kenntnis über die Implementierung des Objekts, welcher Objektadapter oder welcher ORB für den Zugriff benutzt wird.
Objekt-Referenz (IOR)• Die Objekt-Referenz ist die Information, die zum Auffinden eines
Objektes innerhalb eines ORB‘s benötigt wird.� Sowohl Client als auch Objektimplementierung besitzen eine
eindeutige Notation der Objekt-Referenz entsprechend der Programmiersprache.
1�8�������� �� ��� ���� ����� ��������� 1�8�������
CORBA-ObjekteBegriffe
• Request– ein Ereignis, das zu einem beliebigen Zeitpunkt auftreten kann und dessen
Informationen ein Zielobjekt, eine Operation und bei Bedarf Parameter und gegebenenfalls einen Request Context enthalten
– Gefordert wird die Ausführung eines Dienstes für einen Client.
– Requestparameter sind durch ihre Position identifiziert.
• Interface– beschreibt die von einem Objekt über einen Zugangspunkt angebotenen
Operationen, die von den Clients genutzt werden können
– Interfaces werden in der IDL(Interface Definition Language) spezifiziert.
1���������� �� ��� ���� ����� ��������� 1���������
• Operation– ein identifizierbarer Eintrag im Interface, der auf einen Dienst verweist, der von
Clients über das Interface vom Objekt angefordert werden kann
– Eine Operation wird über einen Objektidentifikator identifiziert.
– Die Signatur beschreibt die erlaubten Parameter und Rückgabewerte.
• Parameter– wird durch seinen Modus (Eingabe und/oder Ausgabe; in, out, inout) und
seinen Typ charakterisiert
CORBA-ObjekteBegriffe
1���������� �� ��� ���� ����� ��������� 1���������
• Attribut– Interfaces können Attribute beinhalten.
– Attribut ist mit Zugriffsmethodenpaar, Get() und Set(), verbunden.
• Typ– Die Angabe eines Typs charakterisiert Parameter oder Rückgabewerte.
– Neben den Objekttypen unterscheidet man bei der OMG einfache Typen, wie zum Beispiel Short, Double, String, sowie die zusammengesetzten Typen Struct, Sequence, Union und Array.
CORBA-ObjekteBegriffe
1�1�������� �� ��� ���� ����� ��������� 1�1�������
Object Management Architecture– en detail
1���������� �� ��� ���� ����� ��������� 1���������
CORBA - Übersicht
1�3�������� �� ��� ���� ����� ��������� 1�3�������
CORBA – Grundstruktur
Object Request Broker Kernel
DynamicInvocationInterface
ClientIDLStub
ORBInterface
ServerIDL
Skeleton
DynamicSkeleton
Invocation
ObjectAdapter
Es kann mehrere Object Adapter geben.
ORB-spezifische Schnittstelle
standardisierte Schnittstelle (identisch für alle ORB‘s)
Client Object Implementation
mehrerer jeweils auf einen Objekttyp spezialiserte Schnittstellen
1���������� �� ��� ���� ����� ��������� 1���������
Übergabe des Client-Request an das Server-Objekt
• Der ORB– ermittelt den gewünschten Objektimplementierungs-Code
– übermittelt die Parameter des Requests und
– übergibt die Aktivitätssteuerung über das objektspezifische Interface-Gerüst oder über das dynamische Interface-Gerüst an die Objektimplementierung.
• Die Objektimplementierung– kann während der Ausführung des Auftrages weitere Dienste über den
Objekt-Adapter in Anspruch nehmen und
– übermittelt die Ergebniswerte und gibt die Aktivitätssteuerung ab, wenn der Auftrag erfüllt ist.
• Der Object Adapter implementiert die grundlegende Funktionalität zur Arbeit mit dem Server-Objekt.
1���������� �� ��� ���� ����� ��������� 1���������
Aufruf von Objektmethoden über Client IDL Stub
Object Request Broker Kernel
ClientIDLStub
Client
1���������� �� ��� ���� ����� ��������� 1���������
Dynamischer Aufruf von Objektmethoden
Object Request Broker Kernel
DynamicInvocationInterface
ClientInterface
Repository
1���������� �� ��� ���� ����� ��������� 1���������
Weiterleitung eines Client-Requests über IDL Skeleton
Object Request Broker Kernel
ObjectAdapter
ObjectImplementation
ImplementationRepository
ServerIDL
Skeleton
1�8�������� �� ��� ���� ����� ��������� 1�8�������
Dynamische Weiterleitung eines Client-Requests
Object Request Broker Kernel
DynamicSkeleton
Invocation
ObjectAdapter
ObjectImplementation
ImplementationRepository
1���������� �� ��� ���� ����� ��������� 1���������
Interoperabilität zwischen ORB‘s
Client
ORB A
Proxy(Server)
Proxy(Client)
ORB B
Server-Objekt
IOP
ORB A generiert ein Proxy-Objekt (Server), welches auf der einen Seite das Interface des gewünschten Server-Objektes (Dynamic SkeletonInvocation) und auf der anderen Seite ein Inter ORB Protokollunterstützt.ORB B generiert analog dazu ein Proxy-Objekt (Client) für den Zugriff auf das Server-Objekt (Dynamic Invocation Interface) und für die Kommunikation mit ORB A.
GIOP-General Inter ORB ProtocolIIOP-Internet Inter ORB ProtocolESIOP-Environment Specific IOP
1���������� �� ��� ���� ����� ��������� 1���������
Anwendungsbeispiele und existierende Produkte
• kommerziell:– Visibroker von Borland (und Visigenic)
– Component Broker von IBM
– ...
• kostenlos:– TAO ACEOrb (C++,..; Corba2.5)
– JacOrb (Java; Corba2.3)
– mico (C++,...; Corba2.2)
– ominorb (C++, Python...; Corba2.6)
– Java IDL von Sun Microsystems (Corba2.2)
– ...
• Anwendungsbeispiele:– Success Stories: www.corba.org/succ.htm
1�1�������� �� ��� ���� ����� ��������� 1�1�������
Applikationsentwicklung mit IDL
IDL Schnittstellen Definition
IDL Compiler
Client StubsServer
Skeletons
InterfaceRepository
Language Compiler
Client ProgramObject
Implementation
Object Request Broker
Stub Skeleton
Client Program Object Implementation
ImplementationRepository
1���������� �� ��� ���� ����� ��������� 1���������
Interface Definition Language - IDL
� Unabhängigkeit der Definition der Schnittstellen von der benutzten Programmiersprache für
– sowohl Schnittstellen der OMA als auch
– der Server-Objekte des Applikationsentwicklers
• Umsetzung zwischen der IDL-Schnittstellenbeschreibung und der gewählten Implementierungssprache: Mapping für
– C, C++, Smalltalk, Java, Ada, Cobol, ...
• Die Menge der Schlüsselwörter von IDL ist eine Untermenge des ANSI C++ Standards.
• Einführung neuer Schlüsselwörter
• keine Konstrukte zur Ablaufsteuerung nötig (deskriptiv)
• Vererbung von bereits existierenden Schnittstellen
• lexikalische Regeln wie bei C++
1�3�������� �� ��� ���� ����� ��������� 1�3�������
IDL: Beispiel
module BauamtApp {interface Antrag;interface Briefkasten;interface Person;interface Beamter;
interface Antrag {enum Typ {Neubau, Umbau, Sprengung};attribute string datum;attribute Person antragsteller;
const short max = 1000;typedef string Zeilen[max];attribute Zeilen inhalt;
};
1���������� �� ��� ���� ����� ��������� 1���������
IDL: Beispiel
interface Briefkasten {void einreichen (in Antrag neuerAntrag);
};
interface Person {struct Name {string Vorname;string Nachname;
};union Adresse switch(short) {case 0: string Strasse;case 1: short Postfach;default: string Anschrift;
};void setzeDaten(in Name name, in Adresse adresse);void holeDaten(out Name name, out Adresse adresse);
};
1���������� �� ��� ���� ����� ��������� 1���������
IDL: Beispiel
interface Beamter : Person {typedef sequence <Antrag> AntragSequence;typedef sequence <Antrag, 50> AntragSequence50;AntragSequence stapel();
readonly attribute double Gehalt;
exception Feierabend {string arbeitszeit;
};
void bearbeite(in Antrag antrag)raises(Feierabend);
};
};
1���������� �� ��� ���� ����� ��������� 1���������
Überblick: CORBAservices
• Naming Service– Auffinden von Objekten im Netz
• Event Service– Behandlung asynchroner Ereignisse
• Life Cycle Service– Regelung des Erzeugens, Kopierens, Verschiebens und des Löschens von
Objekten
• Persistance Service– langfristige Speicherung von Objektzuständen
• Security Service– Schutz des Systems vor unerlaubter Benutzung
• Time Service– Synchronisation von Uhren
1���������� �� ��� ���� ����� ��������� 1���������
Überblick: CORBAservices
• Concurrency Control Service– Koordinierung von nebenläufigen Aktivitäten (Lock-Manager)
• Transaction Service– flache und geschachtelte Transaktionen auf Objekte
• Relationship Service– dynamische Erstellung von Verbindungen zwischen Objekten, ohne daß
diese Komponenten davon Kenntnis haben, und Traversierung der entstandenen Strukturen
• Externalization Service– Einlesen/Ausgeben der Daten eines Objektes aus/in einem/einen Stream
• Query Service– Manipulation definierter Collections von Objekten durch die Object Query
Language (OQL) beziehungsweise die Structured Query Language (SQL3)
1�8�������� �� ��� ���� ����� ��������� 1�8�������
Überblick: CORBAservices
• Licensing Service– Überprüfung und Abrechnung der Verwendung von Objekten
• Properties Service– Verbindung von named values (properties) mit beliebigen Objekten, z.B. abhängig
vom Zustand des Objektes
• Trading Object Service– Anbieten (Anmelden) / Anfordern (Auffinden) von speziellen Diensterbringern zur
Laufzeit
• Collections Service– Funktionen zur Verwaltung verschiedenartiger Mengen von Objekten (Collections),
wie zum Beispiel Listen, Stacks, Baumstrukturen
1���������� �� ��� ���� ����� ��������� 1���������
Überblick: CORBAfacilities
• Bereiche für CORBAfacilities:– User Interface
• z.B. Dienste für Ein- und Ausgabe von Verbunddokumenten
– Information Management• z.B. Dienste für unternehmensweite Datenhaltung, wie z.B. Konvertierung und
Komprimierung
– Systems Management• administrative Dienste, wie z.B. Verwaltung von Zugriffsrechten
– Task Management• Dienste zur Unterstützung von Benutzeraufgabe, wie z.B. die Einbindung mobiler und
stationärer Agenten
1���������� �� ��� ���� ����� ��������� 1���������
CORBA 3
• Die Weiterentwicklungen betreffen 3 Kategorien:– Internet Integration
– Quality of Service in CORBA
– CORBAcomponent Architektur (nächste Veranstaltung!)
• Die erforderlichen Spezifikationen sind größtenteils verfügbar.
• Die Integration in die Produkte erfolgt zur Zeit
1�1�������� �� ��� ���� ����� ��������� 1�1�������
Internet Integration
• Firewall Specification– Internet Inter ORB Protocol (IIOP): Port 683 und
Internet Inter ORB Protocol over SecureSocket Layer(IIOP over SSL): Port 684
– Restriktionen für Call Backs vom Server zum Client
• Interoperabler Name Service– Objekt-Referenzen im URL-Format: iioploc, iiopname
– Beispiel: iioploc://www.tu-ilmenau.de/NameService
1���������� �� ��� ���� ����� ��������� 1���������
Quality of Service in CORBA
• Asynchronous Messaging und Quality of Service Control– Polling oder Callbacks
– Einordnung nach Zeit, Priorität oder Deadline
– Setzen von Priorität, Deadline, Time-to-Live, Start- und Endzeit
– Beeinflussung von Routingstrategien und Vorgabe von Routen im Netz
• Minimum CORBA– für eingebettete Systeme
• Real-Time CORBA– Prioritätsgesteuerte Verwaltung von Ressourcen, wie zum Beispiel Threads
und Verbindungen, in Echtzeitumgebungen
• Fault-tolerant CORBA– Redundanz und Fehlermanagement
top related