JSP -hvad er det?
I juni 99 lancerede Sun Microsystems Java Server Pages (også kaldet JSP), som er indlejret Java-kode i HTML-dokumenter, ligesom det kendes fra Microsofts ASP-teknologi og PHP i Open Source/Unix-miljøet. Java havde i forvejen en glimrende placering i form af servlets, som er Java-programmer til servere.
Men det er ikke så smart, som det lyder. Problemet med at skrive binære programmer til brug i webservere er, at programmets output er HTML - og en stor del af HTML-koden er jo design og formattering. Hver gang, sidens design skal ændres, skal der rettes i koden, og programmet skal kompileres om. Det er selvfølgelig ikke særlig hensigtsmæssigt, da design og funktionalitet ikke har noget med hinanden at gøre.
Samtidig viste scripting-sprogene sig at være rigtig populære blandt udviklere, da de er nemme at skrive og vedligeholde, og tillige med at ydelsen for scripts blev forbedret. Microsoft byggede ASP ind i sin IIS-webserver, og Apache fik sig en perlfortolker indbygget med modulet mod_perl. Før disse muligheder var til rådighed, måtte udvikleren benytte CGI som bindeled mellem server og fortolker, og alt i alt gav det en temmelig dårlig ydelse.
Sun, der gerne ser Java bygget ind i alt der kan håndtere bits, ville ikke stå tilbage for nogen, og firmaet introducerede i juni 99 Java Server Pages (JSP) for omverdenen.
JSP ligner umiddelbart de andre websprog - her udskrives tallet 10 og strengen "Hallo":
<HTML>
<BODY>
<% int i = 10; %>
<%= i %>
<P>
<B><%= "Hallo" %></B>
</BODY>
</HTML>
Overfladisk set ligner JSP altså de andre scripting-sprog, men dets sigte og anvendelse er ikke helt som de andre. Hvor ASP og i særdeleshed PHP lægger op til at bygge funktionaliteten direkte i scriptet, fungerer JSP mere som en slags front-end for de servlets og JavaBeans, der så indeholder funktionaliteten. Der kan selvfølgelig siges både pro et contra om begge muligheder.
Scripts contra objekter
Scripts contra objekter
Ved at indbygge logikken ind i scripts, har man et meget fleksibelt miljø. Man kan hurtigt tilføje funktionalitet og lave ændringer, men til gengæld mister man hurtigt overblikket, og det kan blive svært at identificere problemer. Dette forstærkes yderligere af, at større applikationer ender med at sprede sig over mange scripts. Hvert enkelt script dækker så en del af de features, brugeren har, men opdelingen sker udfra et grænseflade-perspektiv, og det er ikke nogen god måde at programmere på.
Omvendt giver det nogle indlysende fordele at bygge funktionaliteten ind i binære moduler, om det så er JavaBeans, COM, CORBA-objekter eller moduler som i Apache. Man kan programmere på en fornuftig facon, og frem for alt får man gemt koden af vejen, så man ikke fristes til at lave hovsa-løsninger.
Man kan altså sige, at i systemer med en stor kompleksitetsgrad, for eksempel systemer der kræver transaktionsstyring, kan det være en rigtig god ide at bygge funktionaliteten ind i en sort kasse, der kan have sit eget stille liv.
Objekter i HTML'en
Problemet med objekter
Der nævnes ofte to problemer ved at benytte en objektorienteret tilgang i webverdenen. For det første er webbet af natur tilstandsløst. Det gør, at tilstandene, for eksempel at identificere en bruger igennem en succesiv række af forespørgsler (en session), skal bæres "ved siden af", hvor Java-objekter i modsætning hertil altid selv er bærere af deres tilstand.
I JSP skal sessioner håndteres ved et session-objekt, og det giver altså en lidt uvant konstruktion, da session-objektet lever ved siden af alle andre objekter - og ikke hænger sammen med dem.
Det andet problem er simpelt hen, at Java er et meget abstrakt sprog, hvilket gør, at der tilsyneladende skal skrives en masse kode for at producere en lille smule. Java-programmørerne kan fortælle os, at det senere hen giver os en meget velstruktureret kode, men de kodestumper, der indlejres, er jo som regel småtterier, da hovedparten af logikken er placeret i en servlet, og da kan Java virke lidt tungt.
Hertil har Sun fundet på, at lave en række tags, der tager sig af ofte udførte opgaver. Problemet er her, at udvikleren også skal have styr på disse tags ud over Java og de JSP-specifikke objekter. Det smarte er, at det giver en nem måde at hente og sætte værdier, for eksempel fra en JavaBean:
<jsp:setProperty id="localName" property="serialNumber" value="string" />
Som en sidste ting kan det nævnes, at Java ikke er noget nemt sprog at lære - slet ikke i sammenligning med VBScript, JScript/Javascript, PHP og Perl, som er de foretrukne sprog i scripting-miljøerne. Til gengæld kan man en masse andre ting med Java end bare JSP, når man først har lært det.
Kvaliteterne i JSP
Der kan retfærdigvis også siges mange gode ting om JSP. For det første er der de førnævnte fordele ved at indkapsle logik, som udviklere i Microsoft-miljøer også kan opnå med COM-objekter. Udover det kan der nævnes de almene egenskaber for Java:
Blandt de store firmaer, der godt kan lide Java, finder vi IBM, og det er jo ikke så mærkeligt, da firmaet producerer en mængde forskellige operativsystemer. Ved store, dyre udviklingsprojekter er der altså en klar pointe i portabilitet.
Relevant link:
CNet: Intro to JavaServer Pages
