Monitoring von Geräten und Diensten Projektgruppe Location-based Services for Wireless Devices WS...
-
Upload
menno-heibel -
Category
Documents
-
view
108 -
download
1
Transcript of Monitoring von Geräten und Diensten Projektgruppe Location-based Services for Wireless Devices WS...
Monitoring von Geräten und Diensten
Projektgruppe Location-based Services for Wireless DevicesWS 2004/05Tobias Beisel
AG Kao
Betriebssysteme und Verteilte SystemeInstitut für InformatikUniversität Paderborn
PG LBS: Monitoring von Geräten und Diensten 228.10.2003
Motivation
• Aktienhandel 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
PG LBS: Monitoring von Geräten und Diensten 328.10.2003
Agenda• Grundlagen Monitoring
Event Notification Event Channel Push-/ Pull-Technologie
• Eventing Middleware DCOM / .NET Remoting CORBA JINI
• Projektbezogene Auswertung Vor-/Nachteile der Optionen Empfehlung
PG LBS: Monitoring von Geräten und Diensten 428.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
PG LBS: Monitoring von Geräten und Diensten 528.10.2003
Event-Notification
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
EventAnbieter
Event Notification
Verbraucher
PG LBS: Monitoring von Geräten und Diensten 628.10.2003
Event-Channel (1)
EventAnbieter
Notification
Verbraucher
NotificationEvent-
Channel
nutze Event- Channel als Mittelsmann typed vs. untyped Event-Channel synchronous vs. unsynchronous Events
PG LBS: Monitoring von Geräten und Diensten 828.10.2003
Push-Technologie
Anbieter 1Event-
Channel
Verbraucher 1push ( ) push ()
Anbieter n
…
Verbraucher m
…push ()push ()
PG LBS: Monitoring von Geräten und Diensten 928.10.2003
Push-/ Pull-Technologie
Anbieter 1Event-
Channel
Verbraucher 1
Anbieter n
…
Verbraucher m
…
push ()
pull ()
push ()
pull ()
Event-Richtung
PG LBS: Monitoring von Geräten und Diensten 1028.10.2003
Channel-Interfaces
• Proxy 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
PG LBS: Monitoring von Geräten und Diensten 1128.10.2003
Eventing – System
EC
NS
PC
EC EC EC
Notification Server
PS PS PS
(R) DBMS
Clients
DB- &Notification-Server
PCPS
BL
Client 1
PCPS
BL
Client 2
PCPS
BL
Client n
BL - Business LogicPS - Push SupplierPC - Push ConsumerEC - Event ChannelNS - Notification Server
Async CommunicationSync CommunicationDatabase Access
PG LBS: Monitoring von Geräten und Diensten 1228.10.2003
Eventing-Middleware
• DCOM (Distributed Component Object Model) / .NET Remoting
• CORBA (Common Object Request Broker Architecture)
• JINI (Java Intelligent Network Infrastructure)
PG LBS: Monitoring von Geräten und Diensten 1328.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
PG LBS: Monitoring von Geräten und Diensten 1428.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
PG LBS: Monitoring von Geräten und Diensten 1528.10.2003
DCOM Architektur
Lokales Betriebssystem
Klassen-Objekt
Objekt-Server
Microsoft-RPC
Client-Maschine
Registry Lokales
BetriebssystemRegistry
SCMSCM
Client-Applikation Objekt
Client-Proxy
Proxy-Marshaller
Proxy-Marshaller
COM COM
Object-Stub
Netzwerk
• 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
PG LBS: Monitoring von Geräten und Diensten 1728.10.2003
CORBA
Applikations-objekte
Vertikale Facilities
AllgemeineObjektdienste
Horizontale Facilities
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)
PG LBS: Monitoring von Geräten und Diensten 1928.10.2003
Architektur CORBA
ORB
IDLStubs
DII
ORB
DSI IDLSkeleton
Objektadapter
Client Objekt-Server
GIOP
Interface Repository
ImplementationRepository
IDLCompiler
operation(in args)
result(out args)Objekt Ref
Statischer vs. Dynamischer Aufruf
PG LBS: Monitoring von Geräten und Diensten 2028.10.2003
Eventing in CORBA
• Service anfordern 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
PG LBS: Monitoring von Geräten und Diensten 2128.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
PG LBS: Monitoring von Geräten und Diensten 2228.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
PG LBS: Monitoring von Geräten und Diensten 2328.10.2003
Eventing in JINI (1)
• JavaBeans 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
PG LBS: Monitoring von Geräten und Diensten 2428.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
PG LBS: Monitoring von Geräten und Diensten 2528.10.2003
Was brauchen wir?• Middleware als Kommunikationsgrundlage:
Push: 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 …
PG LBS: Monitoring von Geräten und Diensten 2628.10.2003
Vor- / Nachteile DCOM
• Vorteile 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
PG LBS: Monitoring von Geräten und Diensten 2728.10.2003
Vor/ Nachteile CORBA
• Vorteile 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
PG LBS: Monitoring von Geräten und Diensten 2828.10.2003
Vor- / Nachteile JINI
• Vorteile 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
PG LBS: Monitoring von Geräten und Diensten 2928.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
PG LBS: Monitoring von Geräten und Diensten 3028.10.2003
Fragen?
? ??
?
PG LBS: Monitoring von Geräten und Diensten 3128.10.2003
Vielen Dank für die Aufmerksamkeit!