Webserverfunktionalität in MFC Anwendung

Question

Hallo

ich möchte eine bestehende MFC Anwendung um eine Webserverfunktionalität erweitern. Um etwas genauer zu werden. Die MFC Anwendung läuft im Hintergrund und wird über verschiedene Bedienoberflächen gesteuert und kontrolliert die mit der MFC Anwendung über Pipes kommunizieren. Es gibt jetzt die Anforderung das diese MFC Anwendung auch über einen Browser über eine Webseite gesteuert und kontrolliert werden soll (mit vermindertem Funktonsumfang gegenüber der Standardbedienoberfläche)
Was ist da der Beste Weg:

a) Der MFC Anwendung einen embedded Webserver verpassen, d.h. irgendeine Webserver Library dazubauen so dass dann in der MFC Anwendung quais der Webserver integriert ist oder

b) einen Webserver nehmen und den dann über eine wie auch immer geartete Komponente mit der MFC Anwendung kommunizieren lassen.

Was ist da der Beste Weg und was kann man da nehmen bzw, gibt es schon.

Bin dankbar für jeden Beitrag

Answer 1

Dein Webserver ist stateless! Ist Dir das klar?
Wenn Du irgendeine Session Information hast, wie eine Anmeldung etc. Dann musst Du Dir was einfallen lassen.

Das Grundproblem ist, dass Du nicht sagen kannst wann Dein Webservice wieder entladen wird, oder ob er zwischen Operationen evtl. schon wieder entladen wurde.

Was spricht dagegen, einfach einen eigenen Webservice in C#mit gewünschtem Interface zu bauen, der dann Deine Kommunikation in die gewohnte Art per named-Pipes umlenkt.
Du hast doch schon ein prozedurales Interface scheint es mir.

---

Martin Richter -- MVP for VC++ [Germany] -- http://blog.m-ri.de

Answer 2

Hallo Martin

Ja an sowas habe ich auch schon gedacht nur nicht mit C# sondern mit C++/MFC, da ich die gesamte Kommunikation in einem separaten thread der in MFC realisiert ist abwickle und dieses eigentlich wieder verwenden möchte. Ich wollte sowas wie Lacewing (http://www.codeproject.com/Articles/87554/Embedding-a-Webserver-in-your-Win32-C-Application) oder den snorkel webserver nehmen und den in einer Applikation implementieren, die dann mit meiner MFC Anwendung via pipes kommuniziert (unter Verwendung des quellcodes fuer oben genannten thread)

Dann hätte ich quasi einen webservice der über alle Infos der MFC Anwendung verfügt und auch mit dieser kommunizieren kann.

Ich bin mir nur nicht sicher ob das der richtige Weg ist hier Lacewing, snorkel oder ähnliches zu verwenden. Gibt es da vielleicht auch irgendwelche Komponenten des IIS oder von Apache die ich in native c++ realisieren kann und die dann dem IIS oder Apache die Kommunikation mit meiner MFC Anwendung beibringen ?

Das Ganze sollte natürlich relativ schlank/smart und einfach sein, da der Webserver nur im lokalen Intranet des Kunden mit relativ wenig Clients aufgerufen wird. Die MFC Anwendung kontrolliert eine Maschine bei der der Kunde dann über sein Smartphone oder irgendeinen Browser Zugriff auf die Maschine bekommen soll.

Ich will mir da eigentlich nix fuer die Zukunft verbauen um z.b. mit Ajax und jquery mobile Webseiten der Maschine zu erzeugen was dann vielleicht zukünftig nicht mehr geht, wenn ich da auf irgend eine Exotenlibrary setze.

Was würdest du empfehlen ?

Answer 3

Kann ich schwer beurteilen. Aber wen es um einen kompleten Webserver mit allem Pipapo geht. Frage ich mich ob Du nicht mit einet separatem C# Implementierung, die den Web-Krams übernimmt besser bedient bist. Die kann ja wieder mit Deiner Anwednung kommunizieren, wenn sie den als Service läuft!

---

Martin Richter -- MVP for VC++ [Germany] -- http://blog.m-ri.de

Answer 4

Hi,

wie Martin bereits geschrieben hatte, ist das Problem dass es kein definiertes Programmende gibt.
Ich hatte viele unserer Programme auch auf WindowsCE portiert. Mit dessen Wegfall hatte ich dann
auch entschieden, die Programme per eigenem WebServer zu erstellen.
Verwendet habe ich den WebServer mongoose (https://github.com/cesanta/mongoose), da dieser sich auch als virtueller WebServer einsetzen lässt.
Ich registriere z.B. die URL "Termine.htm". Wenn jemand den Link aufruft erstelle ich im Callback
eine Liste der Termine als HTML-Seite und registriere Callback_Links der Art Termin1.htm/Termin2.htm etc.

Wenn es ums bearbeiten geht wird es schwieriger.
Dann benötigt man ja ein Lock-Konzept.

Wenn jemand den Link "Termin1.htm" aufruft wird halt dieser z.B. als Formular dargestellt und gelockt.
Jeder Link auf dieser Seite (z.B. "ok" und "Abbrechen") wird wieder registriert und erhält
allerdings die Zusatzinformation dass da irgendein Eintrag gesperrt wurde (und irgendwann wieder entsperrt werden muss).

Ab dieser Stelle kannst du es vergessen, dass die User den "zurück-Knopf" des Browsers nutzen können.
(Sie werden es trotzdem tun.)
Das musst du a) erkennen und b) brauchst du einen Aufräum-Thread der z.B. nach 20 Minuten den Termin doch wieder freigibt.

Tschüß, Holger.

Answer 5

Genau wegen dem stateless Problem hatte ich ja daran gedacht die webserver Funktion als Komponente in eine bestehende Anwendung zu integrieren. In dieser Anwendung werde ich von meinem hintergrundprogramm welches die Maschine steuert permanent benachrichtigt und kann das über Ajax dann an die websessions weitergeben oder eben von dort Nachrichten an meine Maschinensteuungsanwendung schicken. Inzwischen bin ich mir relativ sicher das das ein erfolgversprechender Weg ist, ich bin halt nur noch sicher welche Komponente da das richtige ist. Ich hab da schon mit snorkel und Lacewing rumprobiert und es sah sehr gut aus, mir ist das aber zu exotisch. Die von Martin angefachte Lösung mit einem c# webservice ist aber auch nicht ganz unaufwendig weil ich die gesamte Kommunikation zu meiner Maschinensteurungsanwendung in c# neu implementieren muss Da muss es doch Leute geben die auch das Problem haben ihre Anwendung webserver fähig zu machen ? Deine mongoose Lösung geht ja auch in eine ähnliche Richtung. Wird das Ding noch gepflegt ?

Answer 6

Warum must Du das was neu implementieren?

Kann Dein Web-Service zu Deiner Anwednung eine Verbindung aufbauen oder nicht?
Selbst mit der Behandlung des Stateless Problemes gibt es 100 Tricks. Das Ganze reduziert sich schon, wenn Du einen zentralen Dienst hast, der immer läuft.

Die Frage ist dann nur, wann beginnt eine Session, und wann endet diese.

---

Martin Richter -- MVP for VC++ [Germany] -- http://blog.m-ri.de

Answer 7

Vielleich sehe ich das auch zu einfach:

Ich habe eine Anwendung A die die Kommunikation zu meiner Maschinensteuerungsanwendung B in einem separaten Thread aufbaut und mit dieser Anwendung B kommuniziert und von dieser benachrichtigt wird. Diese Anwendung A läuft im Prinzip immer und auch die Anwendung B läuft immer wenn die Maschine irgendwie betrieben wird (quasi also auch immer)

Die Anwendung A kann die Daten (nennen wir sie mal Maschinendaten) aus der Kommunikation mit Anwendung B in globalem Speicher/Variablen zur Verfügung stellen so das aus dem Mainthread oder anderen Thread der Anwendung A darauf zugegriffen werden kann.

Wenn ich nun die Anwendung A mit einer Webserverfunktion ausrüste wie das z.B. durch die Komponenten von Lacewing oder Snorkel möglich ist. dann kriege ich immer wenn ein Browser eine Session aufmacht irgendwelche Events in der Anwendung A abgesetzt weil der Browser irgendwas wissen will oder mir irgendwas sagen will, dann habe ich doch da vollen Zugriff auf die globalen Maschinendaten die mir der Kommunikationsthread von A aus der Kommunikation mit B liefert .

Eigentlich kann es mir da völlig egal sein wenn eine Session beginnt und wann sie endet. Wenn die Session was wissen will kommuniziert sie mit A und im dem Handler der die Session bedient (irgendwas in der besagten Webserverkomponente) und dort habe ich Dann doch Zugriff auf alles was ich brauche.

Bin ich da völlig falsch unterwegs oder wie denkt ihr darüber ?