(Sehe es mal als allgemeine Frage an, daher hier gepostet. Wenn nötig pls. verschieben)

Hallo,

ich entwickle derzeit eine Service-Client-Anwendung.
Wichtig ist bei dieser ein gewisser Hoch-Verfügbarkeits-Faktor. (Ich nenns mal so)

Um es einfach und Präziese auszudrücken, ist es zwingend notwendig, dass gekennzeichnete Computer in einer Domain mit dem Client ausgestattet sind und diese auch laufen.
Sprich, wenn ich einen neuen PC in meiner Domain habe, wird dieser mittels des Computer-Namens im Netzwerk auf dem Server hinterlegt, und der Server (ein Dienst / Service) sorgt dafür, dass der Client auf den entsprechenden Systemen landet und auch ausgeführt wird. Bei Absturz des Clients sollte dieser dann neu gestartet werden.

Dieses Überwachen stellt kein Problem dar, dafür gibt es innerhalb der Domain entsprechende Möglichkeiten.

Meine Frage ist nun Folgende:

Soll der eigentliche Service (hier ein Alarm-Service, Alarmfunktionen, daher Hoch-Verfügbarkeit) diese Überwachung durchführen?
Oder sollte diese reine Überwachungsaufgabe (Installation, Ausführung, Aktualisierung und was dort an Aufgaben anfällt) in einem separaten Dienst ausgeführt werden?

Hier geht es mir gerade eher um ein "How-To-Do", "best practises", nicht, wie es dann Funktioniert (wie gesagt, Codebasis und Überwachung an sich sollte kein Problem darstellen, Google bietet da genug und ein entsprechender Thread hier hat mir auch schon weiter geholfen).

Entsprechendes Argument meinerseits für einen Extra Dienst wäre, dass es vielleicht irgendwann doch eine Client-Installation sein könnte, für diese müsste dann der Service umgebaut werden, damit er sich nicht mehr drum kümmert. Oder ein Kunde will es so, der andere so.
Ein extra Dienst, welcher dann nur startet / aktualisiert (usw.) wäre Service und Client Code-Technisch unbekannt, und so kann dass ganze auch ohne Überwachung laufen (Unabhängigkeit).

Ein Argument gegen einen extra Dienst wäre die Tatsache, dass ich dann einen Service mit Datenbank, meine Clients und eben einen Überwachungsdienst hätte.



Wie würdet ihr so etwas lösen? Welche Argumente könnt ihr aufbringen, um mir bei meiner Entscheidung ein wenig zu helfen?

Danke im Voraus, lg. Kagu

Die Überwachung der Alarm-Services würde ich zentral von einem (oder mehreren) zentralen Server machen.
Dafür bekommt der Alarmservice ein paar Monitorfunktionen.
Sowohl der Client- als auch der Server-Prozess hören auf einem TCP-Port auf den jeweils anderen.
Das Protokoll zwischen den beiden kannst du dir frei ausdenken.

Das Schöne an der Methode ist, dass du den Server und den Client auch auf derselben Maschine installieren kannst.

Auf der selben Maschine geht generell eh, ich arbeite mit WCF, wo das so problemlos geht.
Service und Client funktionieren auch so wie sie sollen, hier geht es nur um das "am leben halten".

Die Clients pingen den Service regelmäßig, wenn dieser dann tot ist, hat das auf dem entsprechenden Server seine Gründe, und es muss eh ein Admin nachschauen (welche das über diesen Ping auch mitbekommen, der Client weiß ob du Admin bist oder nicht und reagiert entsprechend).

Es müssen so gesehen nurnoch die Clients überwacht werden, denn wenn welche Ausfallen, ist das schlecht (im Alarmfall... wofür auch sonst nen Alarm-Service ^.^)

Und hier halt wissen, was best Praktice ist. Zwei Services (beide in einem Dienst gehostet, musste vorher nicht das das geht), der eine für die Alarme und der andere für die Überwachung) oder ein Service der sich um beides kümmert? (benötige sowieso einen weitern, einen Configuration-Service, da nach geplantem Stand ein Client vorher dem Service bekannt sein muss und weitere Dinge (DB und so))