Um ein bisschen mehr Licht in's Dunkel zu bringen:
Es handelt sich dabei um einen Dienst, der seriell angeschlossenen Grosswaagen ausliest, und die Gewichte und Waagenbenutzer in eine Datenbank schreibt. Weiterhin wird der Waagencontroller (Fremdfabrikat) aus der
DB mit bestimmten Daten versorgt.
Natürlich hätte man das ganze jetzt auch mal locker in einen Dienst über mehrere Threads packen können, was ich auch in der 1. Lösung so realisiert hatte. Nun ist es aber so, dass bei der Kommunikation zu den Waagen manches mal Probleme auftreten können (Anschluss erfolgt über virtuelle
Com-Schnistelle<->
TCP<->
IP-Seriell-Interface) und auch die Waagencontroller kommen gerne mal aus dem Tritt (was aber Gott sei Dank nicht soo häufig auftritt).
Weiterhin sind die Waagen teilweise auch noch über verschiedene Server angeschlossen, und nicht alle immer gleichzeitig in Betrieb.
Kurz und gut, um also von vorneherein das ganze sauber von einander zu trennen und um zu vermeiden, dass eine Fehlfunktion einer Waage im schlimmsten Fall andere Waagen in der Kommunikation stört, habe ich mich dafür entschieden, je Waage ein Dienst.
Mal abgesehen davon ist es für den Kunden später einfacher, einen bestimmten Dienst neuzustarten, ohne dabei die anderen Wiegevorgänge zu beeinträchtigen.
Das kann man als Designfehler bezeichnen....muss man aber nicht. Für jedes Problem gibt es verschiedene Lösungsansätze, und je nach Überlegungen und Schwerpunkte kann man auch verschiedene Lösungen favorisieren.