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) 11 11 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“
9
Embed
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
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
� „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
„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)
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.
• 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)
• 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.
• 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.
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