Vs9 1 9 Middleware. vs9 2 Middleware, Verteilte Plattform (auch Verteilungsplattform*) bietet Verteilungsabstraktion für verteilte Anwendungsprogramme,

Präsentation zum Thema: "Vs9 1 9 Middleware. vs9 2 Middleware, Verteilte Plattform (auch Verteilungsplattform*) bietet Verteilungsabstraktion für verteilte Anwendungsprogramme,"—  Präsentation transkript:

1 vs9 1 9 Middleware

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

3 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

4 vs9 4 COMANDOS - Construction and Management of Distr. Open Systems (EU-Projekt 1986-92) (  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) http://www.opengroup.org/dce Architektur:Client/Server mit Fernaufrufen IDL:C-ähnlich Dienste:Directory Service, Security Service,... Distributed File System ( ≈ AFS,  Vert.BS) Einsatz:System- und Anwendungs-Dienste

5 vs9 5 (COM/OLE  ) DCOM (Microsoft 1990-99) (  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)

6 vs9 6 CORBA – Common Object Request Broker Architecture (Open Management Group [OMG] 1991...) http://www.corba.orgOpen Management Group http://www.corba.org 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

7 vs9 7.NET (Microsoft 2000 …)http://www.microsoft.com/nethttp://www.microsoft.com/net http://msdn.microsoft.com/netframework Architektur: objektorientiert/Fernaufrufe (8.1.6  ) IDL:(unsichtbare Metadaten, vom Übersetzer erzeugt) Dienste:Basisdienste + weitere in Entwicklung Einsatz:universell Standardisierung durch ECMA und ISO: http://www.ecma-international.org/memento/TC39.htm Implementierung nicht nur auf Windows: MonoMono (Open Source, Linux, Novell/Ximian) http://www.mono-project.com/Main_Page „Rotor“ (Shared Source, FreeBSD, Microsoft)Rotor http://research.microsoft.com/Collaboration/University/Europe/RFP/Rotor/

8 vs9 8 9.1 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,...)

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

10 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 */ } = 0x31234567; /* program number */ 9.1.1 Erzeugung von Stub Code Standardisiert bzw. eigene zwischen 0x20000000 - 0x3fffffff

11 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

12 vs9 12 Modul-Definition: /* file date.h for ANSI C */ #define DATE_PROGRAM ((u_long) 0x31234567) #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).9.1.2 ! Maximal ein Parameter/Ergebnis, grundsätzlich als Zeiger !

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

14 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, /*  9.1.3 */ 9.1.3 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 */ }

15 vs9 15 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)

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

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

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

19 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 9.2.1 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.

20 vs9 20 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 wäre: interne, nicht lesbare „IDL“, ist ausreichend für Stub-Erzeugung!  Ziel erreicht in Projekt HERON (FU Berlin, 1991-95)  für Eiffel und (objektorientiertes) Turbo-Pascal