Aufbau Integrierter Informationssysteme Verteilte Objektsysteme am Beispiel von CORBA Falk Ritschel, Stefan Springer, Falko Steponat Martin-Luther-Universität Halle-Wittenberg Informatikseminar - Halle

2 Gliederung Verteilte Objektsysteme am Beispiel von CORBA 3. Kommunikation zwischen den Objekten 4. CORBA in der Praxis 6. Fazit - Ausblick 2. CORBA – Architektur (OMG) 1. Einleitung

3 Gliederung Verteilte Objektsysteme am Beispiel von CORBA 3. Kommunikation zwischen den Objekten 1. Einleitung 4. CORBA in der Praxis 6. Fazit - Ausblick 2. CORBA – Architektur (OMG) Motivation OMG Grundbegriffe Einführung

4 Softwareentwicklung in den letzten 15 Jahren 1. Motivation CORBA Einzug des Paradigmas der Objektorientierung Aufteilung von Software in Komponenten (Objekte) Austauschbarkeit (wohldefinierte Schnittstellen ) und Wiederverwendbarkeit Schnellere Implementierung von Software Zunehmende Vernetzung Client-Server, Multi-Tier, Internet Anwendungen verteilt über Rechner und Architekturen Anwendungen kommunizieren über Middleware bessere Administrierbarkeit, Skalierbarkeit, Ausfallsicherheit, Investitionsschutz Zusammenarbeit heterogener Plattformen

5 1. Motivation CORBA Funktionalität bereitstellen in Form von Komponenten Verteilung der Komponenten auf beliebige Rechner Implementierung in unterschiedlichen Sprachen Logische Konsequenz: Vereinigung der Konzepte: OMG (Object Management Group) Referenzmodell für verteilte Objektsysteme OMA (Object Management Architecture) Konkretisierung dieses Referenzmodells:CORBA (Common Object Request Broker Architekture) Standardarchitektur für verteilte Objektsysteme

6 1. Motivation CORBA Vorteile von verteilten, komponentenbasierten Anwendungen: Wiederverwendbarkeit von Komponenten Vorteile der Objektorientierung auch über Prozeß- und Maschinengrenzen hinaus optimale Strukturierung Fehlerbehebung durch Austausch einer Komponente Verteilung der Arbeitslast auf mehrere Systeme

7 2. Grundbegriffe Verteilte Anwendungen –Bestandteile (Objekte, Komponenten etc.) über mehrere Prozesse u./o. Computer verteilt Heterogene Anwendungen –Bestandteile befinden sich auf Computern mit verschiedener Hardware, BS oder Programmiersprache übliche OOP-Konzepte –Kapselung Schnittstelle und Implementierung grundsätzlich getrennt Schnittstelle wird sprachunabhängig in IDL (Interface Definition Language) beschrieben –Vererbung –Polymorphie CORBA

8 3. Object Managemant Group CORBA Die Object Management Group:Die Object Management Group: 1989 als Industriekonsortium gegründet von: 3COM, American Airlines, Canon, Data General, Hewlett Packard, Philips Telecommunications, Sun Microsystems und Unisys Ziel: Verbreitung von OO-Technik und verteilter Verarbeitung Weg: Erarbeiten und Durchsetzen von Industriestandards Heute weit über 800 Mitglieder! weitaus größtes Industriekonsortium der IT-Branche

9 3. Object Managemant Group CORBA –viele Anbieter und Entwickler von Systemen –Forschungsinstitutionen –reine Anwender objektorientierter Technologien –Populärstes Nichtmitglied war jahrelang die Firma Microsoft Distributed Component Object Model (DCOM) - Standard als Konkurrenz für CORBA inzwischen auch passives Mitglied der OMG –Bekannte Produkte: CORBA und UML Mitglieder:

10 Die OMG ist kein Gremium zur Standardisierung und kann somit nicht mit Institutionen wie dem “American National Standards Institute” (ANSI) oder der “International Standards Organisation” (ISO) verglichen werden. 3. Object Managemant Group CORBA ISO ANSI Die OMG versteht sich als Organisation, die den Mitgliedern die Diskussion kontroverser Ansichten, den Austausch von Ideen, die Suche nach einem Konsens und einer Übereinkunft bezüglich der Verwendung bestimmter Architekturen und Technologien erlaubt. DiskussionAustausch von Ideen Konsens

11 4. Einführung Anforderungen an einen Komponentenstandard in heterogenen Netzen CORBA Der Client und das Serverobjekt können in verschiedenen Programmiersprache n geschrieben sein. Der Client und das Serverobjekt können auf verschiedenen Betriebssystemen laufen. Verschiedene Datendarstellung durch Programmiersprache, Hardware und Compiler vorgegeben Programmiersprachenunabhängigkeit Plattformunabhängigkeit Darstellungsunabhängigkeit Ortsunabhängigkeit Herstellerunabhängigkeit (nicht proprietär) Instanz zwischen Client und Serverobjekt passt unterschiedliche Datenrepräsentation an. Der Client muss nicht wissen, wo das Serverobjekt läuft (Lokal, LAN, WAN, Internet). Objekte verschiedener Hersteller können zusammenarbeiten

12 4. Einführung CORBA Geschichte von CORBA Die Geschichte von CORBA ist die Geschichte der OMG: 1989: Gründung der OMG Anfang 1990: Erste Ergebnisse: Vorstellung des Object Management Architecture (OMA) Referenzmodells Wichtigster Bestandteil: Object Request Broker (ORB) Anfang 1991: Erste CORBA-Version Genauere Spezifikation der ORB Komponente der OMA Problem in der Praxis: Mangelnde Interoperabilität

13 4. Einführung CORBA Geschichte von CORBA 1992: OMA : CORBA 2.0 Interoperabilität zwischen ORBs verschiedener Hersteller Ende 1995: Spezifikation der erweiterten Dienste Anfang 2001: CORBA 3.0 Quality of Service, Unterstützung von Firewalls „Spezielle“ CORBAs: Echtzeitanwendungen, Microcontroller,...

14 Gliederung 2. CORBA - Architektur (OMG) 1. Einleitung 3. Kommunikation zwischen Objekten 4. CORBA in der Praxis 5. Zusammenfassung - Fazit - Ausblick CORBA ServicesFacilities Domain Objekte Applikation Objekte

15 O bject M anagement A rchitecture CORBA OMA = Grundlage aller weiteren Spezifikationen der OMG

16 O bject M anagement A rchitecture CORBA C ommon O bject R equest B roker A rchitecture Objektdienste (CORBA Services) Gemeinsame Einrichtungen (CORBA Facilities) CORBA – Anwendungen Domänen- schnittstellen

17 1. CORBA Services Weiten die Kernfunktionen von CORBA aus. Objekte erzeugen Zugriff auf Objekte steuern Beziehungen zwischen Objekten unterhalten Lifecycle Persistence Transaction Naming Trader Query Events Security Licensing Time CORBA

18 1. CORBA Services Naming Service CORBA Objekt A Registrierung Objekt B Anfrage Adresse Adressierung im Internet: IP-Adresse Host-Rechner + TCP/UDP-Portnummer des Prozesses = damit können Objekte in einer verteilten Umgebung allein anhand ihres Namens Umgebung allein anhand ihres Namens gefunden werden gefunden werden

19 1. CORBA Services Naming Service CORBA = damit können Objekte in einer verteilten Umgebung allein anhand ihres Namens Umgebung allein anhand ihres Namens gefunden werden gefunden werden Ohne diesen Service wäre die Ortstransparenz nicht gegeben.  jedes Objekt, dessen Methoden aufgerufen werden sollen, müsste beim Aufrufer in allen technischen Details bekannt sein

20 2. CORBA Facilities CORBA Gruppen von Komponenten die zusätzliche Funktionen bereitstellen. Funktionen sind für anwendungsspezifische Aufgaben wichtig z.B. Behandlung des Arbeitsablauf und Benutzeroberflächen zusätzliche Unterstützung der Anwendungsentwicklung durch Bereitstellung von Funktionen auf höherer Ebene ( )

21 2. CORBA Facilities CORBA Gruppen von Komponenten die zusätzliche Funktionen bereitstellen. Horizontal Facilities User Interface Information Management Information Modelling Systems Management Task Management Vertical Market Facilities Internet Computer Integrated Manufacturing Verteilte Simulation Öl und Gas Industrie Finanzwelt Applikations-Entwicklung Telekommunikation Gesundheitseinrichtungen

22 3. Domain Objekte CORBA Stellen Funktionen für die Entwicklung von Anwendungen in Speziellen Bereichen bereit. Medizin, Telekommunikation, Finanzwesen Bieten Lösungen für immer wiederkehrende Problemstellungen aus den jeweiligen Bereichen, sind aber zu spezifisch um sie den CORBA Facilities zuzuordnen.

23 4. Applikation Objekte CORBA Gruppen von Objekten oder Komponenten die speziell für bestimmte Anwendungen entwickelt worden. = nutzen den den ORB und die weiteren Dienste der CORBA-Architektur um verteilungstransparent miteinander zu kommunizieren Objekte Verschiedene Anwendungs- programmierer erstellen Verschiedene Hersteller verkaufen

24 Gliederung Verteilte Objektsysteme am Beispiel von CORBA 3. Kommunikation zwischen den Objekten 1. Einleitung 4. CORBA in der Praxis 6. Fazit - Ausblick 2. CORBA – Architektur (OMG) RPC IDL ORB Kommunikation der Objekte

25 Kommunikation zwischen den ObjektenKommunikation zwischen den Objekten RPC – Remote Procedure Call ORB – Object Request Broker Komponenten des ORB Anbieter IDL Interface Definition Language Einführung Sprachumfang Vorteile einer eigenen Beschreibungssprache Kommunikation der Objekte Gliederung CORBA

26 1. RPC – Remote Procedure Call eine verbreitete Abstraktion für die Programmiersprache C ermöglicht den Aufruf einer Prozedur auf einem anderen System Aufrufschnittstelle der Prozedur ist unabhängig von einer Programmiersprache Schnittstelle wird mit der IDL – Interface Definition Language beschrieben Prozeduraufruf Transparent zu gestalten CORBA

27 Portmapper Server Stub Server RPC – Remote Procedure Call CORBA Client Client Stub Network Transport ,6 7 3

28 2. ORB – Objekt Request Broker zentrale Komponente der CORBA Architektur verteilte Objekte transparent miteinander kommunizieren zu lassen Server Objekt finden Parameter übertragen Ergebnis des Methodenaufrufs zurückliefern ORBs müssen auf dem Client und dem Server laufen Kommunikation zwischen den ORBs GIIOP IIOP CORBA

ORB – Object Request Broker CORBA ServerClient ORB – Kern IIOP/GIOP ORB - Kern Dynamic Invocation Interface (DII) IDL- Clientstub ORB- Schnittstelle Objektadapter Interface Repository. Implement. Repository. IDL- Server- skelett Dynamische Skelett- schnittstelle

CORBA 2. ORB – Object Request Broker IDL – Clientstub wird automatisch vom IDL – Compiler erzeugt stellt die Verbindung zwischen Client und ORB her verpacken der Methodenparameter in ein über das Netzwerk transportierbares Format statischer Methodenaufruf d.h. Schnittstellen sind bekannt normale Anwendungsprogramme Dynamic Invocation Interface (DII) und Interface Repository (IFR) dynamischer Methodenaufruf d.h. Schnittstellen sind nicht bekannt eigentliche Basisschnittstelle zum ORB Interface Repository enthält Schnittstelleninformationen Namen und Parameter (Anzahl, Datentyp), Rückgabewert der Methoden Service Programme und Utilities ORB - Schnittstelle stellt eine Sammlung von Operationen zur Verfügung, die zur Realisierung von Clients notwendig sind Zugriff auf die ORB – Schnittstelle auch für den Server möglich Operationen: Object_to_string(), string_to_object() create_list(), create_operation_list()

CORBA 2. ORB – Object Request Broker IDL – Serverskelette wird automatisch vom IDL – Compiler erzeugt stellt Verbindung zum Objektadapter und Serverobjekt her entpackt die Methodenparameter ruft die Methoden im Serverobjekt auf Dynamic Skeleton Interface (DSI) Gegenstück zum Dynamic Invocation Interface eingehende Anfragen können dynamisch beantwortet werden d.h. ohne IDL Spezifizierung nutzt die Informationen die vom DII kommen ORB – Schnittstelle und Implementation Repository ORB – Schnittstelle ist Analog zur Client Seite verwaltet alle Server Objekte wird genutzt wenn noch keine korrekte Instanz eines Server Objektes existiert Object Adapter von OMG wird ein Basic Object Adapter (BOA) spezifiziert ist Verbindungsglied zwischen ORB und Serverobjekt Registrierung von Objektimplementierungen (Server) Server- Aktivierung und – Deaktivierung Erzeugen von Objektreferenzen für Implementierungen Authentisierung und Zugriffskontrolle verantwortlich für die persistente Gültigkeit von Objektreferenzen

CORBA 2. ORB – Object Request Broker ORB - Kern ist verantwortlich für die Kommunikation beinhaltet die gesamte Infrastruktur Objekte zu identifizieren und zu lokalisieren Verbindungen zu verwalten Daten zu übermitteln GIOP – General Inter ORB Protocol basiert auf dem Pyrotechnic Longitudinal ORB Protocol ist Basis für jede CORBA Kommunikation existiert seit CORBA 2.0 ist netzwerkneutral IIOP – Internet Inter ORB Protocol basiert auf dem GIOP Kommunikation in TCP/IP Netzwerke ORBs müssen IIOP unterstützen um CORBA konform zu sein

CORBA 2. ORB – Object Request Broker ORB - Anbieter Visigenic somobjects SOM: IBM IONA Object-Oriented Concepts, Inc und Joe: Sun Microsystems

CORBA 3. IDL – Interface Definition Language IDL – Interface Definition Language ist die genormte Basis zur programmiersprachenunabhängigen Beschreibung von Objektschnittstellen Schnittstelle = alle exportierten Attribute und Methoden eines Objektes orientiert sich an der C++ Syntax wichtiger Bestandteil ist der IDL- Compiler IDL – Compiler Übersetzung der IDL – Schnittstellenbeschreibung IDL - Compiler IDL - Datei IDL - SkeletonIDL - Stub ORB Client Server C Stub C C++ Stub C++ Java Stub Java ADA Stub ADA Smaltalk Stub Smaltalk COBOL Stub COBOL C Skeleton C C++ Skeleton C++ Java Skeleton Java ADA Skeleton ADA Smaltalk Skeleton Smaltalk COBOL Skeleton COBOL

35 3. IDL – Interface Definition Language CORBA

36 3. IDL – Interface Definition Language CORBA Bezeichner Zulässig sind beliebig lange Zeichenketten nicht identisch zu einem IDL – Schlüsselwort beginnt mit einem Buchstaben kann Buchstaben, Ziffern und Unterstriche enthalten ist innerhalb eines Namensraum eindeutig Module erzeugen einen neuen Namensraum, um Namenskonflikte zu vermeiden vergleichbar mit einem Packages bei Java Schlüsselwort ist module Interfaces deklariert die Daten und Operationen eines Objektes entspricht einer Klassendefinition bei Java oder C++ Attribute und Methoden werden nicht implementiert Vererbung ist möglich Schlüsselwort ist interface Operationen eine Aktion die an einem Objekt durchgeführt wird entspricht einer Elementefunktion bei C++ oder einer Methode bei Java Rückgabetyp, Identifizierer Null oder mehrere Parameter (in, out, inout) Optionales raises- Schlüsslewort für Exceptions Schlüsselwort ist Rückgabewert Operationsname raises Attribute Attribute sind vergleichbar mit Variablen nach dem compilieren existieren get und set Methoden optionales Schlüsselwort readonly Schlüsselwort: readonly attribute Datentyp

37 3. IDL – Interface Definition Language CORBA

38 3. IDL – Interface Definition Language CORBA Vorteile einer eigenen Beschreibungssprache maschinelle Weiterverarbeitung unabhängig von Programmiersprachen Isolierung Systemspezifischer Eigenschaften

39 4. Kommunikation der Objekte CORBA Client X ruft Methode M von Y auf Objekt Y Methode M Object Request Broker (Core)

40 4. Kommunikation der Objekte CORBA Client Anwendung IDL - Stub Objektadapter Aufruf Parameter einpacken und weiterleiten Object Request Broker Transport über den ORB Weiterleiten an Schnittstelle Server Anwendung IDL - Skeleton Auspacken und Aufrufen Ermitteln der Implementierung Implementation Repository Aktivieren

41 Gliederung 4. CORBA in der Praxis 1. Einleitung 5. Zusammenfassung - Fazit - Ausblick 2. Konzeptionelle Architekturen 3. Wege zu integrierten Datenbanksystemen Vorgehensmodell Beispielanwendung Verteilte Objektsysteme am Beispiel von CORBA

42 CORBA in der PraxisCORBA in der Praxis Vorgehensmodell Beispielanwendung IDL - Dokumente IDL – Stub, IDL – Client Java Server Java Client Gliederung CORBA

Kunden- auftrag Problemanalyse uns Systemdesign Entwicklung der IDL- Beschreibung IDL- Dokumente IDL- Stubs IDL- Skeleton Server Implemen. Client Implemt. Client Java Compiler Server C++ Compiler Kommunikation

44 2. Beispielanwendung IDL - Datei CORBA

45 2. Beispielanwendung Java - Files Hello.java _HelloStub.java (der Clientstub) _HelloImplBase.java (das Server - Skeleton) HelloHelper.java (einer Helper Klasse) HelloHolder.java (eine Holder Klasse) CORBA

46 2. Beispielanwendung Java - Interface CORBA

CORBA – Server - Objekt anmelden Interaktion mit dem Name Server vorbereiten NamingContext Objekt den richtigen Datentypen zuweisen Anbindung am Name Server (Objekte, Name)

48 2. Beispielanwendung Java - Server CORBA

Java - Client Objektreferenz vom Name Server gewonnen NamingContext Objekt den richtigen Datentypen zuweisen Aufruf der Server Methode

50 Gliederung Verteilte Objektsysteme am Beispiel von CORBA 1. Einleitung 4. CORBA in der Praxis 2. CORBA – Architektur (OMG) 5. Zusammenfassung - Fazit - Ausblick 3. Wege zu integrierten Datenbanksystemen Vorteile - NachteileAusblickZusammenfassung

51 1. Vorteile und Nachteile –Vorteile Ist vergleichsweise einfach Die wichtigsten Sprachen können eingesetzt werden Transparenz (Ort, Verteilung) Statische und dynamische Aufrufe Unabhängig von einer Programmiersprache Vordefinierte Dienste Trennung von Schnittstelle und Implementierung CORBA Nachteile Geringe Performance, insbesondere auf lokalem Rechner Interoperabilität verschiedener ORBs in der Praxis nicht sicher gewährleistet Geringe Bedeutung unter MS Windows

52 2. Ausblick –durch neue Komponentenmodelle in die Defensive gedrängt Enterprise Java Beans (EJB) des J2EE Frameworks COM+ des.NET Framework Web – Services (SOAP, WDSL, XML) –Ziel Brücken zwischen CORBA und neuen Technologien CORBA

53 3. Zusammenfassung –OMG –Geschichte CORBA –CORBA Komponenten –ORB - Objekt Request Broker –IDL - Interface Definition Language –CORBA Kommunikation CORBA