Follow Us on Twitter

JDeveloper for NewBees - deel 3

Het werken in een JSP architectuur
Gepubliceerd in

November 2002 - Er zijn een tweetal technologieën beschikbaar in web-enabled Java omgevingen ten behoeve van het opzetten van een zogenaamd "request handler en response mechanisme", dat immers noodzakelijk is om met Web pagina's om te gaan. De eerste (en oudste) technologie is Servlets - een Servlet is een Java programma dat wordt aangeroepen vanuit de Browser en dat dynamische content combineert met de statische layout. Om hier een alternatief voor te bieden kwam Sun later met de Java ServerPages (JSP) - een technologie  waarbij er wel een scheiding wordt gemaakt tussen de dynamische content en de statistische layout. Eigenlijk is JSP niets anders dan een layer bovenop Servlets, omdat de JSP omgezet wordt in een Servlet at runtime.

In dit Whitebook gaan onze Java experts in op het hoe en waarom van JSP's. 

Er zijn reeds een aantal Whitebooks verschenen over JDeveloper. Het eerste Whitebook ging in op de keuze voor JDeveloper. Klik hier om het eerste deel te lezen. Het tweede Whitebook ging in op Business Components for Java dat een belangrijke component voor JDeveloper is. Klik hier om het tweede deel te lezen. In het vierde en laatste deel van deze serie gaan we in op het STRUTS framework ter ondersteuning van complexe web-gorienteerde applicaties.

De JSP architectuur

JSP is een open standaard voor het gebruik van Java in HTML pagina's om dynamische content te verkrijgen. Wanneer een JSP pagina (te herkennen aan de .jsp extensie) wordt benaderd vanuit de browser zal de web server deze eerst in een Servlet compileren. Hierna wordt de JSP pagina opgeslagen in de cache zodat deze niet steeds gehercompileerd dient te worden voor (herhaald) gebruik. De transformatie van een JSP pagina in een generieke Servlet betekent dat praktisch alles wat een Servlet kan, ook in een JSP pagina mogelijk is, zoals sessie management, cookies en toegang tot databases. 

De Java implementatie in JSP pagina’s gebruikt voornamelijk JavaBeans. Een JavaBean is een Java component die gemaakt wordt met het doel de code in een JSP te vereenvoudigen. Een Bean kan bijvoorbeeld door een andere component gevuld worden met waarden, kan zelf waarden uit een database lezen of bepaalde (veelvoorkomende) bewerkingen uitvoeren.

Naast JavaBeans kunnen JSP pagina’s echter ook pure Java bevatten (zoals bijv. Visual Basic in ASP wordt gebruikt) door het gebruik van zogenaamde scriptlets (blokjes code) en expressies (tags genoemd die op runtime geëvalueerd worden). Tags worden op runtime vervangen door stukjes code die uitgevoerd worden, namelijk: tag libraries. Het voordeel van Taglibraries is dat ze nog makkelijker te hergebruiken zijn en eventuele HTML-designers nog transparanter Java-code op kunnen nemen (dus minder kennis nodig
hebben).

Servlets versus JSP

We willen de hoeveelheid hoeveelheid Java code (zowel directe code, JavaBeans als taglibraries) in onze JSP minimaliseren om een aantal redenen:

  • Scheiding tussen de  ontwikkeling van Java code en de ontwikkeling van HTML code: dit zijn immers twee verschillende expertises;
  • Java code niet dubbel opnemen in meerdere JSP's;
  • Zo min mogelijk Java code tonen in onze JSP pagina's.
  • Het behouden van een acceptabele performance.

Na het overbrengen van de Java code uit de JSP pagina naar andere Java componenten (classes) blijft de HTML code in de JSP pagina achter. Hierdoor kunnen de Java ontwikkelaars zich concentreren op de Java programmatuur terwijl de Website ontwikkelaars zich concentreren op de HTML code. Let er wel op dat een (te) strikte scheiding tussen de ontwikkeling van de Java code en de ontwikkeling van de HTML code kan resulteren in vertragingen en foutgevoeligheid van de applicatie omdat er dan immers met twee aparte teams gewerkt wordt.

We willen graag de Java code zoveel mogelijk op één plek hebben en niet dubbel opgenomen in meerdere JSP's. Met name code, die gebruikt wordt in meerdere aanroepen, zoals het valideren van iemands identiteit (authentication), kan goed overgebracht worden naar een andere Java component zoals een JavaBean, een taglibrary of een aparte class. Hierdoor bevindt de code maar op een plaats, de Servlet, in plaats van meerdere malen gekopieerd in meerdere JSP's.

JavaBeans kunnen gezien worden als de componenten die data verzamelen die getoond moet worden door een JSP. Elke JSP die generieke gegevens moet tonen kan dus een eigen Bean hebben. Deze opzet zorgt er tevens voor dat de afhandeling van de interface losgekoppeld wordt van data access en afhandeling van de business logica. Met deze opzet tekent zich al voorzichtig de contouren van een echte J2EE architectuur af...

JSP's worden naar Java Servlets geconverteerd. Om alle mogelijkheden beschikbaar te hebben in een JSP is de gegenereerde code altijd langer dan wanneer handmatig een Servlet geschreven zou worden. Overmatig gebruik van extra code , JavaBeans, maar vooral Taglibraries kan de hoeveelheid code en daarmee de uitvoertijd merkbaar doen toenemen.

Java heeft een aantal voordelen in zich die verloren gaan bij het gebruik van JSP's. Zo is een klasse hiërarchie en daarmee overerving niet mogelijk. Daarnaast wordt de JSP pas in runtime gecompileerd. Fouten komen daardoor erg laat naar voren en het debuggen wordt hierdoor een stukje lastiger.

Een 2-tal JSP methoden

Voordat we - in het volgende deel van deze Whitebook - ingaan op een aantal applicatie architecturen met Servlets en JSP's , gaan we nu eerst in op de twee basis methoden om met JSP's te werken. 

  • De eerste techniek wordt ook wel de page-centric (of Client-Server) methode genoemd. Bij deze techniek worden de Web requests direct aan de JSP pagina gedaan of aan een Servlet die zelf weer zorgt voor de opbouw van de volgende pagina.
  • Bij de tweede techniek wordt een N-tier methode gebruikt waarbij een basis Servlet zich opstelt als mediator of controller, die vervolgens alle requests doorgeeft aan de JSP pagina's en de JavaBeans.

De "Page-Centric" methode

We beginnen om in wat meer detail te kijken naar architecturen die gebaseerd zijn op de  page-centric of client-server methode. 

Applicaties die gebouwd zijn volgens de client-server methode bestaan al enige tijd; ze bestaan uit een of meer programma's die draaien op de clients, en maken vervolgens verbinding met een server-gebaseerde applicatie (een goed voorbeeld is een client/server Oracle Forms systeem). CGI's en pre-Servlet applicaties waren in het algemeen gebaseerd op dit eenvoudige 2-tier model, en met de introductie van Servlets konder 2- tier applicaties ook in Java gebouwd worden. Dit model staat JSPs of Servlets toe om direct toegang te verkrijgen tot bepaalde resources zoals een database of een 'legacy" applicatie. De eerste JSP specificaties noemden deze aanpak ook wel een "Model 1" programmerings methode.

De JSP pagina vangt het binnenkomende verzoek op, verwerkt het en zendt een antwoord terug naar de client. JSP's verschillen in dit scenario alleen hierin van Servlets door het scheiden van de code met de inhoud door gebruik te maken van data access Java beans. 

Het voordeel van deze aanpak is de eenvoudige programmering. Tevens kan de ontwikkelaar eenvoudige dynamische content genereren die gebaseerd is op de aanvraag van de client en de status van de resources. Deze architectuur is echter niet goed schaalbaar voor grote aantallen simultane gebruikers, doordat iedere client-vraag apart verwerkt wordt met een individuele (en kostbare) verbinding naar de data resources. Een goed voorbeeld zijn de JDBC connecties in Servlets of JSP's en de behoefte om deze connecties in een pool onder te brengen.

Het ondoordacht toepassen van deze architectuur kan al snel leiden tot grote hoeveelheden Java code in de JSP pagina. Dit is zowel een probleem voor de Java ontwikkelaars als voor de web pagina designer. Het is een probleem voor een Java ontwikkelaar, omdat hij niet meer met een echte Java class te maken heeft, maar met een gegenereerde class. Het is een issue voor de web pagina ontwerpers omdat er een kans bestaat dat zij de betreffende Java code beschadigen door het aanpassen van de pagina's. 

De "N-tier" methode

We gaan nu verder met het kijken naar architecturen die gebaseerd zijn op de 'N-tier' methode, waar een Servlet zich gedraagt als mediator of controller die de client verzoeken delegeert. Indien bepaalde acties zoals verwerking en opslag van data noodzakelijk is kan de controller hiervoor andere Servlets of classes aanroepen. Zo gauw de controller weer data terug moet geven, doet hij dit door een JSP aan te roepen. De Controller is daarmee tevens verantwoordelijk voor de volledige navigatie en flow van de applicatie.

In een N-tier applicatie is de serverkant van de architectuur opgesplitst in meerdere tiers. In dit geval bestaat de applicatie uit meerdere tiers, waar de Controller de koppeling vormt tussen de back-end resources en de JSP's die het opbouwen van de interface verzorgen naar de front-end. De EJB's zijn een representatie van de data en zijn dus verantwoordelijk voor de toegang tot de data resources. Hiermee wordt een oplossing geboden voor de performance problemen en het delen van de resources in de 2-tier methode. Dit programmering model is onderdeel van het Java 2 Enterprise Edition (J2EE) platform.

  1. De eerste stap in het ontwerpen van N-tier applicaties is het identificeren van de benodigde objecten en hun interacties, in andere woorden: object modeling. Hiervoor worden door Java architecten class diagrams en tools zoals Rational Rose (http://www.rational.com) gebruikt. Veelal dient een duidelijke keuze gemaakt te worden met betrekking tot welke objecten nu wel en niet gemodelleerd dienen te worden. Het modelleren en bouwen van te weinig objecten levert objecten die te groot, te complex en niet eenduidig zijn.\
  2. De tweede stap is het invullen van de controller met de bijbehorende navigatie, flow en acties (verwerking en database-afhandeling, etc). 
  3. De derde stap is het identificeren van de JSP's of Servlets. Deze componenten worden ook wel "web components" genoemd, omdat zij de daadwerkelijk schermen en interacties representeren die over het web aan de gebruiker worden gepresenteerd.
  4. Bovenstaande twee categorieën komen overeen met het Model-View design patroon, waar de back-end component model is ofwel de business logica ofwel de EJB's. Front-end is de view ofwel de JSP's. Deze aanpak wordt het "Model 2" programmering model genoemd in een vroege release van de JSP specificaties. Het verschil tussen Model 1 en Model 2 ligt in de locatie waar het merendeel van de client verzoeken wordt afgehandeld. 

In een webomgeving wordt altijd gesproken over MVC Model View Controller model, omdat een Controller noodzakelijk is voor de algehele flow van de applicatie. Zelfs bij eenvoudige applicaties levert het weglaten van een Controller extra werk op.

Wordt vervolgd...

Volgende maand - in het vierde en laatste deel van deze serie - gaan we nog wat dieper in op de JSP architecturen en beschrijven het STRUTS framework. Dit framework is een goed hulpmiddel bij het ontwerp en bouw van complexe JSP applicaties.

Waardering:
 

Reacties

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.

Meer informatie over formaatmogelijkheden

CAPTCHA
Deze vraag is om te testen of u een persoon bent en om spam te voorkomen
Image CAPTCHA
Enter the characters shown in the image.