= Common Object Request Broker Architecture 9.4 CORBA = Common Object Request Broker Architecture http://www.corba.org Standard (nicht Produkt!) der OMG – Object Management Group Architektur: objektorientiert/Fernaufrufe + Komponenten IDL: C++ -ähnlich Dienste: sehr reichhaltig Anwendungen: Anwendungen, speziell Einbinden von Altsoftware

9.4.1 Objektmodell: Schnittstellen und Objekte Menge von Operations-Signaturen, beschrieben mit CORBA IDL Objekt:  irgendwie erzeugtes Exemplar irgendeiner Implementierung in irgendeiner Programmiersprache (nicht notwendig objektorientiert) mit einer bestimmten Schnittstelle = Objekttyp,  identifiziert durch CORBA-Objektverweis (= Fernverweis, s.u.),  fernaufrufbar über diesen Verweis

Vererbung/Erweiterung von Schnittstellen ist möglich ! Nicht Teil des Objektmodells sind  Implementierung, „Klassen“  Objekterzeugung Beachte: Das CORBA-Objektmodell ist prinzipiell unabhängig von den Objektmodellen der verwendeten Programmiersprachen – sofern diese überhaupt objektorientiert sind  beschränkte Verteilungsabstraktion !

9.4.2 Schnittstellenbeschreibung mit IDL  Entfernte Ähnlichkeit mit C++  Typsystem mit einfachen und zusammengesetzten Typen  Module bilden Namensräume, auch mit Schachtelung  Ein Modul (module) kann enthalten:  Konstantendefinitionen  Typdefinitionen  Vereinbarungen von Ausnahmen (exceptions)  Vereinbarungen von Schnittstellen (interfaces)

Typsystem: Typ Basistyp Verweistyp (basic type) (reference type) einfach zusammengesetzt Objekttyp Werttyp Object valuetype long struct{fields} char [size] string sequence<type> mit Vererbung ... ... (auch Mehrfachvererbung)

Konstantendefinitionen (const)  benennen explizit angegebene Werte,  sind Bestandteile eines Moduls oder einer Schnittstelle Typdefinitionen (typedef)  benennen explizit angegebene Typen, Ausnahmen (exception)  werden wie Verbundtypen vereinbart Schnittstellen (interface) enhalten  Konstanten,  Operationen,  Attribute

Operationen in Schnittstellen  können Wert liefern (oder auch nicht: void),  können Ausnahmen melden (raises),  kennen 3 Parametermechanismen: in Wertparameter out Ergebnisparameter inout Wert/Ergebnisparameter (bei Objekttypen wird Objektverweis übergeben, bei valuetype wird Objektkopie übergeben!)  können als asynchron vereinbart werden (oneway), sofern ohne Ergebnis und Ausnahmen. Valuetypes: - Typ des FORMALEN Parameters ist ausschlaggebend, - ähnlich ‚struct‘ in C# - dort allerdings KEIN Verweistyp.

Semantik des Operationsaufrufs:  synchrone bzw. asynchrone Ausführung, at-most-once  Ausnahmen wie spezifiziert, zzgl. CORBA-Ausnahmen Attribute in Schnittstellen (attribute)  können als schreibgeschützt (readonly) vereinbart werden,  sind äquivalent zu getter/setter-Operationen (bzw. nur getter, wenn schreibgeschützt)

// file example.idl module example { // no nesting used, only one module typedef string Name; exception NameClash {Name clashing;}; exception Overflow {unsigned long capacity;}; interface Phones { // private phone book long lookup(in Name s); void enter (in Name s, in long n) raises(NameClash, Overflow); void delete(in Name s); readonly attribute long capacity; };

Vordefiniert ist module CORBA { interface ORB { .... // Schnittstelle eines Pseudoobjekts mit }; // objektunabhängigen Standardoperationen interface Object { .... // Standardoperationen für Objekte }; ....... Qualifizierte Namen: z.B. example::Phones, CORBA::ORB Jede Schnittstelle erbt implizit von CORBA::Object, d.h. jeder Objekttyp ist verträglich mit CORBA::Object

9.4.3 Umgang mit Verweisen ist unabhängig von Programmiersprachen und deren Verweisen ! interface Object { // Operationen auf Verweisen Object duplicate(); // liefert Kopie des Objektverweises boolean is_equivalent(in Object other); // bezeichnet other dasselbe Objekt? boolean is_nil(); // bezeichnet der Verweis ein gültiges Objekt? ... }; Alle diese Operationen werden lokal ausgeführt.

Umwandlung von Verweisen in Zeichenketten (und zurück): interface ORB { string object_to_string(in Object o); Object string_to_object(in string s); ... }; Diese Zeichenketten – stringified object references - dienen lediglich als externe Repräsentation für Objektverweise. Es sind binäre Daten in ASCII-Kodierung, man kann aus ihnen die identifizierenden Informationen des Objekts nicht direkt ablesen.

9.4.4 CORBA-Infrastruktur ORB (Object Request Broker): eigentliche Middleware: verteilte Laufzeitunterstützung zwischen Betriebssystem einerseits und Anwendungscode und Vertretercode andererseits, zuständig für Fernaufrufe und lokale Basisdienste (ORB, Object) IOR (interoperable object reference): Objektverweis in standardisiertem Format POA (portable object adapter) Verwalter der lokal vorhandenen, fernaufrufbaren Objekte Servant (≈ Treiber + Implementierung) Implementierung eines fernaufrufbaren Objekts (z.B. ein Java-Objekt)

Interface Repository: verwaltet IDL-Schnittstellenbeschreibungen für Reflection Implementation Repository: verwaltet zugehörige Implementierungen zwecks on-demand-Aktivierung CORBA Services: breite Palette von Standarddiensten wie z.B. Naming Service, Notification Service, Transaction Service, ... CORBA Facilities: Sammlungen von Diensten und Spezifikationen für spezielle Anwendungsbereiche, z.B. Data Interchange, Systems Management, …

9.4.5 Sprachanbindung (language mapping) definiert die Beziehungen zwischen dem CORBA-Objektmodell und Syntax und Semantik einer bestimmten Programmiersprache  setzt die Typsysteme zueinander in Beziehung,  regelt die Nachbildung nicht verfügbarer Parametermechanismen,  stellt Bibliotheksroutinen für die CORBA-Standarddienste zur Verfügung (ORB, Object),  stellt einen Vertreter-Generator – IDL Compiler – zur Verfügung; der Vertreter heißt stub, der Treiber heißt skeleton.

Vertreter-Erzeugung am Beispiel Java: > idl2java example.idl erzeugt für jedes Modul ein Java Package, hier also ein einziges Package example. Das Package umfasst die folgenden Dateien: PhonesOperations.java Schnittstelle entsprechend Phones Phones.java Schnittstelle, die PhonesOperations und org.omg.CORBA.Object zusammenfaßt PhonesStub.java Vertreter-Klasse PhonesStub PhonesHelper.java Hilfsklasse PhonesHelper PhonesPOA.java Treiber-Klasse PhonesPOA (für Vererbung) PhonesPOATie.java Treiber-Klasse PhonesPOATie

Automatische Erzeugung von IDL-Text .idl für bereits vorliegenden Server-Code ist möglich, wenn sich daraus eine Schnittstelle ableiten läßt, z.B. für eine Java-Klasse import java.rmi.*; public class PhonesImpl implements Remote {...} (nach Übersetzung) wie folgt: > rmic –idl PhonesImpl (SUN) oder > java2idl PhonesImpl (VisiBroker u.a.) In der Tat ist hier lediglich ‚implements Remote‘ erforderlich!

9.4.6 Programmierbeispiel in Java Schnittstelle ist example.idl (9.4.2 ) Anbieter besteht aus eigentlichem Objekt – genannt Servant – und dem Server-Prozess, der als Träger des Objekts fungiert: // servant class import org.omg.CORBA.*; public class PhonesImpl extends PhonesPOA { // skeleton as superclass ! ... public int lookup(String n) {...} } Beachte: Klassenname irrelevant, kein interface erforderlich – aber Schnittstelle muss zu example.Phones passen!

import org.omg.CORBA.*; // has class for CORBA::ORB (& others) // server main program import org.omg.CORBA.*; // has class for CORBA::ORB (& others) import org.omg.PortableServer.*; // has interface for PortableServer::POA (& others) public class Server { public static void main(String[] arg) { PhonesImpl ph = new PhonesImpl(); // Java object ..... ORB orb = ORB.init(); // initialize ORB POA poa = POAHelper.narrow( // and POA orb.resolve_initial_references("RootPOA")); org.omg.CORBA.Object obj = // CORBA object! poa.servant_to_reference(ph); ..... // publish obj, e.g. via Naming Service (s.u.) orb.run(); // wait for invocations } } ... zuzüglich Ausnahmebehandlung … oder publizieren durch Ausgabe der stringified IOR.

Alternativ: Delegation statt Vererbung // servant class public class PhonesImpl extends PhonesBase implements PhonesOperations { // no skeleton yet ... public int lookup(String n) {...} } ... sowie ... // server main program PhonesImpl ph = new PhonesImpl(); // Java object PhonesPOATie tie = new PhonesPOATie(ph); // Skeleton! org.omg.CORBA.Object obj = // CORBA object poa.servant_to_reference(tie);

Klient: import org.omg.CORBA.*; ..... ORB orb = ORB.init(); // initialize ORB org.omg.CORBA.Object obj = ... // get CORBA object, e.g., // through Naming Service Phones p = PhonesHelper.narrow(obj);// get Java object if(p == null) ... // type error int number = p.lookup("Otto"); // remote invocation ... zuzüglich Ausnahmebehandlung

9.4.7 Portable Object Adapter (POA) erlaubt Vielzahl unterschiedlicher Strategien zur Gestaltung der Beziehungen zwischen CORBA-Objekt, Servant und Server  Lebensdauer eines CORBA-Objekts und des implementierenden Servants sind unabhängig.  POA unterstützt persistente Objekte, deren Lebensdauer die des POA (d.h. des Server-Prozesses) übertrifft.  Objekt wird aktiviert (incarnated) durch Verbindung mit einem Servant, und wird deaktiviert (etherealized) durch Lösen dieser Verbindung.  POA verwaltet seine Objekte in Objekttabelle (active object map), in der die jeweils zugehörigen Servants verzeichnet sind; für deaktivierte Objekte übernimmt ein Default Servant die Aufrufbehandlung.

Ferner: - Strategien sind programmgesteuert wählbar - Standard-Strategie: transiente Objekte - Persistenz wird unterstützt durch Implementation Repository und ORB Daemon, der bei Bedarf Server-Prozess startet - Weitere POA-Exemplare – z.B. mit unterschiedlichen Strategien – können programmgesteuert erzeugt werden - usw. usf.

= Namensdienst mit hierarchisch strukturiertem Namensraum 9.4.8 Naming Service = Namensdienst mit hierarchisch strukturiertem Namensraum Context enthält - reguläre Objekt-Einträge, - weitere Namensräume (subcontexts) module CosNaming { // Cos = CORBA Service ... typedef sequence<NameComponent> Name; interface NamingContext { void rebind(in Name n, in Object o); void rebind_context(in Name n, in NamingContext c); Object resolve(in Name n); }; }; … zuzüglich Ausnahmen

Benutzung in Java-Client: import org.omg.CosNaming.*; import org.omg.CosNaming.NamingContextPackage.*; ..... org.omg.CORBA.Object obj = orb.resolve_initial_references("NameService"); NamingContextExt root = NamingContextExtHelper.narrow(obj); Name name = root.to_name("mycontext/myserver.ext"); org.omg.CORBA.Object x = root.resolve(name); id[.kind]

Benutzung in Java-Server: import org.omg.CosNaming.*; import org.omg.CosNaming.NamingContextPackage.*; ..... org.omg.CORBA.Object obj = orb.resolve_initial_references("NameService"); NamingContextExt root = NamingContextExtHelper.narrow(obj); NamingContext ctx = NamingContextExtHelper.narrow(root.new_context()); root.rebind_context(root.to_name("mycontext"), ctx); root.rebind(root.to_name( "mycontext/myserver.ext", myserver);

zwischen verschiedenen CORBA-Implementierungen 9.4.9 Interoperabilität zwischen verschiedenen CORBA-Implementierungen General Inter-ORB Protocol (GIOP) (Transfersyntax + Nachrichtenformate) Internet Inter-ORB Protocol (IIOP) andere (+ Realisierung über TCP/IP) (z.B. IPX, OSI, ...) Objektbezugnahme über Interoperable Object Reference (IOR)

Ferner: Environment-Specific Inter-ORB Protocols (ESIOPs) statt GIOP/IIOP, falls auf bereits vorhandener Middleware aufgesetzt werden soll. Beispiel: DCE Common Inter-ORB Protocol (DCE-CIOP) ist ein ESIOP auf Basis des DCE RPC.

Interoperabilität RMI – CORBA durch „RMI over IIOP“ (statt über JRMP – Java Remote Method Protocol) Klient/Anbieter programmiert in Java RMI, Vertreter-Erzeugung mit rmic –iiop Client Server CORBA RMI (Java  IDL ) RMI CORBA (erfordert Java Interface!) Einige Programmierunterschiede zu Java RMI: - Java Naming and Directory Interface (JNDI) statt Registry - keine verteilte Speicherbereinigung - . . .

9.4.10 Replikation Für Fehlertoleranz: CORBA-Spezifikation: Fault-Tolerant CORBA (OMG 2000) Implementierung: Eternal System (Moser et al. 1998-2000), basiert auf Totem-Protokoll für zuverlässige Gruppenkommunikation mit vollständig geordneten Rundrufen Replikationsabstraktion!  Objektgruppe bleibt vor Klienten verborgen  Klient verwendet IOGR genauso wie IOR  Verschiedene Replikationstechniken stehen zur Auswahl

Für Effizienz: Keine CORBA-Spezifikation Implementierung: Cascade System (Chockler et al. 2000), realisiert Caching mit unterschiedlichen Konsistenzeigenschaften Replikationsabstraktion – wenngleich etwas eingeschränkt durch die Möglichkeit, die Konsistenz zu wählen

(Gerald Brose u.a., FU Berlin 1996-.....) 9.4.11 JacORB = Open Source Java ORB (Gerald Brose u.a., FU Berlin 1996-.....) http://jacorb.inf.fu-berlin.de Buch zu CORBA mit Java: Brose, Vogel, Duddy: Java Programming with CORBA. Wiley 2001