Voor en nadelen java-applet

[Devour]

Ik heb een vraag m.b.t. java applets. Ik ben zelf een student hogere informatica en ik weet van de meest talen en scripts wat ze kunnen. Ik zit nu met een probleem, bij een informatie systeem waar ik mee te maken heb.

Het informatiesysteem is voor het invoeren en uitlezen van gegevens uit een database en beveiliging speelt ook nog een beetje mee. Nu wordt er gebruik gemaakt van IBM-websphere, waar d.m.v. servlets, JSP en javabeans de pagina wordt opgebouwd.

Volgens mij zou het sneller zijn als je 1 keer op een dag een applet laad, evt. een 2'e in een nieuw scherm omdat je met meerdere systemen te maken hebt, dan dat je de hele dag nieuwe gegenereerde schermen opvraagt. Je laadtijd over een hele dag is veel langer dan die +/- 10 sec. van een applet 's ochtends vroeg. Een applet zou met RMI-calls (welke nu ook door de beans gebruikt worden) gegevens uit de database kunnen halen.

Wat zijn de voor- een nadelen van een applet t.o.v. het genereren van webpagina's.

[Juup]

Waarom dan niet gewoon een (Java) applicatie schrijven voor op de client? Een applet is een (beperkte) applicatie die je in een browservenster kan draaien.

[Expander]

Een voordeel is dat de webserver minder rekenwerk hoeft te doen.

Misschien is een nadeel dat er meer data over het netwerk moet.

[Juup]

En voor de security is het niet altijd handig dat de client bij 'alle' data kan. Soms mag de client alleen gefilterde data zien. Dan moet je dus toch nog iets serverside doen.

[Alarmnummer]

Anders maak je een application die je via WebStart opstart. Als het werkt, dan is WebStart uitermate handig.

[Devour]

Het voordeel van een applet is dat je naast de applet wel HTML er omheen kunt genereren.
Je zou bv. de applet kunnen veranderen op server niveau, dynamische genereren van een nieuwe applet of de parameters veranderen. Ik noem maar wat.

Dat de client bij alle data kan begrijp ik niet helemaal, met een applet komt de gebruiker toch niet bij de data? Je hebt een class-file that's it.

Sorry ik ben niet echt bekend met Webstart, hoe zie je dat?

[Alarmnummer]

Webstart is niets anders dan een handige manier om een normale Application op te starten via het internet. Als je een jnlp bestand op de server zet en de user gaat dit downloaden. Dan zal webstart (applicatie bij de user) deze herkennen en automatisch de jars downloaden die nodig zijn. Zijn er jars nog up te date van de vorige keer dan haalt hij niets op. Daarna wordt de application opgestart. Het is dus een 100% applicatie zoals je die gewoonlijk ook maakt.

[Devour]

Expander: Ik denk trouwens niet dat het meer dataverkeer met zich mee brengt omdat het interface maar 1 keer geladen wordt en daarna niet meer.

Alarm: welke runtime heb ik daar dan voor nodig? Bij een applet werkt het meestal direct als je niet al te moelijke dingen aanroept, we hebben het tenslotte over een informatiesysteem met simpele invoervelden enzo.

Nog een voordeel van een applet is dat je makkelijker door een database kunt wandelen. Geen problemen met voor of achteruit in een zoekopdracht.

[Alarmnummer]

Je zit toch al gauw van aan jdk1.3/1.4. Het ligt er maar net aan hoe zo`n ingewikkeld systeem het is. Ik zou zelf niets meer in 1.1 willen schrijven, maar als het een simpel systeem is, dan bespaar je wel iedereen een runtime van 10+ mb te downen.

[Devour]

Nog meer mensen die wat voor of nadelen hier van weten?

[Bobco]

Devour schreef op 12 augustus 2002 @ 13:26:
Nog een voordeel van een applet is dat je makkelijker door een database kunt wandelen. Geen problemen met voor of achteruit in een zoekopdracht.

Nadeel hiervan is dat iedereen dat dus ook kan doen Wat ik bedoel is dat je dan niet direct een gemakkelijke manier hebt om je database tegen een mogelijke overload te beschermen. Ik heb geen idee van het aantal gelijktijdige gebruikers, maar de connection pooling die een applicatie server als WebSphere je biedt kan belangrijk zijn als je praat over grote aantallen.

Als elke client een of meer connecties naar de database open heeft staan dan kan dat behoorlijk resources vreten op je database. Volgens mij geldt uiteindelijk altijd meten is weten...

[Devour]

Heb je gelijk aan, mijn idee was om een applet te gebruiken in combinatie met RMI. De server calls gaan nu ook via RMI, dus de websphere server zou je gewoon kunnen houden, dus ook de pooling.

[Devour]

Zijn er nu te weinig mensen die hier een mening over hebben of is deze matherie te moeilijk of te onbekend ?

[Alarmnummer]

Je hebt het over RMI calls naar de database. Wil je dat iedere applet zijn eigen connection heeft, of komt er nog een server tussen te zitten die je mbv RMI aanspreekt? Een eigen connection naar de db is not done ivm veiligheid. Verder kan de RMI server gebruik maken van Connection pooling.

Ik heb trouwens totaal geen verstand van WebSphere en wat het eigelijk is. Is het alleen een db of nog veel meer?

[Bobco]

Alarmnummer schreef op 13 augustus 2002 @ 13:27:
Ik heb trouwens totaal geen verstand van WebSphere en wat het eigelijk is. Is het alleen een db of nog veel meer?

WebSphere is een web/EJBcontainer zoals die beschreven staat in de J2EE specs. kort gezegd is het dus een ding waarin je JSPs, servlets, EJBs en meer van dat soort leuke serverside componenten kan laten draaien.

IBM WebSphere is een van de grotere spelers in dit veld, anderen zijn BEA met WebLogic en Oracle met OC4J, ook wel Oracle 9i AS genoemd.

Strikt genomen hoort er geen database bij WebSphere, maar IBM verkoopt je natuurlijk met veel plezier een kopietje van DB2. Zelfde soort verhaal geldt voor Oracle en er zijn natuurlijk altijd package deals mogelijk.

[Bobco]

Devour schreef op 13 augustus 2002 @ 11:53:
Zijn er nu te weinig mensen die hier een mening over hebben of is deze matherie te moeilijk of te onbekend ?

Tja, dit is wel een heel erg specifiek onderwerp. Ik denk dat de 'doelgroep' van GoT sowieso al meer PHP georienteerd is. Ik kan me in ieder geval niet voorstellen dat er veel mensen zijn die voor de lol een J2EE server draaien. Vrijwel iedereen die ik ken is er min of meer professioneel mee bezig, dwz voor z'n werk.

Het toepassingsgebied voor J2EE ligt natuurlijk oook veel meer alleen in de hoek van het bedrijfsleven dan laten we zeggen iets als PHP. Hetzelfde zie je ook bij .Net van Microsoft. Het 'echte' .Net wordt maar door relatief weinig mensen gebruikt, zeker als je simpele programmaatjes/scripts in VB.Net of ASP.Net afstreept.

[Devour]

Tuurlijk ben ik helemaal met je eens !

Ik heb het eigenlijk meer over de keuze van interface. Wat is dan sneller. Ik had eigenlijk wel gedacht dat iemand een idee had of applets voor een connectie naar een db sneller of handiger zou zijn dan een pagina opzich. Jammer!

[Xanthus]

Met een webpagina is de connectie naar een db denk ik sneller omdat je bij een applet steeds een nieuwe connectie moet maken per client, bij een servlet kan je 1 verbinding openhouden. Ik vind zelf applets vaak ook minder lekker navigeren: reageerd minder snel, geen gebruik backbuttons, AWT is niet fantastisch en anders moeten je klanten een flinke JRE downloaden. Ik zou dus voor een servlet gaan, of eventueel een (webstart)applicatie, dat werkt voor de klant wel erg prettig.