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


Agenda• Grundlagen Monitoring

Event Notification Event Channel Push-/ Pull-Technologie

• Eventing Middleware DCOM / .NET Remoting CORBA JINI

• Projektbezogene Auswertung Vor-/Nachteile der Optionen Empfehlung


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


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


Event-Channel (1)

EventAnbieter

Notification

Verbraucher

NotificationEvent-

Channel

nutze Event- Channel als Mittelsmann typed vs. untyped Event-Channel synchronous vs. unsynchronous Events


Push-Technologie

Anbieter 1Event-

Channel

Verbraucher 1push ( ) push ()

Anbieter n

…

Verbraucher m

…push ()push ()


Push-/ Pull-Technologie

Anbieter 1Event-

Channel

Verbraucher 1

Anbieter n

…

Verbraucher m

…

push ()

pull ()

push ()

pull ()

Event-Richtung


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


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


Eventing-Middleware

• DCOM (Distributed Component Object Model) / .NET Remoting

• CORBA (Common Object Request Broker Architecture)

• JINI (Java Intelligent Network Infrastructure)


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


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


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


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)


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


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


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


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


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


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


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 …


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


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


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


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


Fragen?

? ??

?


Vielen Dank für die Aufmerksamkeit!

monitoring von geräten und diensten projektgruppe location-based services for wireless devices ws...

Documents

eventnotification event

event channel verbraucher

pg lbs

event channel entkoppeln

push folie

attributen und methoden

vernderungen folie

push anbieter n verbraucher