Die Funktionalität dieser Klasse und die der beiden folgenden baut
auf den Funktionen auf, die in [Hak93] erstellt und
beschrieben wurden. Diese Eingenschaften finden sich im Basisteil der
Klassenhierarchie in den Klassen MpxServiceSetC, MpxServiceC, MpxFieldSetC und MpxFieldC wieder (siehe
Abb. 
rechter Teil). Hinzugefügt wurde die
Messagesystemanbindung. Sie bieten die Eigenschaft, Services im
Messagesystem verfügbar zu machen. Die Klassen DevServiceSet, DevService und DevAction erweitern
diese um die Funktionalität der Felder und Aktionen.
Ein ServiceSet ist ein Objekt, das mehrere Services verwalten
kann
. Die Basisklasse dafür ist das MpxServiceSet.
Wenn ein Objekt dieser Klasse erzeugt wird, wird mit Hilfe der
Parameter Domäne und Gerätename ein Messagesystemkanal
zum Messagesystem geöffnet. Innerhalb dieser Domäne ist das
ServiceSet dann unter dem Gerätenamen erreichbar. Über das Objekt
stehen Funktionen zur Verfügung, um einzelne Services in das
ServiceSet einzufügen, zu finden und wieder zu entfernen. Beim
Hinzufügen und Entfernen wird der Name des Services zusätzlich zum
Gerätenamen dem Messagesystem bekanntgemacht bzw. abgemeldet.
Dadurch ist es möglich, während der Laufzeit des Programmes Services
dynamisch an- und abzumelden (siehe [Hak93]), und die
ankommenden Nachrichten können anhand der Adresse dem richtigen
Service zugewiesen werden. Die Services werden in einer dynamischen
Liste verwaltet. Dadurch ist Flexibilität in der Anzahl
gewährleistet und es besteht keine Beschränkung durch
voreingestellte Programmparameter.
Ein Objekt der Klasse DevServiceSet hat alle Eigenschaften eines MpxServiceSetC's. Zusätzlich kennt es Methoden, um Nachrichten zu empfangen, diese nach Service, Feld und Aktion zu analysieren und die entsprechende Aktion anzustoßen. Die zentrale Funktion ist dabei messageLoop, die im Hauptprogramm aufgerufen wird, und in der solange Nachrichten empfangen und verarbeitet werden, bis eine spezielle Stopp-Nachricht eintrifft, um das Programm zu beenden.
Die Arbeit dieser Funktion vollzieht sich in mehreren Schritten, die
in Abb. wiedergegeben sind.
Nachdem eine Nachricht eingetroffen ist, wird zuerst unterschieden, ob
es sich um das Protokoll handelt, das die Services verstehen können,
in dem also Service, Feld und Aktion enthalten sind. Wenn dies nicht der Fall ist, wird
eine spezielle Funktion (no_ecs_msg_received)
aufgerufen, die der Benutzer durch eine eigene Funktion ersetzen kann,
um auch anderer Nachrichtentypen, z.B. selbst definierte, empfangen zu
können. Im anderen Fall wird weiter
unterschieden, ob es sich um eine Stopp-Nachricht handelt - hier
wird die Funktion und damit das Programm beendet -, ob es eine
Anfrage ist, ob der Treiber noch läuft - es wird eine Bestätigung
mit dem Rechnernamen zurückgesendet -, oder ob es eine normale
Aktionsanforderung ist. Im letzteren Fall wird der Service aus dem
ServiceSet herausgesucht. War dies erfolgreich, wird überprüft, ob
der Benutzer, der die Aktion ausführen möchte, dazu berechtigt
ist. Die Berechtigung sollte
eigentlich ganz am Anfang geprüft werden, wofür aber das
Experiment-Steuerungs-Protokoll geändert werden müßte (siehe dazu
Abschnitt ). Dann wird der Service initialisiert. Nach
Heraussuchen der angeforderten Aktion wird für diese, falls noch
nicht erfolgt, die Initialisierungsfunktion aufgerufen und
schließlich die Aktion ausgeführt (siehe Abb. ).
Danach gilt es noch zwei Sonderfälle zu behandeln. Wurde für die Nachricht eine Bestätigung verlangt, wird diese zurückgesendet. Im zweiten Fall geht es um die Möglichkeit, bestimmte Aktionen regelmäßig ausführen zu lassen, um z.B. den Status eines Gerätes (z.B. die Targethöhe) zu kontrollieren. Um diesen Effekt zu erreichen, verschickt das Programm eine sogenannte Timer-Nachricht [Kra92d] an sich selbst mit einem Zeitwert, der die Verzögerung angibt, mit der die Nachricht eintreffen soll. Falls es sich hier um eine solche Nachricht handelte, wird diese erneut abgesandt, um nach dem Ablauf des nächsten Zeitintervalls die Aktion wieder auszuführen.