enthält alle Angaben zur Erzeugung eines Proxy-Objekts Syntax: identity [-f facet] [-t -o -d -O -D][-s] adapterid] : [endpoints]

Transkript

1 9 Stringified Proxy Stringdarstellung von Proxies enthält alle Angaben zur Erzeugung eines Proxy-Objekts Syntax: identity [-f facet] [-t -o -d -O -D][-s] adapterid] : [endpoints] identity Kategorie und Name der Objekt-ID facet Facet-Name Optionen für verschiedene Twoway-, Oneway- etc. Proxies adapterid Name des Objektadapters endpoints Liste von Endpunktstrings I.73 9 Stringified Proxy (2) Beispiele f Second MyAdapter:tcp -p h server.hurz.de:udp -p h server.hurz.de DBServLoc/ABCD-1849-DE9F-A t:tcp -p 2312 Bla/Blubber20 Adapter42: I.74

2 10 Dynamische Aufrufe Streaming-Schnittstellen OutputStream dient zum Marshalling von Slice-Typen Operationen zur Ausgabe aller primitiven Slice-Typen weitere Ausgabefunktion in der jeweiligen Helper-Klasse eines Typs InputStream dient zum Unmarshalling von Slice-Typen Operationen zum Einlesen aller primitiven Slice-Typen weitere Einlesefunktion in der jeweiligen Helper-Klasse eines Typs Erzeugung durch z.b. Ice.Util.createOutputStream() I Dynamische Aufrufe (2) Dynamische Aufrufe auf Client-Seite Ausgabe aller Parameter in ein Byte-Array Aufruf der generischen Proxy-Methode ice_invoke() Übergabe von folgenden Parametern: Operationsname (String) Modus der Operation (normal, idempotent, nonmutating) in-parameter als Byte-Array out-parameter-behälter als ByteSeqHolder-Objekt (mit ByteSeq definiert als sequence<byte>) Einlesen aller Ergebnisse aus empfangenem Byte-Array alternativ: Exception aus gemarshallter Exception erzeugen Rückgabewert false von ice_invoke() zeigt Exception an Vgl. CORBA DII I.76

3 10 Dynamische Aufrufe (3) Dynamische Aufrufe auf Server-Seite Erzeugung eines Servant vom Slice-Typ ::Ice::Blobject interface Blobject enthält eine Methode: bool ice_invoke( in ByteSeq inparm, out ByteSeq outparm ); Objektadapter liefert alle Aufrufe in dieser Methode ab impliziter weiterer Parameter vom Typ Ice.Current enthält Methodenname und Aufrufmodus I IceGrid IceGrid hieß in früheren Versionen IcePack Aufgaben von IceGrid implementiert Ortsdienst für indirektes Binden an Ice-Objekte implementiert Aktivierungs- und Monitoringdienst enthält Deployment-Mechanismen Direktes Binden (direkter Proxy) Endpunkte bekannt werden direkt angesprochen Indirektes Binden (indirekter Proxy) Zugangsinformation nicht bekannt lediglich Identifikator vorhanden Ermittlung der Zugangsinformation durch einen Locator (Ortsdienst) I.78

4 11.1 Indirektes Binden Locator-Interface findobjectbyid() ermittelt Proxy für Objekt mit ID findobjectadapterbyid() ermittelt einen Dummy-Proxy für ObjektAdapter mit bestimmtem Namen Ortsdienst zum Ermitteln der Zugangsdaten für ein Objekt oder einen Objektadapter Konfiguration des Stringified-Proxy zu einem Ortsdienst (z.b. IceGrid) über Property Ice.Default.Locator I Indirektes Binden (2) Stringified Proxy enthält Objektadapter-Name und Objekt-ID Ermitteln des Dummy-Proxies für Objektadapter Generierung eines Proxies für das Objekt Stringified Proxy enthält nur Objekt-ID Ermitteln eines Proxies für das Objekt Locator-Implementierung hält Abbildung von IDs zu Endpunkten hält Abbildungen von Objektadapter-IDs zu Endpunkten können registriert werden Objektadapter mit nichtleeren IDs registrieren sich automatisch I.80

5 11.1 Indirektes Binden (3) Objektadapterkonfiguration Name wird bei Erzeugung vergeben wird genutzt u.a. für Property-Zugriffe Adapter-ID wird über Property konfiguriert Beispiel: MyAdapter.AdapterID=MyAdapter oder MyAdapter.AdapterID= AF-438D-FE DA32 nur mit ID wird Adapter am Locator registriert ID muss im System eindeutig sein (z.b. UUID) I Indirektes Binden (4) Unmittelbarer Vorteil des indirekten Bindens Bindung völlig unabhängig von verwendeten Endpunkten (Protokolle, Ports) z.b. bei Neustart einer verteilten Anwendung lediglich Endpunkt für Locator muss feststehen Locator wird zu einer Art Namensdienst Namen sind Objekt- bzw. Adapter-IDs Namensdienst kann eingespart werden von initalen Bindungen muss jeweils die Objekt-ID bekannt sein Endpunkt wird dann über Locator bestimmt Erzeugung indirekter Proxies veröffentlichte Endpunkte sind leer I.82

6 11.2 IceGrid Registry Registry ist ein Ortsdienst implementiert Locator-Interface Endpunkt kann als Ice.Default.Locator eingetragen werden 11.3 IceGrid Node Serverprozess als Teil von Aktivierung und Monitoring läuft typisch auf jedem Rechner des Ice-Systems Registry kann in einem Node angesiedelt sein (co-located) I IceGrid Node (2) Aktivierung bei Bedarf IceGrid kann Informationen zum Start von Server-Prozessen speichern inkl. IDs der im Server-Prozess beherbergten Objektadapter Auflösung von Endpunkten für solche Adapter führt zum Start des Server- Prozesses Ablauf der Aktivierung bei Bedarf Client fragt nach Endpunkten für bestimmten Objektadapter falls bekannt: Rückgabe der Endpunkte IceGrid-Konfiguration Abbildung Adapter-ID und IceGrid-Knotenname zu Server-Prozess Start des Server-Prozesses auf entsprechendem Knoten Adapter meldet sich bei IceGrid-Registry an Rückgabe der Adapterendpunkte an den Client I.84

7 11.3 IceGrid Node (3) Deaktivierung bei Bedarf Property im Server-Prozess (Ice.ServerIdleTime) nach Ablauf der konfigurierten Zeit ohne externe Aufrufe: automatischer Aufruf von destroy() am Communicator führt zur Deaktivierung der Objektadapter diese melden sich bei IceGrid-Registry ab Manuelle Deaktivierung Server-Prozess kann über Administrationsschnittstelle abgeschossen werden Kommunikation über Signale Kommunikation über ein Ice::Process-Objekt pro Prozess erlaubt Debugausgaben im Prozess erlaubt Herunterfahren des Prozesses im Extremfall Zerstörung über Betriebssystem (z.b. kill unter Linux) I Deployment Etablieren einer Anwendungskonfiguration (Deployment) Deployment-Descriptor beschreibt Server-Prozesse bekommen Namen enthalten Objektadapter mit Adapter-ID werden als Programmdatei gestartet besitzen Aufrufoptionen werden IceGrid-Node zugeordnet beschreibt Anwendungen bestehen aus mehreren Server-Prozessen beschreibt Konfigurationsparameter (Properties) kann verschiedene Varianten beschreiben (Targets) Variante kann beim Deployment ausgewählt werden Deployment-Descriptor ist eine XML-Anwendung I.86

8 11.4 Deployment (2) Beispiel <icegrid> <application name="bank"> <variable name="home.dir" value="/home/bank"/> <node name="productionnode"> <server id="accounts" exe="${home.dir}/bin/accounts"> <adapter name="accounts" endpoints="tcp"/> </server> </node> </application> </icegrid> I Deployment (3) Konfiguration der Server-Prozesse IceGrid sorgt für Konfiguration der Server-Prozesse durch eigene Konfigurationsdateien automatische Aufrufoption --Ice.Config=... Adapter-IDs werden von IceGrid vergeben falls nicht im Deployment-Descriptor konfiguriert IceGrid setzt entsprechende Properties Locator-Konfiguration wird ebenfalls korrekt vorgenommen von IceGrid gestartete Prozesse nutzen automatisch auch IceGrid-Registry I.88

9 11.4 Deployment (4) Administrationsschnittstelle Manipulation der aktuellen Konfiguration Slice-Schnittstelle interaktive textbasierte Schnittstelle grafische Benutzerschnittstelle Beispiel für Kommandos (Textschnittstelle) application add account.xml fügt neuen Deployment-Descriptor hinzu Variablen können gesetzt und im Descriptor ausgewertet werden node list listet alle angeschlossenen IceGrid-Nodes mit Namen werden durch Locator bzw. IceGrid-Registry gefunden I Deployment (5) Administrationsschnittstelle (fortges.) Beispiele für Kommandos (fortges.) adapter list listet alle registrierten Objektadapter im System server stop Accounts fährt Server-Prozess mit Namen Accounts herunter Knoten ist IceGrid bekannt server stdout Accounts Hello World gibt Nachricht auf der Standardausgabe von Server Accounts aus I.90

10 11.4 Deployment (6) Betrieb verteilter Anwendungen Start der IceGrid-Nodes und IceGrid-Registry Rechner Server-Prozess IceGrid-Registry IceGrid-Node Laden des Deployment-Descriptors Aktivierung der Anwendung durch Start mindestens eines Server-Prozesses Auswahl von Konfigurationsvarianten durch Targets und durch Variablenparameter I IceBox Generischer Serverprozess implementiert ein Objekt mit interface IceBox::ServiceManager zur Zeit im Wesentlichen shutdown() Methode startet eine Reihe von Diensten (Services) konfiguriert über Properties Dienst muss bestimmtes Interface implementieren: module IceBox { local interface Service { void start( string name, Ice::Communicator communicator, Ice::StringSeq args); void stop(); }; }; I.92

11 12 IceBox (2) start()-methode erhält als Parameter Deployment-Namen des Dienstes Communicator-Objekt Liste von Argumenten typische Aufgabe Erzeugen von Objektadaptern Erzeugen von Servants und/oder Servant-Locators stop()-methode typische Aufgabe Abbau der Objektadapter (z.b. mit deactivate()) Freigabe von Ressourcen I Konfiguration Konfigurationsproperties für IceBox-Server Endpunkt(e) des ServiceManager-Objekts IceBox.ServiceManager.Endpoints=tcp -p h server.de gemeinsames Communicator-Objekt für alle Dienste in einer IceBox IceBox.UseSharedCommunicator=1 Vorteil: lokal optimierte Kommunikation Konfigurationsproperties für einen Dienst Eintrittspunkt für Dienst IceBox.Service.Bank=Avo.BankServiceI -name TreasureBank in Java: Eintrittspunkt Avo.BankServiceI ist Java-Klasse, die interface Service implementiert I.94

12 12.2 Lebenszyklus eines IceBox-Servers Ablauf beim Start eines IceBox-Server-Prozesses Lesen der Properties Bestimmen der Namen und Eintrittspunkte für alle Dienste z.b. Bank Avo.BankServiceI für jeden Dienst Erzeugen eines Communicator-Objekts oder gemeinsame Nutzung eines vorher erzeugten Communicators Aufruf der start()-methode im Service-Objekt/Eintrittspunkt Reihenfolge des Dienstestartens kann über Property geregelt werden: IceBox.LoadOrder=Bank,HelloWorld Ablauf beim shutdown eines IceBox-Server-Prozesse Aufruf der stop() Methode für jeden Service I IceBox und IceGrid Direkte Konfiguration von IceBox-Servern in IceGrid Beschreibung von Diensten im Deployment-Deskriptor statt eines Elements server steht Element icebox als Unterelemente können Dienste konfiguriert werden, z.b. <icebox exe= /opt/ice/bin/icebox id= 4711 > <service name= Bank entry= Avo.BankServiceI -name TreasureBank /> </icebox> IceGrid erzeugt entsprechende Konfigurationsdateien mit Property- Definitionen Verwendung des generischen IceBox-Server-Prozesses I.96

13 13 Freeze Dienste für Persistenz Dienst für persistente Datenstruktur mit Name-Wert-Paaren Freeze Map Servant-Locator für persistente Klassen-Objekte Freeze Evictor 13.1 Freeze Map Slice-Typ Dictionary speichert Daten in Datenbank Einsatz der BerkeleyDB Open Source und kommerzielle Version I Freeze Map (2) Automatische Erzeugung einer Implementierungsklasse in Java: Implementierungsklasse muss java.util.map implementieren Code-Generator Aufruf für beispielsweise dict<string, int> StringIntMap; slize2freezej --dict StringIntMap,string,int Erzeugung einer Java-Klasse namens StringIntMap.class Zugriff auf persistente Daten Erzeugen eines Datenbankzugangs (Connection) Freeze.Connection con = Freeze.Util.createConnection(communicator, "db"); Übergabe des Communicator-Objekts Übergabe des Pfades zu den Datenbankdateien I.98

14 13.1 Freeze Map (3) Zugriff auf persistente Daten (fortges.) Erzeugung bzw. Zugang zur Datenbank StringIntMap map = new StringIntMap( con, "simple", true ); Übergabe des Connection-Objekts Übergabe des Datenbanknamens Übergabe eines Wahrheitswertes soll Datenbank angelegt werden, wenn noch nicht vorhanden Ablegen von Daten Zugriff auf Map, z.b. map.put( new Integer(5), "Heureka" ); Lesen von Daten Zugriff auf Map, z.b. map.get( new Integer(5) ); I Freeze Evictor Evictor (wörtl. Vertreiber) hier: Entwurfsmuster für die Implementierung eines Servant-Locators Evictor hält einen Cache von Servants installiert neue Servants bei Bedarf ungenutzte Servants werden wieder zerstört Client OA locate() Evictor Servant Datenbank I.100

15 13.2 Freeze Evictor (2) Architektur und Abläufe Implementierung eines Servant-Locators für class-objekte class-objekte benötigen angemeldete Objektfabrik neue class-objekte werden über den Evictor angemeldet Aufruf einer add()-methode (ähnlich wie sonst am Objektadapter) Evictor registriert Servant (Aktivierung) Objektadapter bekommt Servant bei locate()-anfrage I Freeze Evictor (3) Passivierung Evictor kann Servant aus lokalem Cache entfernen Abspeichern der öffentlichen Komponenten in Datenbank Nutzung der Marshalling-Operationen und der Datenstromobjekte (vgl. dynamische Aufrufe) Re-Aktivierung bei locate()-anfragen für passivierte Servants: Erzeugung eines neuen Servant über Objektfabrik Einlesen der öffentlichen Komponenten aus Datenbank Nutzung der Unmarshalling-Operationen und der Datenstromobjekte I.102

16 13.2 Freeze Evictor (4) Typische Implementierung Definition eines interface-typs für entfernte Client-Zugriffe z.b. interface Account Clients erhalten nur Zugang zum interface-typ Definition eines class-typs für den Evictor z.b. class AccountImpl implements Account im Evictor Behandlung von class-objekten class-objekte enthalten zu speichernde Daten als Komponenten I IceStorm Ereignisdienst verteilt Ereignisnachrichten an beliebige Abonnenten Push-Modell Ereignisnachricht wird beim Abonnenten abgeliefert Publisher IceStorm Subcriber Subcriber Subcriber Subcriber I.104

17 14 IceStorm (2) Topic ein Ereignisse wird an einen benannten Topic gebunden Topic wird durch ein Slice-Interface repräsentiert Aufruf von Methoden entspricht Ereignis Methode darf keine out-parameter haben und muss void zurückgeben Verlage (Publisher) können Ereignisse zu einem bestimmten Topic über IceStorm an Abonnenten (Subscriber) ausliefern Topic-Manager zentrales Objekt des IceStorm-Servers Verwaltungsschnittstelle für Erzeugung eines neuen Topic Ermitteln eines oder aller bekannten Topics I Verlagsseite Vorgehen auf der Verlagsseite Erzeugung eines Topics am Topic-Manager unter Angabe eines Namens oder Ermittlung eines Topic-Objekts unter Angabe eines Namens Holen des Publisher-Objekts am Topic Aufruf von getpublisher() muss auf den entsprechenden interface-typ gecastet werden nur uncheckedcast() möglich Aufruf von Methoden am Publisher-Objekt jeder Aufruf wird bei allen Abonnenten automatisch ausgeführt I.106

18 14.2 Abonnentenseite Vorgehen auf der Abonnentenseite Implementierung und Aktivierung eines Ice-Objekts der eigentlicher Empfänger der Ereignisse implementiert den interface-typ eines Topic Ermitteln des Topic-Objekts unter Angabe des Namens beim Topic-Manager Aufruf der subscribe()-methode am Topic Übergabe eines Proxys für das Empfängerobjekt automatischer Aufruf der entsprechenden Methoden im Empfänger I IceStorm-Server IceBox-Anwendung konfiguriert über Properties speichert bekannte Topics, deren Konfiguration und deren Empfänger Endpunkt muss den Verlagen und Abonnenten bekannt sein z.b. über eindeutigen Objektadapter-ID konfiguriert über Property Interface-Typ eines Topics Entwickler müssen auf korrekte Nutzung achten IceStorm leitet alle Aufrufe weiter uncheckedcast() erlaubt beliebige Typen inkompatiblen Aufrufe führen zu unbemerkbaren Fehlern I.108

19 14.4 Ereignisauslieferung Unterschiedliche Protokolle Verlage und Abonnenten können verschiedene Protokolle benutzen typisch sind oneway- und datagram-aufrufe Abonnent konfiguriert Protokoll über seinen Objektadapter Beeinflussung durch Abonnent beim subscribe() kann Quality-of-Service angegeben werden Dictionary für String-String-Paare zur Zeit definiert: Name reliability mit folgenden Werten oneway: Auslieferung als oneway/datagram-methode batch: Auslieferung als batched-oneway/datagram mit konfigurierbarer Zeitschranke zum Sammeln von Ereignissen I Föderationen von Topics Verbindungen (Link) zwischen Topics konfigurierbar gerichtete Verbindung zwischen zwei Topics Auslieferung von Ereignissen des ersten Topic an Abonnenten des verbundenen Topics nur einmalige Weiterverknüfung (nicht mehrstufig) Kostenattribut Verbindungen und Ereignisse können mit Kosten versehen werden virtueller Kostenwert als Integer Kostenangabe zu Verbindungen bei der Erstellung Kostenangabe bei Ereignissen beim Aufruf über Kontextobjekt Kontextobjekt kann als Dictionary bei jedem Aufruf mitgegeben werden I.110

20 14.5 Föderationen von Topics (2) Kostenattribut (fortges.) Weiterleitung über Verbindungen nur falls Kosten des Ereignis nicht größer als Kosten der Verbindung Ereignisse mit Kostenattribut von 0 werden immer weitergegeben Ereignisse werden immer über Verbindungen mit Kostenattribut 0 weitergeleitet Einsatzgebiet Kostenangabe als echte Kosten Weiterleitung von teuren Ereignissen nur an Abonnenten, die entsprechend zahlen Kostenangabe als Priorität verschiedene Topics kapseln ähnliche Ereignisse aber mit unterschiedlicher Priorität I Föderationen von Topics (3) Konfiguration der Verbindungen über Topic-Manager-Schnittstelle über Kommandozeilenschnittstelle am IceStorm-Server über XML-Konfigurationsdatei im IceStorm-Server Persistente Speicherung IceStorm-Server speichert Topic-Graph persistent mit Angabe der Kosten I.112

21 15 Weitere Komponenten Glacier Firewall-Lösung für Ice-Anwendungen alle Aufrufe können an einen Firewall-Port geroutet werden über Properties konfigurierbar Glacier-Firewall setzt Aufruf in anderes Netz um Client Glacier OA Servants fixierter Port Server Glacier2 weitere Implementierungsvariante I Weitere Komponenten (2) Freeze Script Werkzeuge für die Verwaltung von Freeze-Datenbanken Inspektion Schemaänderungen bei Änderung der Objektstruktur Ice SSL SSL-Implementierung für Ice Konfiguration des Protokolls Auswahl der Verschlüsselungsalgorithmen und Verfahren Verwendung von Zertifikaten I.114

22 16 Vergleich mit theoretischen Anforderungen Ice hat ein monolithisches Objektmodell Weltweit eindeutige Objektbezeichner zum Parametertransport Stringdarstellung: Stringified-Proxy Netzwerkdarstellung: Reihe von Slice-Strukturen (z.b. Identity) Eindeutigkeit durch Identity mit UUID für alle Zeiten eindeutig Erzeugung neuer verteilter Objekte Erzeugung von Servants Aktivierung der Servants I Vergleich mit theoretischen Anforderungen (2) Schnittstellenspezifische Stellvertreterobjekte Proxy-Objekt pro Slice-interface-Typ implementieren Methoden aus der Slice-Beschreibung RPC-basiertes Kommunikationsprotokoll Ice-Protokoll über TCP, UDP und SSL/TCP Parameterübergabe von Objektreferenzen Binärform des Stringified-Proxy wird als Objektbezeichner bei Parameterübergabe übermittelt Erzeugung lokaler Proxy-Objekte aus übermitteltem Objektbezeichner I.116

23 16 Vergleich mit theoretischen Anforderungen (3) Automatische Generierung der Stellvertreter Slice-Compiler erzeugt Proxies und Skeletons für bestimmte Sprachen Kein Namensdienst stattdessen Ortsdienst zur Auflösung von Objektadapter-IDs entsprechen auf niedrigerer Abstraktionsebene Namen Bildung von initialen Referenzen durch manuell konfigurierte Stringified- Proxies I Zusätzliche Eigenschaften Aktivierung und Deaktivierung IceGrid realisiert Aktivierungs- und Deaktivierungssystem auf Server-Basis in Kombination mit Freeze kann die Deaktivierung auf Servant-Basis erfolgen Flexibler Objektadapter Servant-Locator kann beliebige dynamische Aktivierungsstrategien implementieren Ereignisdienst IceStorm I.118

24 16.1 Zusätzliche Eigenschaften (2) Weiteres Deployment-Descriptor mit IceGrid generischer IceBox-Server Objekt-Firewall-Implementierung I.119