vs CORBA = Common Object Request Broker Architecture Standard (nicht Produkt!) der OMG – Object Management GroupObject Management Group Architektur: objektorientiert/Fernaufrufe + Komponenten IDL:C++ -ähnlich Dienste:sehr reichhaltig Anwendungen:Dienste, insbesondere Einbinden von Altsoftware

vs Objektmodell: Schnittstellen und Objekte Schnittstelle: 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

vs9.43 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 !

vs 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)

vs9.45 Typsystem: Typ Basistyp Verweistyp (basic type)(reference type) einfachzusammengesetzt Objekttyp Werttyp Objectvaluetype long struct{ fields } char [ size ] string sequence mit Vererbung (auch Mehrfachvererbung)

vs9.46 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

vs9.47 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.

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

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

vs9.410 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

vs 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 Objekt?... }; Alle diese Operationen werden lokal ausgeführt.

vs9.412 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. Sie sehen kryptisch aus, und man kann aus ihnen die identifizie- renden Informationen für das Objekt nicht direkt ablesen.

vs 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 Implementierung eines fernaufrufbaren Objekts (z.B. ein Java-Objekt)

vs9.414 Interface Repository: verwaltet IDL-Schnittstellenbeschreibungen Implementation Repository: verwaltet zugehörige Implementierungen CORBA Services: breite Palette von Standarddiensten wie z.B. Naming Service, Notification Service, Transaction Service,... CORBA Facilities: weitere Spezifikationen, z.B. Data Interchange, Systems Management, …

vs 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.

vs9.416 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 (s.u.) PhonesPOA.java Treiber-Klasse PhonesPOA (für Vererbung) PhonesPOATie.java Treiber-Klasse PhonesPOATie

vs9.417 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 –idlPhonesImpl (SUN)oder > java2idl PhonesImpl (VisiBroker u.a.)

vs Programmierbeispiel in Java Schnittstelle ist example.idl (9.4.2  )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!

vs9.419 // 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 =... // and POA..... org.omg.CORBA.Object obj = // CORBA object! poa.servant_to_reference(ph);..... // e.g., publish obj via Naming Service orb.run(); // wait for invocations } }... zuzüglich Ausnahmebehandlung

vs9.420 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("Robert"); // remote invocation zuzüglich Ausnahmebehandlung

vs 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-Prozesss) ü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.

vs9.422 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.

vs Naming Service = Namensdienst mit hierarchisch strukturiertem Namensraum Context enthält - reguläre Einträge, - subcontexts module CosNaming {... typedef Sequence Name; interface NamingContext { void bind(in Name n, in Object o); void bind_context(in Name n, in NamingContext c); Object resolve(in Name n);... }; }; … zuzüglich Ausnahmen

vs9.424 Benutzung in Java: import org.omg.CosNaming.*; import org.omg.CosNaming.NamingContextPackage.*;..... org.omg.CORBA.Object obj = orb.resolve_initial_references("NameService"); NamingContext root = NamingContextHelper.narrow(obj); org.omg.CORBA.Object x = root.resolve(name);.....

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

vs9.426 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.

vs9.427 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 ClientServer CORBARMI (Java  IDL !) RMICORBA Einige Programmierunterschiede zu Java RMI: - Java Naming and Directory Interface (JNDI) statt Registry - keine verteilte Speicherbereinigung -...

vs Replikation Für Fehlertoleranz: CORBA-Spezifikation:Fault-Tolerant CORBA (OMG 2000) Implementierung: Eternal System (Moser et al ), 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

vs9.429 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

vs JacORB = Open Source Java ORB (Gerald Brose u.a., FU Berlin ) Buch zu CORBA mit Java: Brose, Vogel, Duddy: Java Programming with CORBA. Wiley 2001Wiley 2001