Middleware, Verteilte Plattform (auch Verteilungsplattform*) bietet Verteilungsabstraktion für verteilte Anwendungsprogramme,

Transkript

1 9 Middleware vs9 1

2 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 vs9 system (vs. distributed operating system) 2

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

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

5 (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 ) DCOM Architektur: Client/Server mit Fernaufrufen IDL: MIDL, Erweiterung der DCE IDL Dienste: Microsoft-spezifisch Anwendungen: Dienste (Implementierung: fast nur auf Windows) vs9 5

6 CORBA Common Object Request Broker Architecture (Open Management Group [OMG] ) 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: IDL: Dienste: objektorientiert/fernaufrufe (RMI) + Komponenten + Nachrichten (Java) reichhaltig Anwendungen: vielseitig, insbesondere Datenbank-Anwendungen vs9 6

7 .NET (Microsoft 2000 ) Architektur: objektorientiert/fernaufrufe (8.1.6 ) IDL: Dienste: (unsichtbare Metadaten, vom Übersetzer erzeugt) in Entwicklung Anwendungen: universell Standardisierung durch ECMA und ISO: Implementierung nicht nur auf Windows: Mono (Open Source, Linux, Novell/Ximian) Rotor (Shared Source, FreeBSD, Microsoft) vs9 7

8 9.1 SUN Remote Procedure Call ONC SUN Open Network Computing (Sun 1987/88) Architektur: Client/Server mit Fernaufrufen: RPC IDL: C-ähnlich Dienste: einfacher Namensdienst Anwendungen: Dienste 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) vs9 8

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 Programm 1 Version 1 Prozedur 0 Prozedur Version 2 Prozedur Prozedur Programm 2 Version 1 Prozedur 0 Prozedur Version 2 Prozedur Prozedur vs9 9

10 9.1.1 Erzeugung von Stub Code 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; } = ; /* assigned by central authority */ vs9 10

11 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! vs9 11

12 9.1.2 RPC-Programmierung 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() {... } vs9 12

13 ... und so sieht der Klient aus: #include <rpc/rpc.h> #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 */ vs9 13

14 9.1.3 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 14

15 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 mit Rettung und späterer Wiederherstellung des Zustands (sofern vorhanden). vs9 15

16 9.1.4 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) vs9 16

17 9.2 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 vs9 17

18 9.2.1 Sprachen in COMANDOS C** = C++ mit zusätzlichen Schlüsselwörtern für Persistenz und Verteilung Eiffel** = Eiffel-2, lediglich mit modifiziertem Laufzeitsystem Guide = nichtsequentielle objektorientierte Sprache 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. vs9 18

19 9.2.2 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 vs9 19