CORBA zum Datenzugriff

1. CORBA zum Datenzugriff Sascha Koch 22.1.2001

2. Aufbau des Seminarvortrages Teil 1: CORBA ... • Architektur, Komponenten und Terminologie. • Interface Definition Language (IDL). Teil 2: ... zum Datenzugriff • Integration von Anwendungssystemen mit CORBA. • Möglichkeiten der Datenmodellierung in CORBA. • Betrachtung datenintensiver Anwendungssysteme.

3. Entwicklung zu verteilten Systemen • Monolithische Systeme mit Zentralrechner und Terminals. • Entwicklung zu Client/Server-Systemen mit PCs als Clients, die einen Teil der Verarbeitung durchführen. • Aufteilung der Client/Server-Architektur in Schichten. Einzelne Schichten und insbesondere die Clients sind isoliert. • Verteilte Systeme: die gesamte Funktionalität einer Anwendung wird durch Objekte dargestellt. Objekte können Dienste anderer Objekte nutzen. • Schlüsseltechnologie in verteilten Systemen sind verteilte Objektmodelle als sogenannte Middleware. CORBA stellt ein solches verteiltes Objektmodell dar.

4. CORBA • CORBA = Common Object Request Broker Architecture. • CORBA ist ein von der Object Management Group (OMG) entwickelter Industriestandard. • CORBA ist die Spezifikation einer Infrastruktur für verteilte (idealerweise objektorientierte) Anwendungen. • Die OMG implementiert CORBA nicht selbst. Dies wird dem freien Markt überlassen. • CORBA-Objekte können auf objektorientierer Ebene (durch Methodenaufrufe) über Entfernungen interagieren. • CORBA integriert unterschiedliche Rechnerarchitekturen, Betriebssysteme und Programmiersprachen.

5. Geschichte von CORBA • 1989 Gründung der Object Management Group (OMG) durch 11 Firmen (u.a. Hewlett-Packard, Sun Microsystems). • Ziele: herstellerunabhängige Softwarestandards etablieren, verteilte/unternehmensweite Interoperabilität ermöglichen, objektorientierte Technologie fördern. • Heute: über 800 Mitglieder.

6. Alternativen zu CORBA • Auf niedriger Abstraktionsebene:Socketverbindungen. • Höhere Abstraktionsebene (funktionsorientiert):Remote Procedure Call (RPC). • In reinen Windows-Umgebungen: das von Microsoft entwickelte Objektmodell DCOM. • In reinen Java-Umgebungen: Remote Method Invocation (RMI), d.h. entfernter Aufruf von Methoden, seit JDK 1.1 fester Bestandteil von Java. • CORBA hingegen bietet Unabhängigkeit von Plattform, Betriebssystem und Programmiersprache.

7. Object Management Architecture • Client-Objekte rufen Methoden der Server-Objekte auf. • Die Verteilung ist transparent. • Kommunikationszentrale • Leitet Anfragen/Ergebnisse weiter, führt transparent Formatumwandlungen durch. • Standardisierte Dienste, z.B. Persistenz, Transaktionen.

8. Object Request Broker (ORB) • Die Architektur eines zu CORBA 2.0 kompatiblen ORB. • Der ORB ist als Logik zu verstehen. Er ist verteilt.

9. Formatübertragungen CORBA ist unabhängig von Programmiersprachen:

10. Objektmodell von CORBA • Objektverteilung: entfernter Methodenaufruf ist von lokalem (bis auf Effizienz/Netzwerkfehler) nicht zu unterscheiden. • Objektadapter: Schnittstelle zwischen Implementierung der Serverobjekte und dem ORB, registriert Objekte im Implementation Repository. CORBA verlangt mindestens den Basic Object Adapter (BOA). • Auf Objekte wird nur über die Referenz zugegriffen. Bei Verwendung des BOA bleiben entfernte Objekte entfernt (keine Migration). • Ausnahme: als valuetype definierte Objekte werden als Wert übertragen, allerdings nur als Kopie.

11. Basic Object Adapter (BOA) BOA-Funktionalität = Mindestfunktionalität eines Object Adapters:

12. Interface Definition Language (IDL) • Die Schnittstellen (d.h. exportierte Attribute und Methoden) eines Objektes werden mit der IDL und damit unabhängig von Programmiersprachen beschrieben. • Eine IDL-Spezifikation beinhaltet keine Implementierung. • Die Syntax von IDL ist an C++ angelehnt. • Eine IDL-Spezifikation wird durch den IDL-Compiler auf den Client-Stub und den Server-Skeleton abgebildet. • Abbildung auf die jeweilige Sprache im Client bzw. Server. • Stub = Stellvertreter für das Serverobjekt im Client. • Skeleton = Gerüst für die Implementierung auf Serverseite.

13. Beispiel einer IDL-Spezifikation module Kundschaft { interface Person { readonly attribute long nr; attribute string name; }; // interface Person interface Kunde : Person { long TageOhneBestellung(); }; // interface Kunde }; // module Kundschaft • Ein module entspricht einem package in Java. • Ein interface entspricht einer Klasse. • Die Methoden get_nr(), get_name() und set_name() sind implizit definiert. • (Mehrfach-)vererbungen sind möglich. • Exception-Behandlung.

14. Generierung von Stub und Skeleton

15. CORBAservices und CORBAfacilities • Zur OMA gehören neben der ORB-Funktionalität noch die CORBAservices und CORBAfacilities. • CORBAservices: z.B. Objektpersistenz, Transaktionen, Sicherheit (horizontale/branchenübergreifende Dienste). • CORBAfacilities: z.B. Aussehen der Benutzeroberfläche. • Domain Interfaces: branchenspezifische Dienste (vertikal), waren früher mit den CORBAfacilities zusammengefaßt. • Schnittstellen der Dienste sind in IDL spezifiziert, Implementierung ist Sache der Hersteller. • CORBA-Produkte müssen diese Dienste nicht implementieren, um CORBA-kompatibel zu sein.

16. Zusammenfassung von Teil 1 • CORBA ist ein Industriestandard, der weiterentwickelt wird. Implementierungen sind verfügbar.  Zukunftssicherheit. • CORBA bietet ein hohes Maß an Interoperabilität. Unternehmen sind nicht von einem Produkt abhängig. • CORBA ist ein verteiltes Objektmodell hohe Abstraktion. • CORBA überwindet Plattformheterogenität.  CORBA ermöglicht die Integration verschiedener Systeme. • CORBA ist skalierbar und robust. CORBA ist jedoch auch aufwendig.  Die Stärken von CORBA kommen in unternehmensweiten Anwendungen zum Tragen.

17. Verteilte Softwareentwicklung • Identifikation der Serverklassen im OO-Modell und Spezifikation der Schnittstellen dieser Klassen in IDL. • Wahl des Implementierungsansatzes für die Serverklassen: Vererbung oder Delegation. • Generieren von Client-Stub und Server-Skeleton mit dem IDL-Compiler. • Implementierung des Servers. • Implementierung des Clients (möglicherweise auch parallel zum Server). • Neuentwurf ist im Vergleich zu Integration bestehender Systeme unproblematisch.

18. Vererbung oder Delegation

19. Charakterisierung von Datenquellen • DBMS werden üblicherweise für die Speicherung großer Datenmengen eingesetzt. • Dateien werden in einigen Fällen (z.B. für digitalisierte Filme) den DBMS vorgezogen. • Anwendungsprogramme (AP) • kapseln die eigentliche Datenquelle (Direktzugriff gefährdet die Integrität der Daten), • bieten ein proprietäres API, das von der konkreten Speicherung abstrahiert und • liefern Daten als Ergebnis komplexer Funktionsaufrufe. • Beispiel: SAP R/3.

20. Integration von Anwendungssystemen • Neuentwicklung auf Basis von CORBA ist unproblematisch. • Ein realistischer Anwendungsfall in Unternehmen ist jedoch auch die Integration existierenden Anwendungssysteme. • Problem: existierende Schnittstellen müssen ggf. an die Spezifikation in IDL angepaßt werden. Diese Änderungen können weitere Änderungen im Quelltext nach sich ziehen. • Ist die Architektur der vorhandenen Systeme mit CORBA nicht vereinbar, so sind Entwurfsänderungen nötig. • Insgesamt darauf achten, möglichst wenig in IDL zu spezifizieren, also nur gemeinsam verwendete Klassen.

21. CORBA zum Datenzugriff • Informationssysteme benötigen und erzeugen Daten. Jedes System benötigt eine Datenversorgung. • Informationssysteme können unterschieden werden nach Art des Zugriffs und Größe der zu verarbeitenden Datenmenge:

22. Klassifikation von DB-Anwendungen Auftragsbezogen, z.B. Reservierungssysteme (Operation Shipping) Datenintensiv, z.B. CAD-Systeme (Data Shipping) Puffer • CORBA ist eher für Operation Shipping konzipiert.

23. Anforderungen für Data Shipping • Objektorientiertes Datenmodell als Grundlage. • Anbindung aller Arten von Datenquellen. • Caching: lokale Verfügbarkeit der Daten im Client (durch Migration, nicht durch Kopien). • Absicherung der Verarbeitung durch Transaktionen. • Mengenorientierte Verarbeitung, die auch die kompakte Übertragung großer Datenmengen zuläßt (Bulk Transfer).

24. Datentypen in CORBA

25. Modellierung von Datenobjekten

26. Data Shipping mit CORBA • Operation Shipping hat sich als langsamer als Data Shipping erwiesen (Messungen der DaimlerChrysler AG). • Verwendung von interface führt aber zu Operation Shipping, da in den CORBA-Implementierungen nur der Basic Object Adapter (BOA) verfügbar ist. • Andere Object Adapter (Library Object Adapter oder Object Oriented Database Adapter) würden Migration ermöglichen, stehen aber noch nicht zur Verfügung. • struct: nicht mächtig genug, valuetype: nicht verfügbar. • Mögliche Ansätze: Verwendung von CORBAservices oder proprietäre Lösungen.

27. Verwendung von CORBAservices • Persistent State Service: kein Caching (interface) bzw. unkontrollierte Kopien und somit keine Transaktionen möglich (valuetype). • Query Service: Persistenz nicht als Eigenschaft von Objekten. Bei der Anbindung von RDBMS ist Zugriffsschutz über den Transaction Service möglich. • Lifecycle Service: kein Bulk Transfer, da move-Operation für jedes Objekt einzeln angestoßen werden muß. • Externalization Service: eng verzahnt mit Lifecycle Service, daher ebenfalls kein Bulk Transfer möglich. • CORBAservices sind nur bedingt geeignet.

28. Proprietäre Lösungen • Proprietäre Kopplung zu ODBMS (Zustandsspeicherung über selbst definierte Mechanismen): kein Data Shipping, kein Bulk Transfer. • Proprietäre Datenzugriffskomponente auf Basis von IDL (eigenes interface DataServer, eigene Datenstrukturen auf Basis von struct): unkontrollierte Kopien. • Proprietäre Erweiterungen von CORBA-Systemen: Abhängigkeit vom entsprechenden Produkt, Widerspruch zur CORBA-Philosophie. • Proprietäre Datenzugriffskomponente ist bedingt geeignet.

29. Zusammenfassung • CORBA zeigt Schwächen beim Datenzugriff auf große Datenmengen, wenn Lesen und Schreiben erforderlich ist. Es gibt keine vollständig zufriedenstellende Lösung. • Allerdings waren die Anforderungen sehr hoch angesetzt. • Lesen großer Datenmengen ist mit CORBA realisierbar, da unkontrollierte Kopien im Client dann akzeptabel sind. • CORBA ist besonders für Operation Shipping geeignet. • CORBA ist besonders für die Integration von bestehenden Insellösungen in Unternehmen geeignet.