Hoe krijgt een applet gegevens in een database op de webserver?
Deze vraag lijkt op de vraag van een aantal weken geleden:
Hoe krijgt een Java applet gegevens uit een database op de server?
Een webserver kan parameters genereren naar de applet.
Maar hoe krijgt een applet gegevens terug?
SQL zou ook hier het makkelijkst zijn, maar er is een aantal dipjes.
- Security
- Voor een connectie naar een database zijn een user id en password nodig, ook in een applet.
Dat user ID en password zouden het liefst veilig op de server moeten blijven.
- Onafhankelijke 3 lagen
- Een Java applet is meestal een thick client, een combinatie van
GUI- en
business objecten laag.
SQL code hoort thuis in de data laag.
De objecten laag moet met die database laag interfacen,
ook al staat die remote op de webserver.
Geachte mevrouw S.Q.L. Database,
Hier wat een post voor u:
.
Wilt u de inhoud netjes opbergen?
En schrijft u ook nog iets terug?
|
Het mooiste zou zijn als de applet compleet los staat van de database, slechts een berichtje opstuurt.
De programmatuur op de server kan dan veilig een connectie met de database maken en wat SQL slaken
(zie PHP voorbeeld).
Oplossing 1: parameters in een URL
private void showDocument()
throws MalformedURLException
{ URL url;
url = this.getCodeBase();
url = new URL(url + "index.php?msg=hello&to=world");
// ask browser to exit applet and show page
this.getAppletContext().showDocument(url);
}
|
Een applet kan een URL oproepen
(developer.irt.org/...),
alsof de gebruiker op een HTML linkje geklikt heeft.
In een URL kunnen parameters zitten
voor het programma op de server.
Aardig, maar:
- Een URL heeft een beperkte lengte, wat die ook zijn mag
(faqts.com/knowledge_base/...).
Die beperking kan problemen geven bij een paar honderd parameters.
- Een ander nadeel: Parameters in een URL zijn zichtbaar.
De gebruiker kan de URL, inclusief parameters, bookmarken.
Dat zal een ongewenste herhaling van processing geven bij het opnieuw oproepen van die pagina.
Oplossing 2: POST
Kan een applet ook variabelen POSTen?
Jawel.
Geen ellende met userid's en passwords, parameters verborgen, de 3 lagen netjes gescheiden.
Prachtig, prachtig, prachtig.
Een stukje Java code op
forums.java.sun.com/...
biedt hoop met een HttpURLConnection.
Op runtime knalt de applet er met een ClassCastException uit, in het statement:
HttpURLConnection http = (HttpURLConnection)url.openConnection();
Grr, er blijken hinderlijke verschillen te zitten in de JVM's van de verschillende browsers.
De ene HttpURLConnection is de andere niet.
Na een beetje puzzelen, trial en error, lukt het om de boel aan de praat te krijgen.
De java code hieronder post variabelen naar een PHP script op de webserver.
private Vector postResult()
throws MalformedURLException, IOException
{ URL url;
URLConnection con;
OutputStream oStream;
String parametersAsString;
byte[] parameterAsBytes;
String aLine; // only if reading response
parametersAsString = "msg=hello&to=world";
parameterAsBytes = parametersAsString.getBytes();
// send parameters to server
url = this.getCodeBase();
url = new URL(url + "index.php");
con = url.openConnection();
con.setDoOutput(true);
// setDoInput(true); // only if reading response
con.setDoInput(false);
con.setRequestProperty("Content=length", String.valueOf(parameterAsBytes.length));
oStream = con.getOutputStream();
oStream.write(parameterAsBytes);
oStream.flush();
oStream.close();
}
|
Geachte meneer J. Applet,
Uw bericht ontvangen.
Inhoud goed opgeborgen.
|
De server genereert een response, regels met tekst.
De applet kan die gegenereerde response inlezen.
Het voorbeeld hieronder toont de server response op het Java console.
Dit stukje java code komt tussen de oStream.flush() en de oStream.close().
oStream.flush();
// read response from server
BufferedReader in = new BufferedReader(new InputStreamReader(con.getInputStream()));
aLine = in.readLine();
while (aLine != null)
{ System.out.println(line);
aLine = in.readLine();
}
in.close();
oStream.close();
|
Dit werkt.
Mooi, ik ben tevreden.
Java applet en server applicatie aan de babbel:
- zonder geklooi met geheime passwords,
- en met een nette scheiding tussen de objecten- en database laag.
Tot de volgende week,
Henk Jan Nootenboom
|