Monitoring von Geräten und Diensten Projektgruppe Location-based Services for Wireless Devices WS 2004/05 Tobias Beisel AG Kao Betriebssysteme und Verteilte Systeme Institut für Informatik Universität Paderborn Vorstellen: Name, Tätigkeit, Veranstaltung

Motivation Aktienhandel Anmelden bei verschiedenen Aktien an verschiedenen Börsenplätzen gehandelt Entkoppelte Szenarien: Notationen sind unabhängig von individuellen Handelsentscheidungen Notationen werden an alle registrierten Käufer übermittelt Anmelden bei verschiedenen Aktien Festlegung von Häufigkeit der Benachrichtigung Datenfilterung (z.B. zeitlich) …  Beobachtung der Veränderungen 28.10.2003

Agenda Grundlagen Monitoring Eventing Middleware Event Notification Event Channel Push-/ Pull-Technologie Eventing Middleware DCOM / .NET Remoting CORBA JINI Projektbezogene Auswertung Vor-/Nachteile der Optionen Empfehlung 28.10.2003

Client-Server Kommunikation Verschiedene Hardware/Software, Programmiersprachen, Betriebssysteme  erfordert Middleware Synchrone/ Asynchrone Kommunikation Synchron: Chat, Videokonferenz, Whiteboards  direkt Asynchron: E-Mail, Foren  permanent, zeitunabhängig Monitoring  Beobachtung, Überwachung, Kontrolle Ermöglicht Reaktion auf Ereignis Feststellung von Veränderungen Fehlervorbeugung bzw. schnelle Behebung 28.10.2003

Event-Notification Anbieter Event Notification Event Verbraucher Event: „etwas passiert“, atomares Ereignis tritt auf, change of state ein Börsenkurs über-/ unterschreitet einen Schwellenwert ein neuer Dienst liegt vor Event Notification: Information über ein Ereignis (Nachricht 1:n) Verbraucher fordert nicht explizit Daten an 28.10.2003

Event-Channel (1) nutze Event- Channel als Mittelsmann Anbieter Verbraucher Event Notification Event- Channel Notification nutze Event- Channel als Mittelsmann typed vs. untyped Event-Channel synchronous vs. unsynchronous Events 28.10.2003

Event-Channel (2) Vorteile vom Event- Channel entkoppeln der Kommunikationskanäle Verbraucher für den Erzeuger nicht bekannt Abonnementen kennen nur die Kanäle die sie nutzen Multicast ein Kanal kann Events von mehreren Lieferanten übertragen Kanal überträgt transparent an verschiedene Nutzer Gruppierung von Nachrichten möglich (n:m) asynchrone Kommunikation Anbieter muss nicht auf erfolgreiche Auslieferung warten 28.10.2003

Push-Technologie push () push ( ) … push () Verbraucher 1 Event- Channel Anbieter 1 Anbieter n … Verbraucher m push () - Erzeuger ist aktiv - Channel übernimmt die Server-Rolle und implementiert ein Interface für den Anbieter - Anbieter ruft Interface auf um Event zu übermitteln - Anbieter „pusht“ die Event Notification 28.10.2003

Push-/ Pull-Technologie Verbraucher 1 push () push () Event- Channel Anbieter 1 Anbieter n … Verbraucher m pull () pull () Event-Richtung 28.10.2003

Channel-Interfaces Proxy Interface Register/ Subscribe Interface Definiert Channel als Verbraucher-Proxy für den Anbieter Definiert Channel als Anbieter-Proxy für den Verbraucher Register/ Subscribe Interface Dienst-Abonnement Subscriber sendet eine Referenz auf sein eingenes handler-interface Eintrag in der Subscriber-Liste Callback- Funktion bei Event im Event-Channel 28.10.2003

Eventing – System Clients DB- & Notification- Server EC NS PC Notification Server PS (R) DBMS Clients DB- & Notification- Server BL Client 1 Client 2 Client n BL - Business Logic PS - Push Supplier PC - Push Consumer EC - Event Channel NS - Notification Server Async Communication Sync Communication Database Access 28.10.2003

Eventing-Middleware DCOM (Distributed Component Object Model) / .NET Remoting CORBA (Common Object Request Broker Architecture) JINI (Java Intelligent Network Infrastructure) Alle ermöglichen die Kommunikation verteilter Objekte 28.10.2003

DCOM DCOM (distributed component object model) Unterstützung von Remote-Zugriffen auf Objekte über ORPC Unterstützung dynamischer Objektaufrufe Modell der entfernten Objekte ORPC (Object Remote Procedure Call) - Layer auf DCE‘s (Distributed Computing Environment) RPC aufgesetzt Interagiert mit COM‘s runtime service Implementierung der Schnittstellen Binäre Interfaces MIDL compiler  Generierung von Client-/ Server-stubs (Objekt=Schnittstelle) 28.10.2003

Eventing in DCOM / .NET Remoting Anfangs: Synchrone Aufrufe Höchstens-Einmal-Semantik Events durch verbindungsfähige Objekte realisiert Ermöglichte verbinden mehrerer Clients  „Rückruf“ Client und Objekt müssen aktiv sein Jetzt: asynchrone Events durch Methodenaufruf modelliert Event hat Ereignisklasse (Standardimplementierung) Ereignisse werden gespeichert, falls Client inaktiv DCOM Server Objekt unterstützt mehrere Interfaces Menge von Attributen und Methoden Verbindungsorientierte Objekte: -realisieren Callback-Schnittstellen -es kann ein Zeiger auf eine Callback-Schnittstelle übergeben werden Event ist selbst kein Objekt 28.10.2003

DCOM Architektur SCM SCM Lokales Lokales Netzwerk Monitoring in DCOM Client-Maschine Objekt-Server SCM Client-Applikation Klassen- Objekt Objekt SCM Proxy- Marshaller Client- Proxy Proxy- Marshaller Object- Stub COM COM Lokales Betriebssystem Lokales Betriebssystem Registry Registry Netzwerk Microsoft-RPC Monitoring in DCOM Abonnement Zeiger auf ein Objekt-Interface setzen Ereignis entspricht Methode, die auch der Client implementiert Ereignissystem sorgt für Aufruf der Eventmethode auf Clientseite Entspricht dem Push-Ereignismodell 28.10.2003

Abonnement-Architektur in DCOM Produzent Verbraucher Ereignis- Klassen- Objekt m_event Verbraucher Ereignis- Objekt m_event Schnittstelle, die m_event enthält Der Aufruf wird weitergeleitet Objekt, das m_event implementiert Der Aufruf wird gespeichert Ereignis- Speicher entspricht dem Push-Modell 28.10.2003

Object Request Broker, GIOP CORBA Applikations- objekte Vertikale Facilities Allgemeine Objektdienste Horizontale Services Object Request Broker, GIOP Definition eines verteilten Systems Spezifikation der OMG (www.omg.org) Ziel der besseren Interoperabilität vernetzter Applikationen Framework für verteilte objektorientierte Anwendungen Basiert auf Remote Procedure Calls (RPC) GIOP (General Inter-ORB Protocol) IIOP (Internet Inter-ORB Protocol)  über TCP/IP Dienste in CORBA: Query, Transaction, Naming, Property, Security, Time, Trading, Event, Notification, … 28.10.2003

CORBA Spezifikation der OMG (www.omg.org) GIOP (General Inter-ORB Protocol) IIOP (Internet Inter-ORB Protocol)  über TCP/IP IDL (Interface Definition Language) Programmiersprachenunabhängig, ähnlich zu C++ IDLtoJava-Compiler Dienste in CORBA Query, Transaction, Naming, Property, Security, Time, Trading, Event, Notification, … 28.10.2003

Architektur CORBA Statischer vs. Dynamischer Aufruf Interface Repository Implementation Repository IDL Compiler operation(in args) Client Objekt-Server result(out args) Objekt Ref IDL Stubs DII DSI IDL Skeleton IDL (Interface Definition Language) Programmiersprachenunabhängig, ähnlich zu C++ Hier erklären was beim Remote-Methodenaufruf passiert Objektadapter ORB GIOP ORB Statischer vs. Dynamischer Aufruf 28.10.2003

Eventing in CORBA Service anfordern Event-Service erhalten einer server-object reference Methodenaufrufe an die object-reference Event-Service Event- orientierte Kommunikation als alternative zur call-basierten Client- Server Architektur Pull/Push – Modell Callback–Modell  entkoppelte Kommunikation Verbesserungspotenzial: Skalierbarkeit, Performance, Quality of Service, Flexibilität unterstützt nicht die Filterung von Benachrichtigungen Unterstützt keine Auslieferungsanforderungen 28.10.2003

Eventing in CORBA Verbesserung: CORBA Notification Service Definiert verschiedene Level an „Quality of Service“-Parametern Channel-, Proxy- oder Single-Event Sender wissen welche Event-Typen der Verbraucher erwartet Neue Events können vom Verbraucher erkannt werden bessere Filtermöglichkeiten Filter werden den Proxies zugeordnet Strukturierte Data-Fields Konfiguration der Eigenschaften eines Kanals, Events, Proxy Zuverlässifkeit, Priorität, Verwurfsstrategie Ereignistyp-Repository 28.10.2003

JINI Java Intelligent Network Infrastructure eine Menge von Java-Klassen und –Programmen Dienstevermittlungssoftware (dienst-orientierte Software) eine robuste, verteilte Systemarchitektur ein dynamischer Verbund von Clients und Dienst-Servern Middleware Framework für verteilte Systeme Architektur  Florians Vortrag 28.10.2003

Eventing in JINI (1) JavaBeans JINI Distributed Events Empfänger übergibt Listener an den Ereignisgenerator Methodenaufruf auf dem gespeicherten Listener Lieferung des Events JINI Distributed Events Erweitert JavaBeans Modell Events zwischen JVMs übergeben Listener Registrierung bei Objekt in anderer JVM RMI als Verteilungsmechanismus erweitert java.util.Event Lookup-Service agiert als Vermittler  ortet Dienste Lease-Rückgabe durch den Client RMI – Remote Message Invocation Lookup-Service  verbindet Objekte 28.10.2003

Eventing in JINI (2) Wie funktioniert das? Das registrierte Objekt des Services wird auf Client kopiert RemoteEvent Oberklasse für Remote-Events in JINI Event-ID, Sequenznummer, Quelle & Handback-Objekt RemoteEventListener Remote-Interface zur Übergabe von Events in VMs Methode notify(RemoteEvent e) Vergleichbar mir ActionListener-Klasse EventRegistration Kapselt Informationen für den Client Handback-Objekt  liefert Client bei der Event-Registrierung und sendet es mit jedem Event an den Servers Sequenznummer wächst bei jedem Auftreten des entsprechenden Events an  wie bei TCP 28.10.2003

Was brauchen wir? Middleware als Kommunikationsgrundlage: Push: Pull: Neue Dienste publizieren Wissenswertes zu den Diensten bekannt machen Positionsabhängige Benachrichtigung Beispiele: Erinnerung an den Bus Erinnerung und Weg zur Sprechstunde in Raum Fx.xxx Auf neuen Drucker aufmerksam machen … Pull: Anfragen an unsere und andere Dienste Bsp.: Wo ist der nächste Drucker 28.10.2003

Vor- / Nachteile DCOM Vorteile Nachteile Spezifikation auf binärem Level  freie Programmiersprachenwahl Plattformunabhängig wenn COM-services unterstützt werden EntireX von Software AG (Unix, Linux und Mainframe Plattformen) Microsoft (Windows und Solaris) Sehr weit verbreitet  hat sich bestätigt Nachteile binäre Abbildung  IDL komplizierter als in CORBA Allgemein sehr komplexes, kompliziertes System Gleiche Dinge werden auf verschiedene Weise erledigt Koexistenz verschiedener Lösungen ist teilweise unmöglich 28.10.2003

Vor/ Nachteile CORBA Vorteile Nachteile sprachunabhängig für Objektorientierte Sprachen (IDL) Plattformunabhängige Bereitstellung von Standardfunktionen flexibel und erweiterbar sehr verbreitet Nachteile großer Gestaltungsspielraum benötigt IDL zur Interface Definition Fokus auf verteilte Objekte nicht Dienste vermittelt Methodenaufruf, nur wenn Server erreichbar Übergabe von „remote references“ anstatt komplette Objekte 28.10.2003

Vor- / Nachteile JINI Vorteile Nachteile weniger Komplex als Corba und DCOM subscription- und lease-Konzept sehr einfach gehaltene Schnittstellendefinitionen in Java Fokus auf verteilte Dienste nicht auf Objekte Ausweichmöglichkeiten und Information bei Dienstausfall Bildung spontaner Netze Nachteile sehr auf Java spezifiziert Noch nicht sehr verbreitet bei jeder Nutzung muss Dienst-Proxy übertragen werden kein eigenes Sicherheitskonzept Kann auf jedem noch so einfachen Gerät installiert werden Emulation eines CORBA-Clients 28.10.2003

Empfehlung Monitoring und Eventing in allen Systemen ansprechend „+“ JINI: Lease-Konzept, keine eigene Schnittstellensprache „-“ DCOM: Dienste müssen lokal implementiert sein „-“ DCOM: sehr komplex JINI oder CORBA? Beides wäre gute Wahl „+“ JINI: Fokus auf verteilte Dienste „?“ JINI: Java basiert und einfach zu handhaben „+“ CORBA: sehr verbreitet und flexibel Empfehlung: CORBA scheint fundamentierter Corba aufgrund der größeren Erfahrungswerte 28.10.2003

Fragen? ? ? ? ? 28.10.2003

Vielen Dank für die Aufmerksamkeit! 28.10.2003