Servus allerseits Für eine Webseite möchte ich Java einsetzen. Ich haette 2 Fragen dazu: 1. Frage: Wie gross ist die Chance, dass jemand auf seinem Rechner kein JRE istalliert hat? Gibt es dazu irgendwelche Untersuchungen? 2. Bei php sind ja die username/password etc. für die Datenbank Verbindung auf dem Server abgelegt. Der User kriegt sie nicht zu Gesicht. Bei Java wird aber das Applet zuerst geladan bevor es ausgeführt wird. Wie sicher sind denn dann diese Verbindungsdaten geschützt? MfG aus Istanbul
zu 1: gibt verschiedene Statistiken im Internet, hier ein Beispiel: http://riastats.com Also ich denke man kann sagen, daß 50%-75% aller User Java installiert haben, gegenüber wohl 95%, die Flash installiert haben zu 2: alles was im Applet ist und auf dem Rechners des Users ausgeführt wird, musst du als offen ansehen. Also dort keine Datenbankzugangsdaten ablegen, wenn es ein vom Internet zugängliches Applet ist. Besser z.B. einen kleinen PHP-Wrapper schreiben, der genau definierte Funktionalität dem Applet zur Verfügung stellt.
Danke für die schnelle Antwort. Frank Buss schrieb: > Besser z.B. > einen kleinen PHP-Wrapper schreiben Wie muss ich mir das vorstellen? So wie bei Perl, wo man C-Funktionen einbinden kann?
Mehmet Kendi schrieb: > Servus allerseits > > Für eine Webseite möchte ich Java einsetzen. Ich haette 2 Fragen dazu: > > 1. Frage: Wie gross ist die Chance, dass jemand auf seinem Rechner kein > JRE istalliert hat? Gibt es dazu irgendwelche Untersuchungen? Falscher Ansatz. Ist die Java-Anwendung elementar für dein Angebot? Will meinen, besuche ich dein Angebot gerade deshalb, weil ich deine Anwendung nutzen möchte, oder können andere Leute das bereits ohne Java? Falls ja: Es ist für mich vertretbar, eine Laufzeitumgebung zu installieren. Ein Beispiel wäre z.B. eine Physik-Simulation. Hat mehr 'Anwendungs'-Charakter, der das Javazeugs rechtfertigt, im Gegensatz zu Werbegeblinke oder Designschwachsinn. Falls nein: Noscript o.ä. wird die Anwendung aussortieren. In diese Schublade gehören m.M.n. auch Seiten, die vollständig in Flash oder Java umgesetzt sind und anderweitig garnicht mehr lesbar sind. Da du aber offenbar Größeres vorhast, denke ich schon, dass erster Fall zutrifft.
Mehmet Kendi schrieb: > Danke für die schnelle Antwort. > > Frank Buss schrieb: >> Besser z.B. >> einen kleinen PHP-Wrapper schreiben > > Wie muss ich mir das vorstellen? So wie bei Perl, wo man C-Funktionen > einbinden kann? Jein. Er meinte wohl, deine Anwendung in weitere Schichten aufzuteilen. Damit geht einher, dass dein Java-Frontend 'dumm' ist und alle Eingaben auf der Serverseite nochmals überprüft werden, sodass quasi die Datenbanklogik auf dem Server abläuft und dein Java-Programm wirklich nur Eingabemaske ist.
Sven P. schrieb: > Falscher Ansatz. Es ist ein grösseres Projekt, das ich anfaenglich mit php in Angriff genommen hatte. Super Sprache. Objektorientiert. Eine Library die nichts offen laesst. Das Programm laeuft auf jedem x-beliebigen Browser. Aber irgendwie komme ich mit dieser SESSION Philosophie nicht zurecht. Und je weiter das Projekt weiterschreitet, desto öfters muss ich anhalten um mich zu orientieren. Und vermutlich werde ich, wenn's so weitergeht, nach ein paar Monaten irgendwo steckenbleiben.
Mehmet Kendi schrieb: > Es ist ein grösseres Projekt, das ich anfaenglich mit php in Angriff > genommen hatte. Super Sprache. Objektorientiert. Eine Library die nichts > offen laesst. Das Programm laeuft auf jedem x-beliebigen Browser. > > Aber irgendwie komme ich mit dieser SESSION Philosophie nicht zurecht. > Und je weiter das Projekt weiterschreitet, desto öfters muss ich > anhalten um mich zu orientieren. Und vermutlich werde ich, wenn's so > weitergeht, nach ein paar Monaten irgendwo steckenbleiben. Das ist ein guter Ansatz: Läuft alles prima, aber die Session-Philosophie nicht, daher also alles bisher programmierte wegwerfen und mit Java neu anfangen :-) Aber im Ernst: Java als Applet lohnt sich eigentlich nur, wenn du auf dem Client viel Rechenleistung brauchst, z.B. wie hierfür: http://www.frank-buss.de/automaton/golautomaton.html Wenn du dagegen willst, daß möglichst viele der Webseitenbesucher deine Anwendung nutzen können, dann verwende nur Standard HTML und auf Serverseite PHP auf Serverseite, Tomcat, Ruby on Rails, Zope usw. Was anderes kann es sein, wenn du z.B. eine Buchhaltungssoftware o.ä. programmierst. Da kann es u.U. besser sein, eine Java-Anwendung zu schreiben, z.B. direkt mit Swing oder JGoodies, da du dann nicht auf die Internetbrowser und deren Spezialitäten angewiesen bist (z.B. Eingabeüberprüfung per JavaScript muß man ggf. für verschiedene Browser mehrfach schreiben), sondern immer dieselbe Java-Umgebung zur Verfügung hast. Das sollte man dann aber besser per Java Webstart verteilen, wie z.B. das Programm hier: http://zirkel.sourceforge.net/doc_de/index.html
Mehmet Kendi schrieb: > Sven P. schrieb: >> Falscher Ansatz. > > Es ist ein grösseres Projekt, das ich anfaenglich mit php in Angriff > genommen hatte. Super Sprache. Objektorientiert. Eine Library die nichts > offen laesst. Das Programm laeuft auf jedem x-beliebigen Browser. > [...] Das täuscht. Ging mir genauso, seitdem hab ich PHP nicht mehr angefasst. PHP ist im Kern verfault und kaputt bis zum Geht-nicht-mehr. Vielleicht wäre es sogar angebracht, den Kram serverseitig in C(++) oder Java aufzusetzen.
Vielleicht waere es vernünftiger gewesen, von Anfang an das ganze Bild zu projektieren; aber ich wollte nicht mit vielleicht unnötigem Blabla Eure Zeit stehlen. Vor Jahren hatte ich für eine Firma ein recht komplexes Programm geschrieben. Client/Server Applikation. Sprache: Visual FoxPro. Eine Art Office-Automation ... keine Ahnung wie man das sonst nennen soll. Laeuft nun bei 2 verschiedenen Firmen. Der eine Inhaber will nun einen Teil der Software mit ein paar zusaetzlichen Funktion vom Internet her zugaenglich machen (Auswahl von Dienstleistungen, Zahlungen usw.) Wobei: Die Dienstleistungen sind nicht fix (das Wort 'willkürlich' liegt mir auf der Zunge) und auch die Firmenkunden, welche die Seite besuchen, sind nicht vorhersehbar (deshalb meine Frage nach der Java-Statistik). Frank Buss schrieb: > Das ist ein guter Ansatz: Läuft alles prima, aber die > Session-Philosophie nicht, daher also alles bisher programmierte > wegwerfen und mit Java neu anfangen :-) Das bisher Erreichte über Bord zu werfen würde mir nicht viel ausmachen, da ich erst ca. 20% der ToDo-Liste abgehakt habe.
Wenn der Server das leistet würde ich weg vom Applett und hin zum Servlett (z.B. mit Tomcat oder jetty) das läuft dan wie PHP Serverseitig, generiert aber "normales" HTML.
Läubi .. schrieb: > Wenn der Server das leistet würde ... Keine Ahnung, was man da so an Leistung braucht. :) Ein VPS bei einem guten ISP, würde das klappen?
Mehmet Kendi schrieb: > Läubi .. schrieb: >> Wenn der Server das leistet würde ... > Keine Ahnung, was man da so an Leistung braucht. :) > Ein VPS bei einem guten ISP, würde das klappen? Na deine (geplante) Netzinfrastruktur solltest du doch besser kennen ;) Mit leisten meinte ich eher, das nicht jeder Provider das uneingeschränkte ausführen/installieren von Anwendungsprogrammen unterstützt, und TomCat z.B. nicht zwangsläufig Standard ist.
Hallo Mehmet, jegliche Annahme, die Du über Deine Benutzer oder ihre Maschinen trriffst, wird falsch sein. Immer. Eigene Erfahrung. Nutzer werden selbst mit einer getesteten Anleitung, die nur Copy & Paste bedarf, Fehler machen. Ebenfalls erlebt. Sehr wahrscheinlich wird bald jemand fragen, ob das System auch von einem Android/BB/i* genutzt werden kann - also gehe immer vom allerschlimmsten DAU aus. Nach meiner Einschätzung wird durch das Oracle-Gezeter Java zum Risiko-Faktor. Was nutzt Dir Java, wenn Dir über die Nutzungsdauer Deines Projektes die JRE wegfallen? Würde ich sehr intensiv abwägen.
Jörg Hermann schrieb: > Nach meiner Einschätzung wird durch das Oracle-Gezeter Java zum > Risiko-Faktor. Was nutzt Dir Java, wenn Dir über die Nutzungsdauer > Deines Projektes die JRE wegfallen? Würde ich sehr intensiv abwägen. Einmal gibt es auch alternativen zur Oracle/Sun VM, und anderereseits wird es auch Oracle nicht gelingen "deine" VM Installation über die Ferne zu löschen oder sämtliche Installationspakete aus dem Internet zu tilgen... Meiner Meinung nach also blose Panikmache (woher kommt diese Ansicht eigentlich, ich seh' da keinerlei Anzeichen für).
Heisst das nun, dass man mit Java-Applets keine sicherheitsrelevanten Applikationen schreiben kann?
Läubi .. schrieb: > Meiner Meinung nach also blose Panikmache (woher kommt diese Ansicht > eigentlich, ich seh' da keinerlei Anzeichen für). Oracle wird Java nicht töten, dazu hängen die selber seit vielen Jahren zu tief drin. Aber sie wollen die absolute Kontrolle darüber bewahren, was bei einem Konzern wie Oracle reflexhafte Gegenbewegungen auslöst. Das ist wie früher bei IBM: Wenn die sich technisch für etwas entschieden hatten, dann konnte man fast schon drauf wetten, das der Rest der Welt sich davon abwendet und es anders macht.
Mehmet Kendi schrieb: > Heisst das nun, dass man mit Java-Applets keine sicherheitsrelevanten > Applikationen schreiben kann? Das kann man eigentlich in keiner Sprache, wenn der sicherheitsrelevante Teil auf dem feindlichen Rechner abläuft. Theoretisch kannst du dann bestenfalls Eingabemasken anbieten, deren Auswertung dann wieder auf einem System erfolgt, welches unter deiner Kontrolle ist. Schau dir mal den Blindgänger "X-Pire!" an.
Du kannst das Applet signieren und den Server die mit guter Cryptografie die Signatur überprüfen lassen. Alle Verbindungen müssen dann Verschlüsselt laufen. Ich würde auch möglichst viel Intelligenz auf den Server legen.
Üblich wäre ein normaler Webserver der HTML an die Clients ausliefert und den Rest, wie schon angedeutet, serverseitig löst. Java-Applets verwendet heute eigentlich niemand mehr (abgesehen von den Beispielen oben und einigen Behörden Elster, Stiftung EAR). Die Frage ist schreibt man alles selbst oder nutzt entsprechende Frameworks ala Zope, ASP.NET, Ruby on Rails oder gleich ein CMS mit eigenen Anpassungen. Persönlich würde ich z.Z. als Framework entweder RoR oder ASP.NET/WebSharper nehmen.
Hier sind ein paar Hinweise wie es mit Java weitergehen könnte: http://www.heise.de/ix/meldung/Marktforscher-sehen-den-Java-Community-Prozess-am-Ende-1176520.html Interpretieren und Schlüsse ziehen darf jeder nach seinem Gusto...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.