Einführung in CORBA Fachseminar Informations- und Kommunikationssysteme SS99 MartinVogt, IIIC, 8....

Einführung in CORBA

FachseminarInformations- und Kommunikationssysteme

SS99

MartinVogt, IIIC, 8. Semester

Martin Vogt CORBA 2

Object Management Group (OMG)

• Standartisierungsgremium.

• Im Mai 1989 durch acht Firmen gegründet.

• Heute: über 800 Mitglieder.

– Ausnahme: Microsoft mit Konkurrenzprodukt DCOM.

• Aufgabe: Sammeln und Aufarbeiten von technologischem Know-how für Entwicklung verteilter, aus Objekten aufgebauter Software.

• 1991: CORBA 1.0

– IDL, Language-Mapping und Schnittstellen zum ORB.

• 1994: CORBA 2.0

– IIOP: Zusammenspiel zwischen ORBs verschiedener Hersteller.

• 1998: CORBA 3.0

– Java und Internet-Integration.

– QoS Managment.

Martin Vogt CORBA 3

Interface Definition Language (IDL)

• Mittel zur Beschreibung der Interfaces:

– Betriebssystem- und sprachunabhängig.

– Spezifiziert Parameter, Rückgabewerte.

• An C++ angelehnt:

– Preprozessing: include, define

– Kommentare: /* */, //

– Basistypen: boolean, char, double, float, Object, string, short, ...

– Strukturen: struct, union, enum, array, ...

– Exceptions

– Vererbung

– keine Pointer, kein Überladen von Operationen, ...

• Enthält keine Implementierungsdetails.

• Language Mapping: IDL-Konstrukten durch Precompiler äquivalente Konstrukte einer Programmiersprache zuordnen.

Martin Vogt CORBA 4

IDL: Ein Beispiel

module Bank {interface Account {

exception NoFunds {};exception NonZeroBalance {};void Deposit(in long amount);void Withdraw(in long amount) raises(NoFunds);long GetBalance();void Close() raises(NonZeroBalance);

};},

Martin Vogt CORBA 5

Objektreferenz

• Eindeutiger Name oder Kennung in einem verteilten ORB-System.

• Wird dem Objekt bei dessen Kreierung vom ORB zugewiesen und bleibt solange gültig, bis das Objekt explizit gelöscht wird.

• Implementierung von Objektreferenzen nicht durch Spezifikation festgelegt.

• CORBA 2.0: Interoperable Object Reference (IOR):

– Muss von Anbietern benutzt werden, um Objektreferenzen über heterogene ORBs weiterzugeben.

• Isolation von Implementation und Objektreferenz:

– Referenz ist nicht einfach eine Netzwerk- oder Speicheradresse des Objekts.

– ORB ist dafür verantwortlich, für eine gegebenen Referenz die jeweilige Implementierung zu lokalisieren (z. B. über das Implementation Repository).

Martin Vogt CORBA 6

Object Management Architecture

Object Request Broker (ORB)

ApplicationObjects

CORBAfacilitiesVertical Common Facilities

Horizontal Common Facilities

CORBAservicesNaming

Trader

Life Cicle

Transaction

Concurrency

Licensing

TelecommunicationUser

Interface

Martin Vogt CORBA 7

Eigenschaften des ORBs

• Statische und dynamische Methodenaufrufe:

– Methodenaufrufe statisch beim Kompilieren definieren oder dynamisch zur Laufzeit „entdecken“.

• Freie Wahl von Programmiersprachen:

– Aufrufe durch Sprache Ihrer Wahl unabhängig von Implementationssprache des Servers durch Trennung von Schnittstelle und Implementierung.

– Sprachenunabhängige Datentypen.

• Selbstbeschreibendes System:

– Interface Repository als Verzeichnis der Schnittstellen, die von Servern angebotene Methoden und deren Parameter beschreiben (in IDL).

• Ortstransparenz:

– Vermittelt Aufrufe zwischen Objekten innerhalb eines Prozesses oder Prozessen, die an verschiedenen Orten im Netz unter verschiedenen Betriebssystemen laufen vollkommen transparenz.

Martin Vogt CORBA 8

Aufbau des ORBs

Object Request Broker (ORB) Core

DynamicInvocation

ClientIDLStub

StaticSkeletons

ORBInterface

DynamicSkeletonInterface

InterfaceRepository

ImplementationRepository

ClientObject

Implementation

ObjectAdapter

Martin Vogt CORBA 9

Interface Repository

• Enthält alle Metadaten über Objekte, Services und den ORB selbst (in IDL).

• Laufzeitdatenbank mit IDL-generierter Information, die sich abfragen lässt und aktualisierbar ist.

• Als Satz von Objekten implementiert, die die Information in sich tragen.

• Schnittstelle für die IDL-Strukturen:

– ModuleDef: logische Gruppierung von Schnittstellen (Namensraum).

– InterfaceDef definiert Schnittstelle der Objekte.

– OperationDef definiert Methode eines Objekts.

– ParameterDef definiert Argument einer Methode.

– AttributeDef definiert Attribut einer Schnittstelle.

– ConstantDef definiert eine benannte Konstante.

– ExceptionDef definiert eine Exception, die bei einer Operation auftreten kann.

– TypeDef definiert die benannten Typen, die Teil der IDL-Definition sind.

Martin Vogt CORBA 10

Implementation Repository

• Enthält Information über die von einem Server unterstützten Klassen, den Objektinstanzen und ihren Referenzen.

• Gemeinsamer Speicher für zusätzliche Information, z. B. mit welchem Kommando ein bestimmter Server zu aktivieren ist.

• Wird vom ORB verwendet, um aktive Objekte zu lokalisieren.

• Hängt stark von der jeweiligen CORBA-Plattform ab.

ImplementationRepository


Objektadapter

• Objektadapter sind verantwortlich für:

– Registrieren von Implemenationen im Implementation Repository.

– Generieren und Interpretieren von Objektreferenzen.

– Zuordnen von Objektreferenzen zu ihren jeweiligen Implementationen.

– Aktivieren und Deaktivieren von Objektimplementationen.

– Aufruf von Methoden via Skeleton oder DSI und Übergabe von Parametern.

• Basic Object Adapter (BOA):

– 4 Aktivierungsverfahren:

• BOA-Shared-Server: Mehrere Objekte laufen als Threads im selben Prozess.

• BOA-Unshared-Server: Für jedes Objekt wird ein eigener Prozess gestartet.

• BOA-Server-per-Method: Für jede Anfrage wird ein neuer Prozess gestartet. Server laufen nur für die Dauer einer bestimmten Methode. Es können gleichzeitig mehrere Prozesse für dasselbe Objekt aktiv sein.

• BOA-Persistent-Server: Prozesse werden von ausserhalb des BOA aktiviert (von Hand). Arbeitet danach als Shared-Server.


Statischer Aufruf: IDL Stub und Skeleton

• Durch IDL-Compiler generiert.

• Abhängig von Implementierung und OS.

• Stub:

– Statisches Interface für Objektdienste auf Klientenseite.

– Marshalling/Demarshalling.

– Lokaler Proxy: Akzeptiert Aufrufe von Klients für entfernte Objekte, als ob es lokale Aufrufe wären.

• Skeleton:

– Statisches Interface: Nimmt Methodenaufrufe für Serverobjekt entgegen.

– Marshalling/Demarshalling.

• Vorteile gegenüber dynamischem Aufruf:

– Leichter zu programmieren: Aufruf über Namen mit Parameter.

– Robustere Prüfung der Datentypen beim Compilieren des Klienten.

– Bessere Performance: nur ein einziger API-Aufruf.


Dynamic Invocation Interface (DII)

• Ermöglicht es dem Klienten, sich irgendein Zielobjekt zur Laufzeit auszuwählen und dann dynamisch seine Methode aufzurufen.

• Keine vorkompilierten Stubs nötig.

• Klient entdeckt schnittstellenrelevante Informationen zum Zeitpunkt des Aufrufes.

• Klient muss sich zuerst Objektreferenz verschaffen.

Name der Schnittstelle verschaffen: get_interface()

Methodenbeschreibung verschaffen: lookup_name() describe()

Argumentliste erzeugen: create_list() add_item() ... add_item() ... add_item()

Anfrage erzeugen: create_request(Object Reference,

Method, Argument List)

Entfernte Objektmethode aufrufen: synchron: invoke()

verzögert synchron: send_deferred()get_response()

oneway: send_oneway()

Objekt

InterfaceRepository

3 Möglichkeiten für entfernte Aufrufe


Dynamic Skeleton Interface (DSI)

• Gegenstück zu DII auf der Serverseite.

• Bietet Laufzeit-Verknüpfungsmechanismus für Server, die eingehende Methodenaufrufe für Komponenten bearbeiten müssen, die keine IDL-basierten kompilierten Skeletons haben.

• Das dynamische Skeleton analysiert die Parameterwerte in einer ankommenden Nachricht, um herauszufinden, für welches Objekt und welche Methode sie gedacht ist.

• Anwendungsbeispiele:

– Nützlich für Implementierung von Bridges zwischen verschiedenen ORBs.

– Von Interpretern und Script-Sprachen dazu verwendet, um dynamisch Objektimplementierungen zu erzeugen.


ORB Interface

• Einige wenige API-Funktionen für lokale Dienste: z. B.

– ORB_init: Gibt eine Referenz zum ORB zurück, um nachher Methoden des ORB-Pseudoobjekts aufrufen zu können.

– Object_to_string: Wandelt eine Objektreferenz in einen String um, um diese z. B. in Festspeicher ablegen zu können..

– String_to_object: Wandelt einen String in eine Objektreferenz um.

– Get_service_information: Wird gebraucht, um Information über CORBAfacilities und Dienste zu erhalten, die von diesem ORB unterstützt werden.

– List_initial_services: Gibt eine List mit Namen zurück von verfügbaren Diensten.

– Resolve_initial_references: Gibt zu einem Servicenamen die entsprechende Objektreferenz zurück.

– u. a.


Inter-ORB Architektur

• General Inter-ORB Protocol (GIOP):

– Spezifiziert eine Menge von Nachrichtenformaten und Datendarstellungen für die Kommunikation zwischen den ORBs.

– Kann direkt über jedes verbindungsorientierte Transportprotokoll arbeiten.

– Definiert sieben Nachrichtenformate, die die gesamte request/response-Semantik der ORBs abdecken.

– Mittels Common Data Representation (CDR) werden Datentypen, die in IDL definiert wurden, in eine einfache Nachrichtendarstellung für Netzwerke abgebildet.

• Internet Inter-ORB Protocol (IIOP):

– Legt fest, wie GIOP-Nachrichten über ein TCP/IP-Netzwerk ausgetauscht werden.

– Ermöglicht, das Internet selbst als Backbone-ORB zu verwenden, durch das mehrere ORBs verbunden werden können.


CORBA Services (1)

• Der Naming Service bildet von Menschen vergebene Namen auf Objektreferenzen ab.

• Der Life Cycle Service stellt Operationen zur Erzeugung, zum Kopieren, Verschieben und Löschen von Objekten bereit.

• Der Event Service ermöglicht es Objekten, ihr Interesse an bestimmten Ereignissen dynamisch registrieren zu lassen.

• Der Trader Service stellt „Gelbe Seiten“ für Objekte zur Verfügung. Er erlaubt Objekten, ihre Dienste zu veröffentlichen.

• Der Transaction Service ermöglicht es verschiedenen verteilten Objekten, an einer atomaren Transaktion teilzunehmen. Er unterstützt auch verschachtelte Transaktionen.

• Der Concurrency Control Service ermöglicht Objekten den Zugriff auf gemeinschaftlich genutzte Ressourcen mit Hilfe von Sperren (Locks). Ein Objekt muss eine entsprechende Sperre des Dienstes besitzen, bevor sie auf eine geteilte Ressource zugreift.

• Der Security Service stellt einen ganzen Satz von Sicherheitsmechanismen bereit. Er unterstützt z. B. Authentifizierung und Zugriffskontrolle.


CORBA Services (2)

• Der Persistent Object Service ermöglicht es Objekten, auch dann dauerhaft zu existieren, wenn die Applikation, die das Objekt erzeugt hat, beendet wurde.

• Der Externalization Service definiert Schnittstellen, um Objekte in einen Datenstrom umzuwandeln und sie aus einem Datenstrom zurückzuholen.

• Der Query Service definiert Operationen für Objektabfragen mit SQL3 und OQL ähnlichen Sprachen.

• Der Collection Service ermöglicht es, Objekte in Gruppen zu manipulieren. (Arrays, Bäume, Stacks, ...)

• Der Relationship Service ermöglicht die Definition von Beziehungen zwischen Objekten.

• Der Time Service stellt z. B. Interfaces zur Verfügung, um sich in einer verteilten Umgebung miteinander zu synchronisieren oder zeitabhängige Ereignisse zu definieren.

• Der Licensing Service lässt Sie z. B. die Nutzungsdauer von Komponenten messen und entsprechend abrechnen.

• Der Property Service erlaubt es, einem Objekt dynamisch eine Eigenschaft zuzuweisen (z. B. einen Titel oder ein Datum).


CORBAfacilities

• Sind Sammlungen von IDL-definierten Komponenten, die Dienste anbieten, die für Applikationsobjekte von direktem Nutzen sind.

• Sie werden unterteilt in horizontale und vertikale Komponenten.

• Horizontale Komponenten werden in vier Bereiche gegliedert:

– User Interface: Komponenten, die ein Informationssystem zugänglich machen für die User, z. B. Präsentation von Objekten am Bildschirm, GUI.

– Information Management: Komponenten für das Modellieren, Definieren, Speichern, Managen und Austauschen von Informationen.

– System Management: Komponenten für das Managen von komplexen Informationssystemen.

– Task Management: Komponenten für das Automatisieren von Arbeitsprozessen, sowohl System- wie auch Benutzerprozessen.

• Verschiedene Gruppen arbeiten an den sogenannten Vertical Market Facilities:

– Geldwesen/Banken, Öl und Gas, Telekommunikation, Gesundheitswesen, etc.


CORBA 3.0• Neue Spezifikationen in CORBA 3.0:

– Java und Internet Integration:

• Ein Java-zu-IDL-Mapping für die automatische Generation von IDL stubs und skeleton aus Java-Objekten.

• Firewall-Spezifikation für Aufrufe von CORBA-Objekten durch Firewalls.

– QoS-Kontrolle:

• Erlaubt Klienten und Objekten verschiedene QoS-Parameter zu kontrollieren: Prioritäten, Deadlines, Time-To-Live.

– CORBAcomponents:

• Umgebung definierbar, in der alle Komponenten persistent, transaktional und sicher sind.

– Asynchronous and Messaging Invocation (AMI): Diese Spezifikation definiert eine Anzahl von asynchronen Aufruf-Modi für CORBA. (z. B. Warteschlangen)

– Minimum, Fault-Tolerant and Real-Time CORBA.

– Objekte, die by value übergeben werden können.


Referenzen• Bücher:

– Siegel J., “CORBA Fundamentals and Programming“, John Wiley & Sons, Inc., New York, 1996.

– Redlich J.-P., “Corba 2.0: Praktische Einführung für C++ und Java“, Addison-Wesley, Bonn, 1996.

– Orfali R., Harkey D., Edwards J., “Instant CORBA“, Addison-Wesley, Bonn, 1998.

– Orfali R., Harkey D., Edwards J., “Client/Server Survival Guide“, John Wiley & Sons, Inc., New York, 3. Auflage, 1999.

• Papers:

– Siegel J., “An Overview Of CORBA 3.0“, Object Management Group.

– Kàhkipuro P., “Object-Oriented Middleware for Distributed Systems“, September 1998.

• WWW:

– OMG-Homepage: www.omg.org www.omg.org/corba/beginners.html

– CORBA-Homepage: www.corba.org

Einführung in CORBA Fachseminar Informations- und Kommunikationssysteme SS99 MartinVogt, IIIC, 8....

Documents

Transcript of Einführung in CORBA Fachseminar Informations- und Kommunikationssysteme SS99 MartinVogt, IIIC, 8....