Inhaltsverzeichnis 1 Was und wofür ist CORBA?... 2 1.1 Problematik in Verteilten Systemen... 2 1.2 Entwurfszeile... 2 2 Zweck und Ziele von OMG?... 2 3 Was ist eine Schnittstellenarchitektur?... 2 3.1 OMA (Object Management Architecture)... 2 4 Wozu dienen die CORBA-Spezifikation?... 3 4.1 CORBA-Spezifikationen:... 3 5 Prinzipielle Funktionsweise vom ORB erklären?... 3 5.1 Inter ORB Architektur... 3 5.1.1 General Inter-ORB Protocol (GIOP):... 3 5.1.2 Internet Inter-ORB Protocol (IIOP):... 3 6 Zweck der Schnittstellensprache IDL?... 4 6.1 Interface Definition... 4 6.2 Statischer Objektaufruf... 4 6.2.1 Clientseitige Betrachtungen... 4 6.2.2 Serverseitige Betrachtungen (nach Eintreffen einer Client-Anfrage)... 4 6.3 Objekt Referenz... 4 6.4 Adabter... 4 6.4.1 Aktivierungsverfahren... 5 6.4.2 BOA (Basic Object Adapter)... 5 6.4.3 POA (Portable Object Adapter)... 5 7 Repositories (Verzeichnisse)... 5 7.1 Implementation Repository... 5 7.2 Interface Repository... 5 8 CORBA Services... 5 Seite 1 von 1 wim, 15.08.2003
1 Was und wofür ist CORBA? 1.1 Problematik in Verteilten Systemen Verschiedene Orte im verteilten System Ortstransparenz Heterogenität im verteilten System (Unterschiedliche Hard-/Software) Transparenz der Heterogenität Dienste im verteilten System Unterschiedliche Semantik. Darunter versteht man das unterschiedliche Verständnis der Datentypen, Sprachelementen usw. 1.2 Entwurfszeile CORBA (Common Object Request Broker Architecture) ist eine Client/Server Architektur, ein Standard. Sie ermöglicht eine Kommunikation zwischen unterschiedlichen Programmen, Anwendungen, Prozessen, Objekten, Betriebssystemen und Hardwaren über einen Softwarebus. CORBA ist eine Middleware zur Abstraktion von Hardware, Betriebssystem und Programmiersprache. Objekte verschiedener Struktur (Philosophien) werden mit CORBA-Wrappern (ein Aufsatz der nach Aussen eine einheitliche Struktur darstellt) so verändert, dass sie miteinander sprechen können (Objekt Integration). CORBA dient auch hier als Integrations Middleware. Interoperabilität Eine Anwendung soll ohne Änderungen auf verschiedenen CORBA- Implementierungen ablaufen können. Anwendungen auf verschiedenen CORBA-Implementierungen sollen miteinander kommunizieren können Einbindung von Altapplikationen (Legacy-Anwendungen) Aktueller Trend: 3-Tier-Architektur (Cleint Applikation Prozess und Daten) verbunden mit CORBA/EJB 2 Zweck und Ziele von OMG? OMG (Object Management Group) ist ein Interessenverband Konsortium Vereinbarung zwischen verschiedenen Firmen die sich für einen bestimmten Zweck zusammenschliessen. Damit will man Wissen an die Mitglieder als allgemeine Richtlinien und industriell verwendbare Spezifikationen zur Verfügung stellen. RFP (Request for Proposal) sind Anfragen um Vorschläge, wie ein bestimmter Standard implementiert werden kann. Vorschläge auswerten und als Standard veröffentlichen, ist Aufgabe des OMG. Dabei handelt es sich um verteilte, aus Objekten bestehende Software. 3 Was ist eine Schnittstellenarchitektur? OMA als Referenzarchitektur ist der Sachverhalt, dass ein Software-Bus (ORB) existiert, der Applikations Objekte (Client), Common Facilities (Dienste) und Common Object Services (COS) verbindet. OMA Sammlung von Standard Interfaces (Schnittstellen) für Standard Objekte die CORBA unterstützen. 3.1 OMA (Object Management Architecture) Die CORBA Architektur besteht aus dem ORB. Dieser vermittelt Aufrufe zwischen Objekten. Der ORB weiss wo welches Objekt liegt. Die Anwendungsobjekte können untereinander mit Hilfe des ORB kommunizieren. Die Anwendungsobjekte stehen untereinander in Client/Server-Beziehung. Seite 2 von 2 wim, 15.08.2003
Die Common Object Services (COS) sind allgemeine, anwendungsunabhängige, standardisierte Systemdienste, die eine CORBA Implementierung anbieten kann bzw. muss, z.b. den Naming Service zum Auffinden von Objekten anhand eines Namens oder einen Transaktionsdienst zur Unterstützung von Transaktionen im verteilten System. CORBA-Services verhalten sich wie normale Objekte. Common Facilities sind ähnlich wie Object Services unabhängig von einem bestimmten Anwendungsbereich. Im Gegensatz zu Services legen sie aber nicht Schnittstellen für Systemdienste, sondern Schnittstellen zu Benutzeranwendungen. Domain Interfaces legen ähnlich wie Facilities Anwendungsschnittstellen fest, die sich allerdings an bestimmten Anwendungsbereichen oder Branchen orientieren. Beispielsweise Product Data Management (PDM), Telekommunikation usw. 4 Wozu dienen die CORBA-Spezifikation? Mit der Spezifikation wird das Prinzip festgelegt wie etwas zu geschehen hat. 4.1 CORBA-Spezifikationen: Intelligente, vernetzte Objekte und Komponenten Schnittstellensprache IDL Das Netzwerk-Protokoll IIOP CORBA-Komponentenmodell Serverseitige Objekt-Skalierung Sprach- und Herstellerunabhängig Service-orientierte Schnittstellenarchitektur 5 Prinzipielle Funktionsweise vom ORB erklären? Das Herz von CORBA stellt die OO-Middleware, die Interfaces dar. Mit diesen Interfaces ist es möglich, dass unterschiedlichste Anwendungen miteinander sprechen können. Ein CORBA-Objekt besteht aus einem Client-Objekt in Verbindung mit dem dazugehörigen Interface. Das ORB stellt also einen Vermittler bzw. Software-Bus zwischen den Objekten (verschiedenen Typs) her. 5.1 Inter ORB Architektur 5.1.1 General Inter-ORB Protocol (GIOP): Spezifiziert eine Menge von Nachrichtenformaten und Datendarstellungen für die Kommunikation zwischen den ORBs Kann über jedes verbindungsorientierte Transportprotokoll arbeiten Definiert Nachrichtenformate Mittels CDR (Common Data Representation) werden Datentypen, die in IDL definiert wurden, in eine einfache Nachrichtendarstellung für Netzwerke abgebildet ORB kann selbständig auf Rechner laufen oder mit jedem anderen ORB im Internet verbunden sein (IIOP). Mit dem Einsatz von ORB hat man keine Sorgen mit den Transportmechanismen, der Server-Lokalisierung, Objektaktivierung usw. Mit den Services Sicherheit und Transaktion über Grenzen von Rechnern und ORBs hinweg. 5.1.2 Internet Inter-ORB Protocol (IIOP): Legt fest wie GIOP-Nachrichten über TCP/IP-Netzwerke ausgetauscht werden Ermöglicht das Internet selbst als Backbone-ORB zu verwenden, durch das mehrere ORBs verbunden werden können Seite 3 von 3 wim, 15.08.2003
6 Zweck der Schnittstellensprache IDL? IDL (Interface Definition Language) ist eine Sprache zur Beschreibung von Objekt- Schnittstellen. Die IDL deklariert Interfaces, sie erlaubt Objekten die in verschiedenen Sprachen geschrieben sind zusammenzuarbeiten (Mapping). Es ist also ein Mittel zur Beschreibung der Schnittstellen, Betriebssystem- und Sprachunabhängig. 6.1 Interface Definition IDL: Neutrale Schnittstellensprache / Mapping der Datentypen Compiler: Sprachspezifisch: IDL Stubs/Proxy & IDL Skeleton Client/Server: CORBA Objekt Abstarakt IOR (Interoperable Object Reference) ORB via IIOP (Internet Inter-ORB Protocol) übers Netz 6.2 Statischer Objektaufruf Transformiert den Client-Aufruf in eine standardisierte Netzwerknachricht und sendet sie an die entsprechende Objektimplementation Durch IDL-Compiler generiert Abhängig von Implementierung und OS Stub Statisches Interface für Objektdienste auf Clientseite Marshalling/Demarshalling (Kodierung und Dekodierung der Opertion und ihrer Parameter in einfache Nachrichtenformate) Lokaler Proxy Skeleton Statisches Interface: Nimmt Methodenaufrufe für Serverobjekte entgegen Marshalling/Demarshalling 6.2.1 Clientseitige Betrachtungen Der Client ist durch das Interface abgeschirmt Der Client greift auf ORB Dienste zu Der Client kommuniziert via den Stub, das Proxy-Objekt 6.2.2 Serverseitige Betrachtungen (nach Eintreffen einer Client-Anfrage) Der ORB erhält eine Anfrage Der ORB gibt die Anfrage via Skeleton weiter an die Objektimplementation im Server Die Antwort wird vom Serverobjekt an das Skeleton übergeben Die Antwort wird zurück an den Client gesandt. 6.3 Objekt Referenz Eindeutiger Name oder Kennung in einem verteilten ORB-System Wird dem Objekt bei dessen Kreierung vom ORB zugewiesen und bleibt solange gültig, bis das Objekt gelöscht wird Die Implementierung der Reverenzen ist nicht durch Spezifikationen festgelegt IOR (Interoperable Object Reference) Muss von Anbietern benutzt werden um Reverenzen über heterogene ORBs weiter zu geben Das ORB ist dafür verantwortlich für eine gegebene Referenz die jeweilige Implementierung zu lokalisieren (finden der Implementation über das Implementationsrepository) 6.4 Adabter Serverseite muss dafür sorgen, dass es so aussieht als ob alle Objekte zu jeder Zeit aktiv sind Der Objektadabter arbeitet völlig transpartent mit dem Persistenz-Dienst Objektadapter Seite 4 von 4 wim, 15.08.2003
Registrieren von Implementationen im Repository Generieren und Implementieren von Reverenzen Zuordnen von Referenzen zu ihren Implementationen Aktivierung/Deaktivierung von Implementationen Aufruf von Methoden via Skeleton und Übergabe von Parametern 6.4.1 Aktivierungsverfahren Shared-Server (1:n) Unshared-Server (1:1) (für jede Anfrage zum ersten Mal auf ein Objekt wird ein neuer Prozess gestartet) Server-Per-Method (für jeden Methodenaufruf) 6.4.2 BOA (Basic Object Adapter) Muss von jedem ORB unterstützt werden 6.4.2.1 Ablauf ORB erhält Anfrage Server aktivieren Server informiert BOA mit ready BOA instanziert Objekt im Server BOA übergibt die Anfrage an die Objektimplementation vis Skeleton Objekt übergibt die Antwort an das Skeleton Versandt an den Client 6.4.3 POA (Portable Object Adapter) Ungenügende Unterstützung der Server-Implementierung bei BAO führte zu herstellerspezifischen nicht portablen Lösungen Seid CORBA 2.2 existiert die portable Spezifikation POA POA bestimmen das Verhalten der zugeordneten Servant-Objekte 7 Repositories (Verzeichnisse) 7.1 Implementation Repository Informationen über die vom Server unterstützen Klassen, Objektinstanzen und Referenzen Speicher für zusätzliche Informationen (z.b. mit welchem Kdo ein Server zuaktivieren ist) Wird vom ORB benutzt um aktive Objekte zu lokalisieren Hängt von der CORBA-Plattform ab 7.2 Interface Repository Enthält Metadaten über Objekte, Services und den ORB selbst (in IDL) Laufzeitdatenbank mit IDL-generierten Informationen Schnittstelle für die IDL-Strukturen 8 CORBA Services Naming (Factory Patterns werden verwendet um Naming-Server zu entlasten) Security Transactions Life Cycle Persistence Relationship usw Seite 5 von 5 wim, 15.08.2003