Monitoring von Geräten und Diensten Projektgruppe Location-based Services for Wireless Devices WS 2004/05 Tobias Beisel AG Kao Betriebssysteme und Verteilte.

Präsentation zum Thema: "Monitoring von Geräten und Diensten Projektgruppe Location-based Services for Wireless Devices WS 2004/05 Tobias Beisel AG Kao Betriebssysteme und Verteilte."—  Präsentation transkript:

1 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

2 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

3 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

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

5 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

6 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

7 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

8 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

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

10 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

11 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

12 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

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

14 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

15 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

16 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

17 Object Request Broker, GIOP
CORBA Applikations- objekte Vertikale Facilities Allgemeine Objektdienste Horizontale Services Object Request Broker, GIOP Definition eines verteilten Systems Spezifikation der OMG ( 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, …

18 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, …

19 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

20 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

21 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

22 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

23 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

24 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

25 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

26 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

27 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 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

29 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

30 Fragen? ? ? ? ?

31 Vielen Dank für die Aufmerksamkeit!