4. Programmiermodelle für. für verteilte Anwendungen

Transkript

1 Überblick 4. Programmiermodelle für verteilte Anwendungen 4.1 Klassifikation der Programmiermodelle 4.2 Java RMI 4.3 CORBA 4.4.net O. Kao Grundlagen der Verteilten Systeme Klassifikation: Programmiermodelle für verteilte Anwendungen Programmiermodelle für verteilte Anwendungen sind in der Regel Erweiterungen existierender Programmiermodelle Klassifikation von Programmiermodellen für verteilte Systeme RPC-Modell: Aufruf von Prozeduren und deren Ausführung mit den mitgelieferten Parametern in disjunkten Adressräumen Objekt-basierte Ansätze (z.b. Java RMI, CORBA,.net ): Kommunikation zwischen Objekten in unterschiedlichen Prozessen und Aufruf von Methoden in entfernten Objekten Ereignisbasiertes Programmiermodell (z.b. Jini): Abonnement von Objekten für Ereignisse, die auf relevanten entfernten Objekten auftreten und entsprechende Benachrichtigung Komponentenbasierte Ansätze (z.b. Java Beans/Enterprise Java Beans): Komposition von mehreren Objekten in eine höhere abstrakte Form (Behälter, Container), dessen Funktionalität zur Verfügung gestellt wird Webbasierte Modelle: Applets, Servlets, aktive Seiten, Skripte, O. Kao Grundlagen der Verteilten Systeme 4-2

2 4.2 Objekt-basierte Ansätze Objektkommunikation und -kooperation auf verschiedenen Rechnern Entfernte Schnittstelle definiert für Clients freigegebene Methoden Aus Entwurfssicht gibt es keine Unterscheidung zwischen lokalen und entfernten Objekten Beispiele häufig eingesetzter Systeme Java RMI (Java-basierte Remote Method Invocation) CORBA (Common Object Request Broker Architecture) Object Request Broker (Objektbus) verbirgt Abhängigkeiten Sprachunabhängige Interface Definition Language (IDL) zur Generierung von Stubs/Skeletons für C/C++, Smalltalk, COBOL, Java,.net als Nachfolger von COM/COM+, DCOM Unterstützung von loser (Web Services) und enger (Verteilte Anwendungen) Komponentenkopplung Leichtgewichtige Umsetzung zur Unterstützung der Clientvielfalt Nutzung einer Zwischensprache und Just-in-Time Compiler O. Kao Grundlagen der Verteilten Systeme 4-3 Java RMI Aufruf von Java-Objekten, die von einer anderen JVM in der Regel auf entferntem Rechner erzeugt und verwaltet werden Java-basierte Lösung ohne Unterstützung für andere Sprachen Homogenität (JVM, Java) Keine Schnittstellendefinitionssprache Compiler rmic generiert den Client-Stub (Proxy) und Server-Stub (Skeleton) aus den existierenden Klassen Kommunikation mit entferntem Objekt seitens des Clients erfolgt über einen Binder (Registry) oder einen handle-driven Broker Alle Objekte müssen in Registry vermerkt werden Adresse des Registry standardmäßig auf Port 1099 Ablauf Ist das aufzurufende Objekt mit der Methode in Registry vermerkt? Falls ja, wird der Stub für die entfernte Methode angefordert Mit dem Stub wird die Methode direkt aufgerufen O. Kao Grundlagen der Verteilten Systeme 4-4

3 Aufruf einer entfernten Methode Clientrechner Serverrechner Clientprogramm Lookup() Call remote method Stub 2. Wo ist das entfernte Objekt? 3. Entferntes Objekt gefunden 4. Anforderung Stub 5. Lieferung Stub 6. Rufe entfernte Methode auf 7. Gebe das Ergebnis zurück Stub: Verpackt bzw. entpackt Daten Skeleton: Verpackt bzw. entpackt Daten 1. Registrierung 1099 Registry ObjImpl_Stub.class ObjImpl_skel.class ObjImpl.class rebind(obj) O. Kao Grundlagen der Verteilten Systeme 4-5 Java-Komponenten für RMI Zur Implementierung eines Servers mit entfernten Objekten und für Kommunikation stehen vier Packages zur Verfügung Java.rmi: Klassen, Interfaces und Ausnahmen, die von den aufrufenden Methoden gesehen werden Java.rmi.registry (Registry): Objektlokalisierung und Definitionen der Klassen, Interfaces und Ausnahmen zur Benennung von entfernten Objekten Java.rmi.server: Serverseitig sichtbare Klassen, Interfaces und Ausnahmen Java.rmi.dgc: Verteilte Speicherbereinigung Weitere Unterteilung der Packages, z.b. java.rmi in Interface Remote zur Festlegung eines entfernten Interface Klasse rmi.naming zur Umsetzung der Registry Klasse RMISecurityManager behandelt Sicherheitsaspekte Detaillierte Darstellung Übung O. Kao Grundlagen der Verteilten Systeme 4-6

4 RMI - Programmierung Einzelschritte zur Erstellung eines RMI-Programms Definition der entfernten Schnittstellen (Interface Definition File), welche die zu nutzende entfernte Methode beschreibt. Der Client benutzt diese Methode zur Interaktion mit dem Server Definition einer Serverapplikation, welche die entfernte Schnittstelle implementiert (Interface Implementation File) Generierung der Stub-Klasse aus der Schnittstellenbeschreibung mit Hilfe des rmic - Compilers Starten der Registry und des Servers Definition und Starten des Clients, der die entfernten Methoden des Servers aufruft Beispiel: Hello World Programm Client fragt beim Server nach einem String Server liefert Hello World zurück Client gibt den String aus O. Kao Grundlagen der Verteilten Systeme 4-7 Beispiel: Hello World Interface Definition File legt die Schnittstelle fest, welche die Standardschnittstelle java.rmi.remote erweitert Unterklasse von Remote gibt an, welche Methoden des entfernten Objekts durch einen Client aufgerufen werden können Hier lediglich die Methode sayhello() // Hello interface definition (Datei Hello.java) import java.rmi.*; public interface Hello extends Remote { public String sayhello() throws RemoteException; } O. Kao Grundlagen der Verteilten Systeme 4-8

5 Beispiel: Hello World (2) Interface Implementation File implementiert die Klasse HelloImpl, die einen Konstruktor main() und die sayhello() Methode enthält Nur sayhello() ist für Clients verfügbar Unterscheidung von sayhello() von lokalen Methoden durch Deklaration in der entfernten Schnittstelle, Methode selbst bleibt unverändert main() enthält den Servercode Bindung des Objekts HelloImpl an Naming Registry unter dem Namen hello durch bind (Durch rebind wird ein alter Eintrag überschrieben) // HelloImpl Definieren (Teil 1, Datei HelloImpl.java) import java.rmi.*; import java.rmi.server.*; import java.net.*; public class HelloImpl extends UnicastRemoteObject implements Hello { public HelloImpl() throws RemoteException {super();} public String sayhello() throws RemoteException { return "Hello World!";} O. Kao Grundlagen der Verteilten Systeme 4-9 Beispiel: Hello World (3) Fortsetzung (Teil 2, Datei HelloImpl.java) public static void main(string args[]) { try { // create server object HelloImpl h = new HelloImpl(); String serverobjectname = "//localhost/hello"; // bind HelloImpl to the rmiregistry Naming.rebind(serverObjectName, h); System.out.println("hello server ready"); } catch (RemoteException re) { System.out.println ("Exception in HelloImpl.main: " + re); } catch (MalformedURLException e) { System.out.println ("MalformedURLException in HelloImpl.Main: "+e); } } } O. Kao Grundlagen der Verteilten Systeme 4-10

6 Beispiel: Hello World (4) Generierung von Stubs und Skeletons durch RMI-Compiler rmic Kommandofolge > javac HelloImpl.java > rmic HelloImpl Ergebnis Skeleton HelloImpl_Skel.class (ab JDK 1.2 nicht mehr notwendig) Stub HelloImpl_Stub.class muss für die Kommunikation mit dem Server für den Client (lokal oder durch Download) verfügbar sein Starten der Registry (falls nicht per Default im System gestartet) > rmiregistry& Starten des Servers > java HelloImpl& O. Kao Grundlagen der Verteilten Systeme 4-11 Beispiel: Hello World (5) Definition des Clients Zugriffsüberwachung durch Security-Manager Anfrage an Registry durch lookup() // Hello Client definition (Datei HelloClient.java) import java.rmi.*; public class HelloClient { public static void main(string args[]) { System.setSecurityManager(new RMISecurityManager()); try { Hello h=(hello) Naming.lookup ("rmi://localhost/hello"); // call remote method sayhello String message = h.sayhello(); System.out.println("HelloClient: " + message); } catch (Exception e) { System.out.println("Exception in main: "+e); } } } O. Kao Grundlagen der Verteilten Systeme 4-12

7 4.3 CORBA Entwicklung der OMG (Object Management Group) Gegründet 1989 von 8 Mitgliedern, mittlerweile 700 Mitglieder (Apple, AT&T, DEC, HP, IBM,, Siemens-Nixdorf, Sun, Xerox) Keine Implementierung von Produkten, sondern Festlegung von Spezifikationen für Schnittstellen und Protokolle Ausnahme: Microsoft entwickelt eigenen Objektbus DCOM Abstraktes Objektmodell und objektorientierte Referenzarchitektur OMA (Object Management Architecture) CORBA (Common Object Request Broker Architecture) Middleware zur Kommunikation zwischen Anwendungen unabhängig von den verwendeten Programmiersprachen, HW, SW und Netzwerken Anwendungen werden aus CORBA-Objekten aufgebaut, die IDLdefinierte Schnittstellen besitzen Clients greifen über entfernte Aufrufe und mit Unterstützung des Object Request Brokers (ORB) auf die Methoden der CORBA-Objekte zu Proxies werden in Clientsprache, Skeletons in Serversprache erstellt O. Kao Grundlagen der Verteilten Systeme 4-13 Entwicklungsziele von CORBA Objekte werden als eine einheitliche Metapher definiert, um existierende Anwendungen miteinander zu koppeln Das System ist selbst-beschreibend Spezifikation eines Dienstes ist immer von der Implementierung getrennt Intelligente Komponenten entdecken sich gegenseitig und arbeiten über einen Objektbus zusammen CORBA besitzt einen Satz von spezifischen Diensten, mit denen Objekte erzeugt, gelöscht, über den Namen entdeckt und benutzt werden Objekte mit zusätzlichen Eigenschaften (Persistenz, Sperrung, Sicherung, ) ausgestattet werden können Prinzipielle Vorgehensweise Entwicklung einer gewöhnlichen Komponente mit gewünschter Funktionalität Erweiterung um zusätzliche Eigenschaften durch Mehrfachvererbung von geeigneten CORBA-Diensten zur Compilierungs- oder zur Laufzeit O. Kao Grundlagen der Verteilten Systeme 4-14

8 Einordnung von CORBA CORBA Anwendung BOA/POA C/C++/Java/ Anwendungskommunikation Homogene Sichtweise auf das Client/Server System Implementierungsdetails werden vor den CORBA- Anwendungen versteckt CORBA Anwendung BOA/POA COBOL/Fortran/ C/C++/Java/ Windows XP UNIX Notebook Client Mainframe Server O. Kao Grundlagen der Verteilten Systeme 4-15 Verteilte Objekte im CORBA-Stil Spezifikation der Schnittstellen nicht der Implementierung in der neutralen Sprache IDL CORBA-Objekte können überall im Netz existieren Auslieferung als binäre Komponenten, auf die die Clients über entfernte Methodenaufrufe zugreifen Die zur Erstellung von Serverobjekten verwendeten Sprachen, Compiler, die Position der Objekte, BS, sind für Clients vollkommen transparent Notwendig IDLisierung aller Objekte Spezifikation aller Schnittstellen in IDL Menge vordefinierter Dienste zur Auffindung und Kooperation der Objekte C++ IDL Java IDL Cobol IDL C++ IDL Java IDL Cobol IDL Client Server Object Request Broker (ORB) O. Kao Grundlagen der Verteilten Systeme 4-16

9 Object Request Broker (ORB) Zentrale Komponente des CORBA-Referenzmodells Ermöglicht Clients das Senden von Anforderungen an Objektimplementierungen und Empfangen der Antworten Client merkt nichts von den Mechanismen zur Kommunikation bzw. der aktuellen Objektposition Die für die Clients sichtbaren Schnittstellen sind unabhängig von der Lokalisierung, Programmiersprache, der Objektimplementierung Forwarding Broker zwischen Client und Objekt Mit ORB können sich Objekte untereinander und zur Laufzeit finden und die Dienste des anderen aufrufen Herstellung von Ortstransparenz Kommunikations-, Namens- und Sicherheitsdienste Abstraktion von HW, BS, Netzwerkprotokoll, Implementierung O. Kao Grundlagen der Verteilten Systeme 4-17 Eigenschaften des CORBA-ORB Statische und dynamische Methodenaufrufe Statisch = Festlegung beim Compilieren Dynamisch = Entdeckung der Methodenaufrufe zur Laufzeit Selbstbeschreibendes System Schnittstellenverzeichnis (Interface Repository) enthält aktuelle Informationen über alle vom Server angebotenen Funktionen/Parameter Clients nutzen Metadaten zur Entdeckung der gewünschten Funktionen Metadaten werden automatisch generiert: IDL-Precompiler oder direkte Erzeugung aus einer objektorientierten Sprache Eingebaute Sicherheit und Transaktionen ORB schließt Kontextinformationen in seine Nachrichten ein, um Sicherheit und Transaktionen über Rechnergrenzen zu handhaben O. Kao Grundlagen der Verteilten Systeme 4-18

10 ORB Interoperabilität CORBA ist ein offener Standard Unterstützung unterschiedlicher Produkte erforderlich Verantwortung für die Interoperabilität ist bei ORB Festlegung der Kommunikation/Koordination durch Protokoll GIOP (General Inter-ORB Protocol) Definition einer Transfersyntax (Common Data Representation, CDR) und 7 Nachrichtentypen Beispiel: Internet Inter-ORB Protocol (IIOP) Beschreibung der Abbildung GIOP auf TCP/IP Interoperable Objektreferenz enthält ORB-interne Objektreferenz, Internetadresse, Portnummer Verwaltung durch ORB, unsichtbar für den Programmierer Analog: DCE-ESIOP für Zusammenarbeit mit DCE-basierten Systemen O. Kao Grundlagen der Verteilten Systeme 4-19 Objektmodell von CORBA Bestandteile des Objektmodells Objekte: Gekapselte Einheiten bieten den Clients ihre Dienste an Typen: Zulässige elementare und zusammengesetzte Datentypen Schnittstellen: Spezifikation der angebotenen Operationen Operationen: identifizierbare Einheiten, die ein Client von einem Objekt anfordern kann Anforderung: Vom Client ausgehende Aktion, die Informationen sowie Parameter über die durchzuführende Operation an das Zielobjekt bringt <invoc_semantic> <op_type_spec> <identifier> (param1,, paramt) [raises(except1,, exceptn)] [context(name1, namem)] Aufrufsemantik Mögliche Ausnahmen Zusätzliche Kontextinformationen Ergebnistyp Operationsname Ein- und Ausgabeparameter O. Kao Grundlagen der Verteilten Systeme 4-20

11 Object Management Architecture ORB: Kommunikationsinfrastruktur zum Weiterleiten von Anfragen Services: Basisdienste für Objektverwaltung und manipulation Facility: Aufbauende Dienste, die über IDL Schnittstellen direkt von Anwendungsobjekten genutzt werden, z.b. Internationalisierung, Datenaustausch, Systemmanagement Domain: Ähnlich zu Facility, aber bereichsspezifisch, z.b. Business Object Framework, Manufacturing, Transportation, Anwendungsobjekte CORBAdomains CORBAfacilities Object Request Broker (ORB) CORBAservices O. Kao Grundlagen der Verteilten Systeme 4-22 CORBAservices Alle CORBAservices besitzen eine in IDL spezifizierte Schnittstelle Beispiele für CORBAservices Lifecycle: Instanzmanagement bei Objekten wie create, delete, copy, Naming: Verwaltung von Objektnamen zur Lokalisierung ermöglicht Objekten andere Komponenten über den Namen zu finden und unterstützt verteilte Namensdienste Event: Dynamische Registrierung für Ereignisse und Abonnemente ein permanentes Objekt Event Channel sammelt Ereignisse und verteilt diese an Komponenten, die nichts voneinander wissen Concurrency Control: Ein Lock-Manager führt im Auftrag von Transaktionen oder Threads Lock/Unlock-Funktionen für nebenläufige Verarbeitung aus Time: Schnittstelle zur Zeitsynchronisation in einer verteilten Umgebung sowie Operationen zur Definition/Verwaltung von zeitgetriggerten Ereignissen O. Kao Grundlagen der Verteilten Systeme 4-23

12 CORBAservices (2) Beispiele für CORBAservices ( Fortsetzung) Transaction: Zwei-Phasen-Sperrprotokoll Security: Framework für Objektsicherheit unterstützt Identifizierung, Zugriffskontrollen, Vertraulichkeit bei Interaktion zwischen Objekten Relationship: Beziehungen zwischen Objekten und Metadaten Persistence: Persistente Speicherung von Objekten Trader: Objekte können ihre Dienste anbieten und um Kunden werben Licensing: Operationen zu einer fairen Abrechnung der Nutzungsdauer von Komponenten. Unterschiedliche Modelle der Nutzungskontrolle zu verschiedenen Zeitpunkten des Lebenszyklus wie z.b. Berechnung pro Sitzung/Knoten/Site/Instanz/ Query: Stellt Abfrageoperationen für Objekte auf Basis einer SQL- Erweiterung bereit Außerdem: Properties Service, Collection Service, O. Kao Grundlagen der Verteilten Systeme 4-24 Struktur der CORBA-Schnittstellen: Clientseitige Schnittstellen IDL Stubs: Funktionen werden aus der IDL-Definition generiert und zum Clientprogramm gebunden Statische Schnittstelle Methoden eines entfernten Objekts werden wie lokale Methoden behandelt Interaktion Client mit Objekt durch Illusion, Objekt liegt lokal vor DII (Dynamic Invocation Interface): Absetzen von Anforderungen zur Laufzeit Notwendig, wenn Objektschnittstelle zur Compilierungszeit nicht bekannt ist Hinzufügen von Code nicht möglich Methoden und Parameter des entfernten Objekts werden bei einer zentralen Instanz Interface Repository (IR) spezifiziert ORB-Interface Direkter Zugriff durch Client- oder Servercode auf die ORB-Funktionen Operationen wie Umwandlung von Objektreferenzen in Strings O. Kao Grundlagen der Verteilten Systeme 4-25

13 Struktur der CORBA-Schnittstellen: Serverseitige Schnittstellen IDL Skeleton: Serverseitiges Gegenstück zu IDL-Stub, generiert aus IDL-Beschreibung DSI (Dynamic Skeleton Interface): Server-Gegenstück zu DII Bindet Anfragen von ORB zu Objekten zur Laufzeit Bestimmung des Zielobjekts/der Methode mit Implementation Repository Aufbau von Brücken zwischen ORBs auf verschiedenen Servern Object Adapter: Kommunikationsanbindung an Objekte Laufzeitumgebung zur Instanzierung von Serverobjekten Weiterleitung der Anforderungen Abbildung der Objektreferenzen auf Serverobjekte Drei unterschiedliche Schnittstellen Private Schnittstelle zum IDL Skeleton Private Schnittstelle zum ORB-Kern Öffentliche Schnittstelle durch die Objektimplementierung Adapter kann zur Realisierung spezieller Funktionen ausgetauscht werden O. Kao Grundlagen der Verteilten Systeme 4-26 Struktur einer CORBA-IDL- Datei module <identifier> { <type declarations>; <constant declarations>; <exception declaration>; interface <identifier> [:<inheritance>] { <type declarations>; <constant declarations>; <attribute declarations>; <exception declaration>; [op_type]<identifier>(<parameters>) [raises exception][context];... [op_type]<identifier>(<parameters>) [raises exception][context];... } interface <identifier> [:<inheritance>]...} Definiert einen Namenskontext Definiert eine CORBA-Klasse Definiert eine Methode O. Kao Grundlagen der Verteilten Systeme 4-27

14 Repositories Unterstützung des Brokermechanismus durch Speicher für Schnittstellenbeschreibungen (Interface Repository) Zugriff auf Typinformationen einer Schnittstelle zur Laufzeit Speicher für Spezifikation der Implementierung (Implementation Repository) Bedarfsbasierte Aktivierung von Objekten, wenn ein Aufruf vorliegt IDL Definitions Implementation Installation Interface Repository Stub Skeleton Implementation Repository Client Object implementation O. Kao Grundlagen der Verteilten Systeme 4-28 CORBA-Objektreferenzen Implementierung von Objektreferenzen nicht in CORBA definiert Zwei CORBA-fähige ORBs können verschiedene Repräsentationen für Objektreferenzen besitzen Wie wird die Portabilität erzielt? IORs (Interoperable Object References), die zur Weitergabe von Objektreferenzen über heterogene ORBs benutzt werden müssen Sprachbindungen Sprachbindung isoliert die Repräsentation der Objektbindung von dem Programm Alle ORBs müssen dieselbe Sprachbindung zu einer Objektreferenz für eine Programmiersprache bereitstellen Aufgabe des Anbieters, alle Konflikte der Objektreferenzen zu lösen, die im Clientcode auftreten O. Kao Grundlagen der Verteilten Systeme 4-29

15 CORBA-Objektreferenzen (2) Wie erhalten Client-Programme Objektreferenzen? Aus Verzeichnissen Aus Aufrufen anderer Objekte, zu denen sie Referenzen haben A-priori bekannte Referenzen zu häufig benutzten Objekten Vorgehensweise Client konvertiert die Objektreferenz in Zeichenkette (object_to_string), speichert sie in Datei und schickt sie zum ORB ORB wandelt die Zeichenkette in Objektreferenz und ermöglicht direkte Kommunikation zwischen den Objekten Festdefinierte Operationen, die für jede Objektreferenz aufgerufen werden können get_implementation: liefert Verzeichnisobjekt mit Beschreibung der Implementierung is_nil: Testen, ob das Objekt existiert O. Kao Grundlagen der Verteilten Systeme 4-30 Statisches CORBA Statische Schnittstelle wird direkt vom IDL-Precompiler erzeugt Geeignet für Programme, die alle Einzelheiten der auszuführenden Operationen kennen Häufig eingesetzt, da Leicht zu programmieren Keine Änderung zur gewöhnlichen Programmierung Aufruf durch Name und Parameter Robuste Überprüfung der Datentypen während Compilierung Leistungsfähigkeit Statische Aufrufe wesentliche schneller als dynamische Aufrufe Selbst-dokumentierend Einzelne Vorgänge lassen sich durch Lesen des Codes nachvollziehen O. Kao Grundlagen der Verteilten Systeme 4-31

16 Methodenaufruf über CORBA 2. Parameter einpacken und Aufruf weiterleiten Client IDL STUB 1. Aufruf Objektimplementierung 5. Auspacken 4b. Aktivieren und Aufruf IDL Skeleton 4. Weiterleiten an Schnittstelle Object Adapter Implementation Repository 4a. Auffindung der Implementierung Object Request BrokerCore 3. Transport über ORB O. Kao Grundlagen der Verteilten Systeme 4-32 Objektadapter Objektadapter vermittelt die Illusion, dass jedes Objekt es kann viele Millionen davon geben immer dann aktiv ist, wenn es gebraucht wird Vereinfachter Clientcode, da diese Funktionalität beim Server ausgelagert wird Persistenzdienst ermöglich die permanente Speicherung der Objekte und ihrer Zustände Objektaktivierung = Erzeugung/Wiederverwendung eines Prozesses oder Threads Ein Server kann mehrere Objektadapter unterstützen, aber ein Standardadapter BOA (Basic Object Adapter) oder POA (Portable Object Adapter) mit folgenden Funktionen ist immer vorhanden Implementierungsverzeichnis zur Installation und Registrierung von Objektimplementierungen Methoden zur Generierung und Interpretation von Objektreferenzen Aktivierung/Deaktivierung von Implementierungsobjekten Methodenaufrufe durch Skeletons O. Kao Grundlagen der Verteilten Systeme 4-33

17 Vier Aktivierungsverfahren Objektadapter (2) Shared Server, Unshared Server, Server-per-Method, Persistent Server Objektaktivierungsszenario beim Shared-Server: Aktivierung eines neuen und eines existierenden Objekts 1. Erzeugung zweier neuen Objektinstanzen 2. Das neue Objekt beantragt die Eintragung in BOA (Schnittstelle, Implementierung, Referenzdaten) 3. Existierendes Objekt beantragt die Registrierung bei BOA (Verwendung der bereits existierenden Objektreferenz) 4. Server teilt dem ORB mit, dass alle Objekte gestartet sind und auf Aufrufe warten ORB startet für den Server eine Endlosschleife 5. Nutzung der aktivierten Objekte 6. Objekte deaktivieren sich selbst, z.b. nach dem commit bei einer Transaktion erzeugt wurde ggf. persistente Speicherung des Objekts 7. Server teilt dem ORB mit, dass Aufgabe erledigt ist und fährt herunter O. Kao Grundlagen der Verteilten Systeme 4-34 Vorgehensweise bei statischen Methodenaufrufe Create IDL Definitions Precompiler Developer Skeletons Add Server Implementation Code Compile Instantiate Object Adapter Interface Repository Client IDL Stub Server IDL Skeletons Object Implementation Implementation Repository Client Server O. Kao Grundlagen der Verteilten Systeme 4-35

18 Vorgehensweise bei statischen Methodenaufrufe (2) 1. Definition der Objektklassen mit IDL Welche Operationen sind verfügbar, wie werden sie aufgerufen? 2. Precompiler mit IDL-Datei Sprachskeletons für Serverklassen 3. Erweiterung des Skeletons durch Implementierungscode 4. Compilierung des Codes mit CORBA-fähigem Compiler Importdateien mit Objektbeschreibung für Schnittstellenverzeichnis Clientstubs für die IDL-definierten Methoden Server-Skeletons rufen die Methoden auf dem Server auf 5. Bindung der Klassendefinitionen mit den Schnittstellenverzeichnissen Programme können darauf zur Laufzeit zugreifen 6. Registrierung der Laufzeitobjekte im Implementierungsverzeichnis Objektadapter protokolliert die Objektreferenzen und den Typ eines Objekts, für das Instanzen auf dem Server erzeugt werden Implementierungsverzeichnis gibt an, welche Objektklassen auf einem Server unterstützt werden 7. Instanzierung: Erzeugung von Serverobjekten, welche Methodenaufrufe von entfernten Objekten bedienen O. Kao Grundlagen der Verteilten Systeme 4-36 Beispielprogramm mit CORBA: Hello World Aufgabe: Ein Clientobjekt ruft die Methode sayhello() eines entfernten Objekts auf, die den String Hello World! zurückliefert Hello Client Objektreferenz sayhello Hello World! ORB IIOP Internet (TCP/IP) Hello Server sayhello ORB Statische Vorgehensweise Clientobjekt besitzt entfernte Objektreferenz ORB des Serverobjekts hat ein Skeleton, mit dem der Aufruf und die Parameter in implementierungsspezifische Form überführt und an die Methode weitergeleitet werden Kommunikation zwischen Client-ORB und Server-ORB verläuft über das Inter-ORB-Protokoll IIOP, das auf TCP/IP basiert Notwendige Schritte Definition der entfernten Schnittstelle in IDL und Compilierung Implementierung des Servers und des Clients in Java O. Kao Grundlagen der Verteilten Systeme 4-37

19 Beispielprogramm mit CORBA: Definition der IDL-Schnittstelle Spezifikation der Schnittstelle in IDL (Hello.idl) module HelloApp { idlj fall Hello.idl interface Hello { string sayhello(); oneway void shutdown(); };}; // HelloApp/HelloOperations.java package HelloApp; public interface HelloOperations { String sayhello (); void shutdown (); } // interface HelloOperations Abbildung auf die Clientsprache (Java) mit idlj (idl2java) idlj fall Hello.idl Option fall gibt an, dass Stub und Skeleton erzeugt werden sollen Ausgabedateien HelloPOA.java: Skeleton für serverseitige CORBA-Funktionalität _HelloStub.java: Stub für clientseitige CORBA-Funktionalität Hello.java: Java-Version der Schnittstellen HelloOperations.java: Überblick aller Methoden Hilfsdateien HelloHelper.java, HelloHolder.java, O. Kao Grundlagen der Verteilten Systeme 4-38 Beispielprogramm mit CORBA: Entwicklung des Servers (1) Der Server besteht aus zwei Klassen Implementierung HelloImpl der IDL Schnittstelle (Servant), die je eine Methode für jede der IDL-definierten Methoden bereitstellt Restlicher Code kümmert sich um die Kommunikation mit ORB, Marshalling der Argumente und Ergebnisse, Serverklasse main() hat folgende Aufgaben Erzeugung und Initialisierung der ORB-Instanz Referenz zum Wurzel POA (Portierbarer Objektadapter), der zusammen mit dem Objektmanager für die Objektaktivierung zuständig ist Erzeugt eine Instanz des Objekts Hello und meldet sie bei ORB an Erzeugt eine Objektreferenz für die Registrierung des neuen CORBA Objekts Ermittelt den Namenskontext der Wurzel und registriert das neue Objekt unter dem Namen Hello Wartet für Aufrufe für dieses Objekt von Clients O. Kao Grundlagen der Verteilten Systeme 4-39

20 Beispielprogramm mit CORBA: Entwicklung des Servers (2) import HelloApp.*; import org.omg.cosnaming.*; import org.omg.cosnaming.namingcontextpackage.*; import org.omg.corba.*; import org.omg.portableserver.*; import org.omg.portableserver.poa; import java.util.properties; class HelloImpl extends HelloPOA { private ORB orb; public void setorb(orb orb_val) { orb = orb_val; } // implement sayhello() method public String sayhello() { return "\nhello world!!\n"; } // implement shutdown() method public void shutdown() { orb.shutdown(false); }} Import der Pakete, die für die Stubs, die Benennung, die Auswertung von Exceptions, die Initialisierung des ORB, gebraucht werden Welcher ist der aktuelle ORB, um beim Aufruf von shutdown() ein entsprechendes Signal an diesen ORB zu senden und den Server zu beenden Implementierung der Methoden sayhello() und shutdown() O. Kao Grundlagen der Verteilten Systeme 4-40 Beispielprogramm mit CORBA: Entwicklung des Servers (3) public class HelloServer { public static void main(string args[]) { try{ //create and initialize the ORB ORB orb = ORB.init(args, null); //get reference to rootpoa, activate POAManager POA rootpoa = POAHelper.narrow(orb.resolve_ initial_references("rootpoa")); rootpoa.the_poamanager().activate(); //create servant and register it with the ORB HelloImpl helloimpl = new HelloImpl(); helloimpl.setorb(orb); //get object reference from the servant org.omg.corba.object ref = rootpoa.servant_to_reference(helloimpl); Hello href = HelloHelper.narrow(ref); //get the root naming context org.omg.corba.object objref = orb.resolve_initial_references("nameservice"); Jeder CORBA Server braucht ein lokales ORB- Objekt zur Aufnahme der Kommunikation Server erzeugt ein solches Objekt und meldet den Servant an, so dass der Server das Objekt beim Aufruf finden kann Gewinnung des globalen Benennungskontext und Erstellung der Objektreferenz: diese ist zunächst generisch und wird durch narrow() zum richtigen Typ umgewandelt O. Kao Grundlagen der Verteilten Systeme 4-41

21 Beispielprogramm mit CORBA: Entwicklung des Servers (4) // Use NamingContextExt which is part of the // Interoperable Naming Service (INS) specification NamingContextExt ncref = NamingContextExtHelper.narrow(objRef); // bind the Object Reference in Naming String name = "Hello"; NameComponent path[] = ncref.to_name( name ); ncref.rebind(path, href); System.out.println("HelloServer ready and waiting..."); // wait for invocations from clients orb.run(); } catch (Exception e) { System.err.println("ERROR: " + e); e.printstacktrace(system.out); } System.out.println("HelloServer Exiting..."); } } Weitere Umwandlung der Objektreferenz und Vorbereitung für die Registrierung Registrierung des Servants beim Namensdienst. Es wird eine Komponente namens Hello hinzugefügt. Anschließend wird der Pfad zum Objekt registriert Warten auf Aufrufe Aufnahme von Exceptions aller Art, welche zur Laufzeit erzeugt werden könnten O. Kao Grundlagen der Verteilten Systeme 4-42 Beispielprogramm mit CORBA: Entwicklung des Clients (1) Grundsetup: Importierung der notwendigen Java- und CORBA- Bibliotheken, Definition von main() und betrachteten Exceptions Lokales ORB-Objekt für Marshalling/IIOP-Kommunikation Instanzierung eines org.omg.corba.orb Objekts und Initialisierung Auffindung des CORBA-Servers Client fragt ORB nach dem Server Anfrage über COS Naming Service spezifiziert von OMG und enthalten in Java IDL Dazu wird der Daemonprozess orbd befragt Bestimmung des globalen Namenskontext, d.h. Ermittlung eines Verzeichnisses mit lokalen und entfernten Referenzen basierend auf den Aufrufparametern Konvertierung der Referenz zum benötigten Typ anhand der generierten Helferklasen (siehe idlj - Ausgabe) Auflösung der Referenz für hello im Namensdienst Entfernter Aufruf der Methode sayhello() O. Kao Grundlagen der Verteilten Systeme 4-43

22 Beispielprogramm mit CORBA: Entwicklung des Clients (2) public class HelloClient { static Hello helloimpl; public static void main(string args[]) { try{ // create and initialize the ORB ORB orb = ORB.init(args, null); // get the root naming context org.omg.corba.object objref = orb.resolve_initial_references("nameservice"); // Use NamingContextExt instead of NamingContext. // Part of the Interoperable naming Service. NamingContextExt ncref = NamingContextExtHelper.narrow(objRef); // resolve the Object Reference in Naming String name = "Hello"; helloimpl = HelloHelper.narrow(ncRef.resolve_str(name)); System.out.println("Obtained a handle on server object:" + helloimpl); System.out.println(helloImpl.sayHello()); helloimpl.shutdown(); } catch (Exception e) { } } } Lokales ORB Objekt, das sich um Marshalling und Kommunikation über IIOP kümmert Auffindung des Hello Servers: dazu wird der COS Namensdienst spezifiziert von OMG eingesetzt und der Dämon orbd nach einem Objekt namens Hello befragt. Anschließend wird die gefundene generische Referenz transformiert Ausgabe der Objektreferenz Aufruf der entfernten Methoden O. Kao Grundlagen der Verteilten Systeme 4-44 Beispielprogramm mit CORBA: Kompilierung und Starten Compilierung von Client und Server idlj Hello.idl (auf Clientrechner) javac HelloServer.java HelloApp/*.java (auf Serverrechner) javac HelloClient.java HelloApp/*.java (auf Clientrechner) Starten des Dämons (Serverseitig) und Servers orbd -ORBInitialPort ORBInitialHost jadzia-dax.upb.de & java HelloServer -ORBInitialPort 1050 Starten des Clients Name des Serverrechners java HelloClient -ORBInitialHost jadzia-dax.upb.de -ORBInitialPort 1050 Ausgabe Obtained a handle on server object: HelloApp._HelloStub:IOR: c3a48656c6c6f f48656c6c6f3a312e f e e36362e f afabcb a4969a a Hello world!! O. Kao Grundlagen der Verteilten Systeme 4-45

23 4.4.NET Interoperabilität von Anwendungen durch OLE (Object Linking and Embedding) und COM (Component Object Model) Komponenten müssen global und allgemein verfügbar sein Probleme bei der Verwaltung verschiedener Versionen und der Erzwingung von Rückwärtskompabilität Weiterentwicklung DCOM (Distributed Component Object Model) Definition der Zusammenarbeit von Softwarekomponenten, die in unterschiedlichen Sprachen geschrieben sind und über Rechnergrenzen hinweg kommunizieren DCOM-Objekte besitzen keinen Zustand und stellen eine Ansammlung von Schnittstellen dar Unterstützung der Heterogenität Probleme bei praktischer Umsetzung Enge Kopplung an Windows Umständliche Kommunikation zwischen Komponenten O. Kao Grundlagen der Verteilten Systeme 4-46.NET Strategie.NET ursprünglich als neue COM-Version geplant Völlige Überarbeitung zu einer Plattform und einer Strategie mit folgenden Kerneigenschaften Aufbau von CORBA-like verteilten Anwendungen (Remoting) Unterstützung von Web Services Plattform und Entwicklungsumgebung für möglichst einfache Lose Kopplung von Komponenten über das Internet Enge Kopplung von Komponenten auf verschiedenen Plattformen Leichtgewichtige Umsetzung zur einfachen Portierung und Nutzung auf vielen Plattformen, insbesondere auf PDAs, Tablet-PCs, Berücksichtigung der beschränkten Bandbreite Aufbau auf existierenden und teilweise noch zu verabschiedenden Standards O. Kao Grundlagen der Verteilten Systeme 4-47

24 Unterstützte Szenarien Web Services Datenaustausch zwischen Web Services XML Methodenaufruf entfernter Web Services SOAP Beschreibung von Web Services WSDL Auffindung der Web Services UDDI Remote Method Invocation Heterogenitätsüberbrückung Common Language Runtime (CLR) Effiziente Ausführung Zwischensprache (MSIL) und Just-in-Time Compiler Unterstützung verschiedener Plattformen? Aktuell eingeschränkte Entwicklungen für Linux (Mono, ) FreeBSD (Rotor, Linux, *BSD, Mac OS X, Solaris, AIX (DotGNU, O. Kao Grundlagen der Verteilten Systeme 4-48 Laufzeit- und Entwicklungsplattform.NET Überwindung von Plattformgrenzen Erfahrungen aus bisherigen Entwicklungen Direkte Übersetzung aus einer Hochsprache wie C++ in Maschinencode ist aus verschiedenen Heterogenitäts- und Sicherheitsgründen sowie wegen des Übersetzungsaufwands zur Laufzeit nicht anwendbar Virtuelle Maschinen wie JVM lösen/verlagern das Heterogenitätsproblem durch einheitliche Middleware, arbeiten aber meistens mit Interpretern Ineffiziente Ausführung (Compiler sind teilweise vorhanden, bislang aber für Online-Übersetzung eher wenig eingesetzt).net Ansatz ist ein Kompromiss Laufzeitumgebung (CLR), die eine virtuelle Maschine umsetzt und diese um Funktionsbibliotheken und weitere Komponenten erweitert Zwischensprache (MSIL), die sich zur Laufzeit schneller in Maschinencode übersetzen lässt O. Kao Grundlagen der Verteilten Systeme 4-49

25 CLR (Common Language Runtime) CLR muss auf jeder Plattform installiert werden, auf der.net Anwendungen laufen sollen Plattform- und Sprachunabhängigkeit durch ein VM-Konzept Vereinfache Anwendungserstellung durch weitestgehende Automatisierung Definition einer gemeinsamen Datentypenbasis Komponenten der CLR Just-in-Time Compiler zur Übersetzung von Zwischencode in Maschinencode zur Laufzeit Speicherverwaltung, insbesondere Garbage Collection Verwaltung von Prozessen und Threads (Unabhängigkeit vom aktuellen Betriebssystem) Implementierung und Überwachung von Sicherheitsrichtlinien Laden von Klassen und Komponenten Ausnahmebehandlung und Typüberprüfung O. Kao Grundlagen der Verteilten Systeme 4-50 MSIL (Microsoft Intermediate Language) Zwischensprache MSIL (kurz IL) entsteht durch Übersetzung von.net-unterstützen Sprachen (offline) und wird zur Laufzeit in prozessorspezifischen Maschinencode übersetzt Zentrale Bedeutung für die Portierbarkeit und Ausführungseffizienz von.net Anwendungen Unterschiede zu Java Bytecode Kein Interpreter vorgesehen Erweiterung durch Metainformationen über Datentypen, Objekte, Methoden Beispiel MSIL-Code.method private hidebysig static void Main(string [] args) cil managed {.entrypoint.maxstack 8 IL_0000: ldstr Hello, World! IL_0005: call void [mscorlib]system.console::writeline(string) IL_000a: ret } O. Kao Grundlagen der Verteilten Systeme 4-51

26 Just-in-time Kompilierung Möglichkeiten der Übersetzung von.net-anwendungen: bei Installation oder bei Aufruf (Just-in-Time (JIT), voreingestellt) JIT = Endgültige Übersetzung der Anwendung findet auf dem Zielsystem zur Laufzeit statt Prüfung der in IL-Code enthaltenen Metainformationen auf dem Zielsystem Optimierung der Übersetzung bzgl. spezieller Hardwareeigenschaften des Zielsystems Sicherstellung der Plattformunabhängigkeit JIT Ablauf Komponenten auf Methodenebene werden bei jedem Aufruf neu übersetzt Teilweise Übersetzung von Methoden, die gerade/demnächst gebraucht werden Einlesen der Dateien und JIT-Kompilierung mit Geschwindigkeit von mehreren MByte/s möglich O. Kao Grundlagen der Verteilten Systeme 4-52 Source Code VB Compiler IL - Native Compiler C# Compiler C++ Compiler APL, COBOL, Delphi, Pascal, Eiffel, Haskell, ML, Oberon, Perl, Python, Scheme, Smalltalk IL Code Assembly Assembly Assembly CLR JIT Compiler Native Code Managed Code CLR Dienste Managed Code CLR Managed Code Unmanaged Code Betriebssystem und Hardwareplattform O. Kao Grundlagen der Verteilten Systeme 4-53

27 Managed Code Programmcode, der unter.net-laufzeitumgebung CLR abläuft Managed Code hat folgende Eigenschaften Enthält Metainformationen (unabhängig von der verwendeten Sprache) über Eintrittspunkt, enthaltene Methoden, Sicherheitsinformationen, Ausführungsrechte Spezifikation der Ausnahmebehandlung Rekursive Überprüfung der Zugriffsrechte bei verschachtelten Aufrufen (Security Stack Walk) Zugriff auf managed (von CLR verwaltet) und unmanaged Daten CLR kann den managed Code auf Typübereinstimmung, Sicherheitsanforderungen, überprüfen und erst danach zur Ausführung bringen Codeanalyse zum Startzeitpunkt möglich Herkömmlicher Code = Unmanaged/Classic Code O. Kao Grundlagen der Verteilten Systeme 4-54 Basis für CLR.NET verfolgt die CORBA Idee, dass interoperable Anwendungen in verschiedenen Sprachen geschrieben werden sollen CORBA versteckt Unterschiede hinter IDL Schnittstellen und verwendet Sprachbindungen zur Vermittlung zwischen Sprachen.NET verwendet die Zwischensprache IL und die so genannte CLI (Common Language Infrastructure), mit der die Mindestanforderungen an die.net Sprachen festgelegt werden CLI definiert Dateiformate, IL-Befehlssatz und baut auf CLS (Common Language Specification): Festlegung der Eigenschaften, die alle.net Sprachen erfüllen müssen wie etwa Benennungsregeln und Datenstrukturen (siehe CTS) kleinste gemeinsame Menge aller.net Sprachen CTS (Common Type System): Festlegung der Datentypen in den.net Sprachen gleiche Datentypen in allen.net Sprachen O. Kao Grundlagen der Verteilten Systeme 4-55

28 CTS (Common Type System) Wiederherstellung/Konvertierung von Datenstrukturen ist aufwendig und fehleranfällig.net verfolgt zwei Konzepte für Interoperabilität auf Datentypebene 1. Lose Kopplung der Anwendungen XML und SOAP als kleinster gemeinsamer Nenner 2. Definition aller erlaubten Datentypen, die von allen.net Sprachen unterstützt werden müssen: Vollständige Abbildung wie bei C# Teilweise Abbildung der CTS (CLS Mindestanforderung) wie bei VB Vorteile der Typsicherheit mit CTS Überprüfung der Typkorrektheit während der Laufzeit möglich Effiziente Ausführung Nachteile von CTS Bestehende Sprachen lassen sich nur bedingt einbinden O. Kao Grundlagen der Verteilten Systeme 4-56 Überblick der Datentypen in CTS Object Alles ist ein Objekt Werden Werttypen wie int übergeben, so werden diese automatisch in Objekte umgewandelt (Boxing) Value Type Enum Type String Array Exception Delegate Boolean Byte Char Currency DateTime Decimal Double Guid Int16 Int32 Int64 SByte Single TimeSpan TypedRef. UInt16 UInt32 UInt64 Void O. Kao Grundlagen der Verteilten Systeme 4-57

29 Installation und Einsatz (Deployment) Anforderung an Installation von.net-anwendungen HTML-like, insbesondere bei Aktualisierungen Keine Trennung von Code und Metainformationen wie derzeit (Code im Verzeichnis, Metainformationen im Registry) Grundlage: Module, Manifeste und Assemblies Modul (managed module) Enthält Definitionen von Typen mit Metadaten und IL-Code der definierten Methoden (Nicht direkt verwendbar) Assembly Ausführbare.NET-Einheit für Auslieferung, Kapselung, Versionierung und Sicherheit Setzt sich aus einem Manifest, evtl. mehreren Modulen und anderen Ressourcendateien zusammen Manifeste Tabellen mit allen Metainformationen des Assemblies und der Verknüpfungen innerhalb des Assembly (Module, Ressourcen, ) O. Kao Grundlagen der Verteilten Systeme 4-58 Private Assemblies Unterscheidung zwischen Private und Public Assembly Private Assembly: Alle benötigten Komponenten einer Anwendung werden zusammen in einem Verzeichnis abgelegt Komponenten werden nur von dieser Anwendung genutzt Installation durch einfaches Kopieren (xcopy, ftp upload, ) Verschwendung von Festplattenplatz Reduzierte Gefahr für Konflikte durch nicht übereinstimmende Komponenten (Versions- und Ausführungskonflikte) Beseitigung der DLL-Hölle Komponenten enthalten alle wichtigen Informationen Keine Eintragung an zentraler Stelle (z.b. Registry) notwendig Konfigurationsdatei gibt eine relative Verzeichnisstruktur wieder und ermöglicht der CLR die Auffindung der benötigten Module und Ressourcendateien O. Kao Grundlagen der Verteilten Systeme 4-59

30 Public Assemblies Gemeinsame (public) Assemblies mit zentralen Systembibliotheken Gleichzeitige Nutzung durch mehrere Anwendungen Speicherung im zentralen Verzeichnis (Global Assembly Cache) Änderungen durch eine Anwendung wirken sich auf alle anderen Anwendungen aus Versionskonflikte möglich CLR kann unterschiedliche Versionen der Assemblies verwalten und an Anwendungen liefern Maßnahmen zur eindeutigen Kennzeichnung notwendig Konzept der Strong Keys Teil der Metainformationen mit privaten Schlüssel signiert Assemblies, die darauf zugreifen, verwenden den öffentlichen Schlüssel Eindeutige Identifizierung möglich O. Kao Grundlagen der Verteilten Systeme 4-60 Global Assembly Cache O. Kao Grundlagen der Verteilten Systeme 4-61

31 Leichtgewichtige entfernte Aufrufe (Remoting) In.NET werden auch klassische Verteilte Systeme unterstützt, deren Komponenten direkt miteinander kommunizieren Keine schwergewichtige Elemente wie Webserver erforderlich Remotinginfrastruktur läuft auf 3 Ebenen 1. Nachrichten: Alle Daten werden als Objekte dargestellt und nach Anwendung von Serialisierbarkeitsregeln für Netzwerktransport vorbereitet 2. Formatierer: Konkrete Umsetzung der Serialisierbarkeit..NET bietet vorbereite Regeln für z.b. Binärformat (BinaryFormatter), für SOAP (SoapFormatter), 3. Kanäle (Channels): Transportmedium für serialisierte Nachrichten. Standardmäßig sind TCP/IP und HTTP-Kanal vorhanden Benutzer können eigene Kanäle/Serialisierungsformate (IIOP, RMI, ) definieren Einigung der kommunizierenden Komponenten O. Kao Grundlagen der Verteilten Systeme 4-62 Arten von entfernten Objekten Anforderungen an Rechenzeit, Speicher, Bandbreite definieren, welche Art von entfernten Objekten für ein Szenario gut geeignet ist Serialisierbare Objekte (by Value): Instanzen solcher Klassen werden immer als Kopien zwischen den Partnern übertragen Effiziente Ausführung vor Ort, Netzwerkbelastung bei Übertragung SingleCall (by Reference): Zustandslose Objekte, deren Instanzen nur während des Aufrufs existieren. Nur entfernte Referenz wird übertragen Größtmögliche Skalierbarkeit SingleTon (by Reference): Instanz ist permanent aktiv und empfängt Aufrufe, die i.d.r. weitergeleitet werden (Dispatcher Funktionalität) Klassische Server Client-Side-Activated Klassen Instanzen existieren solange ein Client die Referenz hat und/oder ein Mietvertrag (Lease) für das Objekt nicht abgelaufen ist Server prüft/fragt periodisch nach Ablauf des Mietvertrags, ob das Objekt noch benötigt wird. Falls nein Passivierung O. Kao Grundlagen der Verteilten Systeme 4-63

32 Remotingbeispiel (VB.NET) Analoges Beispiel zu Hello, world für Java RMI bzw. CORBA Entferntes Objekt mit einer Methode GetActiveDomain(), welche den aktuellen Anwendungskontext (Prozess innerhalb der CLR) der Ausführung zurückgibt Einfacher Server, der den Port 8080 auf eingehende Nachrichten abhört und diese an das entfernte Objekt weiterleitet Clientanwendung ruft die entfernte Methode auf und zeigt den zurückgegebenen Anwendungskontext an Flexible Konfiguration mit XML Dateien Keine Neuübersetzung bei Änderungen notwendig Einfache Änderung der Kommunikationskanäle und der Marshallingregeln O. Kao Grundlagen der Verteilten Systeme 4-64 Klasse für entferntes Objekt Entferntes Objekt Objekte mit MarshalByRefObject sind für entfernte Kommunikation gekennzeichnet SingleCall Objekt mir Referenzübertragung Beim ersten Aufruf wird der entsprechende Proxy an die aufrufende Instanz übermittelt AppDomain repräsentiert eine isolierte Umgebung, in der die Anwendung in der CLR ausgeführt wird (Privater Bereich eines Prozesses) Kompilierung zu DLL-Assembly Public Class RemoteObject Inherits MarshalByRefObject Public Function GetActiveDomain() As String Return AppDomain.CurrentDomain.FriendlyName End Function End Class O. Kao Grundlagen der Verteilten Systeme 4-65

33 Server Definiert einen Kommunikationskanal und horcht nach ankommenden Nachrichten Verwendet Remoting-Klassen für Kommunikation Konfiguration mit XML-Datei SimpleServer.exe.config (nächste Folie) Assembly mit dem entfernten Objekt muss im GAC oder im Serververzeichnis vorhanden sein Imports System.Runtime.Remoting Public Class HostForm Inherits System.Windows.Forms.Form Private Sub HostForm_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load ` Horche auf den Eingangskanal, der in der Konfigurationsdatei ` SimpleServer.exe.config definiert ist RemotingConfiguration.Configure("..\SimpleServer.exe.config") End Sub O. Kao Grundlagen der Verteilten Systeme 4-66 Serverkonfiguration Tcp server als vordefinierte Bezeichnung für Port 8080 (Änderung z.b. auf HTTP durch http server ) Benötigtes Objekt ist RemoteObject aus RemoteObject.dll Information über den Server im Feld application name <configuration> <system.runtime.remoting> <application name="simpleserver"> <service> <activated type="remoteobject.remoteobject, RemoteObject" /> </service> <channels> <channel ref="tcp server" port="8080" /> </channels> </application> </system.runtime.remoting> </configuration> O. Kao Grundlagen der Verteilten Systeme 4-67

34 Clientkonfiguration Kontaktangaben für das entfernte Objekt Wo befindet sich der Server? (//pc-kao1.cs.upb.de:8080/simpleserver) Wie heißt das Assembly mit dem entfernten Objekt (RemoteObject) Kommunikation über TCP/IP (Angabe tcp client) <configuration> <system.runtime.remoting> <application name="simpleclient"> <client url="tcp://pc-kao1.cs.upb.de:8080/simpleserver"> <activated type="remoteobject.remoteobject, RemoteObject" /> </client> <channels> <channel ref="tcp client" /> </channels> </application> </system.runtime.remoting> </configuration> O. Kao Grundlagen der Verteilten Systeme 4-68 Client Konfiguration entsprechend SimpleClient.exe.config Anzeige des eigenen Kontext Mit New wird ein lokaler Stellvertreter für Kommunikation erzeugt Entfernter Methodenaufruf analog zum lokalen Aufruf Imports System.Runtime.Remoting Public Class ClientForm Inherits System.Windows.Forms.Form Private Sub ClientForm_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load RemotingConfiguration.Configure("..\SimpleClient.exe.config") MessageBox.Show("Clientanwendung wird ausgeführt in " & AppDomain.CurrentDomain.FriendlyName) Dim RemoteObj As New RemoteObject.RemoteObject MessageBox.Show("Entferntes Objekt wird ausgeführt in: " & RemoteObj.GetActiveDomain) End Sub O. Kao Grundlagen der Verteilten Systeme 4-69

35 Installation 1. Kompilierung der Klasse RemoteObject zu DLL Assembly 2. Kompilierung der Serveranwendung 3. Veröffentlichung der RemoteObject DLL in dem Global Assembly Cache der Zielmaschine 4. Kopieren der Serveranwendung und der Konfigurationsdatei auf die Zielmaschine 5. Starten des Servers 6. Kompilieren der Clientanwendung auf der lokalen Maschine und Kopieren der Konfigurationsdatei in das Arbeitsverzeichnis 7. Starten des Clients 8. Ausgabe O. Kao Grundlagen der Verteilten Systeme 4-70 Änderung auf binäre HTTP Kommunikation In beiden Konfigurationsdateien muss die Kommunikation auf HTTP und binäre Darstellung umgestellt werden, hier für den Server <configuration> <system.runtime.remoting> <application name="simpleserver"> <service> <activated type="remoteobject.remoteobject, RemoteObject" /> </service> <channels> <channel ref="http server" port="8080" /> <clientproviders> <formatter ref="binary"></clientproviders> </channels> </application> </system.runtime.remoting> </configuration> Analog für die Clientkonfiguration O. Kao Grundlagen der Verteilten Systeme 4-71

36 .NET Framework VB C++ C# JScript J# Common Language Specification (CLS) ASP.NET Web Forms Web Services Mobile Internet Toolkit ADO.NET and XML Base Class Library Windows Forms Visual Studio.NET Common Language Runtime (CLR) BS und Hardwareplattform O. Kao Grundlagen der Verteilten Systeme 4-72