Hallo Freunde,

heute mal kein mathematisches/astronomisches Problem, sondern was ganz triviales

Vor geraumer Zeit schrieb ich eine Anwendung, die nun auf einer Reihe Kundenmaschinen läuft. Dummerweise wurde der Ausdruck "Serveranwendung" völlig falsch verstanden, weshalb mancher Kunde mein Programm auf seinen Windows 20xx-Server installiert hat und nun jammert, das erstmal ein Login gemacht werden muß. Ham se ja recht.

Ich würde nun gern einen Service daraus machen, damit diese Login-Problematik verschwindet. Dies wiederum hat zur Folge, das keine GUI mehr anzeigbar ist, auch nicht mit Tricks und mit den Füßen trampeln. Tja... Einen Dienst nmöchten die Kunden schon haben, aber auf die GUI verzichten will dann auch keiner.

Also: Wie bringe ich meinem Dienst eine GUI bei ? Mein erster Ansatz wäre eine TCP-Verbindung zwischen dem Dienst und einer normalen Anwendung. Über diese Verbindung teilt der Dienst mit, welches GUI-Element wie darzustellen ist. Das ist ein ordentlicher Happen Aufwand, hätte aber den Vorteil, das die GUI quasi "überall" laufen könnte.

Hat wer eine bessere Idee ? Vielleicht bietet .NET eine Möglichkeit, sowas elegant vom Hals zu bekommen (MVVM-Pattern) ? Ich habe kein Problem damit, die 60k Zeilen Delphi-Code nach C# zu portieren. Gibt es womöglich bereits ein Framework für dieses Problem ?

Danke fürs grübeln !

Welche Delphiversion benutzt du denn? Wenn du die Enterprise Edition hast, kannst du z.B. sehr einfach mit DataSnap arbeiten.

Eine Variante wäre auch schlicht eine Webseite, die der Server ausliefert. Auch das wäre mit DataSnap möglich und das ist auch unsere Lösung für die Dienststeuerung (und auch recht gebräuchlich dafür). Denn das hat den Vorteil, dass der Benutzer kein installiertes Programm braucht.

Möglich ist eine Webseite mit einem integrierten Webserver aber natürlich auch mit der Professional ohne DataSnap.

Danke für die Antwort !

Eine Webseite zur Anzeige kommt nicht in Frage, denke ich. Ich kann mir eine statische Webseite vorstellen, wenn man ein paar Einstellungen ändern und ein paar Statistiken sehen will. Hier sind Realtime-Daten anzuzeigen (und evtl. Debugging-Infos) und ich denke, eine Webseite ist dafür ungeeignet. Hätte ich man gleich sagen sollen, sorry.

Zum Einsatz käme Delphi XE4, aber auch ein Visual C# wäre kein Thema. Muß eh viel Code neu gemacht werden

OlafSt hat folgendes geschrieben :

Hier sind Realtime-Daten anzuzeigen (und evtl. Debugging-Infos)

Bei uns auch.
Ich habe z.B. gerade eine Trafficanzeige als Diagramm erstellt, die live im Browser mitläuft. Auch welche Clients angemeldet sind und deren aktuelle Aktionen usw. sind als Debuganzeige sichtbar.

OlafSt hat folgendes geschrieben :

Zum Einsatz käme Delphi XE4

Ja, aber welche Edition?
Gerade Inhalte, die vom Server immer wieder aktualisiert werden müssen, lassen sich mit DataSnap durch Callbacks gut abbilden. Aber eben erst ab der Enterprise Edition.

Das heißt nicht, dass das unbedingt die beste Lösung ist. Es kommt auch darauf an um welche Datenmengen es geht usw., aber Webseiten sind heute nicht mehr das gleiche wie vor einigen Jahren. Ich habe z.B. mit JavaScript eine Komponente geschrieben, die sich an ein DataSnap Dataset hängt, dessen Daten anzeigt, filtert, sortiert, ...
Ebenso eine Diagrammkomponente, die ihre Daten vom Server bezieht und sich über Callbacks aktualisiert.

XE4 Professional, ergo fällt Datasnap wohl aus.

Dann ist denke ich mORMot das richtige für dich:
synopse.info/fossil/...me=SQLite3+Framework
(Und es ist auch abseits von Datasnap die einzige komfortable Lösung für Delphi für den Zweck, die ich kenne, die nicht gleich ziemlich viel Geld kostet.)

Um das Problem zu verstehn, auch wenn ich spät dran bin, deine Kunden finden es blöd sich an den Rechner anmelden zu müßen möchten aber auf diesem Rechner trotzdem eine GUI? Ist das nicht irgendwie wiedersprüchlich? Entweder unattended oder GUI

Auch bei Services muss man Parameter setzen oder möchte vielleicht den Status überwachen.
Ich habe das immer mit einer TCP-Verbindung gelöst, oder habe dem Dienst gleich einen kleinen HTTP-Server spendiert.

Ralf Jansen hat folgendes geschrieben :

Um das Problem zu verstehn, auch wenn ich spät dran bin, deine Kunden finden es blöd sich an den Rechner anmelden zu müßen möchten aber auf diesem Rechner trotzdem eine GUI? Ist das nicht irgendwie wiedersprüchlich? Entweder unattended oder GUI

Nein, gemeint ist, dass das Programm aktuell als normales Programm läuft und nicht als Dienst. Es muss also immer jemand angemeldet sein, damit es läuft.
Nun soll es als Dienst laufen, aber interaktive Dienste gibt es ja auch Sicherheitsgründen nicht mehr.

Nersgatt hat folgendes geschrieben :

Auch bei Services muss man Parameter setzen oder möchte vielleicht den Status überwachen. Ich habe das immer mit einer TCP-Verbindung gelöst, oder habe dem Dienst gleich einen kleinen HTTP-Server spendiert.

Genau das machen wir ja mit DataSnap und kann man mit mORMot auch bequem machen.
Der Unterschied zwischen einem einfachen HTTP-Server und DataSnap/mORMot ist, dass man dort auch Objekte usw. direkt übertragen kann.

Zitat:

Es muss also immer jemand angemeldet sein, damit es läuft.

Ebend. Und er wollte im ersten Anlauf die GUI im Dienst belassen also lokal auf dem Desktop einsehbar haben. Und nicht anmelden und trotzdem eine Desktop GUI sehen wollen klingt irgendwie merkwürdig.

Ralf Jansen hat folgendes geschrieben :

Und nicht anmelden und trotzdem eine Desktop GUI sehen wollen klingt irgendwie merkwürdig.

Darum geht es doch gar nicht, das ist doch gar nicht gewünscht.
Aktuell ist der Login notwendig, damit das Programm überhaupt läuft. Das soll nicht mehr so sein, der Server soll auch ohne angemeldetem Benutzer laufen, was als Serveranwendung ja auch logisch ist.

Ähnliche Probleme hatten wir auch als ein paar Programme entsprechend umgestellt wurden.

jaenicke hat es schon richtig erkannt.

Ausgangspunkt ist eine ganz normale Windows-Anwendung, mit GUI und ein paar Einstell-Buttons. Diese Einstellbuttons kommen idR nur ein einziges Mal zum Einsatz, danach nie wieder. Die Windows-Anwendung läuft dann 24x7 durch, sammelt Daten, zeigt einige davon Realtime an und pumpt diese in eine SQL-Datenbank. Falls der Rechner mal kollabiert, stopft man die Anwendung in den Autostart. Fertig ist der Lack.
Da sich Dritt-Anwendungen an diesem Programm anmelden können, handelt es sich um eine Serveranwendung.

Das mit der Serveranwendung haben nun einige Mißverstanden und installieren das Programm nun auf einem Windows-Server 2008 oder 2013. Wenn dieser neu gestartet wird, werden die Autostart-Aktionen erst ausgeführt, wenn sich ein Benutzer direkt am Server einloggt - was aber nicht passiert (warum auch, ist n Server). Konsequenz: Unsere Windows-Software läuft nicht an und alles kommt zum Erliegen.

Nun kann man aus der Windows-Anwendung natürlich einen Dienst machen und sich so die Probleme mit dem User-Login vom Hals schaffen. Dummerweise können Dienste aber nix mehr auf dem Desktop anzeigen, auch nicht mit Tricks. Und nun kommt wieder der Kunde: Er möchte auf keinen Fall auf die Realtime-Anzeigen verzichten.

Ergo: Entweder hast du ne GUI, dann muß aber stets wer am Server eine Anmeldung durchführen, falls der mal neu bootet. Willst du das nicht, kriegst du keine GUI. Kunde (und leider nicht nur einer) will aber beides.

Ich werde wohl nicht drumherum kommen und in den Dienst eine TCP-Verbindung einbauen müssen, über das ein noch zu entwerfendes Protokoll für Control-Updates läuft, so das die GUI ausgelagert werden kann. Die Idee mit ORM ist interessant, aber ich glaube, ich bräuchte da erstmal drei Wochen um überhaupt zu kapieren, was das alles soll

Zitat:

Ergo: Entweder hast du ne GUI, dann muß aber stets wer am Server eine Anmeldung durchführen, falls der mal neu bootet. Willst du das nicht, kriegst du keine GUI. Kunde (und leider nicht nur einer) will aber beides.

Soweit so klar Ich war noch nicht ganz überzeugt ob die im allgemeinen richtige Methode dem Service eine IPC Schnittstelle zu geben auch hier notwendig ist. Man hätte dem Programm ja eine simple duale Startmöglichkeit geben können. a.) Als Dienst dann ohne GUI oder b.) vom Desktop dann halt mit GUI. Das wäre ziemlich simpel mit (ungesehen) wenig Änderungsaufwand aber wenn du noch von DataPump Verhalten schreibst dann ist die Anwendung bisher wohl eher ein Single Process Ding das man nicht einfach so mehrfach starten darf. Da wird dann eh genügend Änderungsaufwand drin hängen so das man das dann auch gleich richtig machen kann.

OlafSt hat folgendes geschrieben :

Die Idee mit ORM ist interessant, aber ich glaube, ich bräuchte da erstmal drei Wochen um überhaupt zu kapieren, was das alles soll

Ich hoffe mal, dass das ähnlich einfach wie DataSnap ist. Da erstellst du z.B. serverseitig eine Klasse, gibst der Methoden, erzeugst dazu Clientklassen und kannst dann am Client diese Methoden einfach aufrufen. Inklusive Klassen, Records usw. als Parameter oder Rückgabewerte.

Ein Blick in die Dokumentation zeigt, dass es dort tatsächlich etwas Ähnliches gibt:
blog.synopse.info/po...ces-in-Delphi-7-2010

Unter Umständen kannst du auch das Problem programmseitig komplett ignorieren und den Leuten ein Zusatztool verkaufen.

www.eltima.com/de/pr...lication-as-service/

Das GUI (für händischen Start/Stop) sieht dann so aus:
wiki.eltima.com/user...e/services-list.html

Funktioniert anderswo sehr zuverlässig.

EDIT fürs Archiv: Es gibt auch noch NSSM als Public-Domain-Software mit dem gleichen Ziel.