vs91 9 Middleware

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

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

vs94 COMANDOS - Construction and Management of Distr. Open Systems (EU-Projekt ) (  9.2) 9.2 Architektur:objektorientiert mit Fernaufrufen IDL:C++ -ähnlich Dienste:minimal Anwendungen:universell (verteiltes Rechnen und 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,  )8.2.4 Anwendungen:Dienste

vs95 (COM/OLE  ) DCOM (Microsoft ) 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 Anwendungen:Dienste (Implementierung: fast nur auf Windows)

vs96 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 Anwendungen:Dienste, insbesondere Einbinden von Altsoftware EJB – Enterprise Java Beans (Sun 1998 …) Architektur: objektorientiert/Fernaufrufe (RMI) + Komponenten + Nachrichten IDL:(Java) Dienste:reichhaltig Anwendungen:vielseitig, auch Datenbank-Anwendungen

vs97.NET (Microsoft 2000 …) Architektur: objektorientiert/Fernaufrufe (7.1.6  )7.1.6 IDL:(unsichtbare Metadaten, vom Übersetzer erzeugt) Dienste:in Entwicklung Anwendungen:universell Standardisierung durch ECMA und ISO: Implementierung nicht nur auf Windows, auch Unix/Linux: MonoMono (Open Source, Novell/Ximian) „Rotor“ (Shared Source, 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 ONC – SUN Open Network Computing (Sun 1987/88) Architektur:Client/Server mit Fernaufrufen: RPC IDL:C-ähnlich Dienste:einfacher Namensdienst Anwendungen:Dienste

vs99 Terminologie: Service = Bündel von „Programmen“, 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

vs910 Beispiel für Schnittstellenbeschreibung: /* file rusers.x */ /* protocol description for */ /* remote users program */ /* interface of version 1 */ program RUSERSPROG { version RUSERSVERSOLD { /* void NULL() = 0; */ /* automatically generated */ int RNUSERS() = 1; /* number of users */ string RUSERS() = 2; /* info about users */ } = 1; } = ; Erzeugung von Stub Code

vs911 Vertreter-Erzeuger rpcgen generiert daraus neben den Stubs /* file rusers.h */ #define RUSERSPROG ((u_long) ) #define RUSERSVERSOLD ((u_long) 1) #define RNUSERS ((u_long) 1) extern int *rnusers_1(); #define RUSERS ((u_long) 2) extern char **rusers_1(); Prozedur und Vertreter tragen den gleichen Namen, haben aber unterschiedliche Signaturen (  9.1.2) ! Parameter/Ergebnisse müssen grundsätzlich Verweise sein !

vs912 … leider mit wenig Verteilungsabstraktion. So sieht der Anbieter aus: /* file rusers.c */ /* remote users server */ #include "rusers.h" int *rnusers_1() { static int result;..... result =...; return(&result); } char **rusers_1() {..... } RPC-Programmierung

vs und so sieht der Klient aus: #include #include "rusers.h" int rnusers(host) char *host; int *result; CLIENT *s; /* "client handle" */ s = clnt_create(host, /* remote linking */ RUSERSPROG, /*  */ RUSERSVERSOLD, "tcp"); if (s!=NULL) { result = rnusers_1(s); /* call stub routine */ if (result!=NULL) return(*result); else..... /*... failed */ } else..... /* server not found */ }

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)

vs915 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 Installation des Anbieters. Eventuell Deaktivierung nach Timeout – mit Rettung und späterer Wiederherstellung des Zustands (sofern vorhanden).

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 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: - hochgradige Verteilungsabstraktion - Interoperabilität verschiedener Programmiersprachen - IDL nur bei Sprachheterogenität erforderlich

vs918 C** = C++ mit zusätzlichen Schlüsselwörtern für Persistenz und Verteilung Eiffel** = Eiffel-2, lediglich mit modifiziertem Laufzeitsystem Guide = nichtsequentielle objektorientierte Sprache 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: interne, nicht lesbare „IDL“ genügt für Stub-Erzeugung!  Ziel erreicht in Projekt HERON (FU Berlin, )  für Eiffel und (objektorientiertes) Turbo-Pascal