Präsentation herunterladen
Die Präsentation wird geladen. Bitte warten
Veröffentlicht von:Gesche Bauer Geändert vor über 7 Jahren
1
Aufbau Integrierter Informationssysteme Verteilte Objektsysteme am Beispiel von CORBA Falk Ritschel, Stefan Springer, Falko Steponat Martin-Luther-Universität Halle-Wittenberg Informatikseminar - Halle - 22.01.2002
2
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
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
4 Softwareentwicklung in den letzten 15 Jahren 1. Motivation 1.4.3.2.5. 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
5 1. Motivation 1.4.3.2.5. 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
6 1. Motivation 1.4.3.2.5. 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
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 1.4.3.2.5. CORBA
8
8 3. Object Managemant Group 1.4.3.2.5. 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
9 3. Object Managemant Group 1.4.3.2.5. 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
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 1.4.3.2.5. 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
11 4. Einführung Anforderungen an einen Komponentenstandard in heterogenen Netzen 1.4.3.2.5. 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
12 4. Einführung 1.4.3.2.5. 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
13 4. Einführung 1.4.3.2.5. CORBA Geschichte von CORBA 1992: OMA 2.0 1995: 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
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
15 O bject M anagement A rchitecture 1.4.3.2.5. CORBA OMA = Grundlage aller weiteren Spezifikationen der OMG
16
16 O bject M anagement A rchitecture 1.4.3.2.5. CORBA C ommon O bject R equest B roker A rchitecture Objektdienste (CORBA Services) Gemeinsame Einrichtungen (CORBA Facilities) CORBA – Anwendungen Domänen- schnittstellen
17
17 1. CORBA Services 1.4.3.2.5. 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
18 1. CORBA Services 1.4.3.2.5. 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
19 1. CORBA Services 1.4.3.2.5. 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
20 2. CORBA Facilities 1.4.3.2.5. 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 (E-Mail)
21
21 2. CORBA Facilities 1.4.3.2.5. 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
22 3. Domain Objekte 1.4.3.2.5. 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
23 4. Applikation Objekte 1.4.3.2.5. 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
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
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 1.4.3.2.5. CORBA
26
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 1.4.3.2.5. CORBA
27
27 Portmapper Server Stub Server 1.4.3.2.5. 1. RPC – Remote Procedure Call CORBA Client Client Stub Network Transport 1 2 4 5,6 7 3
28
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 1.4.3.2.5. CORBA
29
29 1.4.3.2.5. 2. 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
30
30 1.4.3.2.5. 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()
31
31 1.4.3.2.5. 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
32
32 1.4.3.2.5. 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
33
33 1.4.3.2.5. CORBA 2. ORB – Object Request Broker ORB - Anbieter http://www.visigenic.com/prod/VisiBroker: Visigenic http://www.software.ibm.com/objects/ somobjects SOM: IBM http://www.iona.comOrbix: IONA http://www.orbacus.comORBacus: Object-Oriented Concepts, Inc http://www.sun.com/sunsoft/neoNEO und Joe: Sun Microsystems http://www.mico.orgMICO
34
34 1.4.3.2.5. 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
35 3. IDL – Interface Definition Language 1.4.3.2.5. CORBA
36
36 3. IDL – Interface Definition Language 1.4.3.2.5. 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
37 3. IDL – Interface Definition Language 1.4.3.2.5. CORBA
38
38 3. IDL – Interface Definition Language 1.4.3.2.5. CORBA Vorteile einer eigenen Beschreibungssprache maschinelle Weiterverarbeitung unabhängig von Programmiersprachen Isolierung Systemspezifischer Eigenschaften
39
39 4. Kommunikation der Objekte 1.4.3.2.5. CORBA Client X ruft Methode M von Y auf Objekt Y Methode M Object Request Broker (Core)
40
40 4. Kommunikation der Objekte 1.4.3.2.5. 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
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
42 CORBA in der PraxisCORBA in der Praxis Vorgehensmodell Beispielanwendung IDL - Dokumente IDL – Stub, IDL – Client Java Server Java Client Gliederung 1.4.3.2.5. CORBA
43
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
44 2. Beispielanwendung 1.4.3.2.5. IDL - Datei CORBA
45
45 2. Beispielanwendung 1.4.3.2.5. 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
46 2. Beispielanwendung 1.4.3.2.5. Java - Interface CORBA
47
CORBA – Server - Objekt anmelden Interaktion mit dem Name Server vorbereiten NamingContext Objekt den richtigen Datentypen zuweisen Anbindung am Name Server (Objekte, Name)
48
48 2. Beispielanwendung 1.4.3.2.5. Java - Server CORBA
49
Java - Client Objektreferenz vom Name Server gewonnen NamingContext Objekt den richtigen Datentypen zuweisen Aufruf der Server Methode
50
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
51 1. Vorteile und Nachteile 1.4.3.2.5. –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
52 2. Ausblick 1.4.3.2.5. –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
53 3. Zusammenfassung 1.4.3.2.5. –OMG –Geschichte CORBA –CORBA Komponenten –ORB - Objekt Request Broker –IDL - Interface Definition Language –CORBA Kommunikation CORBA
Ähnliche Präsentationen
© 2024 SlidePlayer.org Inc.
All rights reserved.