1 JEGYRENDELÉS AZ INTERNETEN NAGY GERGELY 2001, BUDAPEST2 DIPLOMATERVEZÉSI FELADAT NAGY GERGELY szigorló muszaki informatikus hallgató részére Jegyren...
JEGYRENDELÉS AZ INTERNETEN NAGY GERGELY 2001, BUDAPEST
DIPLOMATERVEZÉSI FELADAT
NAGY GERGELY szigorló muszaki informatikus hallgató részére
Jegyrendelés az interneten Napjainkban egyre több új szolgáltatás megjelenését teszi lehetové az internet. Olyan szolgáltatásokét, melyek esetében már nem önmagában a szükséges információk hatékonyabb megszerzése a feladat, hanem az egyes emberek hétköznapi, illetve a vállalkozások gazdasági folyamatainak kezelése, az internet által nyújtott elonyök leggyakrabban a szélesköru elérhetoség - felhasználásával. Az ilyen szolgáltatások és az azokat nyújtó vállalatok szerepe egyre jelentosebb, az internetes megjelenés sok esetben egyre inkább alapkövetelménnyé válik. A hallgató feladatának a következokre kell kiterjednie: • Mutassa be az elektronikus kereskedelem mai tendenciáit, kitérve a nemzetközi és magyarországi vonatkozásokra. • Ismertesse és jellemezze az internetes vásárlás legfontosabb elemeit. • Helyezze el a jegyrendelést, mint terméket az elektronikus piacon. Mutassa be az internetes jegyrendelést, annak folyamatát, mutasson példákat ilyen szolgáltatást megvalósító rendszerekre. • Ismertesse az elektronikus kereskedelmi alkalmazások fejlesztését lehetové tevo technológiákat és azok jellemzoit. • A legmegfelelobb technika felhasználásával készítsen egy mintaalkalmazást, amely alkalmas termekben történo foglalások kezelésére. • Térjen ki részletesen az alkalmazás fobb elemeinek muködésének magyarázatára és ezen komponensek egymáshoz való viszonyára. Konzulens:
Nagy Tamás
Záróvizsgatárgyak:
Operációs rendszerek Számítógép-hálózatok Integrált szélessávú távközlés
Alulírott szigorló hallgató kijelentem, hogy a diplomatervben foglaltak saját munkám eredményei, csak a megadott forrásokat (szakirodalom, eszközök, stb.) használtam fel.
Tudomásul veszem, hogy az elkészült diplomatervben található eredményeket a Budapesti Muszaki Egyetem, a feladatot kiíró egyetemi intézmény saját céljaira felhasználhatja.
Mai életünk egyik legjellemzobb jelensége, hogy a vásárlás egyre nagyobb szerephez jut. A fogyasztói társadalom nem létezhet fogyasztás, vásárlás nélkül. A másik fontos jelenség életünk tempójának felgyorsulása. Mindebbol következik a gyors vásárlás igénye, mely igény kielégítésében napjainkban egyre fontosabb szerephez jut az internet. A gyors vásárlás speciális esete, mikor az ember nem tárgyakat, hanem lehetoségeket, szolgáltatásokat vesz meg. Ilyen speciális eset a jegyrendelés is, mely diplomamunkám tárgyát képezi. Kiindulásképpen áttekintem az internetes vásárlás tényezoit és módozatait. Az internetes vásárlás kulcskérdései ugyanúgy a jegyrendelés megvalósításában is fontos szerepet kapnak, de dolgozatomban természetesen rámutatok azok speciális vonatkozásaira is. Majd foglalkozom a megvalósítás lehetséges eszközeivel. Ezen technnológiák összehasonlítása és elemzése után döntöttem a JAVA nyelv használata mellett, melynek lehetoségeire részletesebben is kitérek. Végül egy mintaalkalmazás keretén belül kívánom bemutatni a gyors vásárlás és választás lehetoségét. A vizsgált muködo jegyrendelo rendszerek gyenge pontjainak feltérképezése és azok elemzése után dolgozatom legfobb célja egy felhasználóbarát felületet nyújtó példa bemutatása.
INTRODUCTION
One of the most characteristic features of our life today is that shopping is playing a dominating role in it Obviously, consumers’ society cannot exist without the act of consumption, i.e. shopping. The other peculiar feature is the ever-increasing speed of our life. The demand for fast shopping naturally comes from the above two characteristics, and the Internet is playing a more and more important part in meeting such requirements. A special type of purchasing is when one does not buy articles, commodities, but rather services or facilities. Booking tickets – which is the subject of my thesis - is a good example of such purchases. By way of introduction, I am going to give an overview of the factors and modes of purchase through the Internet. Although the key elements of this kind of shopping are present during the act of ticket-booking as well, in my thesis, I will also stress their specific features. Next, I am going to deal with the possible means of application. Having compared and analysed the various technical solutions, I came to the decision to use the JAVA language, the possibilities and advantages of which will be discussed in more detail in this part of my work. Finally, I wish to illustrate and present the possibility of quick choice and fast shopping in the framework of a sample booking. Beside pointing out the weaknesses of the operating ticket-ordering systems I examined, the purpose of my thesis has also been to present an example offering a user-friendly interface.
A MINTAALKALMAZÁS ......................................................................................48
TICKETOFFICE ..................................................................................................................48 CÉL ..................................................................................................................................48 ELOZETES MEGGONDOLÁSOK.............................................................................................49 Miben hoz újítást a mintaalkalmazás?..................................................................49 Meglévo rendszer integrálása...............................................................................50 SPECIFIKÁCIÓ ...................................................................................................................51 MINTAALKALMAZÁSBAN MEGVALÓSÍTOTT............................................................51 A MEGVALÓSÍTÁS ESZKÖZEI ...............................................................................................52 Fejlesztoeszköz.....................................................................................................52 Webszerver ...........................................................................................................54 Adatbázis szerver..................................................................................................54 ADATBÁZIS FELÉPÍTÉSE ....................................................................................................55 A TÁBLÁK LEÍRÁSA ............................................................................................................55 CLIENT (az ügyfél adatait tartalmazó tábla) ........................................................55 PRICE (az árkategóriákat tartalmazó tábla).........................................................55 ROOM (a termek tulajdonságait tartalmazó tábla)...............................................56 CHAIR (a termek alaprajzait tároló tábla).............................................................56 ACTION (az eseményeket leíró tábla)..................................................................56 TYPE (az eseménytípusokat leíró tábla) ..............................................................57 PROGRAM (a musorokat tartalmazó tábla) .........................................................57 SHOW_ACT (az eloadások foglaltságát tartalmazó tábla)..................................57 TOVÁBBI TÁBLÁK ...............................................................................................................58 ACCESS (a rendszerhez való hozzáférések adatait tartalmazó tábla) ...............58 SHOW_OLD (a már nem aktuális eloadásokat tartalmazó tábla) .......................58 ORDER (a foglalásokat regisztráló tábla) ............................................................58 ENTITÁS-RELÁCIÓS DIAGRAM .............................................................................................59 PORTÁL FELÉPÍTÉSE .........................................................................................................60 MENÜSTRUKTÚRA .............................................................................................................60 A RENDSZER RÉSZEI .........................................................................................................62 HTML-JSP OLDALAK ........................................................................................................62 JavaScript menürendszer .....................................................................................62 Keresés .................................................................................................................63 Dátum kiválasztása ...............................................................................................66 Idopont, szín kiválasztása.....................................................................................68 Esemény, terem kiválasztása ...............................................................................68 Adminisztráció .......................................................................................................69
1. VÁSÁRLÁS AZ INTERNETEN BEVEZETÉS Kezdetben az elektronikus kereskedelem hatalmas perspektívákat nyitott az üzlet világában, és szélsoséges sikeráradatot hozott. Ezen felbuzdulva egyre több vállalkozás indult útjára és ma már a hírekben nem csak sikerekrol olvashatunk. A sorozatos sikertelenségek és óriási bukások megkövetelik a hosszú távon sikeres online értékesítés feltételeinek újragondolását. A kudarcok nem azt jelentik, hogy az internetes kereskedelmnek nincs jövoje. Sokkal inkább azt, hogy nagyon is komolyan kell venni. Érdemes alaposabban tanulmányozni a miérteket, és az elektronikus kereskedelem sikeres muködtetése érdekében hosszútávú, életképes és gazdasági alapokon nyugvó stratégiát kell kialakítani, melynek alapját az alábbi pontok képezhetik:
• Piaci igény az interneten kínált termékek és szolgáltatások itránt. • Megfelelo árképzés, amely arra ösztönzi a vásárlókat, hogy ne a hagyományos boltokban vásárolják meg a terméket. • Gondosan megtervezett „eladótér”, amely megfelelo mennyiségu információt nyújt a termékekrol, pótolva a bolti eladók szakértelmét. • Hatékony marketing a potenciális vásárlókat célzó kampányokkal. • Többletértéket nyújtó szolgáltatás, amely megkülönböztetheti az oldalt a többiekétol, és megfogható elonyt nyújt a vásárlónak. • A befektetés életképes stratégiával alátámasztott megtérülése.
Egyelore nem a közvetlen forgalom, hanem elsosorban a reklámbevétel miatt érdemes boltot nyitni az interneten. Ezt az érdekes tényt bizonyítja az alábbi grafikon is, mely a Carnation Consulting adatai alapján készült:
ÁBRA: Fogyasztói elektronikus kereskedelmi forgalom Magyarországon pénzügyi szolgáltatások nélkül és a hazai online reklámipar várható forgalma
Az online kereskedelem kulcskérdés ei Három sarkallatos pontban fogalmaznám meg azon kérdéseket, melyek alakulása és technológiai háttere nagymértékben befolyásolhatja az online kereskedelem jövobeni tendenciáit.
• Internetes penetráció Az elso nagy kérdés az az, hogy kik, hol és milyen mértékben használják az internetet. Ennek ismerete alapveto egy üzleti terv elkészítésében és a megtérülési számítások elvégzésében. Az internetezok létszáma folyamatosan no, és ennek mértékében az internet egyre komolyabb piaci szereplové válik. Ennek pedig egyenes következménye, hogy egyre inkább megéri részesévé válni ennek a piacnak, hiszen a növekedo forgalom egyre nagyobb haszonnal kecsegtet. 1997
1998
1999
2000
2001
Oktatás Vállalatok és kormányzat Otthon és kisvállalat Átfedés
TÁBLÁZAT: Az internetet rendszeresen használók száma Magyarországon JEGYRENDELÉS AZ INTERNETEN, Nagy Gergely [[email protected]]
7. oldal
• Szállítás (logisztika) A megvásárult árunak, terméknek, szolgáltatásnak valamilyen módon el kell jutnia a vevohöz. Ez persze nagyban függ a termék térbeli kiterjedésétol, speciális tulajdonságaitól. Ezekre a tulajdonságokra és a szállítás mai megoldásaira a következo fejezetekben még bovebben kitérek. • Fizetés Talán az egyik legkényesebb kérdés, hiszen az eladónak mindenképp érdeke, hogy megkapja a pénzét, a vásárló pedig ezt teljesen kockázatmentesen szeretné megtenni. Ezért az eladónak olyan fizetési megoldásokat kell kínálnia, ami vonzó a vevo számára és csupán biztonság-technológiai kérdések nem tántorítják vissza vásárlási szándékától.
INTERNETES ÁRUHÁZAK Az internetes áruházak, kihasználva az „új értékesítési csatorna” által nyújtott lehetoségeket, az egyik legolcsóbb és leghatékonyabb megoldást kínálják termékeink és szolgáltatásaink eladására. Az ilyen boltok éjjel-nappal képesek fogadni az ide téro vásárlókat, mégpedig fizetett eladók alkalmazása nélkül. Az eladók jelenlétének hiányát azonban szélesköru, mindenre kiterjedo és jól struktúrált információkkal pótolni kell! Egy internetes áruház lehet egy már meglévo, hagyományos kereskedelmet folytató bolt internetes megjelenése, de sok internetes áruház jött létre pusztán az internetre, mint értékesítési csatornára alapozva, jelentosebb hagyományos kereskedelmi elozmények nélkül. Az online internetes áruházak célja tehát termékek, szolgáltatások értékesítése. Ebben a fejezetben arra a két kérdésre keresem a választ, hogy MIT, milyen termékeket, milyen szolgáltatásokat? és HOGYAN, milyen módon értékesít?
Termékek, szolgáltatások
KATEGÓRIZÁLÁSI SZEMPONTOK • Méret A termék fizikai mérete. A szolgáltatásoknak nyilván nincs kiterjedése, esetükben ezt az értéket 0-nak veszem. E tulajdonság szerepe igen jelentos, hiszen egészen más kezelést igényel egy könyv vagy egy autó házhoz szállítása. • Mennyiség Ugyancsak a kiszállításnál van jelentosége, hogy milyen mennyiséget rendelünk egy adott termékbol, de már a kiválasztás is másképpen történik abban az esetben, ha 10000 db ceruzát veszek, vagy ha 1 db hutoszekrényt. Nagyobb tétel rendelése esetén esetleg jobban érdekel a kapott kedvezmény, mint az, hogy milyen a ceruzák külseje. A hutoszekrénynél pedig inkább az egyedi paraméterek a meghatározóak.
• Ár Az interneten tulajdonképpen képek és egyéb leírt adatok alapján döntök afelol, hogy a sok hasonló áruból melyiket választom. Ezt a döntést egy olcsóbb termék esetén könnyebben meghozza az ember, míg pl. egy 300.000 Ft-os televízió esetén nem biztos, hogy vállalja ezt a kockázatot. • Egyediség A fenti tv-s példa igazából egy kicsit sántít. Ugyanis egy muszaki terméknél sokat számítanak a számszerusítheto paraméterek. Ha tudom, hogy ezek a paraméterek pontosan mit takarnak, akkor vakon is tudhatom, hogy ennek jónak kell lennie (más kérdés, ha ahhoz kell a tv, hogy a nappali dísze legyen, és nem ahhoz, hogy villogásmentes, gyönyöru képpel élvezhessük a sportközvetítéseket). Egy muszaki cikknél, egy könyvnél, egy cd-nél biztosak lehetünk abban, hogy nem egyedi, hanem pontosan egyforma termékek közül válogatunk. Egy ruha esetében azonban nem elegendo csupán a „típus” meghatározása, és felpróbálás nélkül pusztán a paraméterek alapján elég kockázatos a döntés meghozatala.
Az alábbi táblázat áttekintést nyújt az egyes termékcsoportok jellegzetességeirol, felhasználva az elobb tárgyalt szempontokat.
TERMÉK
MÉRET
CD, DVD, videó, kicsi könyv
MENNYISÉG ÁR (FT)
EGYEDISÉG
kis
nem egyedi
100 – 10000
Az egyik legelterjedtebb termékcsoport az online áruházak palettáján. Talán azért, mert postai úton is könnyen szállítható, és olcsó termékeket takar, ami mind a vevo, mind az eladó számára kisebb rizikót jelent. muszaki
cikkek, kicsi – közepes kis
1000 – 1000000 nem egyedi
hardver, mobil Olyan termékek, melyek vásárlásánál elsodleges szempont a fobb technikai paraméterek összehasonlítása. Ez az interneten keresztül nagyon egyszeruen és hatékonyan megteheto.
Elsosorban mindennapos fogyóeszköznek számító irodai termékekrol van itt szó. Nagyobb cégeknél, irodáknál nagy könnyebséget jelenthet, ha csak a listát kell összeállítani a szükséges termékekbol. élelmiszerek
kicsi
közepes, nagy
10 - 10000
nem egyedi
Olyan termékek, melyeknél sokszor nagyon fontos a frissesség, tehát a szállítás nagyon kényes kérdés. A rendelést általában elore teszik meg, és akár állandósítani is érdemes! kozmetikai
kicsi
kis, közepes
100 - 10000
nem egyedi
cikkek Már muködo értékesítési láncolatoknál is bevált dolog a katalógusból való rendelés. Elso vásárlásakor talán nem, de egy bevált termék „utánrendelésére”az egyik legegyszerubb módszert kínálja az internet. háztartási cikkek kicsi – közepes közepes
10 - 10000
nem egyedi
Ez a kategória valahol ötvözi a muszaki cikkek, a kozmetikai cikkek és a bútorok fobb jellemzoit. bútorok
közepes, nagy
kis
1000 - 1000000 változó
Általában nagyobb méretu darabok, és sok esetben fontos a személyes meggyozodés arról, hogy tényleg illik-e a lakásba. A szállítás még normál esetben is sokszor teherautóval történik, ezért standard termékek (pl. irodai székek) esetén nagyon kényelmes lehet interneten való vásárlásuk. építoanyag
kicsi – nagy
közepes, nagy
10 - 1000000
nem egyedi
Csak nagyon kevés esetben fontos az anyag minoségérol való személyes meggyozodés, így remek „vásárlandó”alany. autóalkatrészek
kicsi – közepes kis
100 - 100000
nem egyedi
Nem túlságosan elterjedt termékcsoport. Elsosorban autóforgalmazó cégek megjelenése hozhat áttörést.
Nehéz a sík képernyon megmutatni azt, hogy hogyan is állna rajtunk egy ruhadarab. Mégis történnek ilyen vásárlások is, de azok inkább jól bevált, márkás és nem annyira méretfüggo ruhadarabok. ajándék, virág
kicsi – közepes kis
100 - 10000
változó
Alacsony áruk és kis méretük miatt az interneten is jól kezelheto ez a termékcsoport, ami jó hír ebben a rohanó világban élo emberek számára. jegy, utazás
nincs
kis
100 - 1000000
egyedi
Az egyik legjellemzobb attribútuma ezen termékcsoportnak az egyediség, hiszen pl. kétszer nem adhatom el ugyanazt az ülohelyet egy repülon. A válsztás nagyon kényelmessé teheto, ami ösztönözheti a vásárlót, az eladónak pedig nem kell a kiszállítással foglalkoznia. értékpapír, tozsde
nincs
közepes, nagy
1000 - 1000000 nem egyedi
Rendkívül gyors és kényelmes megoldást kínál az internet banki és tozsdei tranzakciók elvégzésére. Ilyen esetekben maximális biztonság garantálására van szükség, hiszen sokszor nem kis összegekrol van szó. TÁBLÁZAT: Egyes terméktípusok összehasonlítása
A következo grafikonon jól látszik az egyes termékek „népszerusége”: Hazánkban egyelore nem túlságosan széles a választék, de annál dinamikusabban bovül. A piacon leghamarabb megjelent termékek iránti bizalom a legnagyobb, és összességében elmondhatjuk, hogy nagyobb értéku áruk csak ritkán találnak „gazdára”az interneten.
Egyéb Ajándéktárgyak Elektronika, HW Irodai termékek Értékpapír, tozsde Zene Könyv, CD 0
Forgalom (százalékban)
5
10
Könyv, CD
Zene
25.64
15.38
15
20
25
Értékpapí Irodai Elektronik Ajándéktá r, tozsde termékek a, HW rgyak 12.82
10.26
7.69
7.69
30 Egyéb 20.51
ÁBRA: Termékprofilok a fogyasztói elektronikus kereskedelmi website-okon
Áruházak típusai Az áruházakat rengeteg szempont szerint kategorizálhatjuk. A két legalapvetobb típus a plaza vagy bevásárlóközpont, mely több kis boltot ölel fel, esetleg felajánlja meglévo infrastruktúráját a csatlakozni szándékozóknak. A másik típusba tartoznak azok a boltok, melyek önálló honlappal rendelkeznek, és maguk bonyolítják a fizetést és a szállítást. A interneten megjelent cégek között szerepelnek hagyományos kereskedelmet is folytató (Libri, Office Depot) valamint kizárólag internetes boltot mûködtetõ vállalkozások (DVD Futár), egy termékre specializálódott (CD-City) valamint széles termékválasztékot kínáló áruházak (Fotexnet, Rózsakert), évek óta mûködõ (Software Station, Videopart) illetve az interneten csak pár hónapja üzemelõ bolt is (Nettankönyv, Intertéka).
Mag yarors zági áruházak bemutatás a és öss zehasonlítása Néhány meghatározó jelentoségu magyarországi áruházat emelnék ki a jelenlegi helyzet bemutatására. A táblázatos összehasonlítás szempontjai a következok:
• VÁLASZTÉK • FIZETÉS ° Postai utánvétel (PU) ° Fizetés hitelkártyával (H) ° Készpénzzel a futárnak (KF) ° Fizetés futárnak hitelkártyával (HF) • SZÁLLÍTÁS ° Személyes átvétel (SZ) ° Magyar Posta (MP) ° Futárszolgálat Budapestre (FB) ° Futárszolgálat Vidékre (FV) • EGYÉB SZOLGÁLTATÁSOK
Széles termékkínálattal rendelkezo áruház, mely látogatóit sok egyéb szolgáltatással is igyekszik oldalaira csalogatni. Ebolt
10.000 termék
+
-
+
+
-
+
+
-
A bolt fo profilját a számitástechnikai termékek képezik. A fizetési módok között kiemelkedo, hogy a futárnál hitelkártyával is tudjuk rendezni a számlát. Ez sok biztonsági kérdést megold, de csak Budapest területén élhetünk ezzel a lehetoséggel. Libri
6.000 termék
+
+
+
-
-
+
+
-
Elsosorban könyvekre specializálódott áruház, mely a cég hagyományos kereskedelmi szolgáltatásait igyekszik bovíteni. Fókusz
n. a.
+
+
+
-
-
+
+
+
A Libri áruházhoz hasonlóan könyvekre specializálódott oldal, mely a többi bolthoz képest a legtöbb alternatívát nyújtja a fizetés és szállítás terén. Groby
3.000 termék
-
-
+
-
-
-
+
-
Érdekes és Magyarországon mindeddig egyedülálló kezdeményezés ez az élelmiszerekre specializálódott áruház. Netpincér
n. a.
-
-
+
-
-
-
+
+
A Netpincér remekül összefogja a honlapon megtalálható éttermek és pizzériák kínálatát és szolgáltatásait. Depo
6.828 termék
+
-
+
-
+
+
+
+
A felkínált rengeteg számítástechnikai termék több boltból származik, és áruk is más. Az oldal segítségével nagyon könnyen kiválaszthatjuk ezek közül a számunkra legjobban megfelelot. Zeneház
61.196 termék
+
-
-
-
+
+
-
-
A hihetetlen mennyiségu CD, DVD, videó ellenére a fizetési és szállítási lehetoségek még nem igazán megoldottak a Zeneházban. TÁBLÁZAT: Magyarországi online áruházak összehasonlítása JEGYRENDELÉS AZ INTERNETEN, Nagy Gergely [[email protected]]
15. oldal
FIZETÉSI MÓDOK Szeretnék egy rövid áttekintést adni ebben a fejezetben arról, hogy milyen technikák adottak ma interneten keresztül vásárolt áruk kifizetésére.
Fizetési módok csoportos ítás a
OFFLINE • Az áru kézhezvételekor történik a fizetés (utánvét) • Addig nem is küldik az árut, amíg az nincs kifizetve (elore fizetés)
ONLINE • Az áru megrendelésekor (online) történik a fizetés. Igen sok megvalósítása létezik, de abban közösek, hogy mindegyik megoldás igényel valamiféle technológiai hátteret. Ez a technológia sokkal nagyobb szerepet kap, mint az offline fizetés esetében. Hatással van a rendszer biztonságára, megbízhatóságára, és ezen keresztül áttételesen az elterjedtségére, elfogadottságára. A megvalósításához szükséges eszközök meghatározzák a rendszer, és annak muködtetésének költségeit.
A különbözo fizetési módok 5 nagyobb csoportba oszthatók: • ATM kétrésztvevos fizetés: Egy pénzügyi intézmény (bank) és egy számlával rendelkezo ügyfél közötti tranzakció, mely a számlát terheli vagy azon jóváírja a megadott összeget. • Közvetlen kétrésztvevos fizetés: Csak a vevo és az eladó vesz részt a tranzakcióban, melyben a vásárló a termékért (vagy szolgáltatásért) pénzzel, vagy más áruval fizethet.
• Közvetett háromrésztvevos fizetés: A vevon és az eladón kívül egy harmadik fél segítségével történik a pénzügyi tranzakció. • Kreditkártyás online fizetés • Csekkalapú online fizetés • Micropayment módszer: Olyan vásárlásoknál kap jelentoséget, ahol nagyon kis egységekben mérheto csak a termék, vagy szolgáltatás ára. Kialakulásuknak egyik oka, hogy ilyen vásárlásoknál a tranzakció díja jóval magasabb, mint maga a kifizetett összeg. Ez a fizetési módszer gazdaságossá teszi ezeket az eseteket is. • Anonymous fizetési mód: Elektronikusan titkosított fizetoeszközzel történik a tranzakció. Garantálja, hogy a hagyományos fizetéshez hasonlóan nem tudhatjuk, hogy ki használta fel a pénzt.
Ezen kategóriák alapján, 7 lényegesen eltéro fizetési módot különböztettem meg.
Konkrét fizetési típus ok öss zehasonlítás a
KÉSZPÉNZES FIZETÉS Hagyományos offline módszer, melynek alapvetoen két fajtája van. Lehet elore, ill. utánvéttel fizetni, de az elso sokkal kevesebb bizalmat élvez. Ez teljesen értheto, hiszen sokkal nagyobb kockázatot jelent elore kifizetni egy olyan terméket, amit még nem is láthatott a vevo.
TELEFONOS FIZETÉS Olyan szolgáltatásoknál használható, ahol a termék, ill. szolgáltatás értéke arányos az idovel. Tipikusan ilyenek pl. zeneszámok és könyvek letöltése. Ilyenkor a felhasználót átkapcsolják egy másik, emelt díjas vonalra.
HITELKÁRTYÁS FIZETÉS Egyre inkább terjedo megoldás, mely folyamatos reflektorfényben áll. Talán egy kicsit a média által is megnövelt fontossága miatt ejtenék róla néhány szót. Több tanulmány nevezi meg a gyakori online hitelkártya elfogadás hiányát, mint a hazai e-commerce fejlõdés gátját. A hitelkártyás fizetést is elfogadó online boltokban a vásárlók kevesebb, mint öt százaléka választja ezt a fizetési formát. Az alacsony számból látszik, hogy a probléma nyilvánvalóan nem az, hogy egy online bolt elfogad-e hitelkártyás fizetést vagy sem. A valódi ok inkább az a köztudomású tény, hogy még nincs tradíciója a hitelkártya-használatnak, a legtöbben kártyájukat csak készpénzfelvételre használják. Érdemes megvizsgálni, hogy kinek érdeke, hogy a vásárlók inkább hitelkártyával fizessenek. A vásárlónak nyilván nem érdeke, hogy elõre fizessen a termékért. Az új kereskedelmi formával szemben sokan bizalmatlanok, a postai utánvétet választva garanciát kapnak, hogy csak akkor kell fizetniük, ha a rendelt terméket meg is kapják. Több alapja van, hogy a hitelkártyás fizetés a kereskedõ érdeke, mert a megrendelt termékeket nem saját kockázatára kell kiszállítania. Ám az elõny csalóka, mivel a vásárló jóval a fizetés és a termékek kiszállítása után is következmények nélkül visszavonhatja a tranzakciót. Ebben a helyzetben a kereskedõnek meg kell oldania a terméke visszaszerzését. A postai utánvétnél a kereskedõ biztonsága, hogy a vásárló csak akkor kapja meg a rendelt árucikkeket, ha azok ellenértékét a szállítónak kifizette, így egy esetleges csaláskor csak a szállítási és csomagolási költséget kockáztatja. Szintén a hitelkártya használat ellen szól a tengerentúlon oly sok problémát okozó kártyás adatok biztonságának kérdése. Idõrõl idõre megjelennek az újságcikkekben adatok hackertámadásokról, amelyek célja az online kereskedõknél vásárlók hitelkártya adatainak megszerzése. Mivel hazánk már most is kimagasló a bankkártyával elkövetett csalások területén, kicsi a valószínûsége, hogy ez az interneten megváltozna. A már említett, házhozszállítási költséggel kapcsolatos kockázat sem jelentõs hazánkban, hiszen a szállítási költség nem igazán magas, valamint tapasztalati tény, hogy a téves, visszaküldött rendelések száma szerencsére rendkívül alacsony.
ÁRUCSERE Nehéz a különbözo áruk összehasonlíthatósága, ílymódon használata igen korlátozott.
PONTRENDSZER A pontrendszerek egyik legelterjedtebb megoldása a chipkártyás fizetés. Jó példa erre a Smart, a SuperShop és egyéb törzsvásárlói kártyák. Bonyolult infrastruktúrát igényelnek, mivel sokszor több cégnél is felhasználhatóak a gyujtött pontok.
CHIPKÁRTYÁK Drága technológia, de egyike a legbiztonságosabb megoldásoknak. Tulajdonképpen a mai mágneses hitelkártyák szerepét hivatottak átvenni, de terjedésük igen lassú.
ELEKTRONIKUS PÉNZ Elterjedoben lévo technológia. Egyik nagy hátránya az egyszeri használhatóság. A többi technológiához képest viszont elonye, hogy garantálja a hagyományos pénznél megszokott anonimitást.
TÁBLÁZAT: Fizetési módok összehasonlítása JEGYRENDELÉS AZ INTERNETEN, Nagy Gergely [[email protected]]
21. oldal
SZÁLLÍTÁSI MÓDOK Az elektronikus kereskedelem egyáltalán nem elhanyagolható kérdése az, hogy hogyan jut el a vásárlóhoz a megrendelt áru. Sokak szerint egy internetes bolt sikere a mögötte álló logisztikai rendszeren áll vagy bukik. A logisztika legkönnyebben megfogható és értelmezheto eleme az áru kiszállítása. A következokben a magyarországi helyzetet szeretném röviden összefoglalni.
Szállítási módok kategorizálása és összehas onlítás a Az internetes kereskedelem kényelmi vonzerejének egyik fõ összetevõje az otthonról történõ rendelés mellett a termékek házhozszállítása. Hazánkban jelenleg a házhozszállítások túlnyomó részét a Magyar Posta teljesíti. A házhozszállítás költségei elég magasak, de egyre több bolt kínál bizonyos összeg feletti rendelés esetén ingyenes házhozszállítást. A boltok többségében egységáron történik a szállítás, így érdemes egyszerre több terméket rendelni. Jelenleg sem a Posta, sem a hazai csomagszállító cégek nem koncentrálnak az elektronikus kereskedelem kiszolgálására. A tanulmányok és a szakemberek véleménye szerint a változást egy, csak e-commerce rendelésekre szakosodott szállító cég hozhatná meg.
SZÁLLÍTÁSI INFORMÁCIÓK Elõször a boltok oldalán található szállítási információkat vizsgáltam meg. Néhány esetben nem találtam semmilyen tájékoztatást a termékek kiszállításának feltételeirõl, csak a rendelési folyamat során volt lehetõség a szállítási költségek, és módok megismerésére (ha egyáltalán volt rá lehetõség). A kizárólag internetes kereskedelemmel foglalkozó cégek oldalain szinte kivétel nélkül konkrét információk találhatók a szállításra vonatkozóan. A megrendelés, fizetés, szállítás menetének pontos ismeretében a vásárlók bizalma megnõ a bolttal és az online rendeléssel szemben, így nagyobb az esélye annak, hogy megkezdi a vásárlási folyamatot.
A SZÁLLÍTÁS MÓDJA A termékek kiszállítását a legtöbb bolt postai úton végzi, de Budapest területén a boltok közel felében (pl. Fotexnet, Libri) futárszolgálat is igénybevehetõ. A hagyományos kereskedelmet is folytató boltok egy részében a megrendelt termék személyesen is átvehetõ. Ilyen többek közt az Intertéka, és az X-Multimédiashop.
SZÁLLÍTÁSI IDÕ A boltok egyharmada napra pontosan, körülbelül fele idõintervallumot ad meg a kiszállítás idejére vonatkozóan, míg a többi boltban nem található a szállítás idejére utaló információ. Csak kevés bolt vállalja, hogy a megrendeléstõl számított 1 napon belül szállít (pl. FókuszOnline), a többiek 2 napon belül, ill. 2 és 10 nap között teljesítik a szállítást. Bár a nyugati országokban a vásárlók különbözõ napszakok közül választhatnak, hogy mikor szeretnék/tudják a megrendelt terméket átvenni, nálunk ez még nem jellemzõ.
SZÁLLÍTÁSI DÍJ Egyes cégeknek (Magyar Könyvklub) átalánydíjas szerzõdése van a Magyar Postával, azaz súlytól, mérettõl, címvárostól függetlenül (Magyarországon belül) egységes áron szállítják ki utánvétes csomagjainkat. Más cégek a megrendelt áru értékétõl függõen (DVD Futár) vagy darabszám alapján (Zeneház) alakították ki a postai szállítás díjait. A darabszám alapján történõ kalkuláció természetesen az egyfajta típusú termékre specializálódott boltok esetében jellemzõ. A futárral történõ szállítás esetén a különbözõ boltokban attól függõen változnak a díjak, hogy a cég mely futárszolgálattal kötött együttmûködési szerzõdést. Bizonyos összegû megrendelések felett (mely általában 2.000 – 30.000 Ft közt van kereskedõtõl függõen), ill. elofordulnak olyan boltok is (Office Depot, Videopart), melyek Magyarország területén ingyen végzik a házhoszállítást. A kereskedõk boltjaiban történõ személyes átvételkor természetesen nem számolnak fel szállítási díjat.
A JEGYRENDELÉS EGYEDI VONÁSAI, NEHÉZSÉGEI A fentieket összefoglalva tehát a jegyrendelés abban különbözik más (hagyományos) termékektol, hogy • egyedi (legtöbbször konkrét helyre szólnak, tehát egy jegyet nem lehet többször eladni) • nem merül fel szállítási nehézség, elég valamiféle igazolás a rendelésrol Az egyediség elotérbe helyezi a választást. Az eladó rendszerének sokkal inkább fel kell készülnie konkurens rendelések kezelésére, mint más termékek esetében. Ez jóval összetettebb informatikai hátteret igényel, foleg, ha több különálló rendszer integrálása is szükséges. Például egy repülojegy rendelése esetén feltétlen szükséges a repülotársaság rendszerével való kapcsolattartás. Diplomamunkámban a hangsúlyt elsosorban a jegy kiválasztására helyeztem, ugyanis ezen különálló rendszerek integrálása nagymértékben függ azok felépítésétol, szerkezetétol. Ezek az információk a legtöbb esetben nem publikusak, így a konkrét tervezés is csak egy folyamatban lévo projekt megfelelo fázisában kezdodhet el. Nem beszéltem még a szállításról. A jegy tulajdonképpen nem más, mint egy igazolószelvény arról, hogy kifizettem a belépodíjat. Éppen ezért nem szükséges feltétlenül eljuttatni a vevohöz, csak más módot kell biztosítani arra, hogy a vevo igazolhassa azt, hogy kifizette a jegy árát. Ennek érdekében a vásárlónak megfelelo mennyiségu adatot kell szolgáltatnia ahhoz, hogy az eladó is megbizonyosodhasson arról, hogy vásárlási szándéka komoly. Ezen adatok mennyisége tulajdonképpen a jegy árával egyenes arányban no. Hiszen egy mozijegy vásárlásához elegendo egy emailcím megadása, amire elküldik a rendelésünket azonosító kódot, míg egy repülojegy vásárlása esetén valós név, lakcím és egyéb kapcsolatfelvételhez szükséges adatokra is igényt tarthat az eladó. Ezek nem újkeletu dolgok, csak technológia változott kissé. Telefonos taxirendelésnél is szokásos a visszaigazolás a felesleges kiszállások elkerülésére. Mivel a következokben bemutatandó mintaalkalmazás elsosorban termekben zajló eseményekre való jegyek rendelését teszi lehetové, ezért szeretnék egy kis áttekintést adni a hasonló céllal muködtetett oldalakról.
Mag yarors zági mozik helyzete A magyarországi mozik honlapjainak bemutatását egy meglepo adattal kezdeném. A kb. 25 budapesti mozi közül 2 db mozi rendelkezik saját domainnel és tartalommal, és 3 multiplex, ill. 4 muvész mozi jelenik meg egy-egy közös oldalon. Tehát a magyarországi mozik 64%-a NEM képviselteti magát az interneten. Úgy gondolom, hogy az internet remek eszközt kínál a potenciális „mozibajárók” elérésére. Itt elsosorban a fiatalokra gondolok, de más csoportok is megcélozhatók ezen olcsónak számító médium segítségével. A mozik mindezek ellenére inkább a hagyományos reklámok révén próbálnak közelíteni látogatóikhoz (plakát, újságok, rádió). De miért? Egyáltalán szüksége van a mozinak reklámra? Egy-egy új multiplex megnyitásakor hatalmas reklámáradat segít a név elterjesztésében, hogy minél ismerosebben csengjen mindenki számára. Ezután már elegendo „szinten tartani” ezt az ismertséget, hogy egy mozimusor böngészése során a nézok el tudják helyezni a mozit helyben, méretben, árban… Mit kereshet a látogató a mozi weblapján? Mozimusort nem ott keres az ember, hiszen általában csak a sajátjukat közlik (igaz a pontos terembeosztással együtt). A moziról szóló leírásokat, információkat nem hiszem, hogy bárki is rendszeresen olvasná, tehát ezért sem térnek vissza a látogatók. A jegyrendelés az már olyan szolgáltatás, amiért esetleg érdemes újra ellátogatni a honlapra, de általában ez már a film kiválasztása után történik. Plussz szolgáltatásokra lenne szükség az internetezok „csalogatáshoz”. Erre egyedül a Corvin Filmpalota oldalán láttam egy próbálkozást, ahol egy filmekhez kötodo játék keretében lehet jegyeket nyerni az eloadásokra. A törzsvásárlói kártya is ezt a törekvést erosbíti. A fenti kis bevezetoben vázlatosan le is vezettem, hogy miért képviselteti magát oly kevés mozi a hálón. Persze meglepodésem nem múlt el teljes mértékben, mert egy egyszeru bemutatkozó oldalt minden mozi „megengedhetne magának”.
Öss zefoglaló, áttekinto oldalak Tulajdonképpen az összes nagyobb portálról megtudhatjuk (ill. eljuthatunk oda, ahonnan megtudhatjuk), hogy mit, mikor és hol játszanak. Az a tapasztalatom, hogy az emberek elsosorban filmeket választanak. Ehhez keresik meg azt a mozit, mely megfelel a nézo mind árban, mind idopontban, mind helyben támasztott igényeinek. Az áttekintheto mozimusorok nagyban elosegítik ezt a választást, foleg ha a mozikról is rendelkeznek az elobb említett adatokkal. Ezek közül az oldalak közül szeretnék kiemelni két olyat, ahol bovebb információkat is szerezhetünk:
WWW.PORT.HU
Vizsgálódásom során ezt találtam a legkomplexebb és egyben legkönnyebben keresheto hírforrásnak / adatbázisnak. A komoly megjelenés Oracle adatbázisszervert, és alkalmazásszervert takar. Jól átgondolt keresési szerkezetébol adódóan, jól és könnyen összeállítható „kérdéseket fogalmazhatunk meg”. Nagyon ígéretes kezdeményezésnek találom a jegyrendeléssel való összekapcsolást, hiszen akkor mozitól teljesen függetlenül választhatjuk ki a nekünk legjobban megfelelo filmet, és egybol foglalást is tehetünk. Egyelore csak a Mammut Budai Moziközpont filmjeire foglalhatunk jegyet az oldalon keresztül.
WWW.EST.HU
Sokkal inkább a fiatalokra összpontosító portál. Ezt mind megjelenésével, mind témáival egyértelmuen kifejezi. Csak egyszerubb lekérdezések sorával juthatunk közelebb a filmekhez, de mivel a portál nem elsosorban a keresésre koncentrál, ez megbocsátható. A legfontosabb szempont az ido. Ha pl. MOST akarunk moziba menni, akkor két kattintás, és már vehetjük is a kabátunkat…
Multiplex mozik CORVIN MOZI (WWW.CORVIN.HU) • mozimusor • információk a vetített filmekrol • információ a moziról • jegyrendelés • játék Egyike az interneten legrégebben jelenlévo moziknak. Az évek óta változatlan design talán arra utalhat, hogy a kezdeti várakozások nem teljesültek. A honlap minimális változtatásokkal, fejlesztésekkel vegetál. Mindezek ellenére talán az egyik legjobb magyarországi „mozihonlap”. Itt szeretnék néhány szót ejteni az interneten való jegyrendelésrol, mely szolgáltatással a mozi elsoként jelentkezett a hazai piacon. Tulajdonképpen egy darab muködo rendszert találhatunk Magyarországon, amit több moziban is használnak, néhány megjelenésbeli különbséggel (Corvin, Puskin, Mammut). Ez a program, melynek magja egy cgi kód még nem nevezheto igazán felhasználóbarátnak. A jegy rendelése feleslegesen sok lépést tartalmaz, használatához jó, ha az ember konkrét elképzeléssel indul, és még akkor sem biztos, hogy célt ér vele. A program ugyanis az eloadás kiválasztása után önkényesen ajánl fel helyeket (jellemzoen nem a legjobbakat). Ennek nyilván biztonsági megfontolásai is vannak, de véleményem szerint igazából ez nem megoldás. A jövo abba az irányba mutat, hogy az internetes felhasználót ne lehessen korlátozni abban, hogy hány jegyet foglaljon, és hogy hova. A fenti programban a rendelés menete az, hogy az ember kiválaszt egy eloadást, kap egy „helyajánlatot”, és ha elfogadja, akkor kap egy kódszámot, amivel felveheti a jegyét (az eloadás kezdete elott fél órával).
MAMMUT BUDAI MOZIKÖZPONT (WWW.MAMMUTMOZIK.HU) • mozimusor • információk a vetített filmekrol • információ a moziról • jegyrendelés Felépítése és szolgáltatásai szinte teljesen megegyeznek a Corvin moziéval. A jegyrendelés is hasonlóan nehézkes, kicsit talán újszerubb a megjelenése. Az oldal szerkezetének alapját azonban itt is egy egyszeru menüstruktúra adja, ami elég hamar bejárható.
HOLYWOOD MULTIPLEX (WWW.INTERCOM.HU) • mozimusor • információk Kifejezetten jó megjelenésu, fiatalos és a mozifilmek stílusához igazodó design. Érdekes tény, hogy az összes magyarországi Holywood Multiplex musora és leírása a filmforgalmazó oldalán kapott helyet. A hangsúly itt a filmeken van, igazából semmilyen plussz szolgáltatást nem kínál az oldal.
Muvés z mozik ART-MOZI HÁLÓZAT (WWW.ARTMOZI.HU) • mozimusor • információ a mozikról (Puskin, Tabán) • jegyrendelés (Puskin) A „sima bemutatkozó” oldal tipikus esete, sot az www.artmozi.hu domain kifejezetten költségkímélo megoldás. Ígéretesen induló nyitólap, kicsit egyszerubb belso oldalak. A mozihálózat négy mozit foglal egy csoportba. A musort mindegyiknél megtalálhatjuk, de valószínuleg nem ezekben a táblázatokban fogjuk megkeresni az ideális filmeket.
Két mozi (Puskin, Tabán) történetét ismerhetjük meg, és ezek közül a nemrég teljesen megújult, többtermes Puskinba már jegyeket is foglalhatunk, a Corvinból és a Mammutból már jól ismert cgi program segítségével.
Egyéb jeg yrendelési lehetoségek Ezidáig csak a mozikról volt szó. Ennek legfobb oka az, hogy a piac így kívánja. A technológiai fejlodés azonban egyre kisebb anyagi befektetéssel teszi lehetové az online oldalak létrehozását, és az azokon ill. azok szolgáltatásaiban való részvételt. Így egyre nagyobb lehetoséghez juthatnak a kisebb költségvetéssel muködtetett intézmények is.
TICKETEXPRESSZ (WWW.TICKETEXPRESSZ.HU) A TicketExpressz oldala jó kiindulási pont aktuális komoly- és könnyuzenei koncerteken, színházi és sporteseményeken való részvételünk biztosítására. A választás jóval egyszerubb, mint mozifilmek esetén, ugyanis az eloadások listája sokkal kisebb, ezek közül talán a könnyuzenei események listája a legteljesebb. Ami még eltéro az oldalon az az, hogy ezen jegyek általában több árkategóriában kaphatók. Miután kiválasztottuk az eseményt és a kívánt árat (ami persze ülohelyünk pozícióját is nagymértékben befolyásolja) akár hitelkártyával is fizethetünk, feltéve ha már regisztrált felhasználók vagyunk.
Külföldi helyzet ODEON MOZIHÁLÓZAT (WWW.ODEON.CO.UK) Körülbelül egy évvel ezelott már körbenéztem külföldi oldalakon, hogy ott miképpen folynak a jegyrendelések. Ezt a kiterjedt angol mozihálózatot választottam egy tipikus példának. A mozihálózat e hónapban beindította teljesen megújult honlapját és jegyrendelo rendszerét, amit sok szempontból igen tanulságosnak találtam. A muvelet teljesen hasonló a mai magyar rendszerekben megszokottakhoz. Sok lépésben és sok megkötéssel választhatjuk ki a kívánt eloadást. A regisztrált userek egybol vásárolhatnak, míg a többieknél a kártyaszám megadása (SSL-en keresztül) kötelezo. Ilymódon korlátlan számú jegy rendelése válik lehetové.
Tolünk keletebbre is találunk példákat, hasonló kezdeményezéseket. Az alábbi két oldal Indiában található: • http://www.jamnagaronline.net/ticket/ • http://vizagcityonline.com/Movies/welcome.htm
Öss zegzés A jövo az integrált szolgáltatásoké és az integrált, komplex keresoké. Ezeket a lehetoségeket egyre több portál kínálja látogatóinak, méghozzá egyre jobb minoségben. Nincs messze az az ido, amikor már egyáltalán nem érdemes a moziknak saját honlap létrehozásába befektetni. Sokkal inkább elotérbe kerül a minél szorosabb együttmuködés ezen keresoportálokkal. Az internetes jegyrendelés lehetoségét mindenképpen a moziknak kell megoldani, mégpedig úgy, hogy a leheto legkisebb áldozattal beillesztheto legyen bármelyik kereso adatbázis-rendszerébe. Az iménti példákból látható, hogy mintaalkalmazásom sok meg nem oldott feladatra megoldást jelenthet. Igenis szükség van a ma muködo rendszerek megújítására, hogy egy sokkal felhasználóbarátabb felülettel és több funkcióval ellátott oldal 100%-osan kielégíthesse a vásárlók (jegyrendelok) igényeit. Úgy gondolom, hogy erre a mai technológia maximálisan lehetoséget ad, csak élni kell vele.
KLIENS-SZERVER PROGRAMOZÁS Az eleinte egymástól teljesen különálló és külön muködo számítógépek összekapcsolása, hálózatba kötése sok elonnyel kecsegtetett. Lehetové tette eroforrások megosztását, tehát a hálózaton belüli programok, adatok és eszközök mindenki számára elérhetové váltak, függetlenül a felhasználó földrajzi helyzetétol. Alternatív eroforrások használatával nagyobb megbízhatóságot érhetünk el. A hálózatok kialakulásában jelentos szerepet játszott az is, hogy az eroforrás-megosztás által lehetové vált hasonló teljesítményt nyújtó, de takarékosabb rendszerek kialakítása. A kisebb számítógépek ugyanis sokkal jobb ár/teljesítmény aránnyal rendelkeznek, mint a nagyok. Tízszeres sebességnövekedés elérése sokszor ezerszeres költségnövekedést eredményez. A legoptimálisabb megoldásnak az mutatkozott, hogy adjunk minden felhasználónak egy olcsó személyi számítógépet (kliens). Az adatokat pedig egy közösen használt, nagyobb kapacitású gépen (szerveren) tároljuk, így azok mindenki számára könnyen elérhetové válnak. Ezt a megoldást hívjuk kliens-szerver modellnek.
Ebben a modellben tehát az adatok egy központi helyen, az ún. repositoryban tárolódnak. Ez jó, mert biztosak lehetünk benne, hogy minden kliens egyforma adatokat lát. Használatuk azonban felvet egy-két problémát. Az elso ilyen probléma az, hogy egy szervernek kell egyszerre több (akár száz) kliens kérését kiszolgálni, méghozzá minimális késleltetési idovel. Ezen felül biztosítanunk kell az adatok konzisztenciáját, tehát egyszerre mindig csak egy változtatás lehetséges. Ezt a tranzakciós rendszer garantálja, így ha egy adatot két felhasználó egy idoben kíván módosítani, akkor egyikük kísérlete biztosan sikertelen lesz, és errol értesítést kap a rendszertol. Sok kliens kiszolgálása teljesítménybeli problémákat is felvethet, ami gondos tervezéssel ill. több szerver használatával elkerülheto. Mi is az internet? Az internetet tekinthetjük egy hatalmas kliens-szerver rendszernek. Kialakulásának jelentosebb lépéseit szeretném itt röviden összefoglalni. Kezdetben teljesen egyirányú feldolgozást valósított meg. Ha valaki kérést intézett egy meghatározott szerver felé, akkor az válaszként egy file-t adott vissza, amit a felhasználó gépe értelmezett és megjelenített. Késobb ennél már többre volt szükség. Az emberek igényelték a már meglévo kliens-szerver rendszerek összes funkcióját és az általuk kínált elonyöket (pl.: adatbázisok elérése). Szükség volt tehát bonyolultabb kérések megfogalmazására és azok szerver oldali feldolgozására. Ezek persze sokkal több biztonságtechnikai kérdést vetettek fel, mint az eredeti rendszerek esetén (pl.: egy vállalat belso hálózatában). A következo nagy lépést a böngészok megjelenése jelentette. Ezek ugyanis lehetoséget teremtettek arra, hogy ugyanazt az információt változtatás nélkül minden számítógépen meg lehessen jeleníteni, függetlenül a gép típusától, operációs rendszerétol... Eleinte a böngészo „csak egy megjeleníto” eszköz volt. Percekig is eltarthatott egy kérés pontos begépelése, ill. a véletlenül hibásan beírt címek kijavítása. Nem volt sem felhasználóbarát, sem interaktív és nem tette lehetové a legegyszerubb számítási muvelet végrehajtását sem. Viszont rendkívül biztonságos volt, ugyanis a felhasználó gépén nem lehetett hibás, vagy vírusos programokat futtatni. Késobb alakultak ki azok a szabványok, melyek egységes grafika (és animáció) megjelenítését tették lehetové, egyre felhasználóbarátabbá téve ezzel az oldalakat. A böngészok pedig nagy terhet vettek le a szerverekrol azzal, hogy lehetové tették a felhasználó gépén az adatok feldolgozását az ún. kliens oldali programozás lehetové tételével.
Kliens oldali programozás A különbözo típusú böngészok fejlodésük során közelítettek egymáshoz, meg nem is. Sajnos mindmáig rengeteg különbség lelheto fel köztük, ami megnehezíti az egységes kliens oldali megjelenítést és programozást. Tulajdonképpen minden böngészo fejlesztoje arra törekszik, hogy minél felhasználóbarátabb környezetet teremtsen a „szörfözéshez” és az internetes oldalakat minél ízlésesebben tálalja az oda látogatóknak (ezt nevezem közeledésnek). Ez a törekvés azonban sokszor túlmutat a HTML szabvány által adott lehetoségeken. Ilyenkor egyáltalán nem, vagy csak részben specifikált tagek használatával hidalják át ezt a problémát, és ez egyértelmuen a böngészo típusok távolodását jelenti. Ugyanis mivel az adott tag nem része semilyen szabványnak - csak az adott böngészo képes azt értelmezni, így ugyanaz az oldal eltéroen jelenik meg az egyes browserekben. Az alábbiakban a kliens oldali programozás lehetséges alternatíváit igyekeztem összegyujteni, melyek a mai böngészok többségében (Microsoft Internet Explorer, Netscape Navigator, Opera) rendelkezésünkre állnak:
PLUG-IN Egyike a kliens oldali programozás legjelentosebb elorelépéseinek a plug-in-ek megjelenése. Ezek ugyanis lehetoséget biztosítanak a programozó számára, hogy újabb funkciókkal gazdagítsa a böngészot. A plug-in nem más, mint egy kód, ami letöltodés után „becsatlakozik” (szó szerint: plug in) a browser megfelelo helyére. Ez után a böngészo már gond nélkül használhatja ezt az új programrészt az általa megvalósított új tevékenységekre. Segítségükkel rengeteg kézenfekvo probléma megoldható, de programozásuk már korántsem ilyen egyszeru. A hozzáérto számára azonban lehetoséget nyújt akár új kliens oldali programozási nyelvek megvalósítására is, a böngészo gyártójának tudta és beleegyezése nélkül.
SCRIPT NYELVEK (JAVASCRIPT, JSCRIPT, VBSCRIPT) A plug-inek megjelenése a különbözo script nyelvek robbanásszeru elterjedését eredményezte. A programkódot ilyenkor a HTML forrásba ágyazzuk. A böngészo (vagy annak egy plug-inje) automatikusan aktiválódik és interpretálja a programot, miközben a HTML is megjelenik. Általában elonye az ilyen nyelveknek a könnyu olvashatóság, és gyors fejlesztés, ami persze lassabb futást eredményez, mint a fordítást igénylo nyelveknél. JEGYRENDELÉS AZ INTERNETEN, Nagy Gergely [[email protected]]
33. oldal
Ezen elonyök másik oldala viszont az, hogy kódunkat bárki elolvashatja, felhasználhatja, aki letölti a scriptet tartalmazó HTML oldalt. Ha azonban a megfelelo feladatokra használjuk ezeket a kis programokat, akkor ez nem jelenthet túl nagy problémát (egy oldal jelszavas védelmét tehát nem célszeru scriptnyelvekkel megvalósítani, pedig sajnos már erre is láttam példát). Legkézenfekvobb felhasználásuk minél gazdagabb és interaktívabb felhasználói felületek (GUI: Graphical User Interface) kialakítása. A formok értékeinek ellenorzését is legtöbbször rábízzák egy-egy rövid script függvényre, így még azelott figyelmeztethetjük a felhasználót a helytelen kitöltésre, mielott a szerver a hibás lekérdezést lefuttatná.
• Javascript: Netscape által kifejlesztett script nyelv, mely a Sun által fejlesztett Java-tól teljesen külön fejlodött. Eredetileg „Mocha”-nak, majd késobb „LiveScript”-nek hívták. Késobb kapta meg mai nevét, amikor a Sun és a Netscape kapcsolata szorosabbá vált. Hasonlóságaik ellenére (pl.: szintakszis) azért alapvetoen különböznek egymástól, amit most néhány pontban össze is foglalnék: 1. Objektumorientáltság: Míg a Java egy teljes objektumorientált eszközrendszert kínál, addig a JavaScript csak objektum-alapú (object based) nyelvnek nevezheto. Ez azt jelenti, hogy lehetoségünk van objektumok létrehozására, de osztályokat (típusokat) nem definiálhatunk, így természetesen sem öröklésrol, sem polimorfizmusról nem beszélhetünk. 2. Fordítás és interpretálás: A Java nyelv fordítójával szemben (ami ugyan csak egy közbülso kódra fordít) a JavaScript esetében a program szövege kerül interpretálásra. Ez jelentosen megkönnyíti ugyan a fejlesztést, de a programok sokkal lassabban futnak és forrásuk elrejtése sem megoldható. 3. Típusrendszer: A Java szigorúan típusos nyelv, az összes változó típusát deklarálni kell, amit a fordító ellenoriz. Ezzel szemben a JavaScriptben a változóknak nincs eleve elrendelt típusuk, hanem attól teszik ezt függové, hogy éppen milyen értéket tárolnak. Ezzel egyidejuleg az objektumokra való hivatkozásokat csak akkor ellenorzik, ha erre a program végrehajtása során szükség van.
4. Kapcsolatuk a HTML-lel: A Java appleteknek nem sok közük van a HTML dokumentumhoz (bár szükség esetén elérhetoek az oldalon lévo komponensek). Egy kis ablakban futnak, mit sem törodve a környezo lappal. A JavaScript viszont szerves része az oldalnak. Nemcsak, hogy a teljes program forrása a lapon található, de a dokumentum többi részével is közeli kapcsolatban állnak. Közvetlenül hivatkozhatnak a lapon lévo elemekre, de még a böngészo megjelenését, viselkedését is befolyásolhatják.
• JScript: A korábban kialakult és szélesebb körben elterjedt JavaScript Microsoft által fejlesztett megfeleloje. Az oldalon található JavaScript kódot a Microsoft böngészoi eloször JScript kódra konvertálják és úgy futtatják.
• VBScript: A Visual Basic nyelvbol kialakított script nyelv, melyet a Microsoft fejlesztett. Tulajdonképpen a Microsoft válaszlépése a népszeru JavaScript nyelvre. Miután a Netscape nem támogatja böngészoiben, ezért alkalmazása elsosorban intranetes alkalmazásokban kap jelentoséget.
ACTIVEX Az ActiveX eredetileg a Microsoft egy platformfüggo (csak windowsos) megoldása volt. Ma már igyekeznek kiszélesíteni ezt a kört és a többi platformon is megteremteni a lehetoséget használatukra. Az Internet Explorer teljesen támogatja használatát, míg a Netscape Navigatorhoz egy plug-in letöltése szükséges. Bizonyos fokig a Java versenytársa, és a platformfüggoség megszünésével ez a verseny nagy valószínuséggel csak élesedni fog. Az ActiveX nem kötodik egyetlen programnyelvhez sem. Egy tapasztalt (windowsos) programozó minimális változtatásokkal képes ilyen komponensek írására, anélkül hogy bármit kelljen változtatnia programozási módszerein.
JAVA (APPLET) Ha a scriptekkel megvalósítható a kliens oldali programozási problémák 80%-a, akkor a Java-val a maradék 20% (ez az állítás ActiveX-re is érvényes). Általában ez a 20% az igazán „kemény dió”. A Java nem csak azért alkalmas e problémák megoldására, mert platformfüggetlen, objektum-orientált és biztonságos. Folytonosan bovítheto nyelvi lehetoségei és könyvtárai elegánsan képesek kezelni olyan általános problémákat, mint az adatbáziskezelés, hálózati programozás, többszálúság. elosztott programozás. A Java az Applet révén teszi lehetové a kliens oldali programozást. Az applet nem más, mint egy kis program, ami csak böngészo alatt képes futni. A futtatásról a böngészohöz tartozó JVM (Java Virtual Machine) gondoskodik. A HTML oldalban az <APPLET> tag segítségével tulajdonképpen egy linket készítünk a külön file-ban tárolt programhoz, ill. paramétereket is átadhatunk neki. Így az applet, mint a HTML oldal része, automatikusan letöltodik, hasonlóan pl. a képekhez. A felhasználó biztos lehet benne, hogy mindig a legfrissebb verziót használja. A letöltést alapvetoen még két tényezo gyorsíthatja. A változatlan és gyakran használt appletek ugyanúgy a böngészo cache-ében tárolódnak, mint bármilyen más HTML komponens. Ezen kívül lehetoségünk van tömörített formában átküldeni a programot a kliens gépre. Ezt a formátumot JAR-nak nevezzük (Java Archives), ami egy zip technológiával tömörített állomány. Ez a file bármilyen más internetes oldallal hasonló módon a böngészo cache-ében tárolódhat. Így egy újabb látogatás alkalmával nincs szükség a file újbóli letöltésére (feltéve, ha nem változtattak rajta). A forrás közvetlenül nem látható a kliens gépen. Egy köztes fordítási stádiumban, ún. class file formájában található a program.
BIZTONSÁGI KÉRDÉSEK A kliens oldali programozásnál alapveto biztonsági kérdések merülnek fel. Ez abból adódik, hogy programokat töltünk le az internetrol és anélkül futtatjuk, hogy tudnánk pontosan mit is csinál. A tisztánlátás érdekében nézzük végig a letöltodo elemeket, és vizsgáljuk meg azok veszélyességét: • HTML forrás, képek Ezek a komponensek nem okozhatnak semmiféle problémát, ugyanis a böngészo csupán megjeleníti oket.
• Script kódok Ezek ugyan már programok, melyeket a böngészo lefuttat, de általában csak korlátozott funkcionalitással bírnak, ezért veszélyességi szempontból nem foglalkozunk tovább velük. • ActiveX Sajnos ActiveX-el minden megoldható. Ez az egyik oldalról persze jó, hiszen olyan, mintha az ember Windows-t programozna. Semmiféle megszorítás nincsen a memóriahasználatra, filekezelésre. Másrészrol viszont bármilyen vírus, vagy kárt okozó program megvalósítható vele, így használatuk igen kockázatosnak mondható. Mi lehet a megoldás? A vírusok fejlodése és elterjedése az interneten azért ilyen mértéku, mert ez a kommunikációs csatorna lehetoséget ad a teljes anonimitásra. Ennek megszünésével mindenki felelosséggel tartozna az általa írt, ill. továbbküldött, terjesztett programok iránt. Véleményem szerint ez nagyban visszaszoríthatná a rosszindulatú és kárt okozó programok terjedését. A digitális aláírás lehet a megoldás arra, hogy nagy biztonsággal kijelenthessük, kitol is származott a kapott kód. Ez persze nem véd meg minket az olyan hibáktól, melyek a program rossz megvalósításából erednek, de mindenképpen átláthatóbb helyzetet teremt(ene). • Java applet Az applet koncepciójából adódóan normál esetben csak bizonyos keretek között használhatja fel a kliens gép eroforrásait. Egy ún. homokozóban (sandbox) fut, de pl. nem írhat a kliens gépre és a memóriának is csak egy a „homokozón belüli” területét láthatja. Azonban sokszor célunk megvalósításában gátolhatnak ezek a szigorú megszorítások. Ilyenkor az ún aláírt applettel (signed applet) átléphetünk ezeken a kereteken. Nyilvános kulcsú titkosítás használatával garantálja, hogy az applet valóban onnan jött, ahonnan azt várjuk. A Java támogatja a digitális aláírást, így ad lehetoséget arra, hogy kiléphessünk a homokozó területérol. Ebben a kis felsorolásban nem volt szó azokról a file-okról, melyeket nem a böngészo futtat. Letöltésük után ezeket mind mi indítjuk el, így azok hitelességét és vírusmentességét is magunknak kell ellenorizni. A digitális aláírás elterjedése rengeteg probléma megoldására és elkerülésére ad majd lehetoséget, de teljes biztonságot ez sem fog nyújtani. Mi van pl. akkor, ha egy program által okozott hiba csak késobb derül ki? Hogyan állapíthatjuk meg, hogy pontosan mi, és mikor okozta?
Az imént több ízben is felmerült a digitális aláírás, mint az internet biztonsági kérdéseinek egyik megoldása. Segítségükkel a szerver és a kliens között egy sokkal biztonságosabb csatorna létesítheto és visszaszoríthatók az anonimitáson alapuló támadások. Ezért szeretnék most néhány szót ejteni az egyik legelterjedtebb ilyen biztonságos kapcsolatot lehetové tevo technológiáról. • SSL (Secure Sockets Layer) Egy általánosan használt protokol, mely üzenetek biztonságos továbbítását teszi lehetové az interneten. Ehhez egy közbülso réteget használ, ami a HTTP (Hypertext Transfer Protocol) és a TCP (Transport Control Protocol) rétegei között helyezkedik el. Eredetileg a Netscape Communications Corporation fejlesztette ki az RSA** Data Security, Inc.-vel karöltve, és ma már része mind a Microsoft, mind a Netscape böngészoinek, ill. a legtöbb webszervernek. A kifejezés középso szava a kliens és szerver program között a hálózaton (vagy akár egy gépen) kiépülo socket-okon alapuló adatátvitelre utal. Az SSL az RSA nyilvános kulcsú titkosítását használja, mely tartalmazza a digitális tanusítvány használatának lehetoségét is. Ha a szerver digitális tanusítvánnyal rendelkezik, akkor a felhasználó biztos lehet benne, hogy a kapott adatok valóban onnan származnak, ugyanis az SSL garantálja mind az adatok, mind a tanusítvány biztonságos csatornán való továbbítását. Ha egy website egy SSL-t támogató webszerveren fut, akkor megadható, hogy mely oldalaknál követelje meg a klienstol az SSL használatát. Az SSL jelenleg az IETF (Internet Engineering Task Force) elé van terjesztve, mint javasolt hivatalos szabvány. A protokol egyik alternatívája a szintén sokak által használt S-HTTP (Secure-HTTP).
Szerver oldali programozás A kliensek kérésekkel fordulnak a szerver felé, a szerver feladata pedig ezen kérések (minél gyorsabb) kiszolgálása. A legtöbb kérés a webszerverek felé nagyon egyszeru: „Küldd el nekem ezt a file-t!”. A helyzet persze bonyolodik, ha a válaszhoz szükség van pl. egy adatbázis lekérdezésére. Ilyenkor (a legtöbb esetben) a kapott eredményekbol a szerver összeállít egy HTML file-t és azt küldi vissza a kliensnek. Eleinte csak szerver oldali programozással vihettünk interaktivitást oldalainkba. Ez most sincs másképpen (a kliens-szerver architektúrából adódóan), viszont sok terhet levehetünk a webszerver válláról az elobbi szakaszban tárgyalt kliens oldali programozással. Szerverünk akkor lesz gyors és hatékony, ha csak a legfontosabb kérésekkel fordulunk hozzá, és a tole kapott adatok feldolgozását lehetoség szerint minél inkább a kliens oldalon végezzük. Mit értünk interaktivitás alatt? Adott egy bolt, amely árlistáját az interneten is megjelenítette. Egy HTML oldalon felsorolja termékeit és a hozzá tartozó árakat. Egy ilyen listában igen nehézkes a keresés. Linkek használatával könnyebben mozoghatunk. Pl. különválaszthatjuk a különbözo termékcsoportokat, és így egybol megtalálhatjuk kedvenc csokink árát. De mi van akkor, ha én kedvenc csokim, kedvenc mosóporom és kedvenc csigatésztám árát szeretném egymás alatt látni, eltekintve az összes egyéb terméktol, amik teljesen közömbösek a számomra? Ilyenkor a szerverhez egy urlap (form) kitöltésével eljuttatott információk alapján a kérés pillanatában egy program segítségével lehetoségünk van a felhasználó igényei szerint összeállítani az oldalt, és azt elküldeni a kliens géphez. Az alábbiakban szeretném bemutatni a dinamikus oldalak generálását lehetové tevo legfontosabb alternatívákat:
CGI Az internet elso legnagyobb újításainak egyike a CGI (Common Gateway Interface) szabvány, amely meghatározza azokat az adatformátumokat, amelyeket a böngészok (kliens), kiszolgálók (szerver) és programok információcserére használnak. A CGI elott a Web statikus közeg volt, az információt mozdulatlan szövegoldalak és képek formájában továbbította. Egy CGI parancsállomány (script file ) olyan program, amely feldolgozza a felhasználó által bevitt adatokat, és ezek alapján készíti el a választ. A CGI tehát nem programozási nyelv, hanem – mint azt a neve is mutatja – egy szabványos felület (interface). Ilymódon szinte bármely programozási nyelvvel JEGYRENDELÉS AZ INTERNETEN, Nagy Gergely [[email protected]]
39. oldal
megvalósítható a feldolgozás és oldalgenerálás. A leggyakrabban használt nyelvek a következok: Perl, C/C++, Shell script, Tcl/Tk, Pascal. Létezo szerverekben a CGI implementálásának legegyszerubb módja a szerverrel új processzt létrehozatni, átadni az e processzben futó CGI szkriptnek a hívási paramétereket, majd az eredményül kapott lapot kiolvasni a processzbol és visszaadni azt a hívó böngészonek. Az iménti muveletekbol ill. a már szükségtelen processz eltakarításából származó muveletsor igen kis hatékonyságú volt. Azok a webszerverek, melyek elsoként alkalmazták ezt a technológiát, majdnem ugyanannyi idot fordítottak rendszertevékenységekre, mint amennyit lapok szolgáltatására.
• C/C++: A Unix/Linux rendszerek „alapnyelve” a C. Ezen a nyelven íródtak és ezen nyelv adottságainak köszönhetik stabilitásukat és gyorsaságukat. Viszonylag hardverközeli nyelv, melynek objektumorientált „testvére” a C++. A hardverközeliség sokszor igen bonyolulttá teszi a kódot, ami egy egyszeru CGI program esetén nem igazán elonyös. Használata akkor célszeru, ha feladatunk kritikus pontja a sebesség. • Shell script: Rendkívül egyszeru és frappáns megoldásokat lehetové tevo „programozási nyelv”, mely a Unix/Linux rendszerek sajátja. • Perl: Ez a nyelv a SHELL scriptek egyszeruségét igyekszik ötvözni a C gyorsaságával. Tehát egy már meglévo nyelvi eszközökre alapozott interpretált nyelvrol van szó, melynek csak a számítógép hardware adottságai szabnak határt (pl.: egy teljes file-t képes beolvasni egy string változóba, ha van elég memória). Nagyon gyors és rugalmas mintailleszto algoritmusa van szövegek keresésére és cseréjére, többek között ezért is oly kedvelt eszköz CGI-k fejlesztésére.
PHP Míg CGI írásakor teljes szabadságot kapunk (tetszoleges programozási nyelv, tetszoleges library-k), foleg túlterhelt szervereken a CGI lassabban fut, mintha a feladatot az Apache egyik saját modulja végezné. Ennek az az oka, hogy az oldal újratöltésekor egy új processz indul (másodpercenként akár többször is), amely újra felépíti az adatbázis-kapcsolatokat, lefordítja a saját nyelvére, hogy mire kiváncsi a
látogató, és csak ezután tud rá válaszolni. A PHP modulként van az Apache-ba integrálva, így a fenti idokiesés nem jelentkezik. A PHP nyelv szintaktikája a C programnyelvéhez hasonló. A kódot a html forrásba írjuk, amit a webszerver által futtatott interpreter fordít le, és az így generált oldal eredményét továbbítja a kliens felé. A nyílt forráskódú, teljesen ingyenes technika vonzó a kis és közepes méretu weoldalak készítoinek. A nyelv folyamatos fejlesztés alatt áll és egyre több lehetoséget kínál használói számára.
ASP Az ASP (Active Server Pages) tulajdonképpen egy HTML oldal, mely olyan beágyazott scripteket tartalmaz, amit a szerver az oldal elküldése elott lefuttat. A teljesen hasonló muködésu PHP és JSP alternatívája, melyet a Microsoft fejlesztett ki. A PHP-vel szemben azonban a technika elsosorban Microsoft termékekkel és Windows platformon fut. Történtek bizonyos kezdeményezések a technológia Unix/Linux rendszereken való megvalósítására, de ezek a megoldások mind sebességben, mind stabilitásban jóval alulmaradtak az „eredetihez”képest. A Chilisoft ASP nevu termék lehetové teszi ASP scriptek futtatását Linux alatt is, de drága és nem támogatja az ASP legújabb verzióját.
COLDFUSION Az Allaire cég ColdFusion nevu szerverét kínálja megoldásnak. Könnyen bovítheto API csomagokkal, könnyen elsajátítható sajátos nyelvezetével gyors fejlesztést tesz lehetové. Felhasználóbarát eszközöket kínál a teljesítmény figyelésére, a fejlesztésre és az adminisztrációra.
JAVA (SERVLET, JSP) Egy servlet nagyon hasonló módon muködik, mint egy CGI lapgenerátor. A servlet egy Java osztály, mely egy webszerverbe töltodik. A szerverhez érkezett HTTP kérésre HTML lapot vagy más felismerheto típusú választ készít és azt visszaadja a szervernek. Mivel a servlet ugyanabban a processzben és címtérben fut, mint az ot futtató webszerver, nagyon kicsi a servlet-hívással kapcsolatos processzek közti adminisztrációs munka. A szerver egyszeruen egy külön szálban meghívja a servletet
és továbbítja az eredményeket a kérést adó böngészonek. Ez sokkal gyorsabb, mint a tipikus CGI muveletsor. Mi a kapcsolat a servletek és a JSP között? A JSP oldalak jó megközelítéssel visszájukra fordított servleteknek tekinthetok: míg a servletek esetén Java kódban elrejtve szerepelnek a szöveget a kimenetre író utasítások, addig a JSP-nél éppen ellenkezoleg, a rögzített szöveg közé rejtve szerepelnek az oldal tartalmát módosító utasítások. A JSP oldalak tehát inline kódot tartalmazó HTML/XML oldalaknak tekinthetok, ami azért is fontos, mert így az oldal ASP-re vagy JSP-re felkészített webszerkeszto programokkal is manipulálható. A JSP elonyei elsosorban az olyan oldalaknál mutatkoznak, amelyek relatíve sok fix szöveget, és kevés kódot tartalmaznak. A Sun mérnökeinek egyik bevallott célja a JSP megalkotásával az volt, hogy elrejtsék a servletek írásának nehézségeit a programozásban kevéssé jártasak elol azáltal, hogy szétválasztják az oldal programozási részét a tartalomtól és a design-tól. Ez utóbbit ugyanis manapság általában külön tartalomkészítok és webdesignerek készítik, számukra a JSP egyszeru, XML-szeru elemeken keresztül biztosít hozzáférést a szerveroldali komponensekhez (JavaBeans, EJB), elrejtve elolük a tényleges programkódot. A prezentációs- és az alkalmazáslogika ezen szétválasztása a JSP legnagyobb elonye a servletekhez képest: nem csak munkamegosztást tesz lehetové, de izolációt is jelent, ugyanis így nem keveredik az oldal tartalma a programkóddal. A ketto így külön-külön fejlesztheto a véletlen felülírás veszélye nélkül.
1. A kliens elküldi a kérést a szervernek. 2. A web- vagy alkalmazásszerver a .jsp kiterjesztés alapján felismeri, hogy egy JSP file-ra vonatkozik a kérés, így továbbítja azt a JSP containernek, ami lehet a webkiszolgáló része, vagy külön plug-in. 3. Mivel ez volt az adott dokumentumra vonatkozó elso kérés, a JSP fordító a .jsp forrásból sorról-sorra haladva eloállítja a neki megfelelo java servlet forrását. 4. A java kódot a javac fordítóval lefordítja egy .class fileba. (Ezért szükséges, hogy a J2SE-beli tools.jar része legyen a CLASSPATH-nak.) 5. Inicializálja a servletet, majd a servlet a kérést megkapva eloállítja az oldal végleges szövegét. 6. Ami aztán eljut a klienshez.
A trükk tehát egész egyszeruen annyi, hogy a JSP egyszerubb, szövegvezérelt formátumából egy specializált fordító servlet kódot készít, és valójában ez szolgálja ki a kérést. Ez a plusz fordítás természetesen többletterhet, és lassabb válaszidot jelent, de csak az elso kérés kiszolgálásakor jelentkezik, a további kérések ugyanis már egyenesen a servlethez továbbítódnak. Van mód az oldal elofordítására is, így már az elso kérés kiszolgálása sem lesz lassabb.
Miért használjunk mégis servleteket appletek helyett? A kliens oldali programozásról szóló részben éppen azt ecseteltem, hogy lehetoleg minél több feladatot adjunk át a kliensnek, csökkentve ezzel a szerver feladatait. A lehetoség megvan arra, hogy mindent elvégezzünk a kliens gépen, azonban van néhány megfontolandó érv, ami mégis szükségessé teszi a servleteket, sot sok esetben így biztonságosabbá és gyorsabbá tehetjük alkalmazásunkat.
• Biztonság A sandbox (homokozó) elvbol következoen bizonyos feladatokat csak digitálisan aláírt applettel oldahatunk meg, ráadásul a böngészo típusa és verziója sem közömbös a kód futtatásakor. Servlet-ek esetén a standard HTML komponensek használatával a generált oldal kevésbé lesz érzékeny a használt böngészo típusára. • Forráskód Egy másik fontos biztonsági szempont a szellemi tulajdon védelme. Minden végrehajtható program, amelyet egy felhasználó gépére engedünk, ki van téve annak, hogy visszafejtik. Bár léteznek programok, melyek nehezebben fejthetok vissza, nincs olyan létezo vagy elképzelheto rendszer, mely lehetetlenné tenné ezt. Egy vetélytárs keveset nyerhet azzal, hogy visszafejti GUI kódunkat, így egyszeru alkalmazásoknál kicsi ez a kockázat. Olyan programoknál azonban, melyek jelentos mennyiségu üzleti logikát tartalmaznak, mint például minosíto és elemzo rendszerek, már sokkal nagyobb a kockázat. Ezeknél a rendszereknél a vetélytárs rengeteget nyerhet a végrehajtható kódunk visszafejtésével, ugyanis ebbol megtudhatja, hogy mit csinál és hogyan van összeállítva alkalmazásunk. A servletek jó rejtekhelyet biztosítanak a saját szellemi tulajdonnak. Mivel a servlet sohasem hagyja el a webszervert, így nincs kitéve a visszafejtésnek. A kliens csak a servlet outputját látja, és nem azt a folyamatot, melynek eredményeképpen létrejött.
• A fejlesztés egyszerusége Azoknál az alkalmazásoknál, ahol csak egyszeru szöveges vagy táblázatos output generálódik, egy applet gyakran túl eros. Sok esetben az eredmények megjelenítéséhez boven elegendo a HTML. Ezekben az esetekben a servlet jobb megoldás lehet az appletnél, mert az alkalmazás fejlesztéséhez szükséges ido jóval rövidebb. Tehát, ha nincs szükségünk az applet által nyújtott GUI és helyi feldolgozás elonyeire, akkor a servlet jobb választás lehet. • Hálózati korlátozások A fejlesztés egyszeruségén túl a fent említett esetekben a sávszélességgel is spórolunk, ugyanis egy gyakran több száz kByte-ot fogyasztó, grafikával díszített applet helyett egy egyszeru, néhány kByte-os HTML táblázatot kell csak letölteni. Egy 28.8-as modemet használó felhasználó szemszögébol ez igenis fontos.
Öss zehas onlító táblázat Az alábbi táblázatban a kiválasztott szempontok szerint rangsorolom a szerver oldali programozást lehetové tévo technológiákat. Ez a rangsor a megjelölt forrás alapján, de sok esetben személyes tapasztalatok révén alakult ki. A táblázatban a technológiákat A, B és C csoportba soroltam, melyek közül A a legjobb „osztályzat”. Az összehasonlítást kicsit megnehezíti, hogy az alábbi megoldások alapvetoen két nagyobb csoportba sorolhatók (ez maga az elso szempont). A CGI és a SERVLET tulajdonképpen egy különálló program, melynek eredménye egy HTML oldal. A PHP, ASP és JSP kódok pedig magán a HTML oldalon találhatóak. Az egyes programsorok eredményei beékelodnek a statikus HTML forrás megfelelo helyére. A JSP-t és a SERVLET-et mégis egy kategóriába tettem, ugyanis mint azt már korábban is írtam a webszerver a JSP-t elso futásakor SERVLET-té fordítja, így tulajdonképpen csak a kódolás technikája tér el.
CGI Típus
ASP
CFM
PHP
JSP
beágyazott
beágyazott
beágyazott
beágyazott
A beágyazott típus azt jelenti, hogy a kódot a HTML forrásba írjuk. Egyedül a CGI és a servlet nem ilyen. A HTML forrásba ágyazott kódok nagy elonye, hogy grafikus szerkeszto programokkal is nagyon jól és könnyen kezelhetok. Kialakulás
A
B
C
C
C
A technológiák „kora” (A-val jelöltem a legöregebbet, míg C-vel a legfiatalabbakat). Sebesség
B
B
B
B
B
A megoldások sebessége, teljesítménye. Nehéz e kérdésben objektívnak maradni, hiszen minden gyártó a saját termékét hozza ki gyoztesnek. Ezért a pontos sorrend felállítása helyett inkább néhány megjegyzést tennék. A tesztek eredményét alapvetoen meghatározza a hardware, az operációs rendszer, a webszerver, az adatbázisszerver, a futtatott alkalmazás és ezek konfigurációja. Az egyes technológiák más és más feladatoknál érhetik el optimális sebességüket. Napjainkban az internetes alkalmazásoknál sokszor nem is elsosorban azok sebessége, mint inkább a hálózati sávszélesség lehet a szuk keresztmetszet.
A technológia platform-, ill. webszerver-függosége. Minden technológia használható a két legjellemzobb platformon, de a környezet sok eltérést tartalmaz. Egyedül a Java technológia teszi lehetové a kódok operációs rendszerek közötti maximális hordozhatóságát. Fejlesztés
B
B
B
B
B
A fejlesztés gyorsasága ( ≈fejlesztés ára) Ez is egy rendkívül szubjektív szempont. A fejlesztés két alapveto komponense (tervezés, implementálás) aránya nyilván eltéro az egyes technológiák esetében. A cél a minimális idoráfordítás, de emellett a késobbi továbbfejlesztéseket és javításokat nagymértékben megkönnyítheti a gondos tervezés. A Java ezen tervek rendkívül gyors implementálására ad lehetoséget. Ár
A
B
B
A
A
A technológia ára. Az ASP és a ColdFusion kivételével ingyenesek, így sokkal könnyebbé válik a tervezés, és a finanszírozásból adódó korlátok nem befolyásolják a termék minoségét. API-k
A
B
B
B
A
A rendszerek bovíthetosége. E tekintetben a Java kiemelkedo lehetoségeket nyújt a fejlesztok számára. Eszközök
B
B
A
C
C
A fejlesztést segíto eszközök. Az ingyenes technológiák esetén folyamatosan készülnek ingyenes fejlesztoeszközök, de emellett sorra jelennek meg a nagyobb cégek (drága) megoldásai is, melyek a fejlesztoi munkát szeretnék könnyebbé tenni.
Az elterjedtség vizsgálatára egy igen egyszeru, ám nem teljesen pontos módszert választottam. Két nagy keresoben néztem meg az egyes kiterjesztésekre adott találatok számát. Ez a módszer elsosorban a java alkalmazások számában mutathat jelentosebb eltérést, hiszen a servlet-eknél egyáltalán nincs megkötés az elnevezés tekintetében. Az adatok alapján kijelenthetjük, hogy az elterjedtség szoros összefüggésben áll a technológia „korával”. Altavista: url: jsp [152.706], url: servlet [185,643] url: cfm [6,020,415] url: cgi [41,366,938] url: asp [15,005,489] url: php [416,444], url: php3 [1,020,626], url: phtml [359,194] Google: allinurl: jsp [1,500,000], allinurl: servlet [1,560,000] allinurl: cfm [9,490,000] allinurl: cgi [50,700,000] allinurl: asp [33,800,000] allinurl: php [19,400,000], allinurl: php3 [8,510,000], allinurl: phtml [428] TÁBLÁZAT: Szerver oldali technológiák összehasonlítása
TICKETOFFICE C él A TicketOffice rendszer végso célja egy olyan portál létrehozása, mely egységes felületet és lehetoséget nyújt jegyek értékesítésére, mégpedig a pontos hely megjelölésével. A rendszer tervezésekor törekedtem az összes lehetséges funkció figyelembevételére és a könnyu bovíthetoségre. Az így kapott (funkció)halmazból építettem fel egy portált, melyben a legfontosabb részeket valósítottam meg. Jelen alkalmazás az egyes részek funkcionalitását demonstrálja, és ezzel minden lényeges elem helyességét igyekszik bizonyítani. Az alábbi ábrán jól látható a rendszer, és a hozzá kapcsolódó különbözo típusú kliensek:
PROVIDER A szolgáltató, aki a rendszert üzemelteti.
TICKET_OFFICE
INTERNET
A jegyrendelõ rendszer.
CLIENT_SELLER Azok az eladók, akik a rendszert igénybevéve értékesítik szabad jegyeiket.
CLIENT_BUYER Azok a vásárók, akik a rendszert igénybevéve tesznek foglalást.
Elozetes meggondolás ok A mozik honlapjain ma muködo rendszerek funkcióit igyekeztem úgy bovíteni, hogy alkalmassá váljon mindenféle teremben zajló esemény kezelésére. Csak példaképpen álljon itt egy rövid felsorolás: • színház • opera • mozi • sportesemény • konferencia
MIBEN HOZ ÚJÍTÁST A MINTAALKALMAZÁS? Elsosorban a vizuális megjelenítésben, de tartalmaz olyan funkciókat is, melyek pl. egy mozijegy rendelésénél fel sem merülnek. • Árkategóriák Operában, színházakban, sporteseményeken a választás egyik fontos szempontja lehet a jegy ára. A rendszer 100%-osan támogatja ezen árkategóriák kezelését és megjelenítését. • Megjelenítés A jelenlegi jegyrendelo rendszerek nem támogatják az ülo- és állóhelyek vizuális megjelenítésén alapuló választást. Ilyen információkat legjobb esetben is csak a választási folyamat végén kapunk, és azt már nem befolyásolhatjuk. A TicketOffice rendszer megfordítja a sorrendet, és lehetoséget ad a térbeli információk felhasználására a választás folyamatában. • Választás A jegyek kiválasztását megelozoen a rendszer felhasználóbarát felületet nyújt a megfelelo eloadás megjelölésére is.
MEGLÉVO RENDSZER INTEGRÁLÁSA Óriási kérdés az, hogy a mintaalkalmazásban kialakított önálló rendszer hogyan illesztheto a létesítmények már meglévo és muködo rendszeréhez.
• Online kapcsolat A mozi, vagy egyéb létesítmény rendszerének módosításával kialakítható egy online kapcsolat a két adatbázis között, de ez igen jelentos kommunikációt igényel. Önálló laboratóriumom során megvalósítottam egy tesztkörnyezetet, mely egy internetes (PHP) rendszert csatlakoztatott egy szokványos intranetes alkalmazás alapját szolgáltatható MS Access adatbázishoz. A kapcsolat alapja az ODBC technológia, melynek segítségével a legkülönfélébb adatbázisok is elérhetok és összekapcsolhatók. A megoldás mindenképpen lassú (a felhasznált technológiából adódóan), és egy bizonyos forgalom felett nagyon nehezen tartható kézben. • Mozi oldalán lévo szoftver módosítása Nagyobb mértéku módosítással kevesebb kommunikációval is megoldható a kapcsolat. Ehhez bizonyos önálló döntésekre képes programrészletekre van szükség, de ez pont a szabad választás lehetoségétol fosztja meg az embert. Például, ha a jegyet választás közben már lefoglalták, akkor egy bizonyos intervallumon belül a rendszer ajánl helyette másikat. • Egyéb megoldások Offline megoldásnál nincs szükség állandó kapcsolatra. Ez az alternatíva megkímél minket a rendszerek integrálásának oly nehéz problémájától. A létesítmény elore meghatározott és saját rendszerében félrerakott jegyeket kínál eladásra az interneten, a többit pedig a már jól megszokott csatornáin értékesíti. Egyéb információ híján a mintaalkalmazás ezt valósítja meg, hiszen semilyen már meglévo rendszerrol nem rendelkeztem elég adattal.
Specifikáció Az alábbi táblázatban azon feladatokat (leendo szolgáltatásokat) sorolom fel, melyeket a tervezett rendszer megvalósítana. A táblázat második oszlopa a mintaalkalmazás ezen funkciójának rövid leírását tartalmazza.
FUNKCIÓ
MINTAALKALMAZÁSBAN MEGVALÓSÍTOTT
Testre szabható Az adatbázis felépítésénél már számoltam azzal, hogy a termek, alaprajzok termek alaprajza a késobbiekben minél inkább testreszabható legyen. A terem hátterének megadásával és a székek képeivel és színeivel ez 100%-osan megteheto. Árkategóriák, szerkesztése
Minden jegyet eladni szándékozó ügyfél megadhatja, ill. folyamatosan változtathatja árait egy megadott form segítségével (editprice.jsp).
Eloadások szerkesztése
Minden jegyet eladni szándékozó ügyfél folyamatosan bovítheti azon események számát, melyekre jegyet szeretne értékesíteni (editaction.jsp).
Musorok szerkesztése
Az ügyfél számára rendelkezésre álló események ido- és térbeli elhelyezésére szolgáló form, melynek kitöltésével és elfogadásával minden felhasználó számára lehetoség nyílik a helyfoglalásra (editprogram.jsp).
Fizetési módok közüli választás
A mintaalkalmazás megvalósítása során nem foglalkoztam a
Események keresése
Az aktuális eloadások kilistázásán kívül (actual.jsp) lehetoség van egy összetett form kitöltésével keresgélni az adatbázisban lévo események között (search.jsp).
Statisztikák
A statisztikák alapja a következetesen naplózott muveleteken alapszik. Az ebbol való igény szerinti információnyerés a jövo
készítése
konkrét fizetés folyamatával. Az adatbázisban minden adat adott ennek késobbi megvalósítására.
megvalósítandó feladata. TÁBLÁZAT: A mintaalkalmazásban megvalósított funkciók meghatározása
FEJLESZTOESZKÖZ Az elozo fejezet eredményeit felhasználva a JAVA programnyelv használata mellett döntöttem. • Így egységes nyelvet használhatok a kliens és szerver oldal programozásához. • Platformfüggetlensége nagy elonyt jelent az interneten. • Rengeteg API segíti a késobbi fejlesztéseket. • Az objektumorientált technika tervezési módszereit felhasználva tervezhetek és ezzel csökkenthetem az implementálásra fordítandó idot. • Minden esetben 100%-osan hordozható kódot kapok eredményül.
A fejlesztéshez a Sun oldaláról letöltheto fejleszto eszközöket és API-kat (Application Programming Interfaces) használtam: • JavaTM 2 SDK, Standard Edition, v 1.3 Ez tartalmazza a Java 1.3-as verziójának fejlesztoi csomagját (JDK 1.3).
ÁBRA: JavaTM 2 SDK, Standard Edition v. 1.3 blokksémája Az elozo verziókhoz képest újabb funkciókkal bovült, és sokkal nagyobb teljesítményre képes. • JavaTM Servlet Servletek használatával egy könnyen kezelheto módszert kapunk arra, hogy a webszerver funkcióit kibovítsük. JEGYRENDELÉS AZ INTERNETEN, Nagy Gergely [[email protected]]
52. oldal
• JavaServer PagesTM A JSP technológia segítségével a servletekben implementált objektumok, metódusok HTML forrásba ágyazott Java kóddal könnyedén elérhetoek. A megjelenített oldalak sokkal jobban áttekinthetoek és szerkeszthetoek. • JDBCTM A JDBC (Java Database Connectivity) egy adatbázisfüggetlen API, mely lehetové teszi Java programok számára, hogy a legkülönfélébb adatbázisokkal kommunikáljanak. Az API szolgáltatásait három csoportba lehet sorolni: ° Összekapcsolódás a relációs adatbázissal ° SQL utasítások végrehajtása ° SQL lekérdezések eredményeinek feldolgozása A JDBC használatával programjaink nemcsak platformfüggetlenek maradnak, de adatbázis-kezeloktol függetlenekké is válnak.
Az alábbi felsorolásban azokat a Sun termékeket említem meg, amik a legnagyobb segítséget nyújthatják a rendszer továbbfejlesztésében: • JavaMailTM • JavaTM Electronic Commerce Framework • JavaTM Telephony API (JTAPI) • Wireless Telephony Communication APIs (WTCA)
WEBSZERVER Orion Application Server (http://www.orionserver.com) Olyan java alapú webszerver, mely teljesíti a Sun által kiadott specifikációkat, mindemellett nem kereskedelmi fejlesztés esetén a teljes program ingyenesen letöltheto. Egyszeru használatát demonstrálandó idézem a weben is megtalálható dokumentációból a szerver telepítésének útmutatását: 1. Unzip the orion package. 2. Copy the jdk tools.jar file to the Orion directory. 3. Run the orion.jar file in the orion/ dir (orion.jar is an executable jar, so java –jar orion.jar will start it) (if you need to run on another port than port 80, edit the config/default-web-site.xml file) A program alapja láthatóan a Sun által kifejlesztett JDK (Java Development Kit). A szerver és az összes konfigurációt elosegíto kis program mind java-ban íródott, és telepítése kitunoen példázza a nyelv platformfüggetlenségét. A konfigurációs file-ok mind xml formátumúak, ami azt jelzi, hogy már a fejlesztés során a jövore is gondoltak.
ADATBÁZIS SZERVER MySQL (http://www.mysql.com) Nyílt forráskódú, ingyenes relációs adatbáziskezelo. Mindemellett gyors, megbízható és egyszeruen kezelheto. Gyorsasága persze relatív, és sok szempontból bizonyára alulmaradna a drága, tranzakciós adatbázis-kezelokkel szemben (Oracle, MSSQL). Mindemellett a kis- és középméretu website-ok közkedvelt eszköze, ugyanis az ilyen oldalakon sokkal fontosabb a lekérdezések válaszideje, mint a tranzakciós muveletek gyorsasága.
A táblák leírása A mezok felsorolásánál minden esetben vastag betuvel jelöltem az elsodleges kulcsot (vannak táblák ahol ez több kulcsból tevodik össze).
CLIENT (AZ ÜGYFÉL ADATAIT TARTALMAZÓ TÁBLA) A rendszerhez kapcsolódó, jegyet árusító ügyfelek (CLIENT_SELLER) legfontosabb paramétereit tároljuk benne. Az itt létrehozott elsodleges kulcs (client_id) sok kapcsolatban kap majd jelentoséget. client_id általános adatok (name, address, phone, fax, email, internet...) igényelt szolgáltatások (pl.: fizetési mód, jegyek felkínálásának módja) hozzáférés (username, password)
PRICE (AZ ÁRKATEGÓRIÁKAT TARTALMAZÓ TÁBLA) Az ügyfél meghatározhatja és módosíthatja a különbözo kategóriájú jegyek árát és azok megjelenési paramétereit (pl.: szín). Minden ügyfélnek minimum egy ilyen kategória létrehozása szükséges price_id client_id price currency description color
(egy client csak az általa bevitt kategóriák közül választhasson)
ROOM (A TERMEK TULAJDONSÁGAIT TARTALMAZÓ TÁBLA) Itt tároljuk azokat az attribútumokat, melyek egy terem egészére vonatkoznak. Ilyen pl. a terem neve, a megjelenítési paraméterek (háttérszín, háttérkép), ill. a maximálisan foglalható jegyek száma. room_id client_id shortname longname max_order picture color
(egy client csak a saját termei közül választhasson)
CHAIR (A TERMEK ALAPRAJZAIT TÁROLÓ TÁBLA) A tábla adatait felhasználva történik a székek kirajzolása. Az ezt végzo program (applet) a price_id, és a SHOW_ACT táblából származó status mezo alapján tudja, hogy a megadott pozíciójú széket milyen színnel és tulajdonságokkal jelenítse meg. room_id chair_id price_id position description quantity
(terem azonosító) (szék azonosító) (kategória azonosító) (x1, y1, x2, y2, x3, y3, x4, y4 VAGY x, y, alfa) (a „szék”által reprezentált helyek száma)
ACTION (AZ ESEMÉNYEKET LEÍRÓ TÁBLA) Minden ügyfél lehetoséget kap saját eseményeinek felvitelére és szerkesztésére. Ezekhez csak o kap hozzáférést, míg lesznek mindenki számára elérheto események, ami pl. mozik esetében hasznos (ugyanis nem kell mindenkinek külön-külön felvinni az éppen aktuális filmek történetét, szereploit...) action_id type_id client_id upload_date title description
(a létrehozás dátuma, hogy a „friss”eseményeket kiszurhessük) (rendezo, foszereplok...)
TYPE (AZ ESEMÉNYTÍPUSOKAT LEÍRÓ TÁBLA) Olyan törzsadatokat tartalmaz, melyek az események típusáról adnak információt. type_id type
(film, színdarab, komoly-könnyu koncert...)
PROGRAM (A MUSOROKAT TARTALMAZÓ TÁBLA) Ez a kapcsolótábla rendeli össze az eseményeket, a termeket és az idopontot. A musor véglegesítésekor jönnek létre a SHOW_ACT táblában az eloadásnak megfelelo rekordok és onnantól kezdve bárkinek lehetosége nyílik a rendelésre. program_id client_id action_id show_id date time
(az eloadás dátuma) (kezdési idopont)
SHOW_ACT (AZ ELOADÁSOK FOGLALTSÁGÁT TARTALMAZÓ TÁBLA) Ez a tábla a jegyrendelés lelke. Ennek konzisztenciája és maximálisan rövid válaszideje (gyorsasága) elengedhetetlen a rendszer helyes muködése érdekében. Itt nyílik lehetoség esetleg más tulajdonságok tárolására is. Pl.: fizetve/rendelt/interneten keresztül rendelt... show_id room_id chair_id
(eloadás azonosító)
status
(foglalt/szabad, ill. hány szabad hely van még az adott pozíción)
További táblák A fenti táblák (entitások) azok, amelyek a mintaalkalmazás elkészítéséhez is feltétlen szükségesek voltak. Hamar belátható azonban, hogy az alábbi táblák nagyban megkönnyíthetik a rendszer majdani továbbfejlesztését és karbantartását:
ACCESS (A TÁBLA)
RENDSZERHEZ VALÓ HOZZÁFÉRÉSEK ADATAIT TARTALMAZÓ
Akár többszintu jogosultsági rendszer is kialakítható, ha a különbözo azonosítókhoz jelszavakat és jogosultságokat rendelhetünk. Ennek adminisztrálását tenné lehetové ez a tábla.
SHOW_OLD (A MÁR NEM AKTUÁLIS ELOADÁSOKAT TARTALMAZÓ TÁBLA) Pontosan a SHOW tábla kiemelt szerepe miatt fontos, hogy a már elavult eloadások idorol idore áttöltodjenek máshova. Így nem veszítünk információt és a tábla mérete sem no túlságosan meg. Szerkezetét tekintve teljesen megegyezne a SHOW_ACT táblával.
ORDER (A FOGLALÁSOKAT REGISZTRÁLÓ TÁBLA) A késobbi pontos statisztikák készítéséhez ebben a táblában gyujthetnénk a rendelések pontos adatait. order_id show_id ticket_number chair_ids
A rendszer „lelke”a SHOW_ACT tábla. Lekérdezésének gyorsasága kulcsfontosságú, hiszen az összes eloadás foglaltságának aktuális állapotát tartalmazza. Éppen ezért csak a helyek egyedi azonosítóját (show_id + room_id + chair_id) és az azok állapotát jellemzo status mezot tartalmazza. A megjelenítéshez felhasználjuk még a CHAIR táblát. A gyorsaság növelése érdekében a már nem aktuális eloadások SHOW_OLD táblába történo folyamatos áttöltésérol kell gondoskodnunk.
PORTÁL FELÉPÍTÉSE Menüstruktúra Minden oldal fejlécén szerepel az 5 fomenüpont, így bárhonnan eljuthatunk a honlap bármely részére. Ez alól kivételt képeznek az adminisztráció formjai, ugyanis ezek eléréséhez bejelentkezés szükséges. Ha a felhasználó kihagyja ezt a lépést, akkor e menüpont alatt csak a login.jsp-re mutat link, ill. a registration.jsp form kitöltésével igényelhetjük felvételünket a rendszerbe.
ÁBRA: A fomenü
Az 5 menüpont funkciója a következo: • Adminisztráció Termek, árkategóriák, események és a musor szerkesztése. Ezek az oldalak csak érvényes username/password párossal érhetoek el. • Jegyrendelés Az eloadás kiválasztása után megjeleníthetjük annak aktuális foglaltságát és elküldhetjük rendelésünket. • Statisztika Ez a menüpont a késobbiekben fog jelentoséget kapni. • Dokumentáció Ezen diploma tartalmát tölthetjük le több formátumban is. • Segítség A honlap rövid leírását tartalmazza. A menüponthoz nem tartozó oldalak a dátum, idopont és szín kiválasztásánál kapnak jelentoséget, hiszen az oket meghívó oldal mezoinek kitöltését könnyítik meg. A többi oldal minden esetben elérheto a fejlécben található menük segítségével. JEGYRENDELÉS AZ INTERNETEN, Nagy Gergely [[email protected]]
60. oldal
LOGIN.JSP A bejelentkezõ oldal. (új session létrehozása)
USER LOGGED IN
LOGOUT.JSP A session "eldobása".
EDITPRICE.JSP Árkategóriák, és az azokhoz tartozó színek szerkesztése.
EDITACTION.JSP Események szerkesztése.
EDITPROGRAM.JSP Mûsor szerkesztése.
EDITROOM.JSP Termek szerkesztése.
INDEX.JSP Induló oldal, aktuális hírekkel, információkkal.
SELECTCOLOR.JSP Szín kiválasztása.
SELECTDATE.JSP Dátum kiválasztása.
SELECTTIME.JSP Idõpont kiválasztása.
UNSUCCESS.JSP A foglalás sikertelenségét jelzõ oldal.
HELP.JSP Segítség.
ABOUT.JSP Rövid leírás az oldalról.
ACTUAL.JSP Az éppen aktuális elõadások kilistázása.
SEARCH.JSP Elõadások keresése több szempont alapján.
SHOWROOM.JSP A kiválasztott elõadás megjelenítése
SUCCESS.JSP A foglalás sikeressségét jelzõ oldal.
ADMINISZTRÁCIÓ MENÜPONT JEGYRENDELÉS MENÜPONT SEGÍTSÉG MENÜPONT NEM MENÜPONTHOZ TARTOZÓ OLDALAK
HTML-JSP oldalak Feladatuk a portál dinamikus és statikus oldalainak megvalósítása. A termet megjeleníto appletet leszámítva minden HTML oldalt JSP technológiával generálok. Ennek segítségével nagyon egyszeruvé válik az oldalak szerkezetének áttekintése. Példaképpen a fejléc és lábléc megvalósítását említeném. Ezek, miután minden oldalon egységesek külön template file-okba kerültek. Az oldal összeállításakor egy egyszeru <%@ include file="templates/navbar.html" %>
paranccsal beillesztem és ezután már foglalkozhatok az oldal lényegi funkciójának megvalósításával. Hasonlóképpen kerül a lábléc is a dokumentumba. Így nem csak egyszeruen áttekinthetobb az oldal, hanem bármilyen változtatás esetén elegendo a template file-ban elvégezni azt, és az összes oldalon egybol láthatóvá válik a módosítás.
JAVASCRIPT MENÜRENDSZER A legördülo menük megvalósításához layeres technikát és JavaScriptet használtam. Minden menüponthoz definiáltam egy layert, amik a legördülo részen lévo almenüket és a hozzájuk tartozó linkeket tartalmazzák, ezen kívül még 2 „segédlayerre” volt szükségem a megvalósításhoz. Az alábbi kódok jobb megértése érdekében leírom a layerek neveit: administration, ticketorder, statistics, documentation, help, mainmenu (segéd), menucloser (segéd). Ezen layerek visibility tulajdonságát változtatom az egyes egéresemények hatására, így mindig csak 1 menü almenüi láthatóak. Íme egy layert megvalósító HTML kódrészlet, ahol megadjuk annak pontos koordinátáit és a visibility tulajdonság kezdo értékét:
Az almenük megjelenítését a menüpont onMouseOver eseménye váltja ki. Ilyenkor egy az alábbihoz hasonló függvényhívás történik: onMouseOver="MM_showHideLayers('administration','','show','ticketord er','','hide','menucloser','','show','statistics','','hide','documen tation','','hide','mainmenu','','show','help','','hide')"
Így a segédlayerek és egy almenü kivétellel az összes layert eltüntetjük. A mainmenu layer tartalmazza a menüpontokat, így annak mindig láthatónak kell lennie. A menucloser pedig egy üres layer, ami arra szolgál, hogy ha kiléptünk egy látható layer területérol, akkor a menucloser onMouseOver eseményére el tudjuk egybol tüntetni. ÁBRA: Javascript menürendszer
KERESÉS Az alábbi ábra a keresés paramétereit beállító form felépítését mutatja.
CLIENT
CITY
ROOM DATUM
DATUM_FROM
DATUM_TO
IDOPONT
IDOPONT_FROM
IDOPONT_TO
NEW_ACTION ACTION
TYPE
ÁBRA: Keresés
A kereso form segítségével igen változatos lekérdezésekre kaphatjuk meg a feltételeknek megfelelo eloadások listáját. Az eloadások felsorolásának utolsó mezojében található „Jegyrendelés” linkre kattintva pedig már láthatjuk is az aktuális foglaltságot, és válogathatunk a még szabad helyek között.
A formon található legördülo listák között találhatóak statikusak (DATUM, IDOPONT) is, de jó részük adatbázisból töltodik fel (CLIENT, ROOM, NEW_ACTION, TYPE). Erre a muveletre a JSP remek segédeszközöket kínál. Eloszöris két osztályt készítettem: • Search Ezen osztály segítségével állítom össze a keresés eredményét adó SQL utasítást, és itt található az a metódus is, ami a legördülo listák tartalmát szolgáltatja. • SearchResult Egy speciális osztály, mely a keresés eredményeit láncolt lista formájában adja vissza.
Search Attribútumok: query queryresult client room datum idopont action type Metódusok: getAll setAll canSearch() doSearch() buildList()
SearchResult Attribútumok: client room datum idopont action type Metódusok: getAll setAll
ÁBRA: JSP bean-ek
E két osztály felhasználása pedig a következoképpen történik: <jsp:useBean id="search" class="ticket.Search" scope="page" /> <jsp:setProperty name="search" property="*" />
A jsp:useBean akcióval, vagy script-elemmel létrehozott beanek tulajdonságainak beállítását szolgálja a jsp:setProperty akció. Két kötelezo attribútuma a name, és a property, elobbi a kérdéses bean neve (ami megegyezik a jsp:useBean id attribútumának értékével, ha azzal hoztuk létre), utóbbi a beállítandó tulajdonság neve. A property értékeként megadható "*" is, ez esetben minden olyan property értéke automatikusan beállítódik a megfelelo setProperty() metódussal, amelyikhez a JEGYRENDELÉS AZ INTERNETEN, Nagy Gergely [[email protected]]
64. oldal
ServletRequest
objektumban azonos néven tárolva van valamilyen nemüres
érték. (Ez jól használható formok paramétereit tároló beanek feltöltésére). Ugyanez a mechanizmus játszódik le egyetlen propertyvel, ha a property értékeként egy konkrét property nevét adjuk meg, és nem írunk harmadik attribútumot. Mindkét esetben konvertálódik a requestben tárolt érték, ha szükséges. Egy dinamikusan felépített lista forrása: <SELECT NAME="room" SIZE="1" STYLE="width=200"> <% search.setQuery("select distinct room_id, shortname from room order by shortname"); queryresult[0] = "room_id"; queryresult[1] = "shortname"; search.setQueryResult(queryresult); search.buildList(); queryList = search.getQueryList(); while(queryList.hasNext()) { query = (String[])queryList.next(); out.println(""); } %>
A search objektum setQuery() metódusával megadjuk azt az SQL utasítást, melynek eredményét a listában kívánjuk megjeleníteni. Ezután megadjuk azt is, hogy mely eredményoszlopot szeretnénk értékül adni (queryresult[0]), és melyiket szeretnénk kiiratni (queryresult[1]) a lista tagjaiban. A buildList() metódus lekérdezi az adatbázist, és az így kapott lista (queryList) elemeit már beilleszthetjük a HTML forrásba.
DÁTUM KIVÁLASZTÁSA A dátum mezo kényelmes kitöltésére a legalkalmasabb megoldásnak a JavaScriptet találtam. A dátum (és idopont) helyes formátuma elengedhetetlenül szükséges ahhoz, hogy a lekérdezések hiba nélkül lefuthassanak. A tévedések, elírások elkerülése érdekében egy grafikus naptárat jelenítek meg, ahonnan a felhasználó könnyen kiválaszthatja a megfelelo napot. Ezen funkciónak még egyéb adminisztrációs oldalakon is hasznát vehetem, ezért igyekeztem egy általános megoldást kialakítani. Az alábbi kód a dátummezot tartalmazó oldalon található, és azon egy gombot jelenít meg:
A gomb onclick eseményére egy új ablak nyílik meg, melybe a „selectdate.jsp?datum_from” oldal töltodik. Az URL-ben azt adjuk meg a selectdate JSP oldalnak, hogy melyik textboxba kell majd a kiválasztott dátumot beleírnia. Tulajdonképpen ez a mozzanat biztosítja a könnyu újrafelhasználhatóságot. Ezt az értéket könnyen kiolvashatjuk a meghívott oldalon. <% String from = request.getQueryString(); %>
Ezután a JavaScript segítségével készített grafikus felületen kiválasztjuk a megfelelo dátumot és a Select gomb megnyomásával submitáljuk az oldalt. Ekkor a következo függvény hívódik meg: function form_onsubmit() { selected_year = document.all.tbSelYear.value; selected_month = document.all.tbSelMonth.value; selected_day = document.all.calSelectedDate.value; window.alert(selected_year + "-" + selected_month + "-" + selected_day); parent.opener.document.all.<%=from%>.value = selected_year + "-" + selected_month + "-" + selected_day; window.close(); }
A függvény eloször kiolvassa a kiválasztott értékeket, és az adatbázisnak megfelelo dátumformátumban konkatenálja az évet, a hónapot és a napot. Ezt a stringet átadja az oldal szülodokumentumának paraméterül kapott mezojének és utána bezárja az aktuális ablakot.
IDOPONT, SZÍN KIVÁLASZTÁSA A dátum kiválasztásához hasonlóan egy kis ablak segíti a felhasználót az idopont megjelölésében is, és a megjelölt érték beírodik a megfelelo mezobe. Szín kiválasztására az adminisztráció menüpontban van szükség, amikor egy árkategóriát reprezentáló színkódot kell megadnunk. Az alábbi kis popup ablakot meghívva megkímélhetjük magunkat a felesleges fejtöréstol.
ÁBRA: A színkiválasztás képernyoképe
ESEMÉNY, TEREM KIVÁLASZTÁSA Események és termek esetén annyiban változik a helyzet, hogy „egyszeru” felhasználók semmiképpen nem érhetik el ezt a funkciót. Az adminisztrációhoz (ld. következo fejezet) bejelentkezett ügyfél csak a saját maga által felvitt vagy a mindenki számára közös termekbol és eseményekbol válogathat. Ennek magyarázatát a következo fejezetben fejtem ki részletesebben. A választást pedig dinamikusan felépített legördülo menük (combo box) teszik lehetové.
ADMINISZTRÁCIÓ Az adminisztráció joga a jegyet eladni szándékozó ügyfelek joga, és fontos, hogy egymástól függetlenül módosíthassák adataikat. Ezt a saját username-password párossal való beléptetéssel teszi lehetové a rendszer. Az egymástól való teljes szeparáltság azonban hátrányokkal is járhat. Mozik esetén például minden ügyfélnek külön-külön kellene felvinni a filmek címét, rendezojét, tartalmát, ami láthatóan teljesen felesleges. Az ilyen esetekre azt a megoldást találtam, hogy bevezettem egy speciális, 0 kódú ügyfelet (client_id=0). Azok az események, termek, árkategóriák, melyeket ez az ügyfél készített minden más ügyfélnél is megjelennek, és szabadon választhatnak belolük, beépíthetik saját musoraikba. Az elobbi példát folytatva így elég a héten bemutatott filmeket egyszer központilag felvinni, (ezek az adatok akár jöhetnek más adatbázisokból is) és ezt minden mozi felhasználhatja. Az adminisztrációs formok felépítésében tehát a következo két dolog kap fontos szerepet: • Beléptetés, session A beléptetést egy servlet (LoginServlet) végzi mely gondoskodik a jelszó ellenorzésérol és a sikeres belépéshez szükséges session létrehozásáról. • Formok struktúrája Ezen adminisztrációs formok tulajdonképpen nem csinálnak mást, mint az adatbázis egyes tábláit módosítják a bennük található adatok alapján. Mindhárom fontos adatbázis-muvelet könnyen elvégezheto (ADD, DELETE, MODIFY). A már meglévo rekordokat törölhetjük, ill. módosíthatjuk. A legalsó üres sorban pedig új rekordokat vihetünk fel az adatbázisba.
Applet Feladata a kiválasztott eloadás megjelenítése és a lefoglalni kívánt helyek interaktív kiválasztása. applet scroller
Button
Textfield
Button
Button
roompanel FreeChair
ReservedChair
FreeChair
ReservedChair
FreeChair
ReservedChair
ÁBRA: Applet felépítése
AWT VS SWING Az AWT (Abstrct Window Toolkit) nem más, mint eloredefiniált grafikus objektumokat megvalósító osztályok gyujteménye. Nevében az absztrakt jelzo arra utal, hogy a programozó elol teljesen rejtve marad a grafikus objektumok konkrét megvalósítása, lehetové téve ezáltal a különbözo grafikus rendszerektol független felhasználói felületek felépítését. A felület megjelenítéséhez ugyanis az AWT mindig a konkrét grafikus rendszer megfelelo programkönyvtárait fogja felhasználni. Az AWT által tartalmazott ún. nehézsúlyú komponensek (pontosan amiatt, hogy az operációs rendszer intézi a megjelenítésüket) csak bizonyos határok között konfigurálhatók. Túlságosan sok a megkötés, amire a Sun mérnökei is rájöttek, és megalkották a Swinget. A Swing tulajdonképpen egy új Java GUI komponenskészlet, mely tartalmaz számos elemi komponenst és néhány magas szintut is. A Swing pehelysúlyú komponensei 100%-ban Javaban íródtak, ami azt jelenti, hogy tetszoleges Java felületen használhatók és biztosak lehetünk afelol, hogy minden esetben ugyanúgy fognak kinézni és viselkedni (ellentétben az AWT elemeinek platformtól függo megjelenésével). JEGYRENDELÉS AZ INTERNETEN, Nagy Gergely [[email protected]]
71. oldal
A mintaalkalmazásban mégis AWT-t használok, mégpedig a következo okok miatt. A Swing az 1.3-as JDK újítása, ami miatt még a legújabb böngészok JVM-ei sem tudják megjeleníteni ezeket az elemeket. Intranetes fejlesztésekhez tökéletes megoldást nyújt, de ha az interneten mindenki számára lehetové szeretnénk tenni, hogy appletünk szolgáltatásait kihasználja, akkor nem várhatjuk el, hogy bemásolja a megfelelo class file-okat a böngészo által használt class file-ok közé. Megoldást kínálhat még a Java2Plugin, mely automatikusan letöltodve a kliens gépre lehetové teszi Swing komponensek megjelenítését is, de az applet – servlet kommunikációjából eredo jelentos mennyiségu adatcserét nem akartam még ezzel is növelni. Az AWT komponenseivel is remekül megoldható a feladat, még ha a megjelenés egy kicsit el is tér a különbözo platformokon. Pehelysúlyú komponensek létrehozása az alábbi esetekben válhat szükségessé: • Nem téglalap alakú komponensek esetén. • Egész területükön, vagy csak részben átlátszó komponensek esetén. • Egymás területére rajzolni képes komponensek esetén. • Ha a nehézsúlyú komponensek helyett hatékonyabb implementáció szükséges. Az elso állítás adott alapot arra, hogy a kirajzolandó székeket pehelysúlyú komponensek segítségével valósítsam meg. Ha ugyanis azt akarjuk, hogy tetszoleges alaprajzú terem kirajzolása lehetové váljon, akkor nem alkalmazkodhatunk a nehézsúlyú komponensek kötöttségeihez. Ha egy ilyen osztályt szeretnénk létrehozni, akkor annak a java.awt.Component.Container vagy más pehelysúlyú osztály közvetlen leszármazottjának kell lennie. Ebben az új osztályban implementálni kell a komponens külalakját (képernyon való megjelenítését) és viselkedését (eseményekre való reagálását). Az alábbi metódusokat tehát mindenképpen implementálni kell: • konstruktor(ok) • paint() • set, get • eseményeket figyelo interfészek • eseményeket feldolgozó eljárások A következo részben részletesebben leírt objektumok közül 2 pehelysúlyú komponens, a pontos implementációval ott foglalkozok.
OBJEKTUMOK • Chair A szerverrel való kommunikáció gyorsabbá tételéért készítettem egy általános osztályt, mely tartalmazza egy szék minden fontos jellemzojét. Ezek „csak” tulajdonságok, tehát a megjelenítéshez szükséges információkat nem tartalmazzák. Ez az alábbi osztályok feladata. Miután ezen objektum elsodleges célja adattovábbítás az applet és servlet között, ezért egy nagyon fontos tulajdonságot teljesítenie kell. Ez pedig nem más, mint hogy meg kell valósítania a Serializable interfészt. Csak ekkor használhatjuk ugyanis a rendkívül könnyen kezelheto writeObject és readObject metódusokat. „Amikor a writeObject muvelettel elmentünk egy objektumot, elmentodik hozzá egy osztályazonosító is: a másik oldalon megfeleloen meghívott readObject ez alapján tudja beállítani a beolvasott objektum dinamikus típusát. Ez az elmentett osztályazonosító nem tartalmazza az osztály teljes definícióját, ezért annak az olvasó oldalon is elérhetonek kell lennie, ha ez nem teljesül, ClassNotFoundException váltódik ki. Ezután kiíródnak az objektum adattagjai. [...] Ha ezek között az adattagok között van olyan, amely egy másik objektumra mutató hivatkozás, akkor az a másik objektum is elmentodik ugyanezen algoritmus alapján. Ha ebben a hivatkozási gráfban ugyanaz az objektum többször sorra kerül, nem szükséges mindannyiszor elmenteni: az elso elofordulás után elég egy referenciával jelezni, hogy a gráf melyik csomópontjáról van szó. Ily módon egy objektumokból álló összetett struktúra egyetlen utasítással elmentheto, valamint ekvivalens módon visszaállítható.”[3] • FreeChair A szabad (elojegyezheto) székek kirajzolását és a rajtuk történt egéresemények kezeléséért felelos osztály. • ReservedChair Olyan székek kirajzolását végzi ez az osztály, melyekhez nem rendelünk eseményt. Tipikusan ilyenek a már lefoglalt székek. A megvalósítás az applet futását kívánja gyorsabbá tenni a kirajzolások számának csökkentésével.
MEGJELENÍTÉS A székek kirajzolása elott több vizsgálatot teszünk: Ha a Chair objektum status attribútuma 0, akkor egy ReservedChair példányt készítünk és az appletben meghatározott foglalt színnel kirajzoljuk a koordinátáknak megfelelo helyre. Szabad szék esetén (FreeChair, status > 0) nagy jelentoséget kap még a quantity attribútum. Az applet ugyanis megkülönbözteti azokat az objektumokat, melyek egyszerre több jegyet reprezentálnak (quantity > 1) és azokat, melyek csak egyet (quantity = 1). Az elso esetben a kirajzolt székre való kattintásra az objektum színe megváltozik (és elojegyzésre kerül), míg a második esetben az applet jobb felso sarkában adhatjuk meg, hogy a kijelölt (több jegyet reprezentáló) négyszögbol pontosan hány jegyet szeretnénk lefoglalni. Az elojegyzett jegyek kódjainak listája az applet jobb alsó részében található.
Servlet A megvalósítás során 3 servletet készítettem, melyek feladatkörei a következok: • LoginServlet: A username/password páros összehasonlítása az adatbázisban találhatókkal, és ennek megfeleloen új session létrehozása, vagy a bejelentkezés elutasítása. • TicketServlet: A kiválasztott eloadás/terem lekérdezése, és az adatok applet felé történo továbbítása. • OrderServlet: Az appletben megjelölt helyek lefoglalása. Ezt a feladatot jónak láttam különválasztani a TicketServlet-étol, ugyanis míg ez elobbi csak lekérdezést végez az adatbázison, addig az OrderServlet módosítja annak tartalmát. Itt elotérbe kerülnek bizonyos tranzakciós problémák, melyek megoldása a rendszer végleges koncepciójától is függ. A következokben az esetlegesen felmerülo problémákról és azok megoldásairól szeretnék egy összefoglaló képet adni.
RENDELÉS, FIZETÉS A rendelés és a fizetés nagyon szoros kapcsolatban áll egymással. Kronológikus sorrendjük sokmindent már elore meghatároz, függetlenül attól, hogy pontosan milyen fizetési technológiát is alkalmazunk (pl.: online hitelkártyás, vagy offline készpénzes) Ha elore fizettetünk a vevovel, akkor valahogy garantálnunk kell azt, hogy biztosan meg is kaphassa azt a jegyet, amire igényt tartott a fizetés pillanatában. Ha pedig elobb engedélyezzük a helyfoglalást, akkor lehetoség szerint magunkat kell biztosítani arról, hogy ez nem „kamu”foglalás, és a jegy(ek) ki lesz(nek) fizetve. Ez a probléma adatbázis szintjén annyi, hogy mikor módosítsuk az eloadás tábla tartalmát. Ha lefoglaljuk, akkor onnantól kezdve a többi felhasználó már nem igényelheti azt a jegyet.
lefoglaljuk a helyet függetlenül attól, hogy a fizetés hogyan történik
FOGLALT
nem történik tranzakció, újra megjelenítjük a terem aktuális állapotát
automatikusan lefoglaljuk a kért jegyhez legközelebbi vagy a megadott távolságon belüli helyet
ha tényleg nincs több szabad hely, akkor nincs mit tennünk
megkérdezünk egy a vevõnek is még elfogadható távolságot vagy vesszük az alapértelmezett mennyiséget
visszaigazolást adunk a lefoglalt helyekrõl és válaszul megerõsítést kérünk
ÁBRA: A foglalás során fellépo problémák kezelése
A servlet egyelore semilyen logikát nem alkalmaz. Ha idoközben egy másik felhasználó lefoglalta az általa kiválasztott helyet, akkor ezt jelzi, és lehetoséget biztosít új székek kiválasztására. Az applet és a servlet kommunikációjára a következo fejezetben térnék ki részletesebben, de elotte ejtenék néhány szót a servlet és az adatbázis kapcsolatáról és a lekérdezésekrol, ugyanis ez mind a három servletben jelentoséget kap.
ADATBÁZIS-KAPCSOLAT Az elozo fejezetekben már beszéltem a Java programok biztonságáról. Ez az elsodleges oka, hogy az adatbázis muveleteket a servletek végzik, ugyanis így maradhatnak a szerveren lévo kódok, jelszavak a leheto legnagyobb biztonságban. Nem utolsó szempont a lekérdezések gyorsasága optimalizálására is tartogat számunkra eszközöket:
PREPARED STATEMENTS A Statement egy interfész, mely tartalmazza az SQL utasítások végrehajtásához és az eredmények lekérdezéséhez szükséges alapmetódusokat. Segítségével megadhatjuk a lekérdezést és le is futtathatjuk. Ilyenkor minden lekérdezésnél a JDBC driver újra lefordítja az általunk megadott stringet. A mintaalkalmazás servleteiben igen sok hasonló lekérdezés eredményét kell megkapnunk az adatbázistól, legtöbbször csak egy paramétert változtatunk rajtuk. Ilyen esetekben célszeru a Statement interfész egyik kiterjesztettjét, a PreparedStatement interfészt alkalmazni. A PreparedStatement végrehajtásának sebességbeli különbsége akkor válik nyilvánvalóvá, ha ugyanazt az SQL utasítást többször is el kell végezni egymás után (esetleg más paraméterekkel). A PreparedStatement végrehajtó utasításai megegyeznek a Statement-ével, azzal a különbséggel, hogy itt nem kell paramétert adni, hiszen a végrehajtáskor már ismert az elvégzendo SQL utasítás. Végrehajtás elott minden bemeno paraméternek be kell állítani az aktuális értékét. Példaként álljon itt az OrderServlet néhány ide vonatkozó sora: Connection con; PreparedStatement selectStatus, updateStatus, lock, unlock; ResultSet rset; lock = con.prepareStatement(" LOCK TABLES show_act WRITE "); unlock = con.prepareStatement(" UNLOCK TABLES"); selectStatus = con.prepareStatement(" SELECT status FROM show_act WHERE show_id=? and chair_id=? "); updateStatus = con.prepareStatement(" UPDATE show_act SET status=status-1 WHERE show_id=? and chair_id=? "); selectStatus.setInt(1, show_id); selectStatus.setInt(2, ordered[j]); rset = selectStatus.executeQuery();
A két paraméter nélküli elofordított SQL utasítás (lock, unlock) a MySQL adatbáziskezelo miatt kap fontos szerepet. Ez a rendszer ugyanis nem támogatja a tranzakciókat, így nekünk kell gondoskodnunk arról, hogy az egyes módosítások ne befolyásolhassák az adatbázis konzisztenciáját.
