vs9 1 9 Middleware

vs9 2 Middleware, Verteilte Plattform (auch Verteilungsplattform*) bietet Verteilungsabstraktion für verteilte Anwendungsprogramme, bietet Standarddienste (Transaktionen, Sicherheit,...), unabhängig von unterliegenden Betriebssystemen und Hardware, oft unabhängig von den verwendeten Programmiersprachen (stattdessen Schnittstellen-Beschreibungssprache, „IDL“) aber orientiert an einem bestimmten Modell für Interaktion, Architektur, Komponenten * ältere Bezeichnung: network operating system (vs. distributed operating system)

vs9 3 Prominente Beispiele: PVM, MPI (4.1  ) Architektur: kommunizierende (schwergewichtige) Prozesse Keine IDL:(weil einfache Standard-Schnittstelle) Dienste:Prozessfernerzeugung Einsatz:Parallelrechnen ONC – SUN Open Network Computing (SUN 1987/88) (  9.1) 9.1 Architektur:Client/Server mit Fernaufrufen IDL:C-ähnlich Dienste:einfacher Namensdienst Einsatz:Erweiterte System-Dienste

vs9 4 COMANDOS - Construction and Management of Distr. Open Systems (EU-Projekt ) (  9.2) 9.2 Architektur:objektorientiert mit Fernaufrufen IDL:C++ -ähnlich Dienste:minimal (Entwicklungs-/Verwaltungs-Werkzeuge) Einsatz:universell (verteiltes Rechnen, Dienste,...) DCE –Distributed Computing Environment (Open Group [OSF] 1992) Architektur:Client/Server mit Fernaufrufen IDL:C-ähnlich Dienste:Directory Service, Security Service,... Distributed File System ( ≈ AFS,  Vert.BS) Einsatz:System- und Anwendungs-Dienste

vs9 5 (COM/OLE  ) DCOM (Microsoft ) (  9.3) 9.3 COM: Binärcode-“Standard“ für Schnittstelle („vtable“)  Interoperabilität zwischen Programmiersprachen OLE:für heterogene Verbunddokumente (z.B. Excel Chart in Word Document) („lokale Fernaufrufe“) DCOMArchitektur:Client/Server mit Fernaufrufen IDL:MIDL, Erweiterung der DCE IDL Dienste:Microsoft-spezifisch Einsatz:Anwendungsdienste (Implementierung: fast nur auf Windows)

vs9 6 CORBA – Common Object Request Broker Architecture (Open Management Group [OMG] ) Management Group ist Standard, nicht Produkt Architektur: objektorientiert/Fernaufrufe + Komponenten IDL:C++ -ähnlich Dienste:sehr reichhaltig Einsatz:Anwendungen, speziell Einbinden von Altsoftware EJB – Enterprise Java Beans (Sun 1998 …) Architektur: objektorientiert/Fernaufrufe (RMI) + Komponenten + Nachrichten IDL:(Java) Dienste:reichhaltig Einsatz:vielseitig, insbesondere Datenbank-Anwendungen

vs9 7.NET (Microsoft 2000 …) Architektur: objektorientiert/Fernaufrufe (8.1.6  ) IDL:(unsichtbare Metadaten, vom Übersetzer erzeugt) Dienste:Basisdienste + weitere in Entwicklung Einsatz:universell Standardisierung durch ECMA und ISO: Implementierung nicht nur auf Windows: MonoMono (Open Source, Linux, Novell/Ximian) „Rotor“ (Shared Source, FreeBSD, Microsoft)Rotor

vs SUN Remote Procedure Call SUN RPC = modulorientierte Fernaufrufe für C-Programme C-Programm-Module haben zwar Schnittstellen, aber C kennt kein Sprachkonzept „Schnittstelle“ !  Schnittstellenbeschreibung („protocol description“) in C-ähnlicher Sprache (RFC 1014/1831) ONC – SUN Open Network Computing (Sun 1987/88) Architektur:Client/Server mit Fernaufrufen: RPC IDL:C-ähnlich Dienste:einfacher Namensdienst Einsatz:erweiterte System-Dienste (NIS, NFS,...)

vs9 9 Terminologie: Service = Bündel von „Programmen“ (≈ Schnittstelle), eventuell in jeweils mehreren Versionen, bestehend aus jeweils mehreren „Prozeduren“ Server =Prozess, der als Träger eines Service fungiert Prozedur 0 Prozedur 1 Version Prozedur 0 Prozedur 1 Version Programm Prozedur 0 Prozedur 1 Version Prozedur 0 Prozedur 1 Version Programm

vs9 10 Beispiel für Schnittstellenbeschreibung (aus W.R.Stevens: UNIX Network Programming) /* date.x Specification of the remote date and time server */ /* Define two procedures * bin_date_1() returns the binary date and time (no args) * str_date_1() takes a binary time and returns a string */ program DATE_PROGRAM { version DATE_VERSION { long BIN_DATE(void) = 1; /* get binary time code */ /* procedure number = 1 */ string STR_DATE(long) = 2; /* convert code to string */ /* procedure number = 2 */ } = 1; /* version number = 1 */ } = 0x ; /* program number */ Erzeugung von Stub Code Standardisiert bzw. eigene zwischen 0x x3fffffff

vs9 11 Stub-Generator rpcgen generiert daraus: date.h Gemeinsame Modul-Definition (header) date_clnt.c Stub für den Klienten date_svc.c Stub für den Anbieter, inklusive main() und optional mit Schalter -Sc bzw. -Ss : date_client.c Beispiel-Datei für Zugriff durch Klienten date_server.c Beispiel-Datei für Implementierung des Anbieters

vs9 12 Modul-Definition: /* file date.h for ANSI C */ #define DATE_PROGRAM ((u_long) 0x ) #define DATE_VERSION ((u_long) 1) #define BIN_DATE ((u_long) 1) extern long *bin_date_1(); #define STR_DATE ((u_long) 2) extern char **str_date_1(); Normalerweise tragen Prozedur und Vertreter den gleichen Namen, haben aber unterschiedliche Signaturen (  9.1.2) ! Maximal ein Parameter/Ergebnis, grundsätzlich als Zeiger !

vs9 13 … leider mit wenig Verteilungsabstraktion. Anbieter- Implementierung: /* file date_server.c */ /* date and time server */ #include "date.h" long *bin_date_1() { static long result;..... result =...; return(&result); } char **str_date_1() {..... } RPC-Programmierung

vs9 14 /* file date_client.c */... und der Klient dazu. #include #include "date.h" int date_program(host) char *host; long *result; CLIENT *s; /* "client handle" */ s = clnt_create(host, /* remote linking */ DATE_PROGRAM, /*  */ DATE_VERSION, "tcp"); /* or: "udp" */ if (s!=NULL) { result = bin_date_1(s); /* call stub routine */ if (result!=NULL) return(*result); else..... /*... failed */ } else..... /* server not found */ clnt_destroy(s); /* release handle */ }

vs RPC-Namensdienst: Portmapper clnt_create(host,...) realisiert Fernbinden, d.h. stellt Verbindung des Klienten mit einem Anbieter her: 1. Auf host existiert (hoffentlich) ein Namensdienst: Portmapper, stets über Port 111 ansprechbar. 2. Fernaufruf (!) an Portmapper übermittelt den „Namen“ (program, version, protocol) und liefert als Antwort die Portnummer des entsprechenden Anbieters. 3. Internetadresse von host sowie gelieferte Portnummer werden im Client Handle eingetragen (und dieses wird beim Fernaufruf als zusätzliches Argument (!) dem Vertreter übergeben)

vs9 16 Installation des Anbieters: Wenn ein Anbieter hochgefahren wird, beinhaltet die vom Server Stub (!) vorgenommene Initialisierung die Erzeugung geeigneter Ports sowie deren Registrierung beim lokalen Portmapper (durch „lokalen Fernaufruf“). Alternative: Ad-hoc-Installation eines Anbieters (on demand): Initialisierung des Internet Daemon (3.2.1  ) beinhaltet Erzeugung und Registrierung der Ports (gemäß der Konfigurationsdatei). Anfrage bei einem Port bewirkt Aktivierung des Anbieters. Eventuell Deaktivierung nach Timeout per Einstellung.

vs RPC-Protokoll verwendet entweder TCP oder UDP, je nach Dienst Fehlersemantik: at-most-once für TCP, at-least-once für UDP Externe Datendarstellung: XDR (RFC 1014) Zugriffsschutz: entweder keiner oder Unix-Autorisierung oder … (Information über Standarddienste: ypcat rpc.bynumber )

vs COMANDOS Construction and Management of Distributed Open Systems Forschungsprojekt der EU ( ) Ziele: Verteilungsabstraktion und persistente Objekte Vorteile gegenüber SUN RPC u.ä.: - hochgradige Verteilungsabstraktion - Interoperabilität verschiedener Programmiersprachen - IDL nur bei Sprachheterogenität erforderlich

vs9 19 C** = C++ mit zusätzlichen Schlüsselwörtern für Persistenz und Verteilung Eiffel** = Eiffel-2, lediglich mit modifiziertem Laufzeitsystem Guide = COMMANDOS eigene Sprache, nichtsequentiell, objektorientiert, unterstützt Eigenschaften der Plattform optimal Sprachen in COMANDOS Beispiel Eiffel**: Alle Eiffel-Objekte sind potentiell persistent: sie überdauern ihren Erzeuger-Prozeß, sofern sie über den COMANDOS Name Service (direkt oder indirekt) erreichbar sind.

vs Verbergen der IDL  Ziel – in COMANDOS nur partiell erreicht:  Automatische Generierung von IDL-Text aus Schnittstelle einer Klasse (Eiffel, C++,...)  noch konsequenter wäre: interne, nicht lesbare „IDL“, ist ausreichend für Stub-Erzeugung!  Ziel erreicht in Projekt HERON (FU Berlin, )  für Eiffel und (objektorientiertes) Turbo-Pascal