4.2 Server Pages

Web Application Server
Prof. dr. Herwig Mannaert
1
2
3
Inleiding ......................................................................................................... 2
Interactiviteit .................................................................................................. 3
Cruciale problemen .......................................................................................... 3
3.1 Proces per Verzoek ..................................................................................... 3
3.2 Geen toestandsbeheer ................................................................................ 4
3.3 Geen software structuur .............................................................................. 4
3.3.1 Tussen logische lagen ............................................................................ 4
3.3.2 In de presentatielaag ............................................................................ 5
4 Standaard oplossingen ..................................................................................... 5
4.1 APIs - Servlets ........................................................................................... 5
4.2 Server Pages ............................................................................................. 5
4.3 Frameworks ............................................................................................... 6
5 Een totaaloplossing .......................................................................................... 6
5.1 De applicatielaag ........................................................................................ 6
5.2 De presentatielaag ..................................................................................... 7
1
1 Inleiding
De bekende Internet goeroe Simon Phipps stelt: “The web works because shared
standards make grow the value faster than the costs”. Phipps bedoelt hier dat de
doorbraak van het Internet niet gebaseerd is op een revolutionaire nieuwe technologie,
maar op de immense schaalvoordelen die zijn ontstaan door de wereldwijde verspreiding
van een aantal open standaarden. De verspreiding van het Internet en de hierop
gebaseerde standaarden betekent immers dat wanneer iemand hierop aansluit, hij of zij
onmiddellijk kan communiceren met iedereen die van deze gemeenschap deel uitmaakt.
En iedereen die op dit open platform is aangesloten kan op zijn beurt automatisch
communiceren met iemand die nieuw toetreedt.
Volgens Phipps moeten deze wereldwijde informatie- en communicatiestandaarden op
vijf verschillende vlakken beschouwd worden. Alleen de aanwezigheid van open
standaarden op al deze vlakken kan het success van een universeel
communicatieplatform garanderen. Deze vijf deelgebieden, schematisch voorgesteld in
figuur 1 met de overeenkomstige standaarden, zijn:
1. Netwerkprotocols:
computernetwerken
moeten
op
basis
van
een
gemeenschappelijk protocol communiceren, wat op het Internet TCP/IP
(Transport Control Protocol / Internet Protocol) is.
2. Gegevensformaten: gegevens moeten in een voor iedereen leesbaar formaat
worden uitgewisseld, wat op het Internet XML (eXtensible Markup Language) aan
het worden is.
3. Software objecten: software objecten of modules moeten vrij uitwisselbaar zijn en
met elkaar kunnen communiceren, wat in het algemeen wordt verzekerd door een
componentenmodel, of in het bijzonder volgens Phipps door de programmeertaal
Java.
4. Toegangsplatform: een universeel beschikbaar platform wat toegang geeft tot de
verschillende informatie- en communicatiediensten, wat op het Internet het
WWW (World Wide Web) is.
5. Beveiligingsdiensten: gegevens en communicatiesessies moeten op uiterst
betrouwbare wijze beveiligd kunnen worden op basis van uitwisselbare
beveiligingsinfrastructuren, die men PKI (Public Key Infrastructure) is gaan
noemen.
PKI
Web
Comp, Java
XML
TCP/IP
Figuur 1: Voorstelling van de Internet standaarden volgens Simon Phipps.
In deze bijdrage wordt de aard en problematiek van het toegangsplatform of World
Wide Web uiteengezet, met inbegrip van conceptuele problemen en oplossingen.
2
2 Interactiviteit
In de meest eenvoudige communicatie tussen een browser en webserver wordt door de
browser een bestand gevraagd, die vervolgens door de webserver wordt teruggestuurd.
Om dit bestand te identificeren wordt gebruik gemaakt van een URL (Universal Resource
Locator) die als volgt gestructureerd is:
http://www.cnn.com/2003/TECH/biztech/02/24/microsoft.htm
protocol
domein naam
naam folder
bestand
Vandaag is het echter de bedoeling om vanuit het web interactieve toegang te
verschaffen tot alle mogelijke applicaties, en alle mogelijke applicaties te koppelen aan
het web: het web geeft toegang tot alles, alles heeft toegang via het web. Hiervoor dient
de webserver uitgebreid te worden tot een zogenaamde Web Application Server: een
koppeling tussen het web en back-end of legacy applicaties.
Om te kunnen interageren met logica aan de server zijde, wordt in de URL de naam van
een programma opgegeven, waarna de verschillende parameters met hun naam en
waarde volgen. Deze parameters zijn van elkaar gescheiden door een & teken. Een
voorbeeld van een dusdanig gestructureerde URL is:
http://www.amazon.com/cgi-bin/view-basket&name=mannaert&first=herwig&...
protocol
domein
folder applicatie
parameters
De historische manier om op basis hiervan logica aan de server op te roepen wordt
Common Gateway Interface (CGI) genoemd. Hierbij start de webserver een applicatie op,
die in een willekeurige taal kan geschreven zijn, en geeft de string van parameters mee
aan dit programma. Dit programma kan in gelijk welke programmeertaal worden
geschreven, maar werd historisch veel in Perl ontwikkeld omdat deze taal zeer geschikt is
om de string met de parameterwaarden te ontrafelen. Als antwoord stuurde het
applicatieprogramma een nieuw HTML bestand door naar de browser. Hij doet dit door
deze HTML te schrijven of printen op de standaard uitvoer. Het bestand is doorgaans
zeer analoog aan dat HTML bestand waaruit de oproep ontstond, mits invulling van de
gevraagde resultaten.
3 Cruciale problemen
3.1 Proces per Verzoek
In een Common Gateway Interface (CGI) web applicatie, start de web server een nieuw
proces voor elk verzoek of request dat binnenkomt vanuit een web browser. Dit betekent
dat er een nieuw proces wordt opgestart voor elke interactie van elke gebruiker of surfer:
niet alleen wanneer hij een product koopt, maar ook wanneer hij naar de prijs
informeert, wanneer hij naar de status van zijn winkelwagentje of shopping cart kijkt,
enz. Dit is vanuit computationeel standpunt onaanvaardbaar en zelfs ronduit belachelijk
te noemen.
3
3.2 Geen toestandsbeheer
Aangezien er bij elk verzoek een nieuw proces wordt opgestart, wordt er uiteraard ook
geen informatie bijgehouden over de toestand van een bepaalde gebruiker. Er is met
andere woorden geen state management, om tijdens een sessie op een website relevante
gegevens bij te houden. Hier denken we bijvoorbeeld aan de persoonlijke gegevens van
een klant of gebruiker, de toestand van zijn winkelwagentje, het volgnummer van de
getoonde mails bij een webmail applicatie, enz.
3.3 Geen software structuur
De applicatie aan de server zijde dient een volledig nieuw HTML blad te genereren bij elk
verzoek. Vooreerst genereert dit een overhead aan te verzenden informatie. Aangezien
vandaag vrijwel alle informatie voorzien wordt van meta-informatie en het hier niet om
grote hoeveelheden extra gegevens gaat, is dit geen onoverkomelijk probleem. Het feit
echter dat de grafische HTML output wordt geschreven vanuit applicatielogica maakt deel
uit van een veel groter en fundamenteler probleem. Het leidt tot ongestructureerde en
bijgevolg onbeheersbare software.
3.3.1 Tussen logische lagen
Tijdens de ontwikkeling van grote pakketten applicatiesoftware zoals ERP (Enterprise
Resource Planning) is men gaan inzien dat er verschillende conceptuele diensten zijn in
software (Presentatie – Applicatie - Databank), en dat men deze diensten conceptueel
moet scheiden in verschillende lagen of tiers. Dit wordt schematisch weergegeven in de
volgende tekening.
Toegang
Presentatie
Applicatie
Databank
Als je dit model op het web toepast, dan worden de presentatiediensten in de webserver
uitgevoerd, en is de browser of thin client een universeel toegangsplatform:
Browser
Webserver
Applicatie
4
Databank
Dit betekent dat, indien we vanuit de browser op gestructureerde wijze toegang willen
verschaffen tot bedrijfsapplicaties, we de volgende 4-lagige architectuur moeten
beschouwen:
Toegang
Presentatie
Applicatie
Databank
In de historische CGI applicaties was er geen onderscheid tussen presentatie- en
applicatielaag.
3.3.2 In de presentatielaag
De presentatielaag is wellicht de meest ingewikkelde. Hier hebben we immers niet alleen
te maken met logica, maar eveneens met grafische stijl, en met inhoud of content. Dit
zijn niet alleen drie fundamenteel verschillende zaken, ze worden bovendien doorgaans
uitgevoerd door verschillende personen met een zeer heterogeen profiel. Het is daarom
cruciaal om deze zaken op een conceptuele wijze te scheiden.
4 Standaard oplossingen
4.1 APIs - Servlets
Een eerste oplossing bestond erin om applicatielogica niet in een apart CGI programma
te plaatsen, maar ze als functies of modules te integreren in de webserver. Dit lost het
eerste probleem op van de enorme hoeveelheid processen, maar vereist wel een
gestandaardiseerde API (Application Programming Interface) waarmee de webserver de
functies of modules van de applicatieprogrammeur kan oproepen. Hiertoe werd door
Microsoft de ISAPI gedefinieerd en door Netscape de NSAPI of latere WAI (Web
Application Interface). Daarnaast is er de gekende Servlet API om Java modules te
integreren in een webserver, die dan Servlet container wordt genoemd.
Webservers die gebruikerscode bevatten worden in het algemeen containers genoemd.
Dergelijke webservers voorzien meestal ook in een oplossing voor het tweede probleem
of het toestandsbeheer. Zij zullen voor elke gebruiker een session id of identificatiecode
genereren die ze met de browser uitwisselen, en zullen vervolgens bepaalde informatie
voor elke gebruiker bewaren en deze ter beschikking stellen van de gebruikerscode.
4.2 Server Pages
De generatie van grafische uitvoer blijft in het geval van servlets nog steeds deel
uitmaken van de programmacode. Dit leidt tot ongestructureerde code en heeft
bovendien tot gevolg dat grafische vormgevers in programmeerbestanden moeten
5
duiken. Om dit te vermijden hebben verschillende software fabrikanten het principe van
server pages ontworpen. Bij server pages is het mogelijk voor de applicatieprogrammeur
om programmeercode te laten deel uitmaken van HTML pagina’s. Deze code wordt
vervolgens - indien nodig - intern verwerkt door de webserver of container. Varianten
hiervan zijn de Active Server Pages (ASP) van Microsoft op basis van VB Script, en de
Java Server Pages van Sun Microsystems op basis van Java.
Ofschoon dit het grote voordeel biedt dat de graficus niet meer in
programmeerbestanden moet duiken, biedt het geen oplossing voor het fundamentele
probleem van de vermenging van logica, inhoud, en stijl. En in dit geval moet de
programmeur nog steeds in grafische bestanden duiken.
4.3 Frameworks
Aangezien Server Pages bezwaarlijk echte applicatielogica kunnen bevatten, stellen
software bedrijven raamwerken of frameworks om grote applicaties te ontwikkelen. Het
gaat hier om zogenaamde componenten modellen, die beschrijven hoe applicaties in
verschillende componenten dienen te worden opgedeeld, en hoe deze componenten in
een globale infrastructuur kunnen worden ontplooid. De twee dominante raamwerken
voor web applicaties zijn J2EE (Java 2 Enterprise Edition) van Sun Microsystems en .Net
van Microsoft.
Het is belangrijk op te merken dat .Net een software product is van Microsoft, terwijl
J2EE een standaard is met implementaties in producten van verschillende software
bedrijven. Zo ontwikkelen bijvoorbeeld IBM, Sun, BEA, SAP, en Novell J2EE applicatie
servers of containers voor componenten van applicatieprogrammeurs
5 Een totaaloplossing
Omwille van het gestandaardiseerd karakter en de maturiteit van de technologie opteren
we voor het J2EE platform in onze totaaloplossing. Voor de presentatielaag volgen we het
J2EE platform slechts gedeeltelijk wegens de gebrekkige scheiding tussen inhoud, stijl,
en logica. Hier maken we gebruik van een XML (eXtensible Markup Language) raamwerk
of XML Publishing Framework.
5.1 De applicatielaag
Voor de applicatielaag of logica nemen we het EJB (Enterprise Java Beans) model, deel
van het J2EE platform. Dit platform, in meer diepgang uiteengezet in de nota over
Gedistribueerde Object Systemen, voorziet in twee soorten applicatiecomponenten:
entity beans en session beans. Het eerste type object komt overeen met
gestructureerde data en wordt verbonden aan een tabel in een databank, terwijl de
tweede soort objecten worden aangewend voor acties.
De applicatiecode of objecten wordt opgelopen in een EJB container, die een aantal
algemene aspecten zoals schaalbaarheid, betrouwbaarheid, en transactionele integriteit
voor zijn rekening neemt. Daarnaast verzorgt een dergelijke container ook het mappen
van objecten en attributen op tabellen en velden in de databank. En indien aldus
geconfigureerd, kan de container ook de persistentie van de verschillende datastructuren
voor zijn rekening nemen.
6
5.2 De presentatielaag
Voor de presentatielaag maken we gebruik van een J2EE servlet container, en van het
Open Source XML publicatieraamwerk Cocoon. De reden hiervoor is dat Cocoon vandaag
wellicht de meest gestructureerde en geavanceerde scheiding biedt tussen inhoud, stijl,
en logica voor webapplicaties. Hiertoe maakt het gebruik van een structurele
ontkoppeling, schematisch voorgesteld in de volgende figuur.
Management
Inhoud
Logica
Stijl
Hierbij valt onmiddellijk op dat er vijf verschillende structurele interfaces voorzien zijn
tussen de verschillende componenten. Cocoon is geïmplementeerd als een servlet, en het
globale raamwerk waarin de gebruikerscode wordt opgenomen is voorgesteld in de
volgende figuur.
Ingaande logica
Output generatie
Inhoud
Uitgaande logica
xml
x
xsl
Interface logica
Verzoek doorgave
xml
Stijl
x
xsl
html
De inhoud of content van de website of applicatie wordt voorgesteld in XML bestanden,
terwijl de stijl dient te worden ondergebracht in XSL (eXtensible Style Language). Op
deze wijze wordt de eigenlijke grafische uitvoer gegenereerd door XSLT (eXtensible Style
Language Transformations) transformaties. Dit houdt een complete ontkoppeling van
inhoud en stijl in.
Voor de gebruikerslogica maakt Cocoon een vrij fundamenteel onderscheid tussen
ingaande en uitgaande logica in de levenscyclus van een verzoek over het web. De
Cocoon servlet zal het verzoek doorgeven aan de ingaande logica. Hierbij zal hij de
verschillende parameters formatteren, en eveneens de informatie van de
7
gebruikerssessie ter beschikking stellen. De ingaande logica kan nu – mits eventuele
interface logica in de presentatielaag – interageren met de applicatielaag en de
databank. Op basis van resultaten tijdens deze verwerkingsstap kan hij de Cocoon
servlet echter instructies geven wanneer deze met zijn generatie van de uitvoer begint.
Zo kan de ingaande logica bijvoorbeeld bepalen van welk XML inhoudsbestand moet
worden vertrokken en van welk XSL bestand dient gebruik gemaakt te worden voor de
transformatie. Maar hij kan ook informatie opslaan via het sessiebeheer van de Cocoon
servlet en de servlet container.
Tijdens de generatie van de uitvoer wordt een XSLT transformatie uitgevoerd op basis
van een stijlbestand, maar kan via een analoge transformatie kan gebruik gemaakt
worden van de uitgaande logica. Deze wordt gegroepeerd in logische bestanden of XSL
logicsheets, en via XML tags opgeroepen. De uitgaande logica dient om informatie te
verzamelen die in de uitvoerpagina moet worden weergegeven. Hij kan hiervoor –
eventueel via interface logica – een beroep doen op de applicatielaag, maar kan via het
sessiebeheer van Cocoon en de container ook beroep doen op informatie die is verzameld
door de ingaande logica.
8