Allgemein Gültige Schnittstelle gesucht...

[ManSues]

Habe lange gesucht und hoffe in diesem Forum richtig zu sein. Ich würde mich freuen wenn es möglichst viele qualifizierte Meinungen zurückgibt.

Hintergrund: (worum geht es)
Seit Windows Vista (7) ist die Welt des programmierens nicht mehr so einfach wie es bei XP war. Durch strikte Sicherheitsbestimmungen kann nicht mehr jeder mit jedem kommunizieren (Messages), und das normale Programm unter User account ist extrem eingeschränkt, auch in Zugriff auf die Registry.
Ich will gar nicht alle Beschränkungen aufzählen, die wohl jeder kennt. Vor diesen Hintergrund ist es aber immer mehr überlegenswert, die Logik zum Beispiel in einen Windows Service zu legen. Dieser hat aber in der "neuen" Umgebung keine Oberfläche mehr. Auch ein Remote Server wäre denkbar. Also muss noch eine Oberfläche her, damit Daten angezeigt oder Befehle erteilt werden können. Diese beiden EXE müssen also miteinander kommunizieren!

Nun gibt es einige Schnittstellen Ansätze. Sockets oder Pipes wären eine Möglichkeit, auch Interfaces oder Web Services könnte eine Lösung sein. Aber was kommt den optimalen am nächsten?

Um es nicht ganz so einfach aussehen zu lassen, ist es bei dem Ansatz ja ohne weiteres denkbar, den Windows Service als Windows 32 API Applikation zu erstellen und die Oberfläche als Java Webseite! Die Schnittstelle sollte also Sprachübergreifend sein (Was zum Beispiel Sockets und Web Services ja sind).

Ich würde gerne eure Meinung hören, und sei sie noch so abgefahren. Ich denke das Thema wird in Zukunft noch mehr beschäftigen und vielleicht bildet sich ja auch ein Standard wie z.B. MIB.

[himitsu]

Das Thema nennt sich IPC (Interprozesskommunikation, bzw. inter-process communication) und eigentlich gibt es dafür tausende Wege.


- Pipes
- TCPIP über localhost
- MMF (memory-mapped files)
- Mailslots
- Man kann von seinem Programm aus auch irgendwie geziehlt Messages freischalten, damit sie auch von Programmen mit weniger Rechten angesprochen werden können (soweit ich mich richtig erinnere)
...


PS: Die Sicherheit ist eigentlich schon seit WinNT an vielen Stellen stärker eingeschränkt, aber seit Vista setzt Microsoft das endlich mal durch, indem es nicht mehr alle Programme sändig mit Adminrechten laufen läßt.

[ManSues]

Ja, OK, aber bin ich denn der Erste, der nach einer allgemein gültigen Definition sucht? Macht denn jeder von z.B. den AntiVirus Leuten ihre Schnittstelle selbst? Oder hat vielleicht Microsoft (ev. mit Sicherheitslöchern) nicht so was in eine der vielen DLLs gepackt?

[Furtbichler]

Wieso sollte es einen Standard geben, wenn die Anwendungsfälle so unterschiedlich sind?

Wieso gibt es keine Standardkommunikation zwischen Menschen?
Weil es so viele unterschiedliche Anwendungsfälle gibt: Nonverbal, Handzeichen, Reden, Schreiben, Fresse hauen. All das sind perfekte Kommunikationsformen für den jeweiligen Anlass...

[Bernhard Geyer]

Zitat:

Zitat von ManSues (Beitrag 1184040)

Seit Windows Vista (7) ist die Welt des programmierens nicht mehr so einfach wie es bei XP war.

Echt? Ist mir noch nicht aufgefallen? Geht doch alles was man machen will.

Zitat:

Zitat von ManSues (Beitrag 1184040)

Durch strikte Sicherheitsbestimmungen kann nicht mehr jeder mit jedem kommunizieren (Messages),

Wird die wenigsten Stören. Solche (Windows-)Messagekommunikation war schon immer problematisch.

Zitat:

Zitat von ManSues (Beitrag 1184040)

und das normale Programm unter User account ist extrem eingeschränkt, auch in Zugriff auf die Registry.

Eigentlich gibts da nur den unterschied das man im HKLM-Bereich als Normaler user nicht mehr schreiben kann. Aber sonst: Voller zugriff.

Zitat:

Zitat von ManSues (Beitrag 1184040)

Vor diesen Hintergrund ist es aber immer mehr überlegenswert, die Logik zum Beispiel in einen Windows Service zu legen. Dieser hat aber in der "neuen" Umgebung keine Oberfläche mehr.

In Windows-Service sollte man nur legen was auch ohne angemeldetn User permanent laufen muss.

Zitat:

Zitat von ManSues (Beitrag 1184040)

Auch ein Remote Server wäre denkbar.

Halte ich nur für sinnvoll wenn die verteilung andere Vorteile bringt.

Zitat:

Zitat von ManSues (Beitrag 1184040)

Nun gibt es einige Schnittstellen Ansätze. Sockets oder Pipes wären eine Möglichkeit, auch Interfaces oder Web Services könnte eine Lösung sein. Aber was kommt den optimalen am nächsten?

Jede schnittstelle hat ihre Vor- und Nachteile. Der Anwendungsfall entscheidet.

Zitat:

Zitat von ManSues (Beitrag 1184040)

.... und die Oberfläche als Java Webseite

Wenn du mit "Java Webseite" meinst eine Java-Applet. Das ist am Sterben wie Flash und Silverlight auch. Die Zukunft ist HMLT5+JS

Zitat:

Zitat von ManSues (Beitrag 1184040)

Ich würde gerne eure Meinung hören, und sei sie noch so abgefahren

Wenn du was auf einem Server installieren kannst dann gehört HTML5(+JS/CSS/...) die Zukunft. Hier kann man aus einer "Exe" alle Zielplattformen von PC, Tablets und Smartphones bedienen. Wenn's native sein soll dann wirds komplizierter da jedes Plattform (iOS, Android, Windows RT) hier versucht ein abgeschottetes System aufzubauen. Hier gibt aber auch Ansätze die HTML5/JS-Lösung zu "kompilieren" und dann native Laufen zu lassen. Stichworte wären z.B. PhoneGap und Co.

[mkinzler]

Zitat:

Eigentlich gibts da nur den unterschied das man im HKLM-Bereich als Normaler user nicht mehr schreiben kann. Aber sonst: Voller zugriff.

Das konnte man als normaler Benutzer noch nie. Die UAC sorgt nun aber dafür, dass man auch als Admin nur mit Userrechten arbeitet, aber seine Rechte "erhöhen" kann.

[Bernhard Geyer]

Zitat:

Zitat von mkinzler (Beitrag 1184468)

Zitat:

Eigentlich gibts da nur den unterschied das man im HKLM-Bereich als Normaler user nicht mehr schreiben kann. Aber sonst: Voller zugriff.

Das konnte man als normaler Benutzer noch nie.

"Damals" war halt der normale User auch Mitglied der lokalen Admingruppe und die Prozesse haben automatisch diese Rechte geerbt.
Aber nix was großartig Probleme bei der SW-Entwicklung bereitet das man hier jetzt nicht mehr schreiben darf.

[Phoenix]

Zitat:

Zitat von ManSues (Beitrag 1184040)

Durch strikte Sicherheitsbestimmungen kann nicht mehr jeder mit jedem kommunizieren (Messages), und das normale Programm unter User account ist extrem eingeschränkt, auch in Zugriff auf die Registry.

Solange Du keine Software schreibst die zwangsläufig Admin-Rechte benötigen würde, sollten Dich diese (im übrigen sehr sinnvollen) Restriktionen nichtmal ansatzsweise tangieren.

Was ist denn Dein konkreter(!) Einsatzzweck? Was muss Dein Code machen, was er aktuell nicht darf?

[ManSues]

Ja, prima, so langsam kommt die Diskussion in Gang.
Aber Vorweg: Nicht das ihr mich falsch versteht. Ich bin ein absoluter Verfechter der Windows 7 (NT5) Sicherheitsmaßnahmen.

Nun zum konkreten Beispiel:
Unter XP entstanden einige Server, halt ganz normale EXE die Daten über Socket Verbindung (TCP/IP) an die Clients liefern. Da gibt es z.B. IO-Server (Datenlieferant von untergelagerten Systemen), Security-Server (Benutzerverwaltung mit Rechten) oder Language-Server (der zur ID und LCID den Text liefert). Es gibt noch eine Menge mehr, aber als Beispiel sollte es genügen. Diese Server laufen auf irgendeinen PC und beliefern die Anfragen von Clients auf anderen PCs. Nun sollen diese Server als Windows Dienste umgebaut werden, was auch einleuchtend ist, da diese sowieso schon Aufgaben von Diensten erfüllen.
Jetzt kommen wir zum Pudels Kern...
Alle diese Server haben eine Oberfläche (Form) zum Konfigurieren, analysieren und warten. Diese Oberfläche fällt beim Windows 7 Dienst weg. Es muss also die Form von der Logik getrennt werden, Form als EXE und Windows Dienst mit Logik, wobei die Oberfläche nicht zwangsläufig eine Form sein muss. Es ist auch eine Webseite denkbar.
Aber Bedienoberfläche und Dienst müssen kommunizieren. Und da suche ich eine Lösung. Anzumerken sei vielleicht noch, dass der Dienst nur Daten zur Oberfläche liefert oder bekommt. Wie die Oberfläche aussieht, entscheidet der Designer der Oberfläche (vielleicht ein wenig so wie XAML und CodeBehind)

[Bummi]

Named Pipes mit Rechtevergabe auf Benutzerebene über eine beiliegende Dummydatei wäre meine erste Wahl.
TCP/IP 2. Wahl
INI-Dateien 3. Wahl

[Phoenix]

Wenn der Dienst eh läuft, und per TCP/IP Kommuniziert, warum sollte er dann nicht auch noch auf einem weiteren Port z.B. Intraweb hosten und die Web-Oberfläche selber anbieten?

Bitte das oben gesagte nicht falsch verstehen. Ich persönlich halte Intraweb für so ziemlich die absolut falscheste Technologie, mit der man Webanwendungen bauen kann, aber genau für den Anwendungsfall, in dem die Logik eigentlich schon genau in dieser Anwendung ist, ist es vermutlich die einfachste Methode, das wiederzuverwenden.

Da die Anwendung ansonsten eh schon mittels TCP/IP Kommuniziert, könnte sie hier auch alternativ den 'Steuerungskanal' anbieten, den eine weitere Anwendung dann bedienen könnte.

Letzlich gibt es einfach keine 'Allgemein gültige Schnittstelle', es ist zwangsläufig immer eine Einzelfallentscheidung über alle Sinnvollen technologien und welche sich dann am effizientesten einsetzen lässt.

[Union]

Ich mach sowas meistens über Memory Mapped Files, darüber können sich dann Server und Client unterhalten.

[ConstantGardener]

... ich kann da statt Intraweb auch die WebComponents von Habarisoft (der Autor Michael Justin ist auch hier im Forum unterwegs) empfehlen. Sehr einfach zu konfigurieren, interner Webserver, wenig Overhead, RESTFUL Anwendungen/Webservices möglich, günstig usw.

Damit lässt sich eine Wartungs-Console für den Service schnell aufbauen. Wenn nötig auch mit BootStrap oder JQuery für mobile Geräte.

Wirf mal einen Blick drauf....

[ManSues]

TCP ist ganz nett gedacht, aber die Bedienung soll eigentlich nicht mit der Daten Komunikation verkuddelt werden.
Auch Memory maped Files ist ganz nett, aber nur lokal, geht nicht global und schon gar nicht übers Netz wegen fehlender Rechte (Client ist möglicherweise nur ein einfacher User).

Wir werden uns wahrscheinlich für MIB und snmp entscheiden. Das bedeutet es werden eine Client DLL für jede Sprache (C++, Delphi, C#, JS) und eine Server DLL für jede Sprache entstehen die entsprechende Funktionen besitzen womit ich Daten einer Oberfäche anbieten kann und Events der Oberfläche mitteilen.

Danke für eure Meinungen.

[sx2008]

Zitat:

Zitat von ManSues (Beitrag 1185993)

TCP ist ganz nett gedacht, aber die Bedienung soll eigentlich nicht mit der Daten Komunikation verkuddelt werden.

Muss man doch auch nicht.
Das Datenprotokoll sollte vom Datentransport getrennt werden.

Prinzipiell gibt es zwei Arten von Datentransport:
* streambasiert (TCP/IP, Named Pipes,..)
* messagebasiert (UDP/IP, Mailsots, Windows Messages, SNMP, Dateidialog,...)

Bei einem Stream muss man selbst für die Trennung der einzelnen "Befehle" sorgen, während diese Aufgabe bei einem messagebasierten Datentransport schon erledigt ist.
Andererseits kann man mit vielen einzelnen Messages wieder einen Stream bilden.

Die beiden Transportarten können also ineinander umgewandelt werden.

Unabhängig vom Datentransport ist das Protokoll auf Anwendungsebene.
Man könnte z.B. das POP3-Protokoll statt über TCP/IP auch über Named Pipes oder auch über Diskettenlaufwerke (2 Rechner, jeder hat ein Diskettenlaufwerk und es gibt 1 Diskette. Der Benutzer muss die Diskette wechselseitig in Rechner A und B stecken) fahren.

Die grösste Fehler von Indy ist dass Datentransport und Protokoll untrennbar miteinander verbunden sind. :wall:
Wenn man diesen Fehler vermeidet, dann kann es einem egal sein ob die Daten per TCP/IP, Named Piped oder was auch immer übertragen werden.

Das Protokoll könnte man z.B. auf XML, JSON oder Canonical S-Expressions aufbauen.
Wenn es Allgemein sein soll, muss das Protokoll auf jeden Fall eine hierarchische Datendarstellung erlauben.
Eine Liste möglicher Protokolle gibt es hier: http://en.wikipedia.org/wiki/Compari...zation_formats