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