Gleichen Dienst mehrfach installieren -> Name?

[Captnemo]

Zitat von Sir Rufo:

Zitat von Dalai:

Der Display Name kann identisch sein, weil dieser nur der Anzeige dient.

Leider nein, auch der muss eindeutig sein, sonst gibt es eine Fehlermeldung

Selbst wenn's ginge, wär's ja blöd. Wie sollte man die dann noch in der MMC unterscheiden können.

[taveuni]

Wozu würde man einen Dienst mehrfach installieren wollen? Sieht nach Designfehler aus.

[Sir Rufo]

Zitat von taveuni:

Wozu würde man einen Dienst mehrfach installieren wollen? Sieht nach Designfehler aus.

Das erzähl mal Microsoft (z.B. SQL-Server), Oracle (z.B. MySQL-Server), usw.

Es gibt dafür durchaus gute Einsatzgründe für diese Named Services.

[taveuni]

Ich habe SQL Server, Webserver usw. mal stillschweigend ausgeklammert da ich nicht davon ausgegangen bin dass der Ersteller bezüglich Anforderungen an Anzahl Threads, Clientverbindungen usw. die Frage nach einer Mehrfachinstallation gestellt hat. Wir haben hier auch schon einige Multitier Anwendungen geschrieben mit tausenden von Clients auf einen Serverdienst und standen noch nie vor dem Problem. Aber vermutlich gibt es ja andere Gründe dafür. Deshalb auch meine Eingangsfrage gefolgt von der zugegeben provokativen Bemerkung von wegen Designfehler.

[jaenicke]

Zitat von taveuni:

Wozu würde man einen Dienst mehrfach installieren wollen? Sieht nach Designfehler aus.

Zum Beispiel weil ein Server so für mehrere Kundenumgebungen als Host benutzt werden kann. Es existieren bei uns z.B. mehrere Verzeichnisse für verschiedene Filialen, auf denen jeweils ein Server läuft.

Theoretisch könnte man so etwas mit mehr Aufwand auch in eine einzelne Exe packen, aber das erweist sich in der Praxis oft als nicht sinnvoll.

// EDIT:
Ist der Tab schon so lange offen? O.O

[himitsu]

Der 32-Bit Service ist bissl klein, da klappt es nicht, daß er sich bei uns gleichzeitig um zwei/mehr Datenbanken/Dateimanagements kümmert.
Und zusätlich, wenn einer abraucht, dann läuft der Andere weiter.

Bisher hatten wir das über mehrere Installationspfade geregelt, aber das ist bei Updates einfach nur unschön und fehleranfällig (da vergisst man schnell mal Einen upzugraden).

Zitat:

Zum Beispiel weil ein Server so für mehrere Kundenumgebungen als Host benutzt werden kann. Es existieren bei uns z.B. mehrere Verzeichnisse für verschiedene Filialen, auf denen jeweils ein Server läuft.

Ist bei einigen unserer Kunden ähnlich.

Oder Firma ging pleite und fängt neu. Da macht man einen radikalen Schnitt und setzt eine neue Umgegbung für die neue Firma auf,
vorallem da für die Buchhaltung, den Insolvenzverwalter usw. alte und neue Firma getrennt sein müssen und schwupps, so hat man alles doppelt, bis die alte Firma komplett abgewickelt ist.
Oder eben mehrere Filialen/Abteilungen, die in sich aber getrennt sind.

[Captnemo]

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.