- CORBA
-
- der Client bekommt durch den ORB einen Fehler gemeldet. Die Applikation muss dann einen anderen Server suchen
- Der Server muss trotzdem irgendwie die gemeinsame Sicht bekommen - dies wird wohl Anwendungsspezifisch implementiert werden müssen
- DDS
- Fällt ein Teil des Systems aus, so hat der Rest des Systems noch die Datenobjekte.
Der Clustermanager muss ggf. Applikationen neu aufstarten, die Publisher bekommen davon nichts mit.
-
Lastbalacierung
Vermeidung von Inkompatibilitäten - dynamische Zugriff
Selbstverständlich muß organisatorisch durch das Konfigurationsmanagement gerantiert werden, daß kompatible Versionen im System verwendet werden.
- Interface Repository von CORBA
- Metainformationen über die Dienste, kann im DII (dynamic invocation Interface) auf der Clientseite und DSI (Dynamic server Interface) auf der Serverseite verwendet werden.
Offene Fragen:
- Wie stellt CORBA fest, daß ein Typkonflikt besteht ?
- Ist es im DDS-Standard spezifiziert ?
Optimales Verhalten:
Im Fall eines Typekonfikts darf eine Applikation nicht aufstarten.
Mächtigkeit
Können die Middlewarearten sich gegenseitig simulieren/implementieren ?
Simulation des Publish-Subscribeparadigmas mit CORBA
- CosEvent
- CosNotification
- MIOP - oneway-Communikation
Simulation eines RPC mit DDS
Anmerkung: Man kann ja mehrere Middleware-Systeme in einer Anwendung verwenden.
- Datenobjekttypen Request und Response, QoS RELIABLE, VOLOTILE, Lifespan begrenzt
- Jeder Server hat eine Unique Id
- Jeder Request hat eine UniqueId
- Server bearbeitet nur die Requests mit seiner Id
- Client wartet nur auf den Request auf den er gesendet hat
Dieses ist einfach realisierbar. Ein Vorteil ist das Monitoring auf DDS-Ebene.
Allgemeine Wertung
(es kommt aber auf die Anforderungen der Anwendung an!)
Client-Server - Anwendungen:
Viele Clients greifen auf einen oder wenige Server zu
Information auf Server ist zentralisiert z.B. Datenbanken, Fileserver, Transaktionsverarbeitung
Nachteile: Server ist Flaschenhals und Single Point of Failure
Publish-Subscribe → Data-Centric:
- besser für echtzeit-Applikationen, Multimedia Streaming
- schnelle Kommunikation auch im Fall unzuverlässiger Netzwerke
DDS:
Lose Kopplung:
- Raum - Knoten können überall sein
- Zeit - Auslieferung kann sofort nach der Publizierung oder später erfolgen
- Fluß (Flow) - Auslieferung kann zuverlässig in einen Kontrollierten Bandbreite gemacht werden
- für unreliable wie UDP oder Drahtlose Verbindungen
- keine zentralen Server oder specialisierte Knoten (Broker free)
QoS:
- Deadline : MinimalRate des periodischen Publishers (Subscriber können niedrigere rate fordern)
- Zuverlässigkeit:
- best effort: schnell aber unzuverlässig
- Garantierte Reihenfolge
- Publisher: Parameter wieviele DatenObjekte für Wiederholungen gespeichert werden.
- Stength: Subscriber bekommen Daten von dem Publisher mit höchster Strength
damit können Reserve-Sensoren mit niedriger Strength senden → beim Ausfall des Sensors mit der höchsten strength werden die Daten des nächsten gelesen
- Dauerhaftigkeit: Sich später anmeldene Subscriber bekommen die Daten nachgeliefert
Zusammenhang Data centric /Event Driven:
Data centric: nur die Daten, keine Metainfo mit Servern/Empfängern
TODO: Corba-Dienste von TAO durchsehen
Informatik- und Netzwerkverein Ravensburg e.V
Rudolf Weber