Programm auf entfernten Client aus starten

[dirk_2909]

Hallo zusammen,

ist es möglich , und wenn ja Wie, von einem Server aus -sagen wir mal innerhalb eines Webservice-Providers- ein Programm (exe) auf einem Client auszuführen?

Würde es mit Winsock oder Telnet gehen?

[eknori]

Wenn du auf dem Client ein Stüch SW installieren kannst/möchtest,Ja. Nagios und seine Plugins machen Gebrauch davon.

[flaite]

Webservices können zwar über verschiedene Transportwege laufen, aber Winsock oder Telnet sind dafür sehr ungewöhnlich.
Keine Ahnung über welche Wege nagios kommuniziert, aber ich würd Messaging Infrastruktur wie Websphere MQ oder Active MQ für die beste Infrastruktur für sowas halten.
Winsocks und Telnet ist ziemlich sicher a) zu unsicher b) zu low level und c) zu teuer zu administrieren

Du würdest eher eine Architektur bauen, in der die Clients gescheduled gegen irgendwas pollen, um zu fragen, ob sie ein paar Jobs abarbeiten sollen. Das Messaging Zeugs stellt sehr gut sicher, dass die Nachrichten nicht verloren gehen, wenn das Netzwerk unten ist. Und das keine Nachrichten doppelt gesendet werden.
Verteiltes rechnen bringt immer zusätzliche Anforderungen mit sich.
a) günstige Administrierbarkeit
b) günstige Updatebarkeit
c) Sicherheit
d) Ausfallsicherheit
e) Skallierbarkeit
f) etc.
g) etc.
h) etc.
i) etc.

[Gandhi]

Winsock sind meiner Kenntnis nach Methoden um eine TCP/IP Verbindung aufzurufen - Telnet meint an der Stelle den Port?
Das ist also mehr die Frage wie ich welche Leitung aufbaue.

Interessanter ist doch die Frage, wie erstelle ich auf einem Client ein Programm, dass auf einen Port hört, Ein- und Ausgabeparameter hat und eine .exe aufrufen kann.

Das sollte mit Java (Hallo Herr Pityankee?) kein Problem sein:
Einfach ein RMI Java Programm auf den Clients (die dann lustigerweise RMI Server sind) starten und dann zentral (also auf dem Server, der dann ein RMI Client ist) aufrufen.

Betriebssystemaufrufe sollte die Klasse ProcessBuilder bieten - habe ich aber noch nicht ausprobiert.

Einen Webservice dafür zu bauen wäre mir zu aufwändig - wenn es nur um das remote-Starten von Programmen geht.

[dirk_2909]

Danke schon mal für die Antworten.
Ich werde mal schauen, was sich machen lässt und was -vor allem- sinnvoll ist.

[flaite]

Interessanter ist doch die Frage, wie erstelle ich auf einem Client ein Programm, dass auf einen Port hört, Ein- und Ausgabeparameter hat und eine .exe aufrufen kann.

Das sollte mit Java (Hallo Herr Pityankee?) kein Problem sein:
Einfach ein RMI Java Programm auf den Clients (die dann lustigerweise RMI Server sind) starten und dann zentral (also auf dem Server, der dann ein RMI Client ist) aufrufen.

rmi hat wiederum ein ganz eigenes Protokoll. Wird aber kaum benutzt.
Es gibt bessere Wege, um Prozesse auf entfernten Rechnern auszuführen.
Man programmiert sowas einfach nicht low level. Auch wenn ich sowas mit TCP/IP, Java-RMI oder Telnet in 2 Stunden in einer Spielumgebung programmieren könnte, würd ich das in dieser Welt nicht machen. Es geht nämlich um ein wenig mehr, als dass der eine Rechner an den anderen etwas senden kann. Vielmehr gehören dazu:
- Sicherheit
- Failover-Handling
- Administrierbarkeit
- Änderbarkeit
- Übersichtlichkeit

Nur weils in java.net. all diese Socket Klassen gibt, muß man die ja nicht direkt einsetzen.
Die Welt ist für sowas heute ein großer Freund von Message Oriented Middleware wie Active MQ oder Websphere MQ. Da gibts dann eine spezialisierte Middleware, die sich um den Austausch von Nachrichten zwischen unterschiedlichen Rechnern kümmert. Die Nachricht ist dann auf dem Zielrechner ein Event, auf das dann ein Programm gestartet werden kann und über eine andere Queue auch wieder etwas zurückgeschickt werden kann. Das ganze geht synchron (der wo die Nachricht eingestellt hat wartet auf Antwort) oder asynchron (der wo die Nachricht eingestellt hat, wartet nicht auf Nachricht, reagiert aber möglicherweise auf eine solche). Je nach Einsatzgebiet kommt auch das von Ulrich genannte Nagios in Frage. Das wird zum Monitoring und Reporting von verteilten Serverumgebungen verwendet. Da muss man sich über Transport, Adressierung, Sicherheit, Failover, etc. von Nachrichten nicht mehr kümmern, weil die Nagios Entwickler das bereits fertig entwickelt haben. Allerdings würd ich das System nicht für nicht-Monitoring Aufgaben vergewaltigen. ActiveMQ wär eine flexiblere Option, die nicht so wahnsinnig kompliziert ist. Oder - falls vorhanden - Websphere MQ (ehemals MQ Series) -> komplex, teuer, aber eben auch sehr gut. 

Es kann ja irgendwie nicht sein, dass Rechner kunterbunt über allemöglichen Methoden aufeinander zugreifen. Wirklich nicht.

[Pyewacket]

Das waren jetzt diverse Ansätze zum Thema 'Wie' aber warum willst du von einem Server aus ein Programm auf dem Client ausühren?