Vorteile von Nicht-Web-Applikationen?
-
byto schrieb:
Innovativ ist das Google Web Toolkit durch den Java-To-JavaScript Compiler, auf dem diese UI Lib basiert.
Das C++-Webtoolkit (dieses "Wt" bzw "Witty") gab's zuerst und macht ja afair das Gleiche :p
Das Konzept davon finde ich aber auch innovativ.
-
Artchi schrieb:
1. keine end-to-end-Verschlüsselung
Ist mit HTTPS gegeben.
Artchi schrieb:
2. keine einheitliche GUI-Konzepte und Workflow
Ist bei Richclients auch nicht der Fall.
Artchi schrieb:
3. ich habe immer noch Wartezeiten in den Aktionen
Hast du bei Richclients auch, ausser Du verarbeitest ausschließlich Offline Daten.
Artchi schrieb:
4. meine Daten müssen bei fremden Anbietern lagern, was mit end-to-end-Verschlüsselung nicht so schlimm wäre
siehe 1.
Gegenfrage, wie realisiert ihr denn den Zugang auf Eure Host DB2? Wie sichert ihr die Zugangsdaten ohne Server?
-
byto schrieb:
Ihr habt Euch diese Komponenten selbst zusammengebaut. Oben genanntes Framework bietet das Out of the Box. Das ist der Unterschied. Und genau auf den wollte ich hinaus.
Weil unser Terminal-Client das schon seit fast 10 Jahren kann? Und wie lange gibt es das Ext GWT? Ich glaube, Google als Firma gibts nicht mal so lange.
byto schrieb:
Warum gibts keine Swing Library, die solche Komponenten fertig implementiert, wenn sowas - wie Du schön erkannt hast - Gang und Gäbe ist?
Also erstmal, habe ich von einer Terminal-Emulation gesprochen, die wir mit eigenen grafischen Routinen versehen haben. Weil eine Terminal-Maske was anderes ist, als eine Richclient-Maske. Wir haben das nötige drin gelassen, und mit modernem angereichert. Konkret gesagt, wir benutzen keine Swing-Komponenten, nur die Swing-Graphics-Funktionen zum Zeichnen der Maske... ich bezweifel, das es sowas vor über 10 Jahren gab, so wie wir es speziell benötigten.
Leider kann ich kein Screenshot posten, weil das alles Inhouse-Entwicklung ist.
Was aber die Swing-Komponenten für "normale" Richclient-Anwendungen angeht: ich habe doch gesagt, das die alle in der Java-Runtime vorhanden sind. Genauso wie Gtkmm und Qt solche Komponenten auch hat. Ich weiß jetzt nicht wirklich, was du da jetzt vermisst?
-
byto schrieb:
Artchi schrieb:
1. keine end-to-end-Verschlüsselung
Ist mit HTTPS gegeben.
Nein, die Verschlüsselung geht nur vom Browser bis zum HTTP-Server. Das ist keine end-to-end-verschlüsselung, weil die daten z.B. auf dem Server unverschlüsselt abgelegt/verarbeitet werden.
end-to-end heißt, das sie auf dem CLient verschlüsselt werden, und auf dem Client erst wieder entschlüsselt werden. So das der Dienstleister (oder ein anderer dritter) keine Rohdaten erhält.Wenn ich z.B. im WebMail-Interface eine EMail eintippe und losschicke, kann sie jeder lesen. Die verschlüsselung zwischen Browser und http-Server bringt nichts.
Ich muß also den Mailtext auf meinem PC mit einem Tool verschlüsseln, den kryptyschen Text in das WebMail-Interface einfügen und losschicken. Die Mail geht verschlüsselt zum Empfänger. Und der EMpfänger kann erst auf seinem PC entschlüsseln, in dem er den kryptischen Mailtext aus dem WebMail-Interface kopiert und mit einem Tool entschlüsselt. Also von einem Ende zum anderen Ende.
Aber diese Arbeit macht sich doch keiner, da wird man ja blöd bei.
Sowas macht Thunderbird (mit Enigmail) oder TheBat! im Hintergrund für mich. Rich-Client halt. 
-
byto schrieb:
Gegenfrage, wie realisiert ihr denn den Zugang auf Eure Host DB2? Wie sichert ihr die Zugangsdaten ohne Server?
Die Frage habe ich nicht verstanden. Kannst du das genauer formulieren?
-
byto schrieb:
Ihr habt Euch diese Komponenten selbst zusammengebaut. Oben genanntes Framework bietet das Out of the Box. Das ist der Unterschied. Und genau auf den wollte ich hinaus.
Was soll das für einen Unterschied sein? Es gibt überall GUI Bibliotheken, welche spezielle zusammengebaute Komponenten Out of the Box anbieten. Das ist doch keine Innovation oder was neues, sondern da hat sich einfach der Entwickler der Bibliothek ein wenig Zeit genommen, noch ein paar alltägliche zusätzliche Komponenten zusammenzusetzen.
Ich sehe dann eher das Problem, dass die Komponenten zu spezialisiert sind und man ein oder zwei Dinge anders bräuchte und sie dann trotzdem selber erstellen muss. Deshalb sind eben viele Frameworks sehr fundamental gehalten, damit jeder das zusammensetzen kann, was er braucht.
Den einzigen Unterschied, welcher ich sehe, ist vielleicht das WIE des Zusammensetzens. Wobei es allerdings auch bei Richclients bereits solche Ansätze seit längerem gibt. Eine neuere oder bekanntere Vertretung in dem Bereich wäre zum Beispiel WPF für dotNet.
Ich sehe es also auch eher so, dass die Web UIs langsam die Richclient UIs einholen. Wobei dies allerdings hauptsächlich nur das graphische Betrifft. Von der Reaktionszeit solcher Web UIs wollen wir lieber mal nicht reden.
Allerdings finde ich, dass die Diskussion gerade ein wenig in die falsche Richtung geht. Man sollte nicht darüber diskutieren, was für den allgemeinen Fall besser ist, denn das ist wohl ziemlich schwer zu definieren. Es wurde, glaube ich, schon eimal gesagt und ich finde das sehr wichtig für diese Diskussion: Es kommt wahnsinnig stark auf die Anwendung an.
Sollte die Diskussion nicht eher in die Richtung gehen, dass sie definiert, welche Anwendungen man als WebApps realisieren sollte? Ich sehe viele Programme, welche sehr sinnvoll als WebApps sind und viele, welche ich nie als solche haben möchte. Die Kriterien dafür festzusetzen, finde ich aber zum Teil gar nicht so einfach, weil es oft sehr viele Grenzfälle dabei hat.
Ab wann sollte man also eine Anwendung als WebApp implementieren und wann nicht?Grüssli
-
Dravere schrieb:
byto schrieb:
Ihr habt Euch diese Komponenten selbst zusammengebaut. Oben genanntes Framework bietet das Out of the Box. Das ist der Unterschied. Und genau auf den wollte ich hinaus.
Was soll das für einen Unterschied sein? Es gibt überall GUI Bibliotheken, welche spezielle zusammengebaute Komponenten Out of the Box anbieten. Das ist doch keine Innovation oder was neues, sondern da hat sich einfach der Entwickler der Bibliothek ein wenig Zeit genommen, noch ein paar alltägliche zusätzliche Komponenten zusammenzusetzen.
Ich habe GWT als innovativ bezeichnet, nicht diese Lib.
Artchi schrieb:
byto schrieb:
Gegenfrage, wie realisiert ihr denn den Zugang auf Eure Host DB2? Wie sichert ihr die Zugangsdaten ohne Server?
Die Frage habe ich nicht verstanden. Kannst du das genauer formulieren?
Wir realisiert Ihr in Eurem Richclient den Zugriff auf die Datenbank? Und wie stellt ihr sicher, dass die Zugangsdaten für die DB sicher sind?
-
byto schrieb:
Wir realisiert Ihr in Eurem Richclient den Zugriff auf die Datenbank? Und wie stellt ihr sicher, dass die Zugangsdaten für die DB sicher sind?
Du weißt schon was ein Text-Terminal ist? Die Daten kommen mit der Maskenbeschreibung. Ok, wir haben in dem konkreten Fall schon die Maskenbeschreibung und Daten in mehrere XML-Responses getrennt, auch die dynamischen Listen kommen on-demand, aber es ist die selbe Session. Die Maskenbeschreibung kommt nur einmal zu Anfang, die Daten kommen getrennt immer wieder, je nach Aktion des Users.
Es wird also keine Connection vom Client direkt zur DB aufgebaut. Das macht alles der IBM-Mainframe und die COBOL-Programme die da drauf laufen. Die Connection zum Richclient ist aber verschlüsselt, obwohl alles im Intranet läuft.
Im Grunde genommen ist es wie eine WebApp mit Ajax, für Terminal/Mainframes. Aber das habe ich schon an anderer Stelle gesagt.
-
general bacardi schrieb:
hustbaer schrieb:
byto schrieb:
Irgendwie verwunderts wenig, dass in einem C++ Forum eher Skepsis ggü. modernen Webtechnologien herrscht.
Das hat mit Skepsis weniger zu tun als mit Fakten.
Es ist Fakt dass C++ Programmierer skeptisch gegenüber Webtechnologien sind? Das kann ich nicht bestätigen
Nein.
Es ist Fakt, dass Web-Applikationen für grosse, komplizierte User-Interfaces nicht zu gebrauchen sind.
Anders gesagt: ich bin was diesen Punkt angeht nicht Skeptisch, ich *weiss* dass es nicht gescheit funktioniert.
-
hustbaer schrieb:
Nein.
Es ist Fakt, dass Web-Applikationen für grosse, komplizierte User-Interfaces nicht zu gebrauchen sind.Dann sieh dich mal im Internet um. Du hast wohl noch nicht lange Internet?
Ausserdem sollten User Interfaces nie kompliziert sein. EIn kompliziertes UserInterface ist immer ein schlechtes User Interface.hustbaer schrieb:
Anders gesagt: ich bin was diesen Punkt angeht nicht Skeptisch, ich *weiss* dass es nicht gescheit funktioniert.
Weil Du es selber noch nie hingekriegt hast
-
general bacardi schrieb:
hustbaer schrieb:
Nein.
Es ist Fakt, dass Web-Applikationen für grosse, komplizierte User-Interfaces nicht zu gebrauchen sind.Dann sieh dich mal im Internet um. Du hast wohl noch nicht lange Internet?
Ausserdem sollten User Interfaces nie kompliziert sein. EIn kompliziertes UserInterface ist immer ein schlechtes User Interface.
Weil Du es selber noch nie hingekriegt hastDas finde ich nicht! Ein User-Interface ist dann schlecht, wenn es unnötig kompliziert ist. Es ist schlecht, wenn es die Intuition des Users nicht unterstützt, wenn es zu langsam ist, Standard-Features nicht unterstützt usw. Aus der Tatsache, dass ein GUI kompliziert ist, kann man erstmal gar nichts schließen.
Web-GUIs lassen oft (meistens?) Dinge vermissen, die ich normalerweise sehr schätze. Etwa die Bedienung über Shortcuts, Drag & Drop oder ein Clipboard. Letztere beiden natürlich auch zwischen mehreren Applikationen. Wenn ich sowas brauche und nicht vorfinde, dann spreche ich von einem schlechten GUI.
Stefan.
-
Mal ein paar Zusatzinformationen zum Projekt:
- Mini-ERP-Programm für Firma mit rund 30 Mitarbeitern (die allerdings weltweit verstreut arbeiten)
- Eine zentrale Produktionsstätte (dort soll Material, etc. verwaltet werden)
- Die Außenmitarbeiter müssen vor allem Finanzdaten und andere Informationen (also auch eine Art Portal) überall weltweit abfragen können. Die agieren nämlich ziemlich autonom wissen aber oft gar nicht ob die Kapazität vorhanden ist und nicht jemand anderes zur selben Zeit auch gerade alles verplant.
- Einige Außenmitarbeiter beschäftigen sich mit Controlling und Überwachung sowie Koordination.
Jeder hat mindestens Windows XP (verschiedene Sprachen allerdings), jeder hat einen halbwegs modernen Browser, jeder hat auch ein .NET-Framework.
Bei Web-Applikationen fallen mir da spontan folgende Vorteile ein:
- Updates sind leicht gemacht, generell alles kann ich zentral verwalten
- Habe keine Komaptibilitätsprobleme oder sonstigen Bugs die nur einen Mitarbeiter in Sonstwo betreffen und mich viel und teuren Support kosten
- Die Mitarbeiter benötigen nicht einmal Ihr eigenes Notebook sondern können überall darauf zugreifen
- Konfiguration & Deployment sind natürlich auch ein Klacks gegenüber FatclientServer + DB ist sowieso zentral, die Kommunikation zwischen Browser und WebServer ist sicher auch billiger als zwischen Fatclient und Server
Nachteile:
- GUI
- Die ganze Rechenlast liegt ausnahmslos am Server
- Sicherheitsprobleme (sind bei Fatclients natürlich auch nicht ausgeschlossen, aber wenn erstmal jemand Zugriff auf den WebServer hat ists übel...)Mehr Vorschläge von euch in diese Richtung? Wie gut nun welches Framework im Gegensatz zu C++ ist, ist mir eigentlich egal
Die Sprache ist ohnehin C# MfG SideWinder
-
Wenn du eh mit C# arbeitest, wieso kombinierst du nicht beides
EDIT:
Hab mal ein VideoCast von Microsoft gesehen, dass man DotNet-Anwenungen zentral deployen kann. Genauso wie Java Web Start Anwendung. Aber das ist schon etwas her. Mit Erkennung von neue Versionen und Differenzpatching.
-
Spontan sieht mir das sehr nach einer Web-Applikation aus. Allerdings:
- Könnte ich mir schon Kompatibilitätsprobleme vorstellen. Ist es nicht so, dass sich die Browser (etwa in Bezug auf JavaScript und CSS) erheblich unterscheiden? Ich bin definitiv kein Web-Entwickler, habe aber bei Kollegen schon öfter mitgekriegt, dass sie damit echte Probleme hatten.
- Kannst du Sicherheitsprobleme wirklich in den Griff kriegen? Ich denke da einerseits an Angriffe auf den Server (auch über deine Scripte). Andererseits aber auch an die Sicherheit der Daten, die an die Mitarbeiter ausgeliefert werden. Eine für's Controlling ausgelieferte Liste der Umsätze des letzten Jahres aus dem Browser rauszukrigen, stelle ich mir trivial vor.
- Ist es wirklich so erstrebenswert, dass Mitarbeiter von überall aus auf die Daten zugreifen können? Ich denke da an den Browser-Cache, die History und ähnliches. Und das in einem Internet-Cafe oder bei einem Kunden!
Dass die Kommunikation zwischen Client und Server bei Web-Applikationen billiger als bei Fat Clients ist, glaube ich nicht. Zumindest bei einer 3tier-Applikation überträgst du nur die wirklich benötigten Daten und die am besten komprimiert. Ein weiterer Vorteil einer solche Applikation könnte auch der bessere Schutz von DB-Zugriffen sein.
Dass die Rechenlast beim Server liegt, sehe ich nicht als Nachteil an. Da gehört sie doch auf jeden Fall hin.
Stefan.
-
Zeus schrieb:
EDIT:
Hab mal ein VideoCast von Microsoft gesehen, dass man DotNet-Anwenungen zentral deployen kann. Genauso wie Java Web Start Anwendung. Aber das ist schon etwas her. Mit Erkennung von neue Versionen und Differenzpatching.Das wäre ja sehr interessant, hast du den Webcsat noch?
MfG SideWinder
-
Yup habs wiedergefunden:
https://www.microsoft.com/germany/msdn/webcasts/library.aspx?id=118764814Windows Presentation Foundation (Teil 4-4) - Smart Client mit WPF gehalten von Dirk Primbs
ClickOnce Deployment
-
Also ein Fatclient ohne Server kommt imo nicht in Frage. Die DB Zugangsdaten würden auf dem Client liegen und wären somit nicht sicher.
Du solltest Dich also entscheiden zwischen Application-Server + Fatclient oder Application-Server + Webclient. Der Server bietet dabei ja durchaus noch weitere Vorteile. Du kannst z.B. Daten zentral cachen, um DB Abfragen (die ja häufig das Nadelöhr darstellen) einzusparen. Und Du kannst teure Operationen (solltest Du Dich für einen Fatclient entscheiden) auf den Server auslagern. Ausserdem kannst Du viel einfacher Jobs schedulen, also z.B. zu niedrigen Stoßzeiten irgendwelche Reports generieren usw.
Die Vor- und Nachteile hast Du ja schon gut zusammengefasst. Ich sehe bei Deinen Anforderungen allerdings keinen Grund, durch den sich ein Fatclient aufdrängen würde. Im Grunde wirds ja lediglich ne Datenschleuder werden (Daten eingeben, Daten ausgeben), die Paradedisziplin von Webclients.
-
Also ein Fatclient ohne Server kommt imo nicht in Frage. Die DB Zugangsdaten würden auf dem Client liegen und wären somit nicht sicher.
Klar, davon hat ja auch niemand gesprochen.
MfG SideWinder
-
general bacardi schrieb:
hustbaer schrieb:
Nein.
Es ist Fakt, dass Web-Applikationen für grosse, komplizierte User-Interfaces nicht zu gebrauchen sind.Dann sieh dich mal im Internet um. Du hast wohl noch nicht lange Internet?
Ausserdem sollten User Interfaces nie kompliziert sein. EIn kompliziertes UserInterface ist immer ein schlechtes User Interface.hustbaer schrieb:
Anders gesagt: ich bin was diesen Punkt angeht nicht Skeptisch, ich *weiss* dass es nicht gescheit funktioniert.
Weil Du es selber noch nie hingekriegt hast
Achherrjeh, ein Mister Schlau (tm).
Ja, natürlich, du hast Recht, und ich erst seit gestern Internet.
-
Nachtrag:
Twitter geht nach DoS-Angriff in die Knie. Dieser Beitrag war Ausloeser und keine Ahnung, ob es schon gesagt wurde. Webanwendungen sind anfaelliger gegenueber Stoerungen im allgemeinen. Das muss jetzt nicht zwingend eine boeswillige Attacke sein. Die Verteilung einzelner Daten ist wesentlich einfacher als eine Userinterfacekommunikation uber das Netzwerk. Wer oefters mit Linux arbeitet und remote GUI-Anwendungen ueber "ssh -X ..." kennt das vielleicht, dass man da schon eine ordentliche Leitung haben sollte.
