Client-Server Frage für eine Recherche!

K

kalle51

Aktives Mitglied
Thread Starter
Dabei seit
24.08.2005
Beiträge
129
Reaktionspunkte
0
Hallo alle zusammen,
1. Ich habe folgende Frage, es ist doch richtig, das PHP Programme auf dem Server ablaufen und Java Programme auf dem Client - oder?
2. Gibt es noch andere? Wenn ja nennt mir sie bitte.
Danke im voraus!
Kalle
 
Java-Anwendungen können auch auf dem Server laufen. Es kommt darauf an, was die Java-Anwendung machen soll. Sollen z. B. einfach nur HTML-Seiten oder Bilder generiert werden (oder ähnliches), dann läuft dazu auf dem Server ein Programm, das die gewünschte Funktion ausführt. Dieses Programm kann praktisch in jeder belieben Sprache geschrieben sein, z. B. PHP, Java, Ruby, Phyton, Perl, TCL, ASP, C, C++, C#, Objectiv C usw.

Pingu
 
@Pingu: Du hast COBOL, FORTRAN; PL1, etc. vergessen ... :D
 
Hab ich mir schon gedankt, unvollständige Frage - Entschuldigung.

Es geht um folgende Fiktion: Ein Roboter soll von einem Rechner aus der Ferne gesteuert werden, da wäre doch eine Software ungünstiger die auf der Client-Seite liegt, wegen folgender Updates. Den so müsten ja alle Clients aktualisiert werden, anders nur die Serversoftware. - Das ganze ist nur reine Fiktion. Ich möchte nur mit dem Gedanken nicht völlig daneben liegen.

Kalle
 
kalle51 schrieb:
da wäre doch eine Software ungünstiger die auf der Client-Seite liegt, wegen folgender Updates. Den so müsten ja alle Clients aktualisiert werden, anders nur die Serversoftware.

Ja, sicher, dass kann eine Überlegung sein. Aber irgendeine Art von Client Software brauchst Du ja immer, die kann natürlich minimal gehalten sein.

Aber mit PHP oder Java hat das erstmal nichts zu tun, siehe Pingus Antwort.

Alex
 
Über deine Fragestellung wurde in den letzten Jahren heftige diskutiert.

- Beim klassischen Client-Server-Model muss du mit jedem Update auch die Client-Software aktualisieren.

- Dem entgegen hat sich das "Web-Model" entabliert. Der Client ist ein Browser, er verwendet nur HTML. Die gesamte Software wird auf dem Server installiert und upgedatet.

- Mischformen:
+ SAP: Bei SAP muss man nur für große Versionssprünge die Client-Software aktualisieren. Die meisten Änderungen (auch an der GUI) können über ein Server-Update gemacht werden
+ Java-Web-Start: Der Java-Web-Start-Client wird einmal installiert, ruft man dann eine Anwendung auf, so schaut der Java-Web-Start Client nach, ob die aktuelle Version auf dem lokalen Rechner vorhanden ist. Wenn nein wird diese geladen, sonst einfach gestartet. -> keine Installation auf den Clients.
+ Java-Applets: Java-Applets werden auf dem (Web-)Server installiert, laufen aber nacher auf dem Client ab -> keine Installation auf den Clients.

gibt bestimmt noch 1000 andere Beispiele....
 
oglimmer schrieb:
Über deine Fragestellung wurde in den letzten Jahren heftige diskutiert.

- Dem entgegen hat sich das "Web-Model" entabliert. Der Client ist ein Browser, er verwendet nur HTML. Die gesamte Software wird auf dem Server installiert und upgedatet.

Aber auch hier muss der Client (Browser) für bestimmte neue Funktionen upgedated werden.

Gruss

Alex
 
below schrieb:
Aber auch hier muss der Client (Browser) für bestimmte neue Funktionen upgedated werden.

Naja, das stimmt zwar theoretisch, ist aber praktisch irrelevant.

HTML und JavaScript haben sich in den letzten 5 Jahren praktisch nicht verändert.
Bei CSS tut sich zwar noch was, aber in den Implementierungen hat sich auch nicht wirklich was veränert.

Web-Andwendungen verwenden Technologien die seit Jahren von Browsern angeboten werden und bei denen sich fast nichts tut.

Ich bin Software-Entwickler für ein "web-based" product und ich wüsste nicht, dass wir seit bestehen der Anwendung schon mal einem Kunden empfehlen mussten, den Client-Browser upzudaten.

Es wäre also pure Verunsicherung, wenn man Leute davor warnen würde, dass bei einer Browser-Anwendung die praktische Gefahr besteht, der Client müsste von Zeit-zu-Zeit upgedatet werden.
 
oglimmer schrieb:
Es wäre also pure Verunsicherung, wenn man Leute davor warnen würde, dass bei einer Browser-Anwendung die praktische Gefahr besteht, der Client müsste von Zeit-zu-Zeit upgedatet werden.

Ich wollte niemanden verunsichern, sondern nur kurz einwerfen dass jeder Client natürlich auch nur Software ist.

Wenn der Client gut geplant und programmiert wird kann man ihn mit Sicherheit lange verwenden. Wenn meine Applikation dann aber auf einmal ganz neue Dinge machen will (die z.B. nur neue Browser können), dann ist ein Client update fällig.

Alex
 
kalle51 schrieb:
Es geht um folgende Fiktion: Ein Roboter soll von einem Rechner aus der Ferne gesteuert werden

oglimmer schrieb:
Dem entgegen hat sich das "Web-Model" entabliert. Der Client ist ein Browser, er verwendet nur HTML.

Robotersteuerung per WebDav kopfkratz
 
kalle51 schrieb:
Es geht um folgende Fiktion: Ein Roboter soll von einem Rechner aus der Ferne gesteuert werden, da wäre doch eine Software ungünstiger die auf der Client-Seite liegt, wegen folgender Updates. Den so müsten ja alle Clients aktualisiert werden, anders nur die Serversoftware. - Das ganze ist nur reine Fiktion. Ich möchte nur mit dem Gedanken nicht völlig daneben liegen.

Ich denke, da sind erstmal wenigstens 2 Fragen zu beantworten:
1. Für welche Sprachen steht eine Schnittstelle für die Roboterhardware zur Verfügung? Aus Java kann man recht einfach native Bibliotheken aufrufen, möglicherweise existiert sogar schon ein Java-API. PHP oder dergleichen ist für derartige Anwendungen nicht so gedacht - es kann gut sein, dass man sich für eine Ansteuerung aus PHP ziemlich verrenken muss.
2. Wie echtzeitfähig soll das sein und wieviel Kontrolle soll die Fernsteuerung ermöglichen? Wenn nur vorprogrammierte Bewegungsabläufe gestartet werden sollen, ist eine rein HTML-basierte Oberfläche zur Steuerung ausreichend - dann braucht man ja nur ein paar Buttons. Wenn mehr Kontrolle notwendig ist - z.B. beim Verschieben eines Sliders soll sich der Roboterarm analog bewegen - ist das mit einer reinen HTML-Oberfläche auf dem Client soweit ich weiss nicht mehr so einfach möglich. Da wäre dann denke ich ein Java-Applet die beste Wahl - dieses könnte dann über ein massgescheidertes Netzwerkprotokoll mit dem Server kommunizieren und wäre nicht auf http-Requests beschränkt. Der Server könnte dann ein in einer beliebigen Sprache geschriebener Dienst sein.

Gremlin
 
im Allgemeinen bestehen Roboter aus mehreren Antriebseinheiten. Meist sprechen diese CNC oder Komplexeres. Der "Roboter" dient dabei bereits als Server für die Motoren, indem er deren Bewegungen kontrolliert. Dazu muß nat., wie von Gremlin erwähnt, ein RealTime OS laufen.

Server für Roboter könnte ggf. eine Produktionsstraße sein. So etwas wird durch ein PPS ( Produktionsplanungssystem) oder QMS (Qualitätsmanagementsystem) miterfaßt.

Simples Beispiel einer Änderung:

in einer Möbelfabrik werden in einer Straße Stühle gefertigt, dabei sind die Lehnen plötzlich 1-2mm stärker als sonst. Daraus schließt das QMS, daß die Fräsen nicht mehr richtig arbeiten (==> Wartung nötig). Abhängig von der Arbeitstemperatur kann ermittelt werden, ob der Anpreßdruck noch erhöht werden kann ohne das Material zu beschädigen. Dann kann am Schichtende eine Wartung durchgeführt werden ( Fräsköpfe tauschen) oder der Motor erkennt bereits jetzt zu hohe Parameter und schaltet sich ab. Dann wird in letzter Konsequenz auch die Straße angehalten. Dies alles geschieht über Bussysteme (VME). Über Diese werden auch Programme und -Änderungen an die Subsysteme geschickt. Natürlich kann man trotzdem jede weitere Untereinheit direkt ansprechen. Von der Produktionseinheit über Roboter bishin zum CNC-Endgerät. Es gibt also Beides, man kann zentralisiert Produktionseinheiten ansprechen ( und für die Verteilung der Software sorgen) oder Geräte direkt einzeln programmieren. PHP ist dabei nicht verwendbar. Klassisch wird sogar immer noch C eingesetzt bei Mikrocontrollern (C++ ist glaub ich auch heute noch selten - hab sowas vor 10 Jahren mal selbst gemacht). Neuerdings soll es JREs geben, die die Echtzeitforderung erfüllen, so daß Java in dem Bereich möglich wird.
 
Also Leute, ich danke euch ersteinmal, für die vielen, nützlichen Antworten. Ihr braucht jetzt nicht weiter ins Detail zu gehen, ich habe, dank eurer Antworten genug Anhaltspunkte um weiter zu recherchieren.
Gruss Kalle
 
Zurück
Oben Unten