Zusammenfassung Netzprogrammierung (Folien und Bücher)

Zusammenfassung Netzprogrammierung (Folien und Bücher) 1. Einleitung a. Verteilte Systeme Definition: Ein verteiltes System ist eine Menge voneinander unabhängiger Computer, die dem Benutzer wie ein einzelnes, kohärentes System erscheinen. Anschein: autonome Maschinen, einziges System moderne verteilte System bestehen aus Tausenden Prozessen, die über ein unzuverlässiges Netzwerk verteilt sind (Internet) Arten: o Server-Zentrierung: Dumme Terminals nutzen einen Server mit Datenbank, Programme auf dem Server laufen nebenläufig, Terminals sind nur Anzeigegeräte, Netzwerk ist lediglich Draht zur Zeichenübermittlung o Client-Server: durch Middleware verbundene Server bilden einen Server, schlaue Klienten nutzen diese durch Middleware, Netzwerk ist ein WAN oder LAN o Föderation: durch Middleware verbundene Server bleiben autonom und arbeiten zusammen, schlaue Klienten nutzen diese durch Middleware (ist etwas symmetrischer) o Peer-to-Peer: jeder arbeitet mit jedem zusammen, jeder ist gleichberechtigt, Middleware ist erheblich komplexer Gründe: o Technisch: schlecht und unvorhersagbare Reaktionszeit zentralisierter Systeme, insbesondere in Interaktion mit Nutzer, gute Verfügarkeit von Vernetzung, geringe Kosten der Vernetzung o Organisatorisch: größere Integration von Organisationen, virtuelle Organisationen mit natürlicher Verteiltheit von Anwendungen, Ad-hoc Zusammenarbeit erlaubt keine zentralisierten Strukturen Eigenschaften: Systeme sind immer aus verschiedenen, oft unabhängigen Komponenten zusammengesetzt, Komponenten: o sind räumlich verteilt (bedingt Vernetzung, Kommunikation) o sind einzeln von Fehlern betroffen (Fehler und Auswirkungen für andere sichtbar) o müssen integriert sein, so dass sie möglichst homogen erscheinen (bedingt zusätzliche Software = Middleware) o Komponentenheterogenität teilweise transparent (vereinfacht Systemgestaltung) o als autonome Partner in Interaktionen (bedingt Nebenläufigkeit) Vorteile: o bessere Leistung (kostengünstige einfache Komponenten und Vernetzungsund Kommunikationskosten, bessere Antwortzeiten durch Lastverteilung) o bessere Organisation (gemeinsame Nutzung von Ressourcen, Kommunikation im System erlaubt Kommunikation zwischen Usern) o bessere Zuverlässigkeit (durch verteilten Fehlerauftritt und mehrfach vorhandene Ressourcen und Kopien von Daten, unwahrscheinlicher Gesamtausfall, inkrementeller Ausbau möglich, einfachere Wartung) Nachteile: o Leistung abhängig von Netzwerkverfügbarkeit und dessen Qualität (Latenz, Bandbreite) o Organisation: höhere Komplexität der Software und Planung der Kommunikation und Koordination nötig, zusätzlicher Aufwand beim Testen durch nichtdeterministisches Netzverhalten o Zuverlässigkeit: erheblich mehr logische und physische Angriffspunkte

b. Middleware Definition: zusätzliche Softwareschicht zwischen Applikationen und Netzwerkbetriebssystemen (ist in Netzwerkbetriebssystemen für die Verbergung der Heterogenität der vielen verschiedenen Plattformen zuständig ist), höhere Abstraktionsebene möglich Middleware stellt Technologien, Abstraktionen, Schnittstellen bereit, mit der netzbasierte Systeme realisiert werden können Positionierung: Kleber zur Verbindung von Anwendungen (für Anwendungen erscheint verteiltes System homogener, als es tatsächlich ist, sitzt zwischen Anwendung und Betriebssystem Verteilungstransparenzen: Transparenz = Tatsache verbergen, dass Prozesse und Ressourcen (Heterogenität der Software/Hardware, Ort und Bewegung der Komponenten, Mechanismen zur Fehlerbehandlung) physisch über mehrere Computer verteilt sind und so tun, als ob es sich um ein einziges System handelt o Zugriff: verbirgt Unterschiede in der Datendarstellung und wie der Zugriff auf eine Ressource erfolgt (maskiert unterschiedliche Datenrepräsentationen, Aufrufmechanismen, genutzte Programmiersprachen) am notwendigsten! o Position: verbirgt, wo sich eine Ressource befindet (maskiert die Nutzung von Ortinformationen beim Auffinden anderer Objekte, ermöglicht rein logische Sicht auf Namen im System, keine Ortinformationen zur Nutzung von Namen nötig) o Migration: verbirgt, dass eine Ressource an eine andere Position verschoben werden kann (maskiert Ortänderungen an Objekten, ermöglicht transparenten Lastausgleich) o Relokation: verbirgt, dass eine Ressource an einen anderen Ort verschoben werden kann, während sie genutzt wird (sichert Weiterarbeit auch trotz temporär inkonsistenter Sichten) o Replikation: verbirgt, dass eine Ressource repliziert ist (maskiert den Einsatz einer Gruppe von Objekten an einer Schnittstelle, erhöht Performance und Verfügbarkeit) o Nebenläufigkeit/Transaktion: verbirgt, dass eine Ressource von mehreren konkurrierenden Benutzern gleichzeitig genutzt werden kann (beinhaltet Planung, Überwachung, Widerrufen von Aktivitäten) o Fehler: verbirgt den Ausfall und die Wiederherstellung einer Ressource (Bsp: Checkpointing, Transaktionen) o Persistenz: verbirgt, ob eine (Software-) Ressource sich im Speicher oder auf einer Festplatte befindet (maskiert die Aktivierung/Deaktivierung von Objekten zu Klienten und zum Objekt selber, Objekte erscheinen immer verfügbar)

Klassen: RPC Remote Procedure Call (synchroner, entfernter Prozeduraufruf), DOM Distributed Object Middleware (synchroner, entfernter Methodenaufruf an Objekten), Distributed Tuples (Tuplespace als asynchrones Blackboardartiges Koordinationsmedium), MOM Message-Oriented Middleware (Mailbox- Methapher für asynchrone Entkopplung) c. Web als verteiltes System Web = einfaches, konsistentes und einheitliches Modell verteilter Dokumente (unwichtig, von welchem Server das Dokument geladen wurde) eine Web-basierte Anwendung ist ein verteiltes System, jede Komponente (Web Server, Web Crawler, Indexierte Seiten) kann auf anderen Rechner sein http, HTML als Middleware (allerdings nicht hinreichend integriert) d. Client-Server-Modell Clients und Server: o Prozesse werden zwei (möglicherweise überlappende) Gruppen eingeteilt o Server = Prozess, der einen bestimmten Dienst implementiert o Client = Prozess, der einen Dienst von einem Server anfordert, indem er eine Anforderung sendet und auf eine Antwort wartet o Kommunikation zwischen beiden kann in einem zuverlässigen Netzwerk verbindungslos sein (effizienter für lokale Netze, Fehlererkennung allerdings schwieriger!) o Alternative: zuverlässiges, verbindungsorientiertes Protokoll (geringe Leistung für lokales Netzwerk, perfekt für WAN) Ebene der Benutzeroberfläche: o normalerweise durch die Clients implementiert o besteht aus den Programmen, die es den Benutzern ermöglichen, mit Anwendungen zusammenzuarbeiten Verarbeitungsebene: o Komponente, die mit einer Datenbank oder einem Dateisystem arbeitet o Systeme können unterschieden werden in Frontend (implementiert die Benutzeroberfläche), Backend (Zugriff auf Datenbank) und dazwischen liegende Analyseprogramme Datenebene: o normalerweise durch die Server implementiert o enthalten die Programme, die die eigentlichen Daten verwalten, mit denen die Anwendungen arbeiten o Daten sind persistent, werden hier konsistent gehalten Mehrschichtige Architekturen ( Multitier ): o Programme aus den Anwendungsebenen über unterschiedliche Maschinen verteilen o erst nur zwischen Client und Server unterscheiden (Zwei-Schichten- Architektur two-tiered ) (a) terminalabhängigen Teil auf Clientmaschine, Applikationen haben entfernte Kontrolle über Darstellung der Daten (b) gesamte Software für Benutzeroberfläche auf Client, Applikation enthält ein grafisches Frontend (hat nur die Aufgabe der Darstellung) (c) einen Teil der Applikation ins Frontend verschieben (sinnvoll z.b. für ein Formular, das komplett ausgefüllt werden muss, was die Applikation auf Client-Seite erst überprüft und ggf. mit dem Benutzer kommuniziert) (d) Client ist ein PC oder Workstation in einem Netzwerk mit verteiltem Dateisystem oder Datenbank, Großteil der Applikationen werden auf dem Client, Dateioperationen aber auf dem Server durchgeführt (e) lokale Festplatte des Clients enthält einen Teil der Daten

o Server können auch als Clients arbeiten Drei-Schichten-Architektur three-tiered (Verwendung: Transaktionsverarbeitung) 2. Remote Procedure Calls RPC a. Remote Procedure Call Definition: entfernter Prozeduraufruf, als grundlegender Mechanismus für verteilte Systeme (direkt implementiert von SUN RPC, HP RPC, weiterentwickelt in Java RMI, konzeptionell enthalten in HTTP) RPC ist ein synchroner Mechanismus, der Kontrollfluss und Daten als Prozeduraufruf zwischen zwei Adressräumen über ein schmalbandiges Netz transferiert (Birrell, Nelson) versucht Probleme der Nachrichtenübergabe zu verbergen, ideal für Client- Server-Anwendungen Konzept: entfernten Prozeduraufruf wie lokalen Prozeduraufruf aussehen lassen der RPC soll transparent sein Kontroll- und Datenfluss: RPC transferiert Kontrollfluss und Daten über ein Netzwerk zwischen Rechnern, Prozeduraufruf (vom Aufrufer in eine Prozedur) steuert den Kontrollfluss und die Parameter, Prozedurbeendigung (zurück) steuert den Kontrollfluss und die Ergebnisdaten (dafür müssen beide Maschinen identisch sein, denselben Zeichencode und dieselbe Zahlendarstellung verwenden, Bytes identisch nummerieren Big/Little- Endian) Eigenschaften: synchron: Aufrufer blockiert bis Aufgerufener das Ergebnis liefert Prozeduraufruf: Signatur der Prozedur definiert zu übertragende Daten unterschiedlicher Adressraum: Speicheradressen (Zeiger) sind nicht semantikerhaltend übertragbar schmalbandig: Bandbreite des Netzes ist um Dimensionen geringer als die der Kommunikationspfade innerhalb eines Rechners

Unterschiede lokaler / entfernter Aufruf: lokal entfernt Aufrufer und Prozedur werden im Aufrufer und Prozedur werden in selben Prozess ausgeführt unterschiedlichen Prozessen ausgeführt Aufrufer und Prozedur stehen im Aufrufer und Prozedur stehen In selben Adressraum unterschiedlichen Adressräumen Aufrufer und Prozedur liegen in derselben Hard- und Softwareumgebung Aufrufer und Prozedur haben dieselbe Lebensdauer Aufruf ist immer fehlerfrei es müssen nur Anwendungsfehler berücksichtigt werden Aufrufer und Prozedur liegen in unterschiedlichen Hard- und Softwareumgebungen Aufrufer und Prozedur haben unterschiedliche Lebensdauer Aufruf ist fehlerbehaftet es müssen zusätzlich Aufruffehler behandelt werden Vorteile: bessere Aufgabenverteilung, Lastverteilung, Ressourcennutzung, Modularität, Wiederverwendbarkeit, Integrationsfähigkeit, größere Offenheit Vorteile der Prozedurabstraktion: klare und verständliche Semantik von RPC, Prozeduraufrufe wohlverstanden und geeignetes Mittel zur Kommunikation, Einfachheit des Mechanismus ermöglicht effiziente Implementierungen Ablauf: Asynchroner RPC: Klient blockiert nicht, holt Ergebnis später ab, ermöglicht größeren Grad der Nebenläufigkeit (mehrere RPCs können offen sein, mehrere Prozesse in Servern arbeiten an Ergebnissen) Probleme: Semantik im Fehlerfall und von Zeigern, Einbettung in Programmiersprachen, Auffinden und Binden an die entfernten Prozeduren, Protokoll des Datenaustausches, Eigenschaften der Kommunikation

b. Komponenten Anwendungsprozeduren erledigen die eigentliche Arbeit, Stubs ver- und entpacken die Daten zum Transport, Kommunikation: Transport der Daten Interaktionspunkte: lokale Schnittstelle: Modul bietet Prozeduren zum Aufruf an (Modul exportiert eine Schnittstelle), ein anderes Modul ruft die Prozeduren der Schnittstelle auf (es importiert eine Schnittstelle) entfernte Schnittstelle: Anwender-Stub stellt Schnittstelle lokal bereit, Stubs und Kommunikationskomponente leiten Aufrufe an Schnittstelle des entfernten Moduls weiter und Ergebnisse des entfernten Moduls zurück Bindung: zwischen Aufrufer und Aufgerufenem, statische Bindung (zur Übersetzungszeit werden Klienten an feste Serveradressen gebunden), halbstatische Bindung (zur Startzeit des Klienten werden Serveradressen konfiguriert, ermittelt aus Datenbank/Tabelle), dynamisch (zur Aufrufzeit werden Serveradressen ermittelt, Serveradresse kann zwischen 2 RPCs wechseln) Trader/Broker (Vermittler): Komponente, die die Server kennt und Referenzen auf sie vermitteln kann o Registrierung/Abmeldung von Servern: Angabe der exportierten Schnittstelle, Referenz auf sich o Aufsuchen eines passenden Servers: Angabe einer Schnittstellenbeschreibung c. Fehler Fehler Server nicht erreichbar für RPC Server fällt während RPC-Ausführung aus Fehlerursache/folge Maschine ausgefallen Netzwerk ausgefallen Transport maskiert Fehler durch Neuversuche Broker maskiert Fehler durch andere Serverwahl Klient muss Fehler verarbeiten Ausfall während Klient wartet, Seiteneffekte realisiert Ausfall nach RPC Klient wartet, Seiteneffekte eingetreten Klient fällt während Server kann Ergebnis nicht liefern RPC-Ausführung aus neugestarteter Klient kann alte RPCs absagen neugestarteter Klient kann alten RPS übernehmen Server kann Klient überwachen, bei Timeout und Ergebnis bei Ablauf verwerfen Server hat Schnittstelle geändert und bietet Dienst nicht mehr an RPC-Mitteilungen gehen die Anforderung oder Teile davon

verloren das Ergebnis ist weg semantische Eigenschaften: Mix aus Fehlerquelle und Reaktion darauf ergibt unterschiedliche semantische Eigenschaften: o may-be: RPC wird nicht mehr als 1 Mal ausgeführt (oder 0 oder teilweise), passend, wenn Klient kein Ergebnis braucht o at-least-once: mindestens 1 Mal ausgeführt o at-most-once: höchstens 1 Mal ausgeführt (Ausfall vor Verarbeitung keine Ausführung, Ausfall während Verarbeitung Neustart, Konsistenz durch Transaktion, Ausfall nach Verarbeitung Ergebniskopie nach Neustart versandt) o exactly-once: genau 1 Mal 3. Verteilte Objekte in Java RMI a. Verteilte Objekte/RMI Verteilte Objekte : o RPC übertragen auf OO-Welt: entfernter Methodenaufruf o Interaktionsmuster in OO-Sprachen: Objekte tauschen Mitteilungen aus, beim Empfang einer Mittleilung führt ein Objekt eine Methode aus und schickt eventuelle Ergebnisse, Modell sagt nichts über Verteilung aus o Rollen der Partner: Aufrufer <=> Aufgerufener, Dienstnutzer <=> Dienstanforderer, Client <=> Server o Verteilte Objekte in Java: Remote Method Invocation RMI Lokale vs. verteilte Objekte lokales Objektmodell Aufruf an Objekten Parameter und Ergebnisse als Referenzen alle Objekte fallen zusammen aus keine Fehlersemantik verteiltes Objektmodell Aufruf an Interfaces Parameter und Ergebnisse als Kopien einzelne Objekte fallen aus komplizierte Fehlersemantik (Referenzintegrität, Netzfehler, Sicherheit) o ein Java-Programm arbeitet in einer virtuellen Java Machine (JVM) o zwischen JVMs können mit RMI Methoden an Objekten aufgerufen werden o JVMs können auf unterschiedlichen Internet-Rechnern laufen Schnittstellen : Objektschnittstellen definieren Methoden eines Objekts, unterschiedliche Implementierungen für gleiche Schnittstelle S, Modulschnittstellen des RPC werden aud Objektschnittstellen abgebildet, Aufrufweiterleitung durch Stellvertreter (Proxy) Bsp: lokales Zählerobjekt class LocalCounterImplementation { int counter; public LocalCounter () { public void add (Integer i) { counter += i.intvalue(); public Integer value() { return (new Integer(counter));

könnte folgende Schnittstelle implementieren: public interface LocalCounter { /* Addieren */ public void add (Integer i); /* Abfragen */ public Integer value(); Aufruf: c.add(new Integer(10)); Bsp: entferntes Zählerobjekt auf Aufruferseite wird mit einem Interface gesprochen (Schnittstelle macht Fehlermöglichkeit explizit): public interface Counter extends java.rmi.remote { /* Addieren */ public void add (Integer i) throws java.rmi.remoteexception; /* Abfragen */ public Integer value() throws java.rmi.remoteexception; Bsp: RMI Erbringerseite: ein Serverobjekt implementiert das Interface public class CounterServer extends java.rmi.server.unicastremoteobject implements Counter { int counter; public CounterServer() throws java.rmi.remoteexception { public void add(integer i) throws java.rmi.remoteexception { counter+=i.intvalue(); public Integer value() throws java.rmi.remoteexception { return(new Integer(counter)); Bsp: Aufruf eines entfernten Objekts: Aufruf durch Aufruf einer Methode an Interface, tatsächich wird damit eine Methode am Proxy aufgerufen (Unterschied: Fehlermöglichkeit) Counter c;... try { c.add (new Integer (10)); System.out.println ((c.value()). intvalue()); catch (Exception e) { System.err.println(e.getMessage());

rmic: Compiler für Verbindungsstücke: diese (Stub auf Clientseite, Skeleton auf Serverseite) werden automatisch erzeugt, rmic Serverklasse erzeugt Serverklasse_stub.class und Serverklasse_skel.class Bsp: Compilieren und Ausführen: >javac Counter.java >javac CounterServer.java >rmiregistry >java CounterServer >rmic CounterServer >java CounterUser 10 >javac CounterUser.java >java CounterUser 20 b. Objektreferenzen Fragen: Woher kennt der Aufrufer eigentlich das entfernte Objekt?, Wohin schickt der Proxy eigentlich den Methodenaufruf? RMIRegistry: Verzeichnisdienst für Objekte, Registry-Objekt liefert Referenzen auf Objekte rmiregistry: JDK-Programm rmiregistry ist RMI-Objekt für Interface java.rmi.registry.registry, Methoden o void bind, rebind (String name, Remote obj) Binden eines Objekts unter einem Namen o void lookup (String name) Referenz auf gebundenem Objekt erfragen o void unbind (String name) Bindung löschen o String[] list() Bindungen abfragen Bsp: Server-Programm meldet sich an: URL-Schema: rmi://rechner/pfad public class CounterServer extends java.rmi.server.unicastremoteobject implements Counter { //... public static void main(string argv[]) { System.setSecurityManager(new RMISecurityManager()); try { CounterServer c = new CounterServer(); Naming.bind("rmi://"+ (InetAddress.getLocalHost()).getHostName() + "/Teilnehmer",c); catch (Exception e) { System.err.println(e.getMessage()); Bsp: Client-Programm erhält Referenz: import java.net.*; public class CounterUser { public static void main(string argv[]) { try { Counter c = (Counter)java.rmi.Naming.lookup("rmi://" + (InetAddress.getLocalHost()).getHostName() + "/Teilnehmer"); c.add(new Integer(10)); System.out.println((c.value()).intValue());

catch (Exception e) { System.err.println(e.getMessage()); java.rmi.naming: Woher bekommt man eigentlich die Referenz auf ein Registry-Objekt? o Registry-Objekt der lokalen Maschine über statische Methoden der Klasse java.rmi.naming zugänglich o void java.rmi.naming.bin (String name, Remote obj) o void java.rmi.naming.rebind(string name, Remote obj) o Remote java.rmi.naming.lookup(string name) o void java.rmi.naming.unbind(string name) o String[] java.rmi.naming.list() java.rmi.registry.locateregistry: Woher bekommt man eigentlich die Referenz auf ein Registry-Objekt? o Registry-Objekte auf entfernten Maschinen über statische Methoden der Klasse java.rmi.naming zugänglich o Registry getregistry() Lokale Registry auf Port java.rmi.registry.registry.registry_port: o Registry getregistry(int port) Lokale Registry auf einem anderen Port o Registry getregistry(string host) Registry auf Rechner host o Registry getregistry(string host, int port) Registry auf Rechner host, Port port Callback: o zwischen Client und Server-Objekt ist eventuell ein complexes Protokoll notwendig o Client/Server folgt Anfrage/Antwort Protokoll o für Nachfrage/Anfrage/Antwort Protokoll muss Client selber zum Server werden o Nachfrage: Callback Methode des Clienten Objekts o in RMI: auch Client wird ein Serer-Objekt, übergibt Referenz auf sich bei Anfrage Bsp: Schnittstellen: o Server: public interface RMIPongServerInterface extends java.rmi.remote { public void pong(rmipongclientinterface theclient) throws java.rmi.remoteexception ; o Client: public interface RMIPongClientInterface extends java.rmi.remote { public boolean more() throws java.rmi.remoteexception ; Bsp: Server: class RMIPongServer extends java.rmi.server.unicastremoteobject implements RMIPongServerInterface { RMIPongServer() throws java.rmi.remoteexception { public void pong(rmipongclientinterface theclient) throws java.rmi.remoteexception { while (theclient.more()) { System.out.println("Pong");

public static void main(string[] argv) throws java.rmi.remoteexception,java.rmi.alreadyboundexception, java.net.malformedurlexception { RMIPongServer pongserver = new RMIPongServer(); java.rmi.naming.bind("rmi://localhost/pong",pongserver); Bsp: Client: class RMIPongClient extends java.rmi.server.unicastremoteobject implements RMIPongClientInterface { int morecounter = 0; RMIPongClient() throws java.rmi.remoteexception { public boolean more() throws java.rmi.remoteexception { return ((morecounter++)<5); public static void main(string[] argv) throws java.rmi.remoteexception, java.rmi.notboundexception, java.net.malformedurlexception { RMIPongClient pongclient = new RMIPongClient(); RMIPongServerInterface pongserver = (RMIPongServerInterface)java.rmi.Naming.lookup("rmi://localhost/pong"); pongserver.pong(pongclient); c. Serialisierung Objektserialisierung: Parameter und Ergebnisse müssen übertragen warden, das Erstellen einer seriellen Repräsentation eines Objekts ist die Serialisierung, notwendig zum Versenden oder Speichern von Objekten, Instanzwerte+Klasse=Objektrepräsentation automatische Serialisierung: automatisch, wenn Klassen die Schnittstelle java.io.serializable implementieren, rmic erzeugt Code für Serialisierung und Deserialisierung indem Klassendefinitionen angeschaut werden Serialisierung: o implements Serializable bedeutet: die automatische Serialisierung kann angewandt werden o schreibt man RMI Objekte und bewegt Objekte als Parameter oder Ergebnis, dann müssen diese Objekte als Serializable markiert o Fehlerquelle: rmic hat Serialisierungscode erzeugt und man ändert danach das Objekt-Lyaout: ergibt Marshalling Fehler zur Laufzeit Klassen nachladen: Objekte = Daten + Verhalten, serialisierte Java- Objekte=Datenstrom + Klasse, Klassen zu übermitteltem Objekt nachladen, falls nicht vorhanden, Bedrohung durch Angreifer, da alle Rechte gesetzt sein müssen, SecurityManager wird vor sicherheitsrelevanten Aktionen gefragt Security Manager: o Installation eines Security Managers mit der Methode void System.setSecurityManager (SecurityManager s) o fragt eventuell schon vorhandenen SecurityManager, ob das erlaubt ist

o RMI Classloader lädt Klassen von entfernten Rechner nur dann nach, wenn SecurityManager installiert ist o SecurityManager ist eine abstrakte Klasse d. Nebenläufigkeit Threads und RMI Aufrufe o mehrere gleichzeitig eintreffende RMI Aufrufe (lokal und mehrere Netzverbindungen) können in Threads arbeiten o immer davon ausgehen, dass Methoden nebenläufig aufgerufen werden o es kann immer zu Schreibkonflikten kommen 4. CORBA a. Was ist CORBA? Definition: CORBA (Common Object Request Broker Achitecture) ist eine offene, sprachunabhängige, herstellerunabhängige Plattform für vernetzte Anwendungen mit der OMG (Object Management Group) als Träger OMG o CORBA Objekte sind Bausteine von Anwendungen und haben eine typisierte Schnittstelle o es gibt von der Schnittstelle getrennte Implementierungen in unterschiedlichen Programmiersprachen, Aufrufe darauf werden durch Object Request Broker transportiert o Ortstransparenz wird durch IIOP (Internet Inter-ORB Protocol) erreicht, Interworking zwischen ORBs unterschiedlicher Hersteller möglich Bestandteile o IDL zur Definition von Schnittstellen o Mappings von IDL zu Programmiersprachen o APIs zum Objektaufruf (statisch und dynamisch) o ORB als Transportschicht o spezielle Objekte: CORBA Services (verteilt angebotene niedere Dienste) und Common Facilities (nützliche anwendungsbezogene Dienste, die aber nicht als notwendige Dienste angeboten werden müssen) Produkte o einzeln erhältlich (ORBs, IDL Anbindungen, Services, MAF) o mittels CORBA können diese Komponenten unterschiedlicher Herkunft und Implementierung miteinander arbeiten o eine IDL Schnittstelle kann verschiedene Implementierungen in verschiedenen Programiiersprachen haben aus denen sich verschiedene Exemplare ergeben, die als CORBA Objektreferenz zugänglich sind und über ORB aufgerufen werden können Glossar o OMG (Object Management Group) entwickelt Standards o OMA (Object Management Architecture) Standard für verteiltes offenes Objektsystem o ORB (Object Request Broker) Laufzeitsystem in OMA, eigentliche Middleware o CORBA (Common Object Request Broker Architekture) abstrakte Spezifikation von ORBs o IDL (Interface Definition Language) Sprache zur Beschreibung von Schnittstellen in OMA, IDL Compiler erzeugt Stub und Skeleton o IIOP (Internet Inter-ORB Protocol) Protokoll zwischen ORBs o Stub ist Stellvertreter für entferntes Objekt o Skeleton ist Verwaltung des aufrufbaren Objekts o POA (Protable Object Adapter) Adapter Muster Einige Services

o Naming Service:liefert den Mechanismus, mit dem die moisten Clients eines ORB-basierten Systems Objekte finden, die sie benutzen möchten (RMI Registry) o Trading Object Service: erlaubt das Anbieten und Finden von Service- Instanzen verschiedener Typen b. Beispiel Counter-Bsp: notwendig: Schnittstellendefinition, Zählerobjekt, Registrierung des Servers, Nutzung des Servers durch Client o IDL: module counter { typedef struct Info { long value; long counted; _Info; interface Counter { readonly attribute long value; void add(in long value); void addto(inout long clientvalue); Info getinfo(); ; ; c. Interface Definition Language IDL Definition: Sprache zur Definition von Schnittstellen, sprachunabhängig, Semantik der Typen definiert, zur Nutzung Mapping zu konkreter Sprache notwendig, OMG definiert solche Mappings für unterschiedliche Sprachen d. Java IDL Mapping e. 5. Netzkommunikation Internet-Sockets a. Kommunikation Internet Internet: weltweiter Verbund von Rechnern, die über Netze Daten austauschen können, eine Protokollfamilie, ein offenes System, in dem Dienste genutzt und angeboten werden können Das Internet Protokoll IP ermöglicht Internetworking durch Etablierung eines Datenformats und Transportprotokollen, die auf unterschiedlichen Datenverbindungen aufgesetzt werden können Enveloping/Encapsulation: Fragmentation und Reassemblierung bon IP Paketen IP Datagramme: z.b. 6 32-Bit Worte plus Daten IP-Adressen: b. TCP c. Nebenläufige Serverprogramme d. UDP 6. Netzkommunikation Internet Dienste 7. Internet-Dienste in Java 8. Zustand in Web Anwendungen 9. Java Applets 10. HTML 11. XML Dokumente und ihre Verarbeitung 12. Andere Programmiermodelle