Technológiák
integrációja a Digitalcity portálon
A Debreceni Egyetem Matematikai és Informatikai
Intézete az elmúlt évek során többször vett részt az OMFB által meghirdetett
pályázaton. Az egyik pályázat olyan alkalmazás elkészítését tűzte ki
célul, amely lehetővé teszi a legszélesebb körű
információszolgáltatást. A pályázatot a Matematikai és Informatikai Intézet
nyerte el. Az induló projekt keretein belül jött létre a Digitalcity
webalkalmazás.
A rendszer jelenlegi formáját több éves fejlesztés alatt érte el.
Időközben túlléptünk a kezdeti célokon, és mára egy komplex webalkalmazást
sikerült létrehozni. A fejlesztés során megismerkedtünk néhány eszközzel és
technológiával, melyeket előadásomban szeretnék áttekinteni, és egy átfogó
képet festeni a projektről.
Az Internet óriási léptékű fejlődése és elterjedése miatt
egyre több információ található meg rajta. Ma már egy magára valamit adó
kisvállalkozás sem engedheti meg magának, hogy információi ne legyenek
elérhetőek az Interneten keresztül. Ez azonban nem kevés költséget ró
rájuk: hardver- és szoftverköltségek, és egy (vagy több) informatikus
szakember, aki biztosítani tudja a rendszer működését. Ezeket a
költségeket egy kisvállalkozás nem minden esetben engedheti meg magának.
A Digitalcity alapvető célkitűzése, hogy a társadalom
széleskörű információs igényeit kielégítse. Lehetővé teszi
magánszemélyek, cégek, közösségek, intézmények – vagyis mindenki – számára,
hogy magukról információt juttassanak el partnereikhez. A portálon bárki
megjelenhet, ehhez mindössze regisztráltatnia kell magát a portál
üzemeltetőjével. A regisztráció után az ügyfél megszerkesztheti saját
információit. Igen, megszerkesztheti, ugyanis a regisztrációval jogosulttá
válik az interaktív szerkesztőprogram használatára. (A szerkesztés
ugyanakkor kötelességévé is válik, mert a szerkesztést senki más nem fogja
elvégezni helyette.) A szerkesztőprogram használata egyszerű, könnyen
elsajátítható, és nem igényli a fejlesztők közreműködését.
Segítségével önállóan végezhető el a tartalom összeállítása, és az arculat
megtervezése.
Ezen a ponton válik érthetővé, hogy a Digitalcity miért több mint
egy egyszerű portál, és miért beszélek róla úgy, mint egy alkalmazásról.
Újdonság csak a kezelőfelületben van. A használatához egy böngészőn
kívül semmi másra nincs szükség, és éppen ebből származik előnye a
hagyományos alkalmazásokkal szemben. A világon bárhol használható, ahol
számítógép és Internet-elérés rendelkezésre áll.
A Digitalcity tulajdonképpen nem egyszerű portál, hanem egy olyan
webalkalmazás, amely számos portál kezelését teszi lehetővé, melyek közös
alapra épülnek. A portálok domain-ek alá vannak rendezve. A böngészőbe egy
domain címét írva (mint például a www.digitalcity.hu) megkapjuk az adott
domain-hez tartozó portálok listáját. Emellett láthatjuk azokat a híreket, fontos
eseményeket, amelyek a domain-hez tartoznak. A portállistából választva
beléphetünk egy portál nyitó oldalára. Ezzel egyben egy nyelvet is ki kell
választanunk. Ezután az adott portálon minden információ az adott nyelven
jelenik meg.
Lehetőség van egy portálra való közvetlen belépésre is, csak a
megfelelő címet kell a böngészőnknek megadni
(hajduszoboszlo.digitalcity.hu). Itt már csak az adott portálhoz tartozó
információkat láthatjuk.
Egy portálon sokféle információ megjeleníthető. A portál
szereplői (egyedek és objektumok) természetesen szeretnék bemutatni saját
magukat, amely általában statikus információt jelent (nem változik, vagy csak
ritkán). Ezt hívjuk mi bemutatónak. További nagyon fontos információt az
események jelentenek. Ezen kívül találhatunk híreket is. Az információ
sokszínűsége miatt további rendszerezésre van szükség, melynek
lehetőségei a következők.
Az egyedek, objektumok, események és hírek menübe szervezettek.
A menükapcsolatokat a regisztráció során kell megadni. Egy információ több
menüponthoz is köthető. A felhasználó többek között ezen menükapcsolatok
segítségével érheti el egy egyed információit, akár több irányból is. A
menürendszer egy tematikus, logikai kapcsolaton alapuló osztályozást valósít
meg.
A következő rendszerezési lehetőség a katalógus. Egy
egyed – a menühöz hasonlóan – szintén több katalógus-kategóriához
hozzákapcsolható. A katalógus általában valamilyen tevékenységi kör szerinti
rendszerezést jelent.
A harmadik lehetőség a térkép használata, ahol a keresés
alapja a hely. Ha egy bizonyos területen található egyedek érdekelnek, vagy a
közelünkben rendezett események között szeretnénk válogatni, akkor erre
kézenfekvő megoldást ad a térkép. Ez teljesen digitális formában tárolja
az adatokat, és korlátozás nélkül nagyítható, kicsinyíthető, vagy a
szélrózsa bármelyik irányába eltolható. A térképen megjelenő kis ikonokra
kattintva azonnal elérhetők azok az információk, amikhez egyébként a
menürendszeren kellene végignavigálni.
A térkép információi bizonyos tematikákba vannak besorolva. Ugyanazon
tematikába tartozó információk a térkép egy rétegében jelennek meg. Ezek a
rétegek ki- vagy bekapcsolhatók annak megfelelően, hogy milyen
információra vagyunk kíváncsiak.
A térkép akkor is elérhető, ha egy információhoz a menün keresztül
jutunk hozzá. Az átjárás mindkét irányban biztosított, amennyiben egy
információhoz tartoznak földrajzi koordináták.
A Digitalcity biztos alapokon nyugszik. A megfelelő
teljesítményről egy IBM AS/400 820 típusú középkategóriás szerver
gondoskodik. A szerverben két processzor található, így valódi párhuzamos
programvégrehajtásra képes. Fizikai memóriája 1 GB, melyet a két processzor
közösen használ. Hat darab 17,5 GB-os merevlemeze van, melyek a kellő
sebességet és hibatűrést a RAID technika 5-ös szintjével érik el. Egy
merevlemez kiesése esetén a teljesítmény romlik, ám az adatok hiánytalanul
visszaállíthatók a többi merevlemezről.
A gépbe maximálisan 16 Netfinity processzorkártya helyezhető. Ezek
a kártyák önálló számítógépet jelentenek az AS/400-on belül, és külön operációs
rendszerrel rendelkeznek. A kártyákra Windows vagy akár Linux is
telepíthető, melyek erőforrásaikat az AS/400-tól kapják.
Az AS/400 operációs rendszere az OS/400, mely kifejezetten az AS/400-ra
van tervezve és optimalizálva. Állományrendszere az ún. integrált
állományrendszer, amely tetszőleges állományrendszer kialakítását
lehetővé teszi, akár egymás mellett is. Az OS/400 kezeli az összetett
állományszerkezeteket is, mint amilyen az indexelt állomány. Az ilyen
mértékű optimalizálást a tervezett felhasználási terület magyarázza. Az
AS/400-at elsősorban adatbázisszervernek ajánlják, ám emellett a
webszerver és az alkalmazásszerver feladatát is gond nélkül el tudja látni. Az
állománykezelés ilyen mértékű támogatása és operációs rendszerbe
integrálása tökéletes egy adatbázis-kezelő rendszernek.
A hardver ismertetése után következzen most a fejlesztéshez használt
eszközök bemutatása. Ezekre is jellemző az a nagyfokú integráltság, amit az
előzőekben a szerverrel és a rajta futó operációs rendszerrel
kapcsolatban megismertünk.
Az operációs rendszerrel
szorosan összekapcsolódik a DB2 adatbázis-kezelő rendszer. Nagyban épít az
operációs rendszer nyújtotta állománykezelésre, és a lekérdezések nagyon gyors
végrehajtását teszi lehetővé. Saját nyelve van, mellyel tárolt eljárások
készíthetők. A nyelv leginkább az Oracle PL/SQL nyelvére hasonlít, ám
ez nem meglepő, hiszen ugyanarra a célra találták ki mindkettőt.
Ez egy Windows környezetben futó programcsomag, amelynek segítségével
az AS/400 menedzselésével kapcsolatos feladatok elvégezhetők.
Lehetőség van feladatok (job-ok) konfigurálására, vagy akár az
adatbázis-kezelési feladatok – mint a táblák, nézetek, indexek létrehozása vagy
törlése és lekérdezések végrehajtása – elvégzésére is. Mindezt a megszokott
grafikus felületen keresztül végezhetjük el, mivel a program Windows platformon
működik.
Az IBM saját fejlesztésű makrónyelve a Net.Data. Ezzel a nyelvvel
dinamikusan állíthatók elő HTML oldalak. A webszerver megfelelő
konfigurálása esetén a Net.Data nyelven írt makrókat ez a szerverprogram
dolgozza fel, majd továbbítja az eredményt a webszervernek. Számunkra azért
fontos ennek a bemutatása, mert a Digitalcity alkalmazás egyik része Net.Data
nyelven íródott.
A Net.Data nyelv az IBM korábbi technológiáinak egyik képviselője,
így túl sok támogatás (IDE vagy szövegszerkesztő) nem jár hozzá.
Ez, mint a neve is mutatja, egy alkalmazásszerver. Funkciójában a
Net.Data makrófeldolgozóhoz hasonlít, ám újabb attól. Segítségével Java nyelven
írt szerveroldali alkalmazások futtathatók. A Digitalcity másik része ezen
alkalmazásszerver felügyelete alatt működik.
A Studio kifejezetten internetes alkalmazások készítésére fejlesztett,
integrált fejlesztőeszköz, vagy inkább fejlesztőeszköz-készlet. A
grafikusok és a programozók munkáját egyaránt támogatja. Munkánk során
projekteket hozhatunk létre. A projekt komponenseit mindenki látja és
szerkesztheti, ám egymás munkáját nem zavarhatják. Erről a Studio
beépített zárolási mechanizmusa gondoskodik. Egy komponens állapotát
(szerkesztés alatt, új komponens, publikált komponens, stb.) ikonokkal jelzi.
Főbb részei a következők:
–
Munkaterület (Workbench): a projekt állományainak szervezését,
kezelését teszi lehetővé. Segítségével lehetséges a projekt publikálása
egy vagy több szerverre. A fejlesztés menetének megfelelően több
publikálási szint hozható létre. A legtipikusabb felhasználási lehetőség a
fejlesztési, tesztelési fázis és az éles üzemeltetésnek megfelelő fázis
létrehozása.
–
Page Designer: fejlett HTML- és JSP-szerkesztő program. Az oldalak
WYSIWYG módban és forráskód szintjén is szerkeszthetők. A grafikák
elkészítéséhez külön modult biztosít.
–
különféle varázslók: JavaBean, Database és SQL varázsló teszi
lehetővé lekérdezések, majd azokból további Java komponensek létrehozását
néhány egérkattintással.
Java programok és egyéb Java komponensek készítésére alkalmas integrált
fejlesztői környezet (IDE). Ma már teljesen természetes, hogy az IDE-k
színekkel segítik a szintaktikai elemek kiemelését (syntax highlighting), és
egyre több környezet rendelkezik kód-kiegészítési képességekkel (code-insight).
Ezen kívül a forráskód formázására is képes (többféle kódolási stílus szerint),
ám a többi IDE közül más tulajdonságok emelik ki:
–
adattárház (repository)
A forrásokat és a
lefordított bájtkódot itt tárolja. Az IDE-n kívülről nem is lehet ezekhez
hozzáférni. A szerkesztőprogram egyszerre csak egy metódust enged
szerkeszteni, majd a mentés után egyből fordítja is (inkrementális
programfordítás).
–
csapatmunka-támogatás
Az adattárház lehet közös.
Egyszerre több fejlesztő dolgozhat ugyanazon a projekten, ám a projektet
csak egy helyen kell karbantartani. A projekt egyes részeinek megosztását
ugyanolyan zárolási technikával biztosítja, mint a WebSphere Studio.
–
verziókövetés
A VisualAge for Java
beépített verziókövető rendszert is tartalmaz. Használatához semmiféle
konfigurálásra nincs szükség. A fejlesztés során bármikor visszatérhetünk egy
osztály, vagy akár csak egy metódus korábbi változatához.
–
WebSphere Test Environment
A fejlesztőeszközhöz
járó kiegészítés, mellyel servletek és JSP oldalak tesztelhetők.
Tulajdonképpen egy beépített alkalmazásszerverről van szó, amely
ugyanazokat a feladatokat látja el, mint a WebSphere Application Server.
–
External Tools/400 (ET/400)
A VisualAge fel van készítve
az AS/400-ra való közvetlen fejlesztésre. Az ET/400 kiegészítés segítségével
Java osztályainkat bármikor exportálhatjuk AS/400 számítógépünkre, futtathatjuk
programjainkat, és hibakereső is rendelkezésre áll. Mindezt anélkül
tehetjük meg, hogy VisualAge környezetet egyetlen percre is elhagynánk.
A technológiai integráció az eszközök szintjén jelentkezik
először. Az utóbbi három eszköz – WebSphere Application Server, WebSphere
Studio és VisualAge for Java – nagymértékű integráltsága figyelhető
meg. Az utóbbi két eszköz közvetlenül kommunikálva tud egymással Java
forráskódot és bájtkódot cserélni. A kommunikáció bármelyik eszközből
kezdeményezhető.
Szoros a VisualAge és a WebSphere Application Server közötti kapcsolat
is. A VisualAge olyan környezetet biztosít a servletek és JSP lapok
futtatásához, ami specifikációiban megegyezik az alkalmazásszerverrel. A
VisualAge-ben fejlesztett és tesztelt Java komponensek változtatás nélkül
futtathatók az alkalmazásszerveren.
A WebSphere Application Server és a WebSphere Studio is közel áll
egymáshoz. A Studio-ban létrehozott és karbantartott projektek könnyedén
telepíthetők (publikálhatók) az alkalmazásszerverre. Egy telepítési szint
több szervert is tartalmazhat, melyek között a projekt részei szabadon
szétoszthatók.
A Net.Data az egyik eszköz, amivel HTML oldalainkat
dinamikusan tudjuk előállítani. A Digitalcity egyik nagyon fontos része, a
szerkesztőprogram Net.Data makrókból épül fel.
Egy makróban – hasonlóan a többi programozási nyelvhez – használhatunk
változókat, elhelyezhetünk vezérlési szerkezeteket és függvényhívásokat. Egy
makró olyan szövegfájl, ami HTML tag-eken és Javascript kódon kívül
tartalmazhat SQL (vagy más) nyelvű függvényeket, és természetesen Net.Data
nyelvi elemeket.
A webszerver CGI alkalmazásként futtatja a Net.Data makrófeldolgozót,
ha azt érzékeli, hogy a kért URL egy makróra mutat. Ez interpreterként
működik, vagyis soronként értelmezi a makróban található utasításokat,
generálja az oldalt, majd az eredményt visszaadja a webszervernek.
Egy makró egyszerű szöveges állomány, amely Net.Data nyelvi
szerkezetek sorozatából áll. Két nagy része van: a deklarációs rész változók és
függvények definícióját tartalmazza, a prezentációs rész HTML blokkokból állhat,
amelyek meghatározzák a weboldal kinézetét. Ebben a részben felhasználhatjuk a
deklarációs részben definiált elemeket. A részek tetszőleges sorrendben
követhetik egymást, és többször is szerepelhetnek.
Az itt használható két legfontosabb elem a DEFINE blokk és az alprogramdefiníció. Ezen kívül tartalmazhat IF
és MESSAGE blokkot, valamint EXEC és INCLUDE utasításokat. A következőkben néhány példa látható:
–
DEFINE utasítás vagy blokk: változók definiálására szolgál
%DEFINE nls_hu_hti = "1"
%DEFINE {
NLS_ESEMENY_LEIRASA = "Esemény leírása"
NLS_KEZDETE = "Kezdete"
NLS_VEGE = "Vége"
%}
A definiált változókra $(változónév) alakban lehet hivatkozni.
–
FUNCTION blokk: olyan alprogram definiálható vele, amely
később hívható egy makróban, de a feldolgozást nem a Net.Data végzi el,
hanem valamilyen nyelvi környezet, amit a FUNCTION kulcsszó után kell
megadni. Így lehet például adatbázis-lekérdezéseket végrehajtani.
%FUNCTION(DTW_SQL) egyed_kat(fmn, OUT table) {
SELECT KTG.KTGKEY, KTG.KTGNEV FROM
($(COLLECTION)T_KTG KTG
JOIN
$(COLLECTION)T_FKK FKK
ON KTG.KTGKEY = FKK.KTGKEY)
WHERE FKK.FMNKEY = '$(fmn)'
ORDER BY KTGNEV
%MESSAGE {
100 : "" : continue
%}
%}
Az előbbi példában egy eljárás látható.
Definiálhatók függvények is, amelyek visszatérési értékkel rendelkeznek. Ezek
megadási módja megegyezik az előbbivel, kivéve, hogy plusz információként
meg kell adni egy nevet, amivel a visszatérési értékre lehet hivatkozni a
függvény törzsén belül.
%FUNCTION(DTW_SQL) allas_katnev(ktgkey) RETURNS(x) {
SELECT KTGNEV FROM $(COLLECTION)T_KTG WHERE KTGKEY = '$(ktgkey)'
%REPORT{%ROW{@DTW_ASSIGN(x,V_KTGNEV)%}%}
%}
– MACRO_FUNCTION blokk: szintén alprogram definiálható vele, azonban ennek
feldolgozását a Net.Data végzi el.
%DEFINE tmp_dom = %TABLE
%MACRO_FUNCTION dom_lista() {
@dc_domain_domain_lista_sqlm(tmp_dom)
@DTW_ASSIGN(pattern, "<INPUT type=""button"" value=""%2"" onClick=
""document.forms['global'].server.value='%1';
document.forms['global'].submit();""><BR>")
@dc_jelenit_normalis_mfi(tmp_dom, @DTW_TB_rROWS(tmp_dom))
%}
Természetesen
az alprogramoknak lehetnek paraméterei. Ezek megadási módja megegyezik az Ada
szintaxisával. Három paraméterátadási mód van, IN, OUT és INOUT. Az IN és INOUT
módú paramétereknek értéket kell adni a hívás előtt. Az OUT és INOUT módú
paraméterek értéket adnak vissza. Az alprogramok hívását a @
karakter jelzi.
Mint említettem, egy Net.Data makró egyszerű szöveges állomány,
amit a makrófeldolgozó értelmez. A változók értékét is idézőjelek között,
karakterláncként kell megadni. Még a legegyszerűbb numerikus
műveletek is, mint az összeadás, csak alprogramok segítségével
végezhetők el. Emiatt az alprogramok kiemelt szerepet kapnak. A Net.Data
számos beépített függvénnyel és eljárással rendelkezik. Ezek neve a DTW_
előtaggal kezdődik, így könnyen megkülönböztethetők saját
alprogramjainktól.
Ez a rész HTML vagy XML blokkokat tartalmaz. Minden
ilyen blokknak névvel kell rendelkezni. Ezek jelentik a makró belépési
pontjait, így minden makrónak kell tartalmazni legalább egy HTML vagy XML
blokkot. Amikor egy kliens alkalmazás a Net.Data-t hívja, akkor tulajdonképpen
egy makró nevét és egy belépési pont nevét kell megadni. Egy kéréskor mindig
csak egy ilyen blokkot hajt végre a makrófeldolgozó.
A belépési pont blokkok tartalmazzák az oldalak leírásának nagy részét.
Ezen kívül tartalmaznak változóhivatkozásokat, vezérlési szerkezeteket
(elágazások és ciklusok), valamint alprogramhívásokat, esetleg INCLUDE utasításokat. Minden, amit a Net.Data nem ismer fel nyelvi elemnek,
változatás nélkül kerül be az eredménybe.
A Net.Data egyszeres elágaztató utasítást és előfeltételes ciklust
ismer. Lássuk most ezeket. Szerepük megegyezik a magasszintű programozási
nyelvek megfelelő utasításáéval.
–
IF blokk
%IF (feltétel1)
utasítás_blokk
%ELIF (feltétel2)
utasítás_blokk
%ELSE
utasítás_blokk
%ENDIF
– WHILE blokk
%WHILE (feltétel) {
utasítás_blokk
%}
A feltételben a <, >, <=, >=, !=, ==, &&, || operátorok szerepelhetnek.
Operandus lehet változóhivatkozás, karakterlánc konstans vagy függvényhívás.
A Net.Data a fentieken kívül tartalmaz még
néhány további elemet, aminek az ismertetésére nem térek ki.
A fejlesztés során kiderült, mik az egyes
technológiák előnyei és hátrányai. Kezdjük a Net.Data előnyeivel:
–
interpreteres, vagyis a fejlesztés során nem kell a forrást mindig
újrafordítani
–
egyszerűen elsajátítható
Elég sok hátránya vagy hiányossága van,
melyek egy része szintén interpreteres jellegéből fakad, más részük pedig
inkább az egyszerűségéből:
–
a végrehajtás lassabb, mint egy fordítóprogramos rendszer esetén
(főleg ciklusok esetén)
–
a programban maradhatnak szintaktikai hibák, ha nem megfelelően
teszteljük
–
használatához új nyelvet kell megtanulni
–
csak a HTML nyújtotta lehetőségekkel élhetünk (később
láthatjuk majd, milyen plusz lehetőségek vannak Java technológiák
használata során)
A servletek valójában olyan Java osztályok,
amelyekkel dinamikusan lehet tartalmat generálni. Funkciójukat tekintve
megegyeznek a Net.Data-val, ám működésükben jelentős eltérések
vannak. Servleteket (és JSP lapokat) a Digitalcity másik nagy részében, a
megjelenítő modulban alkalmaztunk.
A servletek teljesen közönséges Java osztályok. Ennek értelmében
szükség van egy Java virtuális gépre, amelyben futhatnak. Futtatásukról egy
alkalmazásszervernek kell gondoskodni. A servletek működése röviden a
következőképpen vázolható. Ha a webszerver érzékeli, hogy a hozzá
érkező kérés egy servletnek szól, akkor a kérést továbbítja az
alkalmazásszerver felé, az pedig eljuttatja a megfelelő servletnek. A
servlet feldolgozza a kérést, majd előállít egy HTML oldalt vagy
oldalrészletet. Az oldal visszakerül a webszerverhez, amely továbbítja azt a
kliens felé.
Egy servlet életciklusa nagyon egyszerűen adható meg. Az
alkalmazásszerver legkésőbb az első kérés megérkezésekor a servlet
osztályából létrehoz legalább egy példányt. A servlet ettől kezdve él, és
kiszolgálja a hozzá érkező kéréseket, majd valamikor megszűnik.
Természetesen a servletpéldány megszüntetése is az alkalmazásszerver feladata,
ám ez programozói szempontból lényegtelen. Fontos megjegyezni, hogy nem tudjuk
azt, hogy az alkalmazásszerver mikor hány példányt hoz létre a servletből.
Csak az biztos, hogy az első servletnek szóló kérés kiszolgálása
előtt már létezni fog legalább egy példány az adott osztályból.
A servletek létrehozásához szükséges alapvető
Java osztályokat és interfészeket a javax.servlet csomag tartalmazza.
Ez a Java 2 SDK Enterprise Edition része, valamint
külön csomagként is letölthető a Sun honlapjáról. A csomag tartalmazza a Servlet interfészt és a GenericServlet absztrakt osztályt.
Egy általános célú servletet ebből az osztályból kell származtatni. A
servlet fő tevékenységét a service() metódusban kell
implementálni.
Mivel a servletek legfőbb alkalmazási területe a HTML lapok
előállítása, létrehoztak egy másik csomagot is (javax.servlet.http), melynek osztályai
és interfészei használatával pontosan ezt a feladatot lehet egyszerűen
megvalósítani. A kulcsfontosságú típusok a HttpServlet osztály, valamint a
HttpServletRequest és a HttpServletResponse interfészek.
A HTTP protokoll szerint a kérések POST vagy GET módszerrel érkezhetnek
a webszerverhez. A HttpServlet osztályban definiáltak két
metódust, ami az adott típusú kéréseket szolgálja ki. A várt működés
eléréséhez servletünket a HttpServlet osztályból kell
származtatni, és a doPost() és doGet() metódusokat
felüldefiniálni. Általános esetben a két metódus ugyanazt csinálja, így
elegendő az egyiket implementálni, és a másikból meghívni azt.
Ezen a két metóduson keresztül tudjuk feldolgozni a kéréseket és azok
paramétereit, illetve elkészíteni a válaszokat. A doGet() és doPost() metódusoknak két
paramétere van. Az egyikben a webszerverhez érkező kérésről, a
másikban a webszerver által adott majdani válaszról lehet információt szerezni
vagy beállítani. Az első paraméter típusa a fent említett HttpServletRequest, a másodiké pedig a HttpServletResponse. Nagyon sok
információt tartalmazhat egyetlen kérést reprezentáló objektum is.
Lehetőség van például arra, hogy megállapítsuk a kérést küldő gép
nevét, megtudjuk, milyen böngészőt használ, milyen nyelvi beállításokkal
dolgozik. Ha egy HTML űrlapot dolgozunk fel, akkor az űrlap
mezőinek értékeit is a kérésen keresztül tudjuk elérni.
A válasz egy valódi referencia lesz a webszerver által adott válaszra.
Ennek segítségével nyílik lehetőség az eredmény HTML oldal
előállítására is. Az eredményt most is – mint Net.Data esetén – egy
program állítja össze, így tetszőleges információ megjelenhet rajta. A
kliens egyik esetben sem fogja tudni, hogy az az oldal, amit lát, egy statikus
HTML oldal, vagy pedig egy program által dinamikusan előállított.
A következő példa szemlélteti, hogy
ténylegesen milyen egyszerű egy servlet elkészítése. Csupán az
előzőekben leírtakat kell alkalmazni a legegyszerűbb servlet
megírásához.
package hu.tsoft.servlet;
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class PeldaServlet extends HttpServlet {
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
doPost(request, response);
}
public void doPost(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/html; charset=ISO-8859-2");
PrintWriter out = response.getWriter();
out.println("<HTML>");
out.println(" <HEAD>");
out.println(" <META http-equiv=\"Content-Type\" "
+ "content=\"text/html; charset=ISO-8859-2\">");
out.println(" </HEAD>");
out.println(" <BODY>");
// ide jön a tényleges tartalom, pl. egy adatbázis alapján
out.println(" </BODY>");
out.println("</HTML>");
}
}
Egy servlet két, ugyanazon kliensről
érkező kérelem kiszolgálása között megőrizhet a kliensről néhány
információt. Erre két technika létezik.
Az egyik szerint a servlet “sütiket” (cookie) helyez el a kliens
gépen, majd azokat próbálja meg visszaolvasni. Ez a lehetőség a Net.Data
esetén is fennáll, mivel ez a HTTP protokoll alapján működik.
Természetesen, ha a kliens nem támogatja a “sütik” elhelyezését, akkor gondban
vagyunk, hiszen nem tudjuk eltárolni az információinkat. Nyilvánvaló, hogy
ekkor vissza sem tudjuk majd őket kérni.
Ennek a kiküszöbölésére a servlet technológia biztosít még egy
lehetőséget. Jóval biztonságosabb megoldás, ha a klienseket a szerveren
tartjuk számon. A szerver képes azonosítani a klienseket, és az egy
klienstől egymás után érkező kéréseket egy munkamenet-objektumba
gyűjti. (Az angol terminológiában session.) Ehhez az objektumhoz a
programozó extra kód írása nélkül hozzáférhet a kéréseken keresztül, eltárolhat
objektumokat, vagy lekérheti a már eltárolt objektumok referenciáját. Ezzel az
is megoldható, hogy nyilvántartsuk azt, ki látogatja meg már sokadik alkalommal
a lapunkat. Ha jelszóval védett oldalaink vannak, akkor így azonosíthatjuk a
már bejelentkezett felhasználókat.
A servlet technológia az alkalmazás-szintű adatok tárolására is
biztosít objektumot, amit a munkamenettel megegyező módon használhatunk.
Ezek a lehetőségek nyilvánvaló többletet jelentenek a Net.Data
lehetőségeihez képest.
A működés nagyon
hasonlít a CGI (Common Gateway Interface) megoldáshoz, azonban a Java nyelv
használata miatt sokkal bővebb lehetőségekkel rendelkezik:
–
nem kell új nyelvet megtanulni (ha valaki már ismeri a Java-t)
–
az alkalmazásszerveren futó virtuális gépen folyamatosan életben
lévő servlet használatával gyorsabbá válik a kiszolgálás, hiszen nem kell
megvárni, míg a program betöltődik
–
könnyen megoldható az alkalmazásszintű és a felhasználói adatok
megőrzése a servlet két futása között
–
platformfüggetlenség, mivel a servlet technológia szabványosított.
Minden J2EE-megfelelő alkalmazásszervernek tudni kell futtatni az
elkészült servleteket.
–
skálázhatóság
A sok előny mellett természetesen hátrányok is
származnak a használatból:
–
minden módosítás után újra kell fordítani a servletet
–
az alkalmazásszervernek minden fordítás után újra kell inicializálni a
servlet egy példányát
–
az előzőek miatt a fejlesztés menete kismértékben csökken (ez
gondos tervezéssel ellensúlyozható)
A JSP technológia a szervlet technológia
továbbfejlesztéseként jött létre. Azért fejlesztették ki, hogy megkönnyítsék az
olyan webes oldalak előállítását, amik statikus és dinamikus elemeket
egyaránt tartalmaznak. A JSP technológia lehetővé teszi, hogy a servlet
technológia összes előnyét kihasználjuk, viszont a statikus tartalom
előállítására egy sokkal természetesebb megközelítést alkalmaz.
A JSP lapokat használat előtt ugyanúgy le kell fordítani, mint a
servleteket. Ezt a feladatot elvégzi helyettünk az alkalmazásszerver. Ha azt
látja, hogy egy JSP lap újabb, mint a belőle készült osztály, a
következőt teszi. A JSP lap alapján generál egy forrást, ami egy valódi
servlet lesz. Ezután ezt a generált forrást fordítja le. A működés a
továbbiakban megegyezik a servleteknél megismerttel.
Mivel egy JSP technológia a servletek továbbfejlesztése, az ott
megismert összes lehetőség használható. Ehhez implicit objektumok állnak
rendelkezésre, melyek közül a legfontosabbak a request, session és application objektumok. Az első a servleteknél megismert doGet() és doPost() metódusok HttpServletRequest paraméterének felel
meg. A másik kettő az a két objektum, amit a munkamenet- és az
alkalmazás-szintű adatok tárolására használhatunk. Létezik response objektum is a válaszhoz, ám ezt általában nem kell közvetlenül
használni.
Egy JSP oldal kétféle szöveget tartalmaz: az oldal
sablonját, amely többféle formátumú is lehet – például HTML, XML, WML vagy SVG
– valamint speciális JSP elemeket. Ezek a speciális elemek teszik lehetővé
a dinamikus tartalom előállítását. A JSP elemek a következők:
<%@ direktíva paraméterek %>
Ezekkel lehet a működést befolyásolni,
egy másik állományt beszerkeszteni (fordítási időben) vagy
tag-könyvtárakat megadni.
A JSP technológia elvileg megengedi, hogy a
Javatól eltérő nyelvet használjunk az alkalmazáslogika elkészítéséhez. Ezt
szintén egy direktívával lehet megadni. A jelenlegi alkalmazásszerver-implementációk
azonban csak a Java nyelvet támogatják, így a következő elemekben is a
Java nyelvet kell használni.
<%! deklaráció; [deklaráció;]+ … %>
Változók vagy metódusok
deklarálhatók. Az itt definiált változók és metódusok a generált osztály tagjai
lesznek.
<%= kifejezés %>
Végrehajtáskor az oldalon a kifejezés értéke
fog majd megjelenni.
<% kódrészlet %>
Ide teljes értékű Java programrészeket
lehet írni. Ezalatt az összes Java utasítást kell érteni, tehát ciklust lehet
létrehozni vagy valamilyen feltételtől függő elágazást lehet
megvalósítani. Korlátozás nélkül használható a teljes Java API.
Ezek a HTML tagekhez hasonlóak, vagyis egy nyitó és egy záró
tagből állnak, amiket <> jelek közé kell írni. A leggyakrabban
használt tagek a következők:
<jsp:useBean> |
Létrehoz egy szerveroldali Java objektumot.
Az objektumnak kötelezően JavaBean-nek kell lenni. A létrehozáskor
négyféle élettartam adható meg: alkalmazás, munkamenet, kérés és oldal. |
<jsp:setProperty> |
Beállítja egy adott bean valamelyik
tulajdonságát. |
<jsp:getProperty> |
Lekérdezi egy adott bean valamelyik
tulajdonságát. |
<jsp:include> |
Beszerkeszti egy másik állomány tartalmát
(dinamikusan, futásidőben). A másik állományt így szintén lehet
szervlettel előállítani. |
Most pedig nézzük meg, hogyan is néz ki az előző
egyszerű servlet JSP megfelelője. Láthatjuk, hogy ezt a JSP oldalt
még egyszerűbb elkészíteni, mint a servletet.
<%@ page contentType="text/html; charset=ISO-8859-2" %>
<HTML>
<HEAD>
<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-2">
</HEAD>
<BODY>
<%-- ide jön a tényleges tartalom, pl. egy adatbázis alapján --%>
</BODY>
</HTML>
Általában akkor célszerű JSP-t
készíteni, ha az oldal sok megjelenítési elemet tartalmaz, mivel ezek között lényegesen
egyszerűbb néhány speciális tag-et elhelyezni, mint az egészet servletként
megcsinálni. Servletet inkább vezérlésre célszerű használni. Ha MVC design
pattern-ben gondolkozunk, akkor egy JSP oldal inkább view, egy servlet pedig
kontroller funciót kell betöltsön.
A JSP technológia
robosztusságát az adja, hogy lehetőséget biztosít saját tag-ek
létrehozására. A tag-ek működését megfelelő Java osztályokban kell
megadni. Az összerendelést tag-könyvtár leíróban (tag library descriptor, TLD)
kell megadni. Ez valójában egy XML állomány. Készíthetünk például egy olyan
tag-könyvtárat, amivel többnyelvű oldalakat lehet készíteni.
<%@ taglib uri="nls.tld"
prefix="nls" %>
...
<nls:init language="hu" />
...
<nls:variable
name="NLS_ESEMENY_KEZDETE" />
Saját tag-ek alkalmazásával a megjelenítést
teljesen el lehet választani az alkalmazáslogikától. Ez minden esetben
előnyös, mert ez teszi lehetővé, hogy a követelmények változásakor
minél kevesebb módosításra legyen szükség.
Ma már elkerülhetetlen egy olyan nyelv használata,
amivel szabványos formában lehet megadni strukturált adatokat. Az XML-t pont
erre fejlesztették ki: az adatok strukturált formában vannak leírva egy XML
állományban. A leírás magában foglalja azt is, hogy egy adott adat az adott
szituációban éppen mit jelent.
Az XML előnye, hogy szabványos nyelv. Emiatt már az újabb Java
API-k is tartalmazzák az XML állományok kezeléséhez szükséges osztályokat, így
használatához nem kellett a Java keretein kívülre lépni. Több helyen is XML állományokban
adtuk meg a szükséges információkat:
–
tag-könyvtár leíró
–
az egy csoportba tartozó lekérdezéseket egy-egy XML állományban
helyeztük el
–
a Digitalcityben szereplő diagramgeneráló modul is XML-re épül
–
a projekt kezelését, publikálását a Ant programra bíztuk, mely az
Apache Jakarta projekt része. A publikálás menetét leíró szabályokat kell
XML-ben megadni. Szerepe a C/C++ fejlesztők körében használt
Makefile-okkal egyezik meg.
Mint említettem, a Digitalcity nem egyetlen portál,
hanem egy olyan alkalmazás, amellyel több portál kezelése valósítható meg. A
portálok alapkoncepciója és felépítése ugyanaz, de mégsem kell ugyanúgy
kinézniük. Kinézetük teljesen eltérő is lehet.
Bár a HTML oldalakat előállító program ugyanaz, a megjelenítésre
vonatkozó információkat az oldalak nem tartalmazzák. Helyette minden oldal egy
hivatkozást tartalmaz egy stíluslapra. Az egyes HTML elemek – <BODY>, <TABLE>, <TR>, <TD>, stb. – megjelenítési módja ezekben a stíluslapokban van megadva.
A CSS2 nem újkeletű dolog, hanem már 1998 május óta éve W3C
ajánlás. Ennek ellenére a régebbi böngészők nem, vagy csak részben
támogatják. Ezért van az, hogy egy Digitalcity portál megtekintéséhez
viszonylag új böngészőre van szükség (IE 5.0 vagy Netscape 6 és újabb
változataik, Mozilla, Konqueror).
A kész alkalmazáson megfigyelhetjük, hogyan
működik egymás mellett, egymással párhuzamosan két, alapkoncepciójában
eltérő rendszer, a Net.Data és a Java alkalmazás. Együttműködésüket a
háttérben működő DB2 adatbázis-kezelő rendszer teszi
lehetővé, valamint a HTML nyelv és a HTTP protokoll.
A Net.Data és a Java komponensek természetesen ugyanazzal az
adatbázissal dolgoznak. Mindkét modul HTML lapokat állít elő az adatbázis
táblái alapján. A HTML oldalak űrlapokat tartalmaznak. Minden a szerver
felé küldött információ ezeken az űrlapokon keresztül jut el rendeltetési
helyére. A HTTP szabvány biztosítja azt, hogy a böngészőktől a
szerver felé küldött kérelmeket mindkét rész ugyanúgy értelmezze, a válaszokat
pedig ugyanolyan formában küldje vissza.