CORBA: Common Object Request Broker Architecture. Interoperabilität? CORBA die Idee. Die Object Management Group

Transkript

1 CORBA: Common Request Broker Architecture Interoperabilität? Middleware-Architektur-Spezifikation der Management Group (OMG) Überblick: Die Management Group (OMG) Das Objektmodell der OMG Die Management Architecture (OMA) Die ORB - Architektur (CORBA) Das CORBA Component Modell (CCM) Der Implementierungsablauf 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 Request Broker 38 3 CORBA die Idee Die Management Group Die Vision der 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 0/9, erste Vollimplementierung 7/93 Zur Zeit aktuell: CORBA 3.0 (die meisten Produkte impl. CORBA 2.3) Die OMG wurde 4/989 von 3 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 00 Corporate Members

2 CORBA technische Ziele Problem der Komplexität 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 s) 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. 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 3 Objektmodell der OMG CORBA /Implementierung/Server 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 CORBA-s 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. Ein CORBA-Objekt ist eine identifizierbare gekapselte Instanz, welche über ein oder mehrere (s) Dienste anbietet CORBA-Server sind Software-Komponenten in denen Objekt- Implementierungen residieren und deren Methoden ausgeführt werden können (Container/RE-Semantik) Alle CORBA-Objekte ( verteilte Objekte ) können als Dienstnutzer oder Diensterbringer auftreten erweitertes /Server-Modell (bei jeder Kommunikationsbeziehung gibt es allerdings einen und einen Server)

3 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 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. Der hat Zugriff auf Objektreferenzen. Erst mit der Objektreferenz wird der Zugriff auf die Dienste (über Objektoperationen) möglich. Der kennt nur die logische Struktur des Objektes entsprechend dem und kann auf das Verhalten des Objektes nur über Operationsaufrufe einwirken. s 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 als auch Objektimplementierung besitzen eine eindeutige Notation der Objekt-Referenz entsprechend der Programmiersprache. CORBA-Objekte Begriffe CORBA-Objekte Begriffe 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. Requestparameter sind durch ihre Position identifiziert. beschreibt die von einem Objekt über einen Zugangspunkt angebotenen Operationen, die von den s genutzt werden können s werden in der IDL( Definition Language) spezifiziert. Operation ein identifizierbarer Eintrag im, der auf einen Dienst verweist, der von s über das 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 8

4 CORBA-Objekte Begriffe Management Architecture en detail Attribut s 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 - Übersicht CORBA Grundstruktur Dynamic Invocation IDL Stub ORB Dynamic Invocation Server IDL Adapter Request Broker Kernel standardisierte Schnittstelle (identisch für alle ORB s) Es kann mehrere Adapter geben. mehrerer jeweils auf einen Objekttyp spezialiserte Schnittstellen ORB-spezifische Schnittstelle 3

5 Übergabe des -Request an das Server- Objekt Aufruf von Objektmethoden über IDL Stub Der ORB ermittelt den gewünschten Objektimplementierungs-Code übermittelt die Parameter des Requests und übergibt die Aktivitätssteuerung über das objektspezifische -Gerüst oder über das dynamische -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 Adapter implementiert die grundlegende Funktionalität zur Arbeit mit dem Server-Objekt. IDL Stub Request Broker Kernel Dynamischer Aufruf von Objektmethoden Weiterleitung eines -Requests über IDL Dynamic Invocation Server IDL Adapter Request Broker Kernel Request Broker Kernel

6 Dynamische Weiterleitung eines -Requests Interoperabilität zwischen ORB s Dynamic Invocation Request Broker Kernel Adapter ORB A Proxy (Server) IOP Proxy () GIOP-General Inter ORB Protocol IIOP-Internet Inter ORB Protocol ESIOP-Environment Specific IOP Server-Objekt ORB B ORB A generiert ein Proxy-Objekt (Server), welches auf der einen Seite das des gewünschten Server-Objektes (Dynamic Invocation) und auf der anderen Seite ein Inter ORB Protokoll unterstützt. ORB B generiert analog dazu ein Proxy-Objekt () für den Zugriff auf das Server-Objekt (Dynamic Invocation ) und für die Kommunikation mit ORB A. 8 Anwendungsbeispiele und existierende Produkte Applikationsentwicklung mit IDL IDL Schnittstellen Definition kommerziell: Visibroker von Borland (und Visigenic) Component Broker von IBM... kostenlos: TAO ACEOrb (C++,..; Corba2.5) JacOrb (Java; Corba 2.3) mico (C++,...; Corba 2.2) ominorb (C++, Python...; Corba 2.6) Java IDL von Sun Microsystems (Corba 2.2)... Anwendungsbeispiele: Success Stories: Program Stubs Program Stub IDL Compiler Language Compiler Request Broker Server s

7 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++ 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 = 000; typedef string Zeilen[max]; attribute Zeilen inhalt; 3 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 : short Postfach; default: string Anschrift; void setzedaten(in Name name, in Adresse adresse); void holedaten(out Name name, out Adresse adresse); 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);

8 Ü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 Ü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 Query Language (OQL) beziehungsweise die Structured Query Language (SQL3) Überblick: CORBAservices Überblick: CORBAfacilities 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 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 Bereiche für CORBAfacilities: User 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 8

9 CORBA 3 Internet Integration 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 Firewall Specification Internet Inter ORB Protocol (IIOP): Port 683 und Internet Inter ORB Protocol over Secure Socket Layer (IIOP over SSL): Port 684 Restriktionen für Call Backs vom Server zum Interoperabler Name Service Objekt-Referenzen im URL-Format: iioploc, iiopname Beispiel: iioploc:// 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