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.

1. A Digitalcity webalkalmazás bemutatása

1.1. Az alkalmazás filozófiája

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.

1.2. A Digitalcity felépítése és szereplői

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.

2. Az infrastruktúra

2.1. A hardver

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.

2.2. A szoftverek

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.

DB2 Universal Database

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.

Operations Navigator

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.

Net.Data makrófeldolgozó

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á.

WebSphere Application Server

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.

WebSphere Studio

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.

VisualAge for Java

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.

3. A technológiák

3.1. A Net.Data makrónyelv

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.

A makrók felépítése

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.

Deklarációs rész

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.

Prezentációs rész

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.

Előnyök és hátrányok

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)

3.2. Java servletek

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 megvalósítás

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>");

    }

}

 

Információ megőrzése a kliensekről

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.

Előnyök és hátrányok

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ó)

3.3. JavaServer Pages

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.

JSP elemek

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ívá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ók

<%! 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ések

<%= kifejezés %>

Végrehajtáskor az oldalon a kifejezés értéke fog majd megjelenni.

-      Scriptlet-ek

<% 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.

-      JSP specifikus tagek

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.

Tag-könyvtárak

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.

3.4. XML

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.

3.5. HTML és stíluslapok (CSS2, Cascading Style Sheets Level 2)

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).

4. Összegzés

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.