a legfon­ tosabb címsor, a

a legkevésbé fontos. Ezek után a böngészőre van bízva, hogy a címsorokat ténylegesen hogyan jeleníti meg. A kisebb számmal jelzett címsorok tipi­ kusan nagyobb és vastagabb betűtípussal jelennek meg, de a böngésző akár különböző színeket is rendelhet a különböző szintű címsorokhoz. A

címsorok jellemzően nagy, félkövér betűtípussal szerepelnek, alattuk és felettük legalább egy üres sorral. A

szintű címsorok ugyanakkor kisebb méretű betűtípust használnak, és kisebb he­ lyet is hagynak a címsor alatt és fölött.

680

SZÁMÍTÓGÉP-HÁLÓZATOK

Címke

Magyarázat

...

Azt deklarálja, hogy a weboldal HTML-ben íródott

...

Az oldal fejrészét határolja



A címet határozza meg (ez az oldalon nem jelenik meg)

...

Az oldal törzsét határolja

...

Egy n szintű címsort határol

...

A ...-ot félkövérré teszi

...

A ...-ot dőlt betűssé teszi

...

Az oldal közepére vízszintesen

...

Egy sorszám nélküli (pontozott) listát zárójelez

...

Egy számokból álló listát zárójelez

...

Egy sorszámozott vagy számokból álló lista egy tételét zárójelezi




Egy törés kikényszerítése az adott ponton

Bekezdés kezdete

---

Vízszintes vonal



Egy kép betöltése az adott ponton

...

Egy hiperhivatkozást definiál

7.27. ábra. Néhány szokásos HTML-címke. Némelyiknek további paraméterei is vannak A és címkék a félkövér (boldface) és dőlt betűs (italics) módba történő váltáshoz használatosak. Ha a böngésző nem képes megjeleníteni a félkövér vagy dőlt betűket, akkor valami más módot kell használnia a visszaadásukra, például mindket­ tőhöz más-más színt vagy esetleg inverz megjelenítést. A HTML különféle mechanizmusokat biztosít listák, sőt akár egymásba ágyazott listák létrehozására is. A listák kezdetét az

vagy
, az egyes listaelemeket pe­ dig mindkét esetben a
1. címkék jelzik. Az
   egy sorrend nélküli listát indít. Az egyes elemek előtt, melyeket a forrásban az
   • címke jelöl, pontok (•) jelennek meg. Ennek a mechanizmusnak egy másik változata az
     , ami sorszámozott listákat ké­ szít. Amikor ezt a címkét használják, az
     1. elemeket a böngésző sorszámozza meg. Az eltérő kezdő- és végcímkéktől eltekintve az
        és
        szintaxisa azonos, és eredményük is hasonló. A
        ,

        és

        ---

        címkék mind egy-egy határt jelölnek a szöveg egyes részei közt. A pontos formátumot az oldalhoz rendelt stíluslap (lásd később) határozza meg. A
        címke egy egyszerű sortörést kényszerít ki. A böngészők rendszerint nem szúrnak be üres sort a
        után. Ezzel ellentétben a

        egy bekezdés kezdetét jelöli, amely például beszúrhat egy üres sort és esetleg némi behúzást is. (Elméletben a

        szolgál arra, hogy egy bekezdés végét jelölje ki, de ezt ritkán használják. A legtöbb HTML-szerző nem is tudja, hogy ilyen létezik.) Végül, a

        ---

        egy törést kényszerít ki, és egy vízszintes vonalat húz keresztbe a képernyőn.
        
        AZ ALKALMAZÁSI RÉTEG
        
        681
        
        A HTML lehetővé teszi, hogy a szöveg közé ábrákat is illesszünk egy weboldalon, Az címke mondja meg, hogy az oldalon az adott helyen egy képet kell megjes leníteni. A címkének számos paramétere lehet. Az src paraméter adja meg a kén URL-jét. A HTML-szabvány nem rendelkezik arról, hogy mely grafikus formátumod megengedettek. A gyakorlatban minden böngésző támogatja a GIF- és JPEG-állomás nyokat. A böngészők támogathatnak más formátumokat is, de ez a lehetőség kétélíj fegyver. Ha a felhasználó olyan böngészőhöz szokott, amely támogatja, mondjuk, a. BMP-állományokat, akkor esetleg ilyeneket fog rakni saját weboldalaira, és később meg fog lepődni, amikor a többi böngésző egyszerűen figyelmen kívül hagyja gyö­ nyörű műveit. Az további paraméterei az align, amely a képnek a szöveg alapvonalához viszonyított elhelyezkedését szabályozza {top - felette, middle - középen, bottom alatta), az alt, amely egy szöveget ad meg arra az esetre, ha a felhasználó letiltotta volna a képeket, és az ismap, ami azt jelzi, hogy az ábra egy aktív térkép (azaz rá lehet kattintani a részeire). Végül elérkeztünk a hiperhivatkozásokhoz, melyek az (anchor, horgony) és címkéket használják. Az -hez hasonlóan az -nak is számos paramétere van, többek közt a href (az URL) és a name (a hiperhivatkozás neve). Az és közötti szöveg megjelenítésre kerül. Ha rákattintunk, akkor egy új oldalra jutunk el. Ide egy ábrát is el lehet helyezni, ebben az esetben az ábrára való kattintás szintén aktiválja a hiperhivatkozást. Példának vegyük az alábbi HTML-részletet: A NASA honlapja
        
        Amikor egy, a fenti részletet tartalmazó oldalt megjelenítenek, a képernyőn a követ­ kező fog feltűnni: A NASA honlapja Ha a felhasználó ezek után rákattint a szövegre, a böngésző azonnal letölti és megje­ leníti azt az oldalt, melynek URL-je http://www.nasa.gov. Második példánknak vegyük a következőt:
        
        Amikor megjelenítik, ez az oldal egy képet fog mutatni (pl. egy űrsiklóról). A képre kattintva a NASA honlapjára kerülünk ugyanúgy, mintha az előző példában a szöveg­ re kattintottunk volna. Ha a felhasználó letiltotta az ábrák automatikus megjelenítését, akkor a NASA szöveg fog megjelenni a kép helyén. Az címke kaphat egy name nevű paramétert is, melynek segítségével beültet egy hiperhivatkozást magába az oldalba. így egy hivatkozás mutathat az oldal közepé­ re is. Néhány weboldal például egy tartalomjegyzékkel kezdődik, amelyre rá lehet kattintani. A tartalomjegyzék egy elemére kattintva a felhasználó az oldal megfelelő részére fog ugrani.
        
        682
        
        SZÁMÍTÓGÉP-HÁLÓZATOK
        
        
        
        
        
        

        Néhány eltérés a HTML-verziók között

        Elem	HTML 1.0	HTML 2.0	HTML 3.0	HTML 4.0
        Hiperhivatkozások	x	x	x	x
        Képek	x	x	x	x
        Listák	x	x	x	x
        Aktív térképek és képek		x	x	x
        Űrlapok		x	x	x
        Egyenletek			x	x
        Eszköztárak			x	x
        Táblázatok			x	x
        Elérési lehetőségek				x
        Objektumok beágyazása				x
        Szkriptek				x

        
        
        (a) Néhány eltérés a HTML-verziók közt HTML 1.0
        
        HTML 2.0
        
        HTML 3.0
        
        HTML 4.0
        
        X
        
        X
        
        X
        
        X
        
        Képek
        
        X
        
        X
        
        X
        
        X
        
        Listák
        
        X
        
        X
        
        X
        
        X
        
        Aktív térképek és képek
        
        X
        
        X
        
        X
        
        Űrlapok
        
        X
        
        Elem Hiperhivatkozások
        
        X
        
        X
        
        Egyenletek
        
        X
        
        X
        
        Eszköztárak
        
        X
        
        X
        
        Táblázatok
        
        X
        
        X
        
        Elérési lehetőségek
        
        X
        
        Objektumok beágyazása
        
        X
        
        Szkriptek
        
        X
        
        (b) 7.28. ábra. (a) Egy HTML-táblázat. (b) Ennek a táblázatnak egy lehetséges megjelenítése
        
        AZ ALKALMAZÁSI RÉTEG
        
        683
        
        A HTML folyamatosan fejlődik. A HTML 1.0 és 2.0 verziókban még nem voltak táblázatok, csak a HTML 3.0-ban jelentek meg. Egy HTML-táblázat egy vagy több sorból áll, a sorok pedig egy vagy több cellából (cell). A cellák sok mindent tartal­ mazhatnak, például szöveget, számokat, ikonokat, fényképeket, sőt akár más tábláza­ tokat is. A cellákat egybe lehet vonni, így például egy címsor több oszlopot is átfog­ hat. Az oldal szerzőjének van némi beleszólása az elrendezésbe, beleértve az elhelye­ zést, a keret stílusát és a cellahatárolókat, de a táblázatok megjelenítésénél az utolsó szót a böngészők mondják ki. Egy HTML-táblázatdefiníció látható a 7.28.(a) ábrán. Ennek egy lehetséges vissza­ adását mutatja a 7.28.(b) ábra. Ez a táblázat csak párat mutat meg a HTML-táblázatok alapvető jellemzői közül. A táblázatok a címkével kezdődnek. További in­ formáció is megadható a táblázat általános tulajdonságainak leírására. A (Table Row, táblázatsor) címkével kezdődnek. Az egyes cellákat a címkék is vannak. Mi eddig nem töródtünk az ilyesmivel. Az XML- és az XSL-specifikáció azonban sokkal szigorúbb, mint a HTML-specifikáció. Az előb­ biek kimondják, hogy a szintaktikailag helytelen állományokat kötelező visszautasíta­ ni még akkor is, ha a böngésző ki tudja találni, mire gondolt a webtervező. Nem felel meg a szabványnak az olyan böngésző, ami elfogadja a szintaktikailag helytelen XML- vagy XSL-állományokat, és saját maga kijavítja a hibákat. Ennek megfelelően az ilyen böngészők a megfelelőségi teszteken is megbuknak. Az ugyanakkor engedé­ lyezett, hogy rámutassanak a hibára. Erre a kissé drákói szigorra azért volt szükség, hogy tegyünk valamit a jelenleg kiállított irdatlan mennyiségű hanyag weboldal ellen. Az alábbi utasítás egy C nyelvű for utasítással analóg: <xsl:for-each select="konyvlista/konyv">
        
        AZ ALKALMAZÁSI RÉTEG
        
        689
        
        <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL7Transform" version="1.0"> <xsl:template match="/">

        címke használható képaláírások megadására. A táblázatok sorai a

        (Table Header, táblázat fejrésze) és a	(Table Data, táblázatadat) jelölik. Ez a megkülön­ böztetés lehetővé teszi, hogy a böngészők másképp jelenítsék meg a címsort, mint a többi sort, ahogyan azt a példánkban is láthattuk. A táblázatokban is használható számos attribútum. Megadható többek között a függőleges és vízszintes cellaigazítás, a cellán belüli igazítás, a szegélyek stílusa, a cellák csoportosítása, mértékegységek és még sok más. A HTML 4.0 további lehetőségeket tartalmaz. Ezek között van olyan, amely a hát­ rányos helyzetű felhasználók számára biztosít elérési lehetőséget, amely objektumbe­ ágyazást tesz lehetővé (ez az címke általánosítása úgy, hogy más objektumok is beágyazhatok legyenek az oldalakba), amely támogatja a szkripteket (megengedve a dinamikus tartalmat). További lehetőségek is vannak. Ha egy webhely elég bonyolult, és több oldalból áll, melyeket egyazon cég külön­ böző szerzői hoztak létre, akkor gyakran kívánatos az oldalak egységes kinézetének biztosítása. Ez a stíluslapok (style sheets) használatával oldható meg. Ebben az eset­ ben az egyes oldalak nem használnak fizikai stílusokat, mint például a félkövér vagy dőlt betű. Az oldalak szerzői ehelyett logikai stílusokat alkalmaznak, olyanokat, mint a (definíció), <em> (gyenge hangsúlyozás), <strong> (erős hangsúlyozás), és (programváltozók). Ezeket a logikai stílusokat egy stíluslapban határozzák meg, melyre az egyes oldalak elején hivatkoznak. Ezáltal minden oldalnak egységes lesz a stílusa, és ha a webmester úgy dönt, hogy a 14-es méretű, dőlt betűs, kék színű <strong> stílus helyett 18-as méretű, félkövér, rémes rózsaszínű <strong> stílust szeretne, akkor egyetlen definíció megváltoztatásával átalakíthatja az egész webhelyét. A stíluslapokat egy C program #include állományához hasonlíthatjuk: ha ott megváltoztatunk egy makródefiníciót, akkor az megváltozik az erre hivatkozó összes állományban is. Űrlapok A HTML 1.0 alapvetően egyirányú volt. A felhasználók lehívhattak oldalakat a tarta­ lomszolgáltatóktól, de bonyolult volt a másik irányba információt visszaküldeni. Ahogy egyre több és több kereskedelmi szervezet kezdte el használni a Világhálót, a 684 SZÁMÍTÓGÉP-HÁLÓZATOK kétirányú forgalom iránt nagy igény jelentkezett. Sok társaság akarta azt például, hogy képes legyen rendeléseket felvenni a termékeire a Világháló oldalain keresztül. A szoftvercégek szoftvert akartak terjeszteni a Világháló útján, és az ügyfelekkel elekt­ ronikusan akarták kitöltetni a regisztrációs kártyákat. A Világháló-keresést ajánló tár­ saságok pedig azt akarták, hogy ügyfeleik begépelhessék a keresési kulcsszavakat. Ezek a követelések vezettek oda, hogy a HTML 2.0-tól kezdve az űrlapokat (forms) is belevették a szabványba. Az űrlapok dobozokat vagy gombokat tartalmaz­ hatnak, amelyek lehetővé teszik a felhasználók számára, hogy információt írhassanak be, vagy a felkínált lehetó'ségek közül választhassanak, majd az információt visszaküldhessék az oldal tulajdonosának. Erre a célra az (bevitel) címkét használ­ ják. Ennek sokfajta paramétere van, amelyek meghatározzák a megjelenített doboz méretét, természetét és használatának módját. Ennek legközönségesebb formái a fel­ használó szövegét befogadó üres mezők, a kipipálható dobozok, az aktív térképek és a submit gombok. A 7.29. ábra példája ezen választékból mutat be párat. Kezdjük az űrlapok tárgyalását azzal, hogy végigmegyünk ezen a példán. Mint minden űrlapot, ezt is a és címkék fogják közre. A címkébe nem zárt szöveg egyszerűen megjelenik. Minden szokásos címke (mint pl. a ) megengedett az űrlapon belül. Ezen az űrlapon háromfajta bemeneti dobozt használtunk. Az elsőfajta bemeneti doboz a „Név" szöveg után következik. A doboz 46 karakter hosszú, és a felhasználótól egy szöveget várunk bele, amelyet azután a customer vál­ tozóban tárolunk el későbbi feldolgozás céljából. A címke arra utasítja a böngé­ szőt, hogy a következő szöveget és dobozokat a következő sorban helyezze el, még akkor is, ha lenne még hely az aktuális sorban. A és más elrendezési címkék használatával az oldal szerzője szabályozhatja az űrlap kinézetét a képernyőn. Az űrlap következő sora a felhasználó utcájának nevét kérdezi, 40 oszlop szélesen, szintén külön sorban. Az ezután következő sor a városra, az államra és az országra kérdez rá. Itt nem használtunk címkéket a mezők között, így a böngésző mindet egy sorban fogja megjeleníteni, ha elférnek. A böngésző szemében ez a bekezdés csak hat elemet tartalmaz: három karakterláncot és három dobozt váltakozva. Egymás után jeleníti meg ezeket, balról jobbra, mindannyiszor új sort kezdve, valahányszor az ak­ tuális sorba nem fér ki a következő elem. Elképzelhető tehát, hogy egy 1600 x 1200-as képernyőn mindhárom doboz és a hozzájuk tartozó karakterláncok is egy sorban fog­ nak megjelenni, míg egy 1024 x 768-as képernyőn esetleg két sorra oszlanak. A leg­ rosszabb esetben az „Ország" szó az egyik sor végén lesz, a hozzá tartozó doboz pedig a következő sor elején. A következő sor a hitelkártya számát és lejáratának dátumát kérdezi meg. A hitel­ kártyaszámokat csak megfelelő biztonsági intézkedések megtétele után lenne szabad átvinni az Interneten. Ezek közül néhányat a 8. fejezetben fogunk tárgyalni. A lejárat dátuma után új funkcióval találkozunk: a rádiógombokkal (radio buttons). Ezeket akkor használják, amikor két vagy több lehetőség között kell választani. Az elméleti modell itt egy autórádió volt, melynek fél tucat gombja van az állomások ki­ választására. A böngésző ezeket a dobozokat olyan formában jeleníti meg, amely le­ hetővé teszi a felhasználó számára, hogy kattintással (vagy a billentyűzet segítségével) kiválaszthassa azokat, vagy megszüntesse a kiválasztást. Ha az egyikre rákattintanak, az az ugyanabban a csoportban levő összes többit kikapcsolja. A vizuális megjelenítés 685 AZ ALKALMAZÁSI RÉTEG a böngészőtől függ. A szerkentyű méretének megadására mi is két rádiógombot hasz­ náltunk. A két csoportot a name mezejükkel különböztetjük meg, nem pedig olyan statikus címkékkel, mint mondjuk a és a . AWJ ÜGYFÉL MEGRENDELŐLAP Ügyfél megrendelőlap Név Város Utca Házszám La­ kás Hitelkártyaszám Lejárat M/C Visa Szerkentyű mérete Nagy Expressz küldönccel szállítás Köszönjük, hogy megrendelt egy AWI szerkentyűt. A legjobb szerkentyű, amit csak kapni lehet! (a) AWI ÜGYFÉL MEGRENDELŐLAP Név Város Utca Házszám Hitelkártyaszám Szerkentyű mérete Lejárat | Nagy Q Kicsi O M/C Lakás [ [ Q VisaO Expressz küldönce el szállítás \_j Rendelés elküldése Köszönjük, hogy megrendelt egy AWI szerkentyűt. A legjobb sze rkentyű, amit csak kapni lehet! (b) 7.29. ábra. (a) Egy megrendelőlap HTML-je. (b) A megformázott oldal J 686 SZÁMÍTÓGÉP-HÁLÓZATOK A value paramétereket a lenyomott rádiógomb jelzésére használják. Attól függően, hogy a felhasználó melyik hitelkártya-változatot választotta, a cc változó értéke vagy a „visacard", vagy a „mastercard" karakterláncra fog beállni. A két rádiógombkészlet után eljutottunk a szállítási lehetőségekhez, amelyet egy ellenőrző gomb, checkbox típusú négyzet jelképez. Ez lehet ki- vagy bekapcsolva. A rádiógomboktól eltérően, amelyeknél a halmazból pontosan egyet kell kiválasztani, minden checkbox típusú doboz ki- vagy bekapcsolt állapotban lehet, az összes többitől függetlenül. Például, amikor a felhasználó az Elektro-Pizza weboldaláról rendel piz­ zát, akkor választhat szardíniát és hagymát és ananászt (ha így szereti), de nem vá­ laszthat kis és közepes és nagy pizzát egyszerre. A pizzafeltéteket három külön check­ box típusú gomb jelképezné, míg a pizza mérete rádiógombok egy halmaza lenne. A rádiógombok némileg kényelmetlenek olyan, nagyon hosszú listák esetén, ame­ lyekből egy elemet kell kiválasztani. Ezért hozták létre a <select> és címkéket, amely címkék közötti választási lehetőségek felsorolása található, a rádiógombok sze­ mantikájával (hacsak nincs megadva a multiple - többszörös - paraméter, amelynél a szemantika megegyezik a kijelölhető dobozok szemantikájával). Néhány böngésző a <select> és a közé eső elemeket egy legördülő menüben ábrázolja. Eddig már az címke kétfajta beépített típusát is láttuk: a radio és checkbox típusokat. Sőt, tulajdonképpen már egy harmadikat is, a text-et (szöveg). Mivel ez a típus az alapértelmezés, nem bajlódtunk azzal, hogy a type - text paramétert is meg­ adjuk, de megtehettük volna. Két másik típus a password és a textarea. Egy password (jelszó) doboz ugyanolyan, mint egy text doboz, kivéve, hogy a begépelt karakterek nem jelennek meg. A textarea (szöveges terület) doboz megegyezik a text dobozzal, csak több sort is tartalmazhat. Visszatérve a 7.29. ábra példájához, most a submit gombbal kapcsolatos példával találkozunk. Amikor erre rákattintunk, az űrlapban levő felhasználói információ viszszakerül ahhoz a géphez, amely az űrlapot biztosította. Az összes többi típushoz ha­ sonlóan a submit is egy fenntartott szó, amelyet a böngésző megért. A value (érték) karakterlánc itt a gomb címkéje, és ez jelenik meg. Minden doboznak lehet értéke, de csak itt volt szükségünk erre a szolgáltatásra. A text dobozok esetében a value mező tartalma megjelenik az űrlappal együtt, de a felhasználó azt átszerkesztheti vagy kitö­ rölheti. A checkbox és radio dobozoknak szintén lehet kezdőértéket adni, ez egy checked nevű mezővel tehető meg (mivel a value csak a szöveget adja meg, de nem jelöl ki semmilyen előnyben részesített választási lehetőséget). Amikor a felhasználó a Rendelés elküldése gombra kattint, a böngésző egyetlen hosszú sorba csomagolja az összegyűlt információkat, és visszaküldi azt feldolgozásra a kiszolgálónak. A mezők elválasztására az & szolgál, a szóközt pedig a + jelképezi. Példánk űrlapjában ez a sor a 7.30. ábrán láthatóhoz hasonló lehet (itt azért törtük há­ rom részre, mert nem elég széles az oldal). Vasarlo=John+Doe&cim=100+Main+St.&varos==White+Plains& allam=NY&orszag=USA&kartyaszam=1234567890&lejarat=6/98&cc=mastercard& termek=olcso&expressz=be 7.30. ábra. A böngésző egy lehetséges válasza a kiszolgálónak a felhasználó által megadott információkkal AZ ALKALMAZÁSI RÉTEG 687 Ezt a karakterláncot egyetlen sorként küldenék vissza a kiszolgálónak, és nem há­ romként. Ha egy jelölőnégyzet nincs kiválasztva, akkor kimarad a karakterláncból. A karakterlánc értelmezése a kiszolgálóra van bízva. Ennek lehetséges módjait a fejezet későbbi részében tárgyaljuk. XML és XSL A HTML sem az űrlapokkal, sem azok nélkül nem ad semmilyen struktúrát a weboldalaknak, és a tartalmat is vegyíti a formázással. Az e-kereskedelem és egyéb alkalmazások elterjedésével azonban egyre nó' az igény a strukturált weboldalak, va­ lamint a tartalomnak a formázástól való elválasztása iránt. Egy olyan programnak pél­ dául, ami végigböngészi a Világhálót, hogy a legjobb áron találjon meg egy könyvet vagy CD-t, sok weboldalon kell megnéznie a keresett címet és az árat. HTML-ben íródott weboldalak esetén ez a program nehezen fogja kitalálni, hogy az oldalon hol van a cím, és hol az ár. A W3C épp ezért elkészítette a HTML továbbfejlesztését, hogy lehetővé tegye a weboldalak strukturálását az automatikus feldolgozhatóság érdekében. Erre a célra két új nyelvet fejlesztettek ki. Az első az XML (eXtensible Markup Language - kiter­ jeszthető jelölőnyelv), mely a webes tartalmat írja le strukturált formában, a második, az XSL (eXtensible Style Language - kiterjeszthető' stílusnyelv) pedig tartalomtól függetlenül írja le a formázást. Mindkét téma terjedelmes és bonyolult, rövid beveze­ tésünk tehát csak a felszínt fogja érinteni, de remélhetőleg elég lesz arra, hogy képet alkossunk a dolgok működéséről. Tekintsük példaként a 7.31. ábrán szereplő XML-dokumentumot. Ez egy „könyv­ lista" nevű szerkezetet határoz meg, ami történetesen könyvek listája. Minden könyv­ nek három mezője van: a cím, a szerző és a kiadás éve. Rendkívül egyszerű módon, ezen struktúráknak lehetnek ismétlődő mezőik (pl. több szerző), opcionális mezőik (pl. egy CD-ROM-melléklet) és alternatív mezőik (pl. egy könyvesbolt URL-je, ha a könyv kapható, vagy egy aukciós hely URL-je, ha már nem kapható). Példánkban mindhárom mező oszthatatlan entitás, de egyébként a mezők további részekre való osztása is megengedett. Például, a még aprólékosabb keresések és for­ mázások-érdekében a szerző mezőt a következőképp is megadhattuk volna: <szerzo> Andrew Tanenbaum Minden mezőt almezőkre, majd al-almezőkre stb. oszthatunk, tetszőleges mélységig. A 7.31. ábrán látható állomány mindössze egy három könyvből álló listát ad meg. Arról semmit sem mond, hogy hogyan kell megjeleníteni a weboldalt a képernyőn. A formázási információ megadásához egy második állomány szükséges, a konyvlista.xsl, mely az XSL-definíciókat tartalmazza. Ez az állomány egy stíluslap, amely meg­ mondja, hogy hogyan kell megjeleníteni az oldalt. (A stíluslapoknak vannak alternatí- 688 SZÁMÍTÓGÉP-HÁLÓZATOK Számítógép-hálózatok, 4. kiadás <szerzo> Andrew S. Tanenbaum <ev> 2003 Korszerű operációs rendszerek, 2. kiadás <szerzo> Andrew S. Tanenbaum <ev> 2001 Strukturált számítógép-szervezés, 4. kiadás <szerzo> Andrew S. Tanenbaum <ev> 1999 7.31. ábra. Példa egy XML-ben íródott weboldalra váik is, mint például az XML HTML-be való átalakítása, de ezek az alternatívák túl­ mutatnak könyvünk keretein.) A 7.32. ábrán egy példa XSL-állomány található a 7.31. ábrán látható adatok for­ mázásához. Néhány szükséges deklaráció, többek közt az XSL-szabvány URL-jének megnevezése után az állomány címkéket tartalmaz, kezdve a és cím­ kékkel. Ezek egy weboldal kezdetét jelzik, mint általában. Ezt követi egy táblázatde­ finíció, benne a három oszlop fejlécével. Figyeljük meg, hogy a	címkék mellett itt már

        <xsl:for-each select="konyvIista/konyv">

        Cím	Szerző	Év
        <xsl:value-of select="cim"/>	<xsl:value-of select="szerzo"/>	<xsl:value-of select="ev"/>

        
        
        7.32. ábra. Egy stíluslap XSL-ben Ennek hatására a böngésző a ciklus törzsét (melyet a zár) ismétel­ geti minden egyes könyvre. Minden ismétlés öt sort írat ki: a címkét, a címet, a szerzőt, az évet, és végül a címkét. A ciklus után kiírásra kerülnek a és a zárócímkék. A stíluslap értelmezésének eredménye ugyanaz lesz, mintha ma­ ga a weboldal tartalmazta volna ezt a táblázatot. Ebben a formában ugyanakkor a programok is elemezhetik az XML-állományt, és könnyen megtalálhatják például a 2000 után kiadott könyveket. Érdemes hangsúlyozni, hogy bár az XSL-állomány egy­ fajta ciklust tartalmazott, az XML-ben és XSL-ben íródott weboldalak továbbra is statikusak, hiszen egyszerűen csak az oldal megjelenítésére vonatkozó utasításokat adnak a böngészőnek, akárcsak a HTML-oldalak. Az XML és XSL használatához persze a böngészőnek meg is kell értenie ezeket a formátumokat, de a legtöbb böngé­ sző már rendelkezik ezzel a képességgel. Azt még nem tudni, hogy az XSL vajon át­ veszi-e a hagyományos stíluslapok szerepét. Megemlítjük, hogy a weboldalak tervezői az XML segítségével ún. definíciós ál­ lományokat is létrehozhatnak, melyek előre definiálják az oldalak szerkezetét. Ezen állományok felhasználásával összetett weboldalak is felépíthetők. Az XML és XSL sok más képessége mellett erről is bővebben olvashatunk a kiterjedt szakirodalomban, például (Livingstone, 2002; valamint Williamson, 2001) munkáiban.
        
        690
        
        SZÁMÍTÓGÉP-HÁLÓZATOK
        
        Mielőtt befejeznénk az XML és az XSL tárgyalását, érdemes rámutatnunk a WWW konzorcium és a webtervezők közössége között zajló ideológiai vitára. A HTML eredeti célja a dokumentum szerkezetének, nem pedig a megjelenésének meg­ határozása volt. Például, a

        Deborah fényképei

        
        
        parancs arra utasítja a böngészőt, hogy emelje ki a címsort, de nem mond semmit a betűtípusról, a betűméretről vagy a színről. Ezek a böngészőre voltak bízva, hiszen az ismerte a képernyő tulajdonságait (pl. hogy hány képpontból áll). Sok webtervező azonban teljesen uralni akarta az oldalaik megjelenítését, ezért új címkéket adtak a HTML-hez, hogy befolyásolni lehessen a megjelenítést, mint például az alábbi cím­ kével: Deborah fényképei
        
        Emellett lehetővé vált a képernyőterületen való elhelyezkedés pontos megadása is. Ezzel a megközelítéssel az a baj, hogy nem hordozható. Lehet, hogy egy oldal töké­ letesen jelenik meg abban a böngészőben, amelyikben kifejlesztették, de egy másik böngészőben, esetleg ugyanazon böngésző egy másik verziójában, vagy egy másik képernyőfelbontás mellett már teljesen összekuszálódik. Az XML egyik törekvése pont az volt, hogy visszatérjen az eredeti célhoz, és csak a dokumentum szerkezetét határozza meg, ne a kinézetét. Igen ám, de ott van az XSL is, a megjelenítés kezelésé­ re. Mindkét formátumot lehet helytelenül használni, és hogy erre lesz is példa, arra mérget vehetünk. Az XML-t nem csak a weboldalak leírására lehet használni. Egyre szélesebb kör­ ben használják a különböző alkalmazások közti kommunikáció nyelveként is. Konk­ réten a SOAP (Simple Object Access Protocol - egyszerű objektumelérési proto­ koll) az, ami lehetőséget ad az alkalmazások közti távoli eljáráshívások nyelv- és rendszerfüggetlen lebonyolítására. Az ügyfél XML-üzenetként állítja össze a kérést, és a HTTP-protokoll segítségével (lásd lejjebb) küldi el a kiszolgálónak. A kiszolgáló a választ szintén XML-üzenetként küldi vissza. Ily módon a különböző platformokon lévő alkalmazások is kommunikálhatnak egymással.
        
        XHTML - a kiterjesztett HTML A HTML folyamatosan fejlődik, hogy eleget tegyen a legújabb elvárásoknak is. Az iparban sokan érzik úgy, hogy a jövőben a webképes eszközök többsége nem PC, ha­ nem vezeték nélküli, kézi, PDA jellegű eszköz lesz. Ezek az eszközök csak korlátozott memória felett rendelkeznek, így nem futtathatnak nagy böngészőket tele heurisztiká­ val, hogy valahogy kezelni tudják a szintaktikailag helytelen weboldalakat. Ezért a HTML 4 után a következő lépés egy olyan nyelv lesz, ami Nagyon Válogatós. Ezt nem is HTML 5-nek nevezik, hanem XHTML-nek (eXtended Hypertext Markup Language - kiterjesztett hipertext jelölőnyelv), mert alapjában véve nem más, mint a HTML 4, csak XML-ben újrafogalmazva. Ezalatt azt értjük, hogy az olyan címkék-
        
        AZ ALKALMAZÁSI RÉTEG
        
        691
        
        nek, mint például a

        , nincs valódi jelentése. A HTML 4-nek megfelelő hatás el­ éréséhez szükség van egy XSL-definícióra is. Az XHTML a Web új szabványa, és minden új weboldal létrehozásánál ez használandó, hogy a lehető legjobb hordozható­ ságot érjük el az egyes platformok és böngészők között. Az XHTML és a HTML 4 között hat nagyobb, és számos kisebb különbség van. Tekintsük át a nagyobbakat! Először is, az XHTML-oldalaknak és -böngészőknek szigorúan meg kell felelniük a szabványnak. Elég a silány weboldalakból! Ezt a tulaj­ donság az XML-től származik. Másodszor, minden címkének és attribútumnak kisbetűsnek kell lennie. Az olyan címkék, mint a , már nem érvényesek az XHTML-ben. A címkéket ehelyett kötelező így használni: . Hasonlóképp, az se megen­ gedett, mert nagybetűs attribútumot tartalmaz. Harmadszor, ki kell rakni a záró címkéket is, még a

        esetén is. Azoknál a cím­ kéknél, melyeknek nincs természetes záró címkéjük, mint például a
        ,

        ---

        és , egy perjelnek kell megelőznie a záró „>"-t, például így:
        
        Negyedszer, az attribútumokat idézőjelekkel kell körülvenni. Az alábbi címke pél­ dául többé már nem megengedett:
        
        Az 500-at is idézőjelek közé kell írni, akárcsak a JPEG-állomány nevét, még akkor is, ha az 500 egy puszta szám. Ötödször, a címkéket helyesen kell egymásba ágyazni. Eddig a helyes egymásba­ ágyazás nem volt követelmény, feltéve, hogy az elért végeredmény megfelelő volt. Megengedett volt például az alábbi: Képek a nyaralásról
        
        XHTML-ben ez már nem szabályos. A címkéket mindig a megnyitásukhoz képest fordított sorrendben kell lezárni. Hatodszor, minden dokumentumnak meg kell határoznia a maga típusát. Erre töb­ bek között a 7.32. ábrán láthattunk példát. A www.w3.org az összes különbséget tár­ gyalja, kicsiket és nagyokat egyaránt.
        
        7.3.3.
        
        Dinamikus vvebdokumentumok
        
        Idáig a 6.6. ábra modelljét használtuk: az ügyfél elküld egy állománynevet a kiszol­ gálónak, mire az visszaküldi az állományt. A kezdeti időkben a Weben valójában minden tartalom ilyen statikus volt (puszta állományok). Az utóbbi időben azonban egyre több tartalom lett dinamikus, azaz igény szerint előállított, nem pedig lemezen tárolt. A tartalom előállítása történhet a kiszolgáló és az ügyfél okialán is. Nézzük most meg sorban mindkét esetet!
        
        692
        
        SZÁMÍTÓGÉP-HÁLÓZATOK
        
        Weboldalak dinamikus előállítása a kiszolgáló oldalán Annak érdekében, hogy lássuk, miért van szükség tartalom előállítására a kiszolgáló oldalán, tekintsük a korábban leírt űrlapok használatát. Amikor a felhasználó kitölt egy űrlapot, és rákattint az Elküld gombra, akkor a kiszolgáló egy üzenetet kap, mely tartalmazza az űrlapot, és a felhasználó által kitöltött mezőket. Ez az üzenet termé­ szetesen nem egy visszaadandó állomány neve. Ilyenkor az üzenetet egy programnak vagy egy szkriptnek kell átadni feldolgozásra. Ez a feldolgozás általában azt is jelenti, hogy a felhasználó által megadott információ felhasználásával kikeresnek egy rekor­ dot a kiszolgáló lemezén lévő adatbázisból, és egy egyéni HTML-oldalt állítanak elő, amit visszaküldenek az ügyfélnek. Egy e-kereskedelmi alkalmazásban például, amikor a felhasználó a TOVÁBB A PÉNZTÁRHOZ gombra kattint, a böngésző elküldi a bevá­ sárlókocsi tartalmát leíró sutit, de ekkor még a kiszolgáló oldalán is meg kell hívni valamilyen programot vagy szkriptet, hogy feldolgozza a sutit, és előállítson egy HTML-oldalt válaszként. A HTML-oldal megjeleníthet egy űrlapot, ami részletezi a bevásárlókocsi tartalmát, és kiírhatja a felhasználó utoljára megadott postázási címét, hogy a felhasználó ellenőrizze azt, valamint döntsön a fizetés módjáról. A HTMLűrlapok adatainak feldolgozásához szükséges lépéseket a 7.33. ábra szemlélteti. Az űrlapok és más interaktív weboldalak kezelését hagyományosan a CGI (Common Gateway Interface - általános átjáró interfész) nevű rendszer végzi. Ez egy szabványos interfész, mely lehetővé teszi, hogy a webszerverek olyan kiszolgáló ol­ dali programokkal és szkriptekkel beszéljenek, melyek valamilyen bemenetet fogad­ nak el (pl. űrlapokból), és válaszul HTML-oldalakat állítanak elő. Ezeket a kiszolgáló oldali szkripteket általában Perl nyelven írják, mert Perl-szkripteket könnyebben és gyorsabban lehet írni, mint programokat (főleg, ha valaki tud Periben programozni). Ezek a szkriptek szokás szerint egy cgi-bin nevű könyvtárban helyezkednek el; ez az URL-ben is látszik. Néha a Perl helyett egy másik szkriptnyelvet, a Pythont használják. A CGI általános működését szemléltető példaként tekintsük azt az esetet, amikor az Igazán Nagyszerű Termékek Vállalat egy termékéhez nem adnak regisztrációs kártyát a garanciához, hanem a vásárlónak kell magát on-line regisztrálnia a www.intv.com címen. Ezen az oldalon van ilyen hiperhivatkozás:
        
        Felhasználó /
        
        1. 2. 3. 4.
        
        Böngésző
        
        Kiszolgáló
        
        CGIszkript
        
        Adatbázis a háttértáron
        
        2
        
        A felhasználó kitölti az űrlapot Az űrlapot visszaküldik Átadják a CG l-nek A CGI lekérdezi az adatbázist
        
        5. 6. 7. 8.
        
        Megvan a rekord A CGI felépíti az oldalt Az oldalt visszaadják Az oldal megjelenik
        
        7.33. ábra. A HTML-űrlapon található adatok feldolgozásának lépései
        
        AZ ALKALMAZÁSI RÉTEG
        
        693
        
        Kattintson ide a terméke regisztrálásához
        
        Ez a hivatkozás mondjuk a következő Perl-szkriptre mutat: www.intv.com/cgibin/reg.perl. Ha ezt a szkriptet paraméterek nélkül hívják meg, akkor a regisztrációs űrlapot tartalmazó HTML-oldalt küldi vissza. Amikor a felhasználó kitölti az űrlapot, és az Elküld gombra kattint, egy üzenetet küldenek vissza ennek a szkriptnek, amely tartalmazza a beírt értékeket a 7.30. ábrán látható stílusban megadva. A Perl-szkript ezután feldolgozza a paramétereket, készít egy bejegyzést az adatbázisban az új fel­ használó számára, majd visszaküld egy HTML-oldalt, ami megadja a regisztrációs számot és az ügyfélszolgálat telefonszámát is. Ez az űrlapok kezelésének általános módja, noha nem ez az egyetlen lehetőség. Számos könyv is íródott a CGI-szkriptek készítéséről és a Periben való programozásról. Ilyenek például (Hanegan, 2001; Lash, 2002; valamint Meltzer és Michalski, 2001) művei. Nem csak CGI-szkriptek segítségével lehet a kiszolgáló oldalán dinamikus tartal­ mat előállítani. Egy másik gyakori eljárás az, hogy a HTML-oldalakba ágyaznak ki­ sebb szkripteket, melyeket maga a kiszolgáló futtat az oldal előállítása során. A PHP (PHP: Hypertext Preprocessor - hipertext előfeldolgozó) egy népszerű nyelv, mely megfelelő az ilyen szkriptek megírásához. Használatához a kiszolgálónak értenie kell a PHP-t (csakúgy, mint ahogy a böngészőnek is értenie kell az XML-t, hogy értel­ mezni tudja az XML-ben íródott weboldalakat). A kiszolgálók általában elvárják, hogy a PHP-t tartalmazó weboldalak kiterjesztése html vagy htm helyett php legyen. A 7.34. ábra egy apró PHP-szkriptet szemléltet. Ennek minden olyan kiszolgálón működnie kell, ahol a PHP telepítve van. A címkében lévő PHPszkriptet leszámítva az ábra csak hagyományos HTML-t tartalmaz. Ez a címke egy olyan weboldal-részletet állít elő, ami megadja, hogy mit tud a szkript az azt meghívó böngészőről. A böngészők ugyanis a kérésekkel (és az esetleges sütikkel) együtt némi információt is elküldenek magukról, ez az információ pedig a HTTP_USER_AGENT nevű változóba kerül. Ha az ábrán látható forrást berakjuk a test.php nevű állományba az ABCD társaság WWW könyvtárában, akkor a www.abcd.com/test.php URL egy olyan weboldalt fog előállítani, ami megadja, hogy a felhasználó milyen böngészőt, milyen nyelvet és milyen operációs rendszert használ.

        Ezt tudom rólad

        '
        
        7.34. ábra. Példa HTML-oldalra beágyazott PHP-vel A PHP különösen alkalmas űrlapok kezelésére, és egyszerűbb is használni, mint a CGI-szkripteket. A 7.35. ábra az űrlapok PHP-val történő kezelésére mutat egy példát. Az ábrán egy szokványos HTML-oldal látható, benne egy űrlappal. Az egyetlen szo-
        
        694
        
        SZÁMÍTÓGÉP-HÁLÓZATOK
        
        katlan dolog az első sorban van, ami megadja, hogy az action.php állományt kell meghívni a paraméterek kezeléséhez, miután a felhasználó kitöltötte és beküldte az űrlapot. Az oldal két szövegdobozt jelenít meg: az egyik a nevet, a másik az életkort kéri. Miután ezeket kitöltötték, és az űrlapot beküldték, a kiszolgáló elemzi a 7.30. áb­ rához hasonló visszaküldött karakterláncot, és a nevet a name, a kort pedig az age változóba teszi. Ezután válaszként megkezdi a 7.35.(b) ábrán látható action.php állo­ mány feldolgozását. Az állomány feldolgozása során a PHP-parancsok végrehajtásra kerülnek. Ha a felhasználó azt írta a dobozokba, hogy „Barbara" és „24", akkor a visszaküldött HTML-oldal a 7.35.(c) ábrán látható lesz. Az űrlapok kezelése tehát rendkívül egyszerű lesz a PHP használatával. Annak ellenére, hogy a PHP-t könnyű használni, valójában egy hathatós progra­ mozási nyelv, mely a Web és a kiszolgáló oldali adatbázis közötti kapcsolatot hivatott megteremteni. Vannak benne változók, karakterláncok, tömbök, tartalmazza a C-ben megtalálható vezérlési szerkezetek többségét, és ezenfelül egy, a puszta printf-né\ sokkal hatékonyabb l/O-t. A PHP forráskódja nyílt és szabadon hozzáférhető'. A PHP-t kifejezetten úgy tervezték, hogy jól működjön az Apache-csal, mely a vi

        Kérem, adja meg a nevét:

        Kérem, adja meg az életkorát:

        
        
        (a)

        Válasz:

        Hello . Jóslat: jövőre éves leszel.
        
        (b)

        Válasz:

        Hello Barbara. Jóslat: jövőre 25 éves leszel. (c) 7.35. ábra. (a) Egy űrlapot tartalmazó weboldal, (b) PHP-szkript az űrlap adatainak kezelésére, (c) A PHP-szkript kimenete, ha a bemenet „Barbara", illetve „24" volt
        
        AZ ALKALMAZÁSI RÉTEG
        
        695
        
        lág legelterjedtebb webszervere, és szintén nyílt forráskódú. A PHP-ről többet is meg­ tudhatunk (Valade, 2002) munkájából. Már két különböző' módot is láttunk dinamikus HTML-oldalak előállítására: a CGI-szkripteket és a beágyazott PHP-t. Van egy harmadik eljárás is, a JSP (Java Server Pages - Java-kiszolgálóoldalak), ami hasonlít a PHP-hez, azzal a különbség­ gel, hogy a dinamikus rész PHP helyett a Java programozási nyelven íródik. Azoknak az oldalaknak, melyek ezt az eljárást használják, jsp a kiterjesztésük. A negyedik módszer, az ASP (Active Server Pages - aktív kiszolgálóoldalak) nem más, mint a PHP vagy a JSP Microsoft-féle változata. Ez a Microsoft saját szkriptnyelvét, a Visual Basic Scriptet használja a dinamikus tartalom előállítására. Az ilyen módszerrel ké­ szült oldalak kiterjesztése asp. A PHP, JSP és ASP közti választás általában inkább politikai (nyílt forrás, Sun vagy Microsoft), mint technológiai kérdés, mivel a három nyelv nagyjából egyenértékű. A tartalom menet közbeni előállítására szolgáló technológiák összességére néha dinamikus HTML (dynamic HTML) néven is hivatkoznak.
        
        Weboldalak dinamikus eló'állítása az ügyfél oldalán A CGI-, PHP-, JSP- és ASP-szkriptek megoldják az űrlapok kezelésének problémáját, és lehetővé teszik a kiszolgáló adatbázisainak elérését is. Mindannyian képesek az űrlapokból beérkező információk fogadására, információk kikeresésére egy vagy több adatbázisból, valamint az eredményeket tartalmazó HTML-oldalak előállítására. Egyi­ kük sem képes azonban egérműveletekre reagálni vagy a felhasználókkal közvetlenül érintkezni. Ezekre a célokra olyan szkripteket kell beágyazni a HTML-oldalakba, melyeket nem a kiszolgáló, hanem az ügyfél oldalán hajtanak végre. A HTML 4.0-tól kezdődően lehetővé vált az ilyen szkriptek használata, a <script> címke segítségével. A legnépszerűbb ügyféloldali szkriptnyelv a JavaScript, melyet most röviden be is mutatunk. A JavaScript olyan szkriptnyelv, melyet nagyon távolról inspirált a Java programo­ zási nyelv néhány ötlete. Ettől még semmiképpen nem azonos a Javával. A többi szkriptnyelvhez hasonlóan ez is nagyon magas szintű nyelv. Egyetlen JavaScriptsorral megoldható például az, hogy földobjunk egy dialógusablakot, megvárjuk a szö­ veges bevitelt, majd az eredményül kapott karakterláncot egy változóban tároljuk. Az ilyen magas szintű képességek miatt a JavaScript ideális az interaktív weboldalak lét­ rehozására. Másrészt viszont a nyelv nem szabványos, és gyorsabban mutálódik, mint a röntgengépbe szorult muslica. Emiatt rendkívül nehéz olyan JavaScript-programokat írni, melyek minden platformon működnek, de egy nap talán ez a helyzet is rendeződik. A 7.36. ábra egy JavaScript-programra mutat példát. A 7.35.(a) ábrához hasonlóan itt is egy űrlap jelenik meg, ami megkérdezi a nevet és az életkort, majd megjósolja, hogy hány éves lesz az adott személy jövőre. Az oldal törzse majdnem ugyanaz, mint a PHP-példában. A legfontosabb különbség itt az Elküld gomb deklarációjában és a benne levő hozzárendelési utasításban van. Ez a hozzárendelési utasítás mondja meg a böngészőnek, hogy gombnyomásra hívja meg a válasz szkriptet, és adja át neki az űr­ lapot, mint paramétert.
        
        696
        
        SZÁMÍTÓGÉP-HÁLÓZATOK
        
        <script language="javascript" type="text/javascript"> function valasz(test_form) { var személy = tesMorm.nev.value; var evek = eval(test_form.kor.value) + 1; document.open(); document.writeln(" "); document.writeln("Helló" + személy + ".
        "); document.writeln("Jóslat: jövőre" + evek + "éves leszel."); document.writeln(" "); document.closeQ; }
        Kérem, adja meg a nevét:

        Kérem, adja meg az életkorát:

        
        
        7.36. ábra. A JavaScript használata egy űrlap feldolgozására Ami teljesen új, az a válasz nevű JavaScript-függvény deklarációja a HTMLállomány fejrészében, ahol rendszerint csak a cím, háttérszín stb. található. Ez a függ­ vény kiolvassa a nev mező értékét az űrlapból, és karakterláncként tárolja a személy nevű változóban. Kiolvassa még a kor mező értékét is, átalakítja egésszé az eval függ­ vény használatával, hozzáad egyet, és az eredményt tárolja az evek változóban. Aztán megnyit egy dokumentumot a kimenet számára, elvégez négy kiíratást a writeln eljá­ rással, majd lezárja a dokumentumot. A dokumentum egy HTML-állomány lesz, amint az a benne lévő különféle HTML-címkékből is látszik. Végül a böngésző meg­ jeleníti a dokumentumot a képernyőn. Fontos megértenünk, hogy a 7.35. és a 7.36. ábra forrásai hasonlók ugyan, de telje­ sen máshogy kerülnek feldolgozásra. A 7.35. ábra esetében, miután a felhasználó rá­ kattintott az Elküld gombra, a böngésző összegyűjti az információt egy hosszú karak­ terláncba a 7.30. ábra módjára, és elküldi annak a kiszolgálónak, amelyik az oldalt küldte. A kiszolgáló látja a PHP-állomány nevét, és futtatja azt. A PHP-szkript egy új HTML-oldalt állít elő, és ezt az oldalt küldik vissza a böngészőnek megjelenítésre. A 7.36. ábra esetébén az Elküld gomb megnyomása után a böngésző értelmezi az adott oldalon található JavaScript-függvényt. Mindez ott helyben, a böngészőn belül kerül végrehajtásra; a kiszolgálóval nem veszik fel a kapcsolatot. Ennek köszönhetően az eredmény gyakorlatilag azonnal megjelenik, míg a PHP esetében akár több másodperc
        
        697
        
        AZ ALKALMAZÁSI RÉTEG
        
        Böngésző
        
        Kiszolgáló
        
        /
        
        1 L '4
        
        í•VA- / £*
        
        2
        
        >
        
        3
        
        ^
        
        Böngésző Felhasználó / 1
        
        Felhasználó
        
        l '2 ^
        
        PHP-modul
        
        (a)
        
        Kiszolgáló
        
        -w^rK AH)
        
        A
        
        JavaScript
        
        (b)
        
        7.37. ábra. (a) Kiszolgálóoldali szkript PHP-vel. (b) Ügyféloldali szkript JavaScripttel is eltelhet, mire a HTML-eredmény megérkezik az ügyfélhez. A kiszolgáló- és az ügyféloldali szkriptek használata közti különbséget a 7.37. ábra szemlélteti, az ezekkel járó lépésekkel együtt. A számozott lépések mindkét esetben azután kezdődnek, hogy az űrlap megjelent. Az első lépés a felhasználói bevitel elfogadásából áll. Ezután jön a bevitel feldolgozása, ami eltérő a két esetben. Ez az eltérés nem azt jelenti, hogy a JavaScript jobb, mint a PHP, hiszen a kettőnek egészen más a felhasználási területe. A PHP (és ebből adódóan a JSP és az ASP is) akkor használatos, amikor egy távoli adatbázissal kell érintkezni. A JavaScriptet ezzel szemben akkor használják, amikor a számítógép előtt ülő felhasználóval kell érintkez­ ni. Mindazonáltal lehetséges (és szokásos is) az olyan HTML-oldalak készítése, me <script language="javascript" type="text/javascript"> funclion response(test_form) { function factorial(n) {if (n == 0) return 1; else return n * factorial(n - 1);} var r = eval(test_form.number.value); // r = a beírt argumentum document.myform.mytext.value = "Itt vannak az eredményekAn"; for (var i = 1; i <= r; i++) //Egy sor kiírása 1-től Ng document.myform.mytext.value += (i + "! = " + factorial(i) + "\n"; }
        Kérem, adjon meg egy számot:

        
        
        7.38. ábra. JavaScript-program faktoriális számítására és kiíratására
        
        698
        
        SZÁMÍTÓGÉP-HÁLÓZATOK
        
        lyek mind a PHP-t, mind a JavaScriptet is használják, de ezek ekkor természetesen nem végezhetik ugyanazt a munkát, vagy nem birtokolhatják ugyanazt a gombot. A JavaScript teljes értékű programozási nyelv, a C vagy Java összes eró'sségével. Vannak benne változók, karakterláncok, tömbök, objektumok, függvények, és meg­ található az összes szokásos vezérlési szerkezet. Ezenkívül számos olyan szolgáltatást is nyújt, ami kifejezetten a weboldalak készítőinek hasznos, többek közt lehetó'vé teszi az ablakok és keretek kezelését, a sütik elküldését és visszanyerését, az űrlapok és a hiperhivatkozások kezelését. A 7.38. ábra egy olyan JavaScript-programra mutat pél­ dát, mely egy rekurzív függvényt használ. A JavaScript képes a képernyő objektumai fölött történő egérmozgások követésére is. Sok JavaScriptes weboldalra jellemző, hogy ha az egérmutatót elvisszük valami­ lyen szöveg vagy kép fölött, akkor valami történik, például megváltozik egy kép vagy hirtelen előbukkan egy menü. Az ilyen működést egyszerű megvalósítani JavaScript segítségével, ez pedig eleven weboldalakhoz vezet. A 7.39. ábra erre mutat példát. Nem csak a JavaScript segítségével kaphatunk erősen interaktív weboldalakat. Egy másik népszerű eljárás a kisalkalmazások (applets) használata. Ezek apró Java­ programok, melyeket egy virtuális számítógép, a JVM (Java Virtual Machine - Ja­ va virtuális gép) számára gépi utasításokra fordítottak. A HTML-oldalakba (az és címkék közé) ágyazható kisalkalmazasokat a JVM-mel ellátott böngészők értelmezik. Mivel a Java-kisalkalmazásokat nem közvetlenül futtatják, ha­ nem értelmezik, a Java-értelmező meggátolhatja, hogy Rossz Dolgokat tegyenek. Legalábbis elméletben. A gyakorlatban a kisalkalmazások írói a kihasználható hibák szinte végtelen sorát találták meg a Java I/O könyvtárakban.
        
        <script language="javascripf" type="text/javascript"> if (Idocument.myurl) document.myurl = new Array(); document.myurl[0] = "http://www.cs.vu.nl/~ast/im/kitten.jpg"; document.myurl[1] = "http://www.cs.vu.nl/~ast/im/puppy.jpg"; document.myurl[2] = "http://www.cs.vu.nl/~ast/im/bunny.jpg"; function pop(m) { var urx = "http://www.cs.vu.nl/~ast/im/cat.jpg"; popupwin = window.open(document.myurl[m], "mywind", "width=250, height=250"); }

        Kitten

        Puppy

        Bunny

        7.39. ábra. Interaktív weboldal, mely reagál az
        
        egérmozgásokra
        
        699
        
        AZ ALKALMAZÁSI RÉTEG
        
        A Microsoft válaszul a Sun Java kisalkalmazásaira létrehozta az ActiveX vezérlő­ ket (ActiveX controls) tartalmazó weboldalakat. A vezérlők olyan programok, me­ lyeket a Pentium gépi nyelvére fordítottak le, és tisztán hardveresen futtatnak. Emiatt sokkal gyorsabbak és rugalmasabbak is, mint az értelmezett Java-kisalkalmazások, mert megtehetnek mindent, amit egy program megtehet. Amikor az Internet Explorer egy ActiveX vezérlőt talál egy weboldalon, akkor letölti, ellenőrzi az azonosságát, és futtatja. Az idegen programok letöltése és futtatása azonban biztonsági kérdéseket vet fel, melyeket a 8. fejezetben válaszolunk meg. Mivel szinte minden böngésző képes mind a Java-programok, mind a JavaScript értelmezésére, az a tervező, aki egy erősen interaktív weboldalt szeretne elkészíteni, legalább két módszer közül választhat, sőt, ha a különböző platformok közti hordoz­ hatóság nem szempont, akkor ehhez még az ActiveX is hozzájön. Általános szabály­ ként elmondhatjuk, hogy a JavaScript-programokat egyszerűbb megírni, a Java­ kisalkalmazások gyorsabban hajtódnak végre, az ActiveX vezérlők pedig a leggyor­ sabban tudnak. Továbbá minden böngésző pontosan ugyanazt a JVM-et implemen­ tálja, de nincs két olyan böngésző, mely ugyanazt a JavaScript-verziót implementálná, ezért a Java-kisalkalmazások hordozhatóbbak, mint a JavaScript-programok. A JavaScriptről többet is megtudhatunk a témában íródott számos terjedelmes (olykor 1000 oldalnál is hosszabb) könyvből, mint például (Easttom, 2001; Harris, 2001; va­ lamint McFedries, 2001) műveiből. Mielőtt elhagynánk a dinamikus webtartalom témakörét, foglaljuk össze röviden, hogy mi mindent érintettünk eddig. Teljes weboldalakat is elő lehet állítani menet közben különféle szkriptekkel a kiszolgáló oldalán. A böngésző megkapja és egysze­ rűen megjeleníti ezeket, mint a szokványos weboldalakat. A szkripteket meg lehet írni Periben, PHP-ben, JSP-ben vagy ASP-ben, amint azt a 7.40. ábra mutatja. A dinamikus tartalmat az ügyfél oldalán is elő lehet állítani. A weboldalakat XMLben is meg lehet írni, majd ezután HTML-be lehet alakítani egy XSL-állomány alap­ ján. A JavaScript-programok tetszőleges számításokat elvégezhetnek. Végül, plug-inek és segédalkalmazások segítségével a tartalmat különböző formákban is meg lehet jeleníteni. XSLértelmező-
        
        Az ügyfél gépe Böngésző
        
        A kiszolgáló gépe Kiszolgáló
        
        XMLértelmező" HTMLértelmező JavaScript- Plug-in értelmező 7.40. ábra. A tartalom előállításának és megjelenítésének különböző módjai
        
        700
        
        7.3.4.
        
        SZÁMÍTÓGÉP-HÁLÓZATOK
        
        HTTP - a hipertext átviteli protokoll
        
        A HTTP (HyperText Transfer Protocol - hipertext átviteli protokoll) a Világháló (Web) általános átviteli protokollja. A protokoll meghatározza, hogy az ügyfelek mi­ lyen üzeneteket küldhetnek a kiszolgálóknak, és hogy ezekre milyen válaszokat kap­ hatnak. Minden interakció egy ASCII-kérésból és egy ezt követő' RFC 822 MIMEszerű válaszból áll. A protokollt az RFC 2616 definiálja; ezen előírásoknak eleget kell tennie minden ügyfélnek és kiszolgálónak. Ebben a szakaszban szemügyre vesszük a HTTP fontosabb tulajdonságait. Kapcsolatok A böngészők általában úgy veszik fel a kapcsolatot a kiszolgálókkal, hogy egy TCPösszeköttetést építenek ki a kiszolgáló gépének 80-as portjával, bár a szabvány ezt formálisan nem követeli meg. A TCP használatának előnye az, hogy sem a böngésző­ nek, sem a kiszolgálónak nem kell aggódnia az elveszett, megkettőzött vagy hosszú üzenetek, illetve a nyugták miatt. Az összes ilyen kérdésről a TCP-implementáció gondoskodik. A HTTP 1.0-ban az összeköttetés kiépítése után egyetlen kérést küldtek el, amire egyetlen válasz érkezett. Ezután a TCP-összeköttetést lebontották. Abban a világban, amikor egy tipikus weboldal még kizárólag szövegből állt, ez még helyénvaló is volt. Pár év múlva azonban egy átlagos weboldal már számos ikont, képet és egyéb vizuális nyalánkságot tartalmazott, és nagyon költségessé tette a működést, hogy minden egyes ikon átviteléhez külön TCP-összeköttetést kellett kiépíteni. Ez a megfigyelés vezetett a HTTP 1.l-hez, ami már támogatja a tartós kapcsola­ tokat (persistent connections). Ezáltal lehetővé vált, hogy kiépítsünk egy TCP összeköttetést, elküldjünk egy kérést, megkapjuk a választ, majd pedig további kéré­ seket küldjünk és válaszokat kapjunk. Azáltal, hogy több kérés esetén nem kell külön TCP-kiépítés és lebontás, az egyes kérésekre jutó, a TCP által okozott relatív többlet­ terhelés sokkal kisebb lesz. A kéréseket akár csővezeték (pipeline) módszerrel is lehet küldeni, azaz már azelőtt el lehet küldeni a 2-es kérést, hogy az 1 -es kérésre megérke­ zett volna a válasz. Eljárások Bár a HTTP-t a Weben való használatra tervezték, szándékosan a szükségesnél általá­ nosabbra készítették, szem előtt tartva az eljövendő objektumorientált alkalmazásokat. A protokoll ebből kifolyólag olyan műveleteket, más néven eljárásokat (method) is támogat, melyek nem pusztán egy weboldal elkérésére irányulnak. Ez az általánosság tette lehetővé a SOAP létrejöttét is. Minden kérés egy- vagy többsornyi ASCIIszövegből áll, ahol az első sor első szava a kért eljárás neve. A beépített eljárásokat a 7.41. ábra sorolja fel. Amikor általános objektumokhoz kell hozzáférni, az objektumra jellemző eljárások is elérhetők lesznek. A nevek érzékenyek a kisbetű/nagybetű kü­ lönbségre, így a GET egy legális eljárás, de a get nem az.
        
        AZ ALKALMAZÁSI RÉTEG
        
        701
        
        Leírás
        
        Eljárás GET
        
        Kérés egy weboldal olvasására
        
        HEAD
        
        Kérés egy weboldal fejrészének olvasására
        
        PUT
        
        Kérés egy weboldal tárolására
        
        POST
        
        Egy megnevezett erőforráshoz (pl. weboldalhoz) való hozzáfűzés
        
        DELETE
        
        A weboldal eltávolítása
        
        TRACE
        
        A bejövő kérés visszaküldése
        
        CONNECT
        
        Fenntartva későbbi használatra
        
        OPTIONS
        
        Bizonyos opciók lekérdezése
        
        7.41. ábra. A beépített HTTP-kérés-eljárások A GET eljárás arra kéri a kiszolgálót, hogy küldje el az oldalt (ami alatt a legáltalá­ nosabb esetben objektumot értünk, de a gyakorlatban ez rendszerint csak egy állo­ mány). Az oldal megfelelő módon MIME-ben van kódolva. A webszerverekhez inté­ zett kérések túlnyomó többsége GET. A GET szokásos alakja: GET állománynév HTTP/1.1
        
        ahol az állománynév a letöltendő erőforrás (állomány) neve, és 1.1 a használt proto­ koll verziója. A HEAD eljárás csak az üzenet fejrészét kéri, a tényleges oldal nélkül. Ez az eljá­ rás használható arra, hogy megszerezzük egy oldal utolsó módosítási idejét, hogy in­ formációt gyűjtsünk indexelési célokra, vagy egyszerűen ellenőrizzük egy URL érvé­ nyességét. A PUT eljárás a GET fordítottja: az oldal olvasása helyett írja azt. Ez az eljárás te­ szi lehetővé weboldalak gyűjteményének felépítését a távoli kiszolgálókon. A kérés törzse tartalmazza az oldalt. Ez lehet MIMÉ szerint kódolt; ebben az esetben a PUT-ot követő sorok tartalmazhatják a Tartalom típusa és a hitelesítési fejrészeket annak bi­ zonyítására, hogy a hívónak valóban van engedélye a kívánt feladat végrehajtására. A PUT-hoz némileg hasonló a POST eljárás. Ez is egy URL-t hordoz, de a megle­ vő adat felülírása helyett az új adatot „hozzáadja" ahhoz valamilyen általános érte­ lemben. Az ilyen értelmű hozzáadásra lehet példa egy üzenet postázása egy hírcso­ portba, vagy egy állomány hozzáadása egy hirdetőtábla-rendszerhez. A gyakorlatban sem a PUT-ot, sem a POST-ot nem nagyon használják. A DELETE azt teszi, amit várunk: törli az oldalt. Akárcsak a PUT-nál, itt is nagy szerepet játszik a hitelesítés és az engedélyezés. Arra azonban nincs garancia, hogy a DELETE sikerülni fog, mert még ha a távoli HTTP-kiszolgáló hajlandó is törölni az oldalt, az azt tartalmazó állománynak olyan attribútuma lehet, amely megtiltja a ki­ szolgáló számára a módosítást vagy eltávolítást. A TRACE eljárás a hibakeresést szolgálja. Arra utasítja a kiszolgálót, hogy küldje vissza a kérést. Ez akkor hasznos, amikor a kéréseket nem megfelelő' módon dolgozzák fel, és az ügyfél tudni akarja, hogy ténylegesen milyen kérést kapott meg a kiszolgáló.
        
        702 Kód
        
        SZÁMÍTÓGÉP-HÁLÓZATOK
        
        Jelentés
        
        Példák
        
        Információ
        
        100 = a kiszolgáló jóváhagyja az ügyfél kérését
        
        2xx
        
        Siker
        
        200 = sikeres kérés; 204 = nincs tartalom
        
        3xx
        
        Átirányítás
        
        301 = az oldal elköltözött;
        
        1xx
        
        304 = a gyorstárban tárolt oldal még érvényes 4xx
        
        Ügyfél hibája
        
        403 = tiltott oldal; 404 = az oldal nem található
        
        5xx
        
        Kiszolgáló hibája
        
        500 = belső hiba a kiszolgálóban; 503 = próbálkozzon újra később
        
        7.42. ábra. A válasz állapotkódjának csoportjai A CONNECT eljárást jelenleg nem használják, jövőbeli használatra van fenntartva. Az OPTIONS eljárás lehetővé teszi, hogy az ügyfél lekérdezze a kiszolgáló vagy egy konkrét állomány tulajdonságait. Minden kérésre érkezik egy válasz, ami egy állapotsorból, és esetleg további in­ formációkból (pl. egy weboldal része vagy egésze) áll. Az állapotsor tartalmazza a há­ romjegyű állapotkódot, ami megmondja, hogy a kérést teljesítették-e, és ha nem, miért nem. Az első számjegy öt nagy csoportra osztja a válaszokat, ahogy azt a 7.42. ábra mutatja. Az lxx kódokat ritkán használják a gyakorlatban. A 2xx kódok azt jelentik, hogy a kérést sikeresen kezelték, és érkezik is vissza a tartalom (ha van). A 3xx kódok arra utalnak, hogy az ügyfélnek máshol kell keresgélnie vagy egy másik URL-lel vagy a saját gyorstárjában (ezt később tárgyaljuk). A 4xx kódok azt jelentik, hogy a kérést az ügyfél hibája miatt nem lehet teljesíteni, mert pl. érvénytelen a kérés, vagy nem létezik az oldal. Végül, az 5xx kódok azt jelzik, hogy magának a kiszolgálónak van valamilyen gondja vagy egy szoftverhiba vagy az ideiglenes túlterhelés miatt.
        
        Üzenetfejrészek A kérés sora (pl. a GET eljárást tartalmazó sor) után további információkat tartalmazó sorok következhetnek. Ezeket a kérés fejrészének (requesí headers) nevezzük. Az ilyen információk az eljáráshívások paramétereihez hasonlatosak. A válaszoknak szintén lehetnek válaszfejrészei (response headers). Egyes fejrészeket akár mindkét irányban is lehet használni. A legfontosabb fejrészeket a 7.43. ábra mutatja be. A Felhasználói-ügynök (User-Agent) fejrész lehetővé teszi, hogy az ügyfél közölje a kiszolgálóval böngészőjének és operációs rendszerének tulajdonságait, és egyéb jellemzőket. A 7.34. ábrán már láthattuk, hogy a kiszolgálónak varázslatos módon volt ilyen információja, és kérésre elő tudta azt állítani egy PHP-szkriptben. Ezt a fej­ részt tehát arra használja az ügyfél, hogy információkat adjon át a kiszolgálónak. A négy Elfogadható (Accept) fejrész azt mondja meg a kiszolgálónak, hogy az ügyfél mit hajlandó elfogadni, amennyiben csak egy korlátozott választék elfogadásá­ ra van módja. Az első típus azt adja meg, hogy az ügyfél milyen MIME-típusokat lát szívesen (pl. text/html). A második megadja a karakterkészletet (pl. ISO-8859-5 vagy Unicode-1-1). A harmadik a tömörítési eljárásokkal foglalkozik (pl. gzip). A negyedik
        
        703
        
        AZ ALKALMAZÁSI RÉTEG
        
        egy természetes nyelvet jelöl (pl. spanyol). Ha a kiszolgáló több oldal közül is vá­ laszthat, akkor ezen információk felhasználásával azt adhatja vissza, amit az ügyfél keres. Ha nem képes teljesíteni a kérést, akkor egy hibakóddal tér vissza, és a kérés meghiúsul. A Hoszt (Hőst) fejrész a kiszolgálót nevezi meg; ezt az URL-ból veszik ki. Ez a fejrész kötelező. Azért használják, mert némely IP-címhez több DNS-név is tartozik, és a kiszolgálónak valahogy el kell döntenie, hogy melyik hosztnak adja tovább a kérést. Az, Engedélyezés (Authorization) fejrészre a védett oldalak esetén van szükség. Ek­ kor az ügyfélnek esetleg bizonyítania kell, hogy jogosult megnézni az oldalt - erre szolgál ez a fejrész. Fejrész
        
        Tartalom
        
        Típus
        
        Felhasználói­ ügynök
        
        Kérés
        
        Információ a böngészőről és annak platformjáról
        
        Elfogadható
        
        Kérés
        
        Az ügyfél által kezelhető oldalak típusa
        
        Elfogadható­ karakterkészlet
        
        Kérés
        
        Az ügyfél által elfogadható karakterkészletek
        
        Elfogadható­ kódolás
        
        Kérés
        
        Az ügyfél által kezelhető oldalkódolási típusok
        
        Elfogadható-nyelv
        
        Kérés
        
        Az ügyfél által kezelhető természetes nyelvek
        
        Hoszt
        
        Kérés
        
        A kiszolgáló DNS-neve
        
        Engedélyezés
        
        Kérés
        
        Az ügyfél igazolásainak listája
        
        Süti
        
        Kérés
        
        Visszaküld egy előzőleg kapott sutit a kiszolgálónak
        
        Dátum
        
        Mindkettő
        
        Az üzenet elküldésének dátuma és ideje
        
        Átállás
        
        Mindkettő
        
        Az a protokoll, amire a kiszolgáló váltani szeretne
        
        Kiszolgáló
        
        Válasz
        
        Információ a kiszolgálóról
        
        Tartalom-kódolás
        
        Válasz
        
        Hogyan van kódolva a tartalom (pl. gzip)
        
        Tartalom-nyelv
        
        Válasz
        
        Az oldalon használt természetes nyelv
        
        Tartalom-hossz
        
        Válasz
        
        Az oldal hossza bájtokban
        
        Tartalom-típus
        
        Válasz
        
        Az oldal MlME-típusa
        
        Utoljára­ módosítva
        
        Válasz
        
        Az oldal utolsó változtatásának dátuma és ideje
        
        Hely
        
        Válasz
        
        Utasítás az ügyfélnek, hogy küldje a kérését máshova
        
        Elfogadható­ tartományok
        
        Válasz
        
        A kiszolgáló elfogadja a bájftartományokra vonatkozó kéréseket
        
        Süti-beállítás
        
        Válasz
        
        A kiszolgáló azt akarja, hogy az ügyfél tároljon egy sutit
        
        7.43. ábra. Néhány HTTP-üzenetfejrész
        
        704
        
        SZÁMÍTÓGÉP-HÁLÓZATOK
        
        Bár a sütikkel nem az RFC 2616, hanem az RFC 2109 foglalkozik, ezeknek is ju­ tott két fejrész. A Süti (Cookie) fejrész segítségével az ügyfelek visszaküldhetnek a kiszolgálónak egy olyan sutit, mely előzőleg a kiszolgáló körzetének valamelyik gé­ pétől érkezett. A Dátum (Date) fejrész mindkét irányban használható, és az üzenet elküldésének dátumát és idejét tartalmazza. Az Átállás (Upgrade) arra szolgál, hogy egyszerűbbé tegye a HTTP-protokoll egy jö­ vőbeli (esetlegesen inkompatibilis) verziójára való átállást. Ez lehetővé teszi, hogy az ügyfél bejelentse, mit képes kezelni, és hogy a kiszolgáló is kimondja, mit használ. Ezzel elérkeztünk azokhoz a fejrészekhez, melyeket kizárólag a kiszolgáló használ a kérésekre adott válaszokban. Az első, a Kiszolgáló (Server) lehetővé teszi, hogy a kiszolgáló bemutatkozzon, és elmondja pár tulajdonságát, ha akarja. A következő négy, „Tartalom-" (Content) kezdetű fejrész segítségével a kiszolgáló megadhatja az éppen elküldött oldal jellemzőit. Az Utoljára-módosítva (Last-modified) fejrész megmondja, hogy mikor módosítot­ ták utoljára az oldalt. Ez a fejrész fontos szerepet játszik a gyorstárak kezelésében. A Hely (Location) fejrészt a kiszolgáló arra használja, hogy közölje az ügyféllel: próbálkozzon egy másik URL-lel. Ez akkor hasznos, ha az oldal elköltözött, vagy ha több URL is mutat ugyanarra az oldalra (esetleg különböző kiszolgálókon). Használ­ ják még azok a vállalatok is, melyeknek van egy központi weboldaluk a com körzet­ ben, de onnan az ügyfeleket átirányítják a nemzeti vagy regionális oldalra az IP-címük vagy a preferált nyelvük alapján. Ha egy oldal nagyon nagy méretű, akkor egy kisebb ügyfél esetleg nem akarja megkapni egyszerre az egészet. Egyes kiszolgálók bájttartományokra vonatkozó kéré­ seket is elfogadnak, így az oldalt több kisebb egységben is le lehet tölteni. Az Elfo­ gadható-tartományok (Accept-Ranges) fejrész azt jelenti be, hogy a kiszolgáló hajlan­ dó ilyen jellegű részleges kéréseket kezelni. A kiszolgálók a második sütifejrész, a Süti-beállítás (Set-Cookie) útján küldik el sütijeiket az ügyfeleknek. Az ügyfélnek el kell mentenie a sutit, és az ezt követő kéré­ sekben vissza kell küldenie a kiszolgálónak. Példa a HTTP használatára A HTTP egy ASCII-protokoll, ezért meglehetősen egyszerűen lehet egy terminálról (nem pedig böngészőből) személyesen és közvetlenül a webszervérrel beszélni. Ehhez nem kell más, csak egy TCP-összeköttetés a kiszolgáló 80-as portjával. Javasoljuk, hogy az Olvasó személyesen is próbálja ki ezt a forgatókönyvet (lehetőleg egy UNIX rendszerről, mert egyes más rendszerek nem adják vissza a kapcsolat állapotát). A kö­ vetkező parancssorozat elég is lesz: telnet www.ietf.org 80 >log GET/rfc.HTML HTTP/1.1 Hőst: www.ietf.org
        
        close
        
        AZ ALKALMAZÁSI RÉTEG
        
        705
        
        Ez a parancssorozat egy telnet (azaz TCP) összeköttetést kezdeményez az IETF webszerverének 80-as portjával a www.ietf.org címen. A kapcsolat eredményét a log állományba irányítjuk át, későbbi tanulmányozás céljából. Ezután következik a GET parancs, ami megnevezi az állományt és a protokollt. A következő sor a kötelező Hoszt fejrész. Az üres sorra szintén szükség van: ez jelzi a kiszolgálónak, hogy nincs több kérésfejrész. A close parancs arra utasítja a telnet programot, hogy bontsa le az összeköttetést. A log állományt bármely szerkesztővel megtekinthetjük. Az elejének a 7.44. ábra tartalmához hasonlónak kell lennie, hacsak az IETF meg nem változtatta az oldalt mostanában. Az első három sort a telnet program írja ki, nem a távoli hely. A HTTP 1.1 -gyei kez­ dődő sor az IETF válasza, miszerint hajlandó a HTTP 1.1 nyelven beszélni velünk. Ezt követi egy csomó fejrész, majd a tartalom. Az összes fejrészt ismerjük már, kivéve az ETag-et, ami egy egyedi oldalazonosító a gyorstárak számára, és az X-Pad-et, ami nem szabványos, és valószínűleg valamilyen hibás böngésző számára szükséges praktika.
        
        Trying 4.17.168.6... Connected to www.ietf.org. Escape character is ']'• HTTP/1.1 200 OK Date: Wed, 08 May 2002 22:54:22 GMT ETag: "2a79d-c8b-39bce48d" Accept-Ranges: bytes Content-Length: 3211 Content-Type: text/html X-Pad: avoid browser bug <script language="javascript"> function url() { var x = document.forml .number.value if (x.length == 1) {x = "000" + x } if (x.length == 2) {x = "00" + x } if (x.length == 3) {x = "0" + x } document.forml .action = 7rfc/ríc" + x + ".txt" document.forml .submit }
        
        7.44. ábra. A www.ietf.org/rfc.html oldal kimenetének eleje
        
        706 7.3.5.
        
        SZÁMÍTÓGÉP-HÁLÓZATOK
        
        Teljesítménynövelés
        
        A Web népszerűsége kis híján a vesztévé is vált. A kiszolgálók, routerek és vonalak gyakran túlterheltek. A WWW-t sokan már Világméretű Várakozásként (World Wide Wait) kezdik emlegetni. A vég nélküli késedelmek miatt a kutatók különféle módsze­ reket fejlesztettek ki a teljesítmény növelésére. Most hármat vizsgálunk meg ezek közül: a tárgyorsítást, a kiszolgálók többszörözését és a tartalomszolgáltató hálózatokat.
        
        Tárgyorsítás A teljesítmény fokozásának viszonylag egyszerű módja az, hogy a kért oldalakat eltá­ roljuk arra az esetre, ha megint szükség lenne rájuk. Ez a módszer különösen haté­ kony a sokat látogatott oldalak esetében, mint például a www.yahoo.com vagy a www.cnn.com. Az oldalak későbbi felhasználás céljából történő tárolását tárgyorsí­ tásnak (caching) nevezzük. A szokásos eljárás szerint egy helyettes (proxy) nevű folyamat kezeli a gyorstárat (cache). A tárgyorsítás használatához a böngészőt be le­ het állítani úgy, hogy minden kérést a helyetteshez intézzen az oldal tényleges kiszol­ gálója helyett. Ha a helyettes rendelkezik az oldallal, akkor azonnal visszatér vele. Ha nem, akkor letölti az oldalt a kiszolgálóról, berakja a tárba későbbi használatra, és visszaadja annak az ügyfélnek is, akitől a kérés származott. A tárgyorsítás két fontos kérdése a következő: 1. Ki végezze a tárgyorsítást? 2. Mennyi ideig legyenek az oldalak a gyorstárban? Az első kérdésre több válasz is adható. Helyettesek gyakran futnak az egyes PC-ken is; ezek gyorsan meg tudják keresni az előzőkben meglátogatott oldalakat. Egy válla­ lati LAN-on a helyettes sokszor egy olyan gép, melyen a LAN összes többi gépe osz­ tozik, így ha egy felhasználó megnéz egy bizonyos oldalt, majd ugyanazon LAN egy másik felhasználója is meg szeretné nézni ugyanazt az oldalt, akkor azt le lehet tölteni a helyettes gyorstárából. Sok internetszolgáltató is futtat helyetteseket, hogy felgyor­ sítsa az elérést előfizetői számára. Mindezen gyorstárak gyakran egyszerre működnek, azaz a kérés először a helyi helyetteshez kerül. Ha itt nem sikerül teljesíteni, akkor a helyi helyettes megkérdezi a LAN helyettesét. Ha ez sem jár sikerrel, akkor a LAN helyettese a szolgáltató helyettesénél próbálkozik. Ez utóbbinak már mindenképp si­ kerül teljesíteni a kérést, vagy a helyi gyorstárból, vagy egy magasabb szintű tárból, vagy pedig magától a kiszolgálótól. A több, sorban egymás után következő gyorstárat magában foglaló séma neve hierarchikus tárgyorsítás (hierarchical caching). A 7.45. ábra ennek egy lehetséges megvalósítását szemlélteti. Hogy mennyi ideig legyenek az oldalak a gyorstárban, az már kicsit fogósabb kér­ dés. Egyes oldalak egyáltalán nem valók a tárba. Egy olyan oldal például, mely az 50 legaktívabb részvény árait tartalmazza, minden másodpercben változik. Ha ezt berak­ nánk a gyorstárba, akkor az innen másolatot kapó ügyfél elévült (stale) adatokhoz
        
        707
        
        AZ ALKALMAZÁSI RÉTEG
        
        Helyettes
        
        Ügyfél gépe
        
        Internet
        
        Ügyféloldali LAN
        
        Helyettes
        
        Az internetszolgáltató LAN-ja
        
        .7.45. ábra. Hierarchikus tárgyorsítás három helyettessel
        
        jutna. Másfelől viszont, ha a tőzsdei kereskedés már véget ért aznapra, akkor az oldal még órákig vagy napokig érvényes marad, míg a következő kereskedési nap el nem kez­ dődik. Ennélfogva az oldalak gyorstárban való tárolhatósága idővel erősen változhat. El kell döntenünk tehát, hogy mikor rakjunk ki egy oldalt a tárból. Ennek a döntés­ nek az a kulcskérdése, hogy a felhasználó milyen fokú évültséget hajlandó elfogadni. (Mivel az oldalak tárolása a háttértáron folyik, az elfoglalt hely kérdése nemigen je­ lent gondot.) Ha a helyettes hamar kidobja az oldalakat, akkor ritkán fog elévült ol­ dallal visszatérni, de nem is lesz túl hatékony (vagyis alacsony lesz a találati aránya). Ha viszont túl sokáig tartja meg az oldalakat, akkor magas találati arányt érhet el, de ennek az lesz az ára, hogy gyakran fog elévült oldalakkal visszatérni. Kétfajta megközelítés lehetséges a probléma kezelésére. Az első egy heurisztika segítségével igyekszik kitalálni, hogy mennyi ideig tartsa meg az egyes oldalakat. Ez esetben a benntartási időt az Utoljára-módosítva fejrész alapján szokták megválaszta­ ni (lásd a 7.43. ábrát). Ha az oldalt egy órája módosították, akkor egy óráig fogják tá­ rolni a gyorstárban. Ha egy éve módosították, akkor nyilván nagyon stabil oldal (mondjuk, a görög és római mitológia isteneinek listája), következésképp egy évre el lehet tárolni azzal az ésszerű feltételezéssel, hogy ezalatt nem fog változni. Ez a heu­ risztika többnyire jól működik a gyakorlatban, bár időről időre elévült oldalakat is szolgáltat. A másik megközelítés költségesebb, de kiküszöböli az elévült oldalak lehetőségét azáltal, hogy kihasználja az RFC 2616-nak a gyorstárak kezelésére vonatkozó külön­ leges funkcióit. Ezen funkciók közül az egyik leghasznosabb a Ha-változott-azóta (IfModified-Since) kérésfejrész, amit a helyettes küldhet a kiszolgálónak. Ez megadja a helyettes által kért oldalt, és azt az időt, amikor a tárolt oldalt utoljára módosították (az Utoljára-módosítva fejrész alapján). Ha az oldal azóta nem változott, a kiszolgáló egy rövid Nem módosult (Not Modified) üzenetet küld vissza (304-es állapotkód a 7.42. ábrában), ami arra utasítja a helyettest, hogy használja tovább a tárolt oldalt. Ha az oldal azóta megváltozott, akkor visszaküldik magát az új oldalt. Ennél az eljárásnál ugyan mindig szükség van egy kérés- és egy válaszüzenetre, de a válaszüzenet nagyon rövid lesz, ha a tárban lévő példány még mindig érvényes. A két megközelítés könnyen ötvözhető is. Ekkor az oldal letöltését követő AT idő­ ben a helyettes mindig a tárolt példányt adja vissza az ügyfeleknek; bizonyos idő el­ telte után pedig a Ha-változott-azóta üzenetek segítségével ellenőrzi az oldal frisses­ ségét. AT értékét állandóra választva a dolognak valamilyen heurisztikát ad attól füg­ gően, hogy az oldal milyen régen volt utoljára módosítva.
        
        708
        
        SZÁMÍTÓGÉP-HÁLÓZATOK
        
        Dinamikus (pl. PHP-szkript által generált) tartalommal rendelkező weboldalak so­ ha nem gyorsíthatók így, mivel paramétereik változhatnak. Ezen és más esetek keze­ lésére létezik egy általános eljárás, amely szerint a kiszolgálónak utasítania kell az út­ vonal mentén lévő összes helyettest, egészen az ügyfélig visszamenően, hogy ne használják az adott oldalt ismét frissességének ellenőrzése nélkül. Ezt az eljárást egyébként bármely, várhatóan gyorsan változó oldal esetében is lehet használni. Az RFC 2616 még számos egyéb gyorstár-vezérlő algoritmust is definiál ezeken kívül. A teljesítmény növelésének újabb eszköze a proaktív tárgyorsítás. Ha egy helyettes letölt egy oldalt egy kiszolgálóról, akkor egyúttal megvizsgálhatja azt, hogy vannak-e rajta hiperhivatkozások. Ha vannak, akkor máris elküldheti a kéréseket a fontosabb kiszolgálóknak, hogy előre betöltse a tárba a hivatkozott oldalakat, hátha szükség lesz rájuk. Ez a módszer csökkentheti az egymást követő kérések elérési idejét, ugyanak­ kor el is áraszthatja a kommunikációs vonalakat olyan oldalakkal, melyekre sosem lesz szükség. Nyilvánvaló, hogy a webes tárgyorsítás kérdése messze nem triviális, ezért sokat beszélhetnénk még róla. Valójában egész könyveket is írtak róla, például (Rabinovich és Spatschek, 2002; valamint Wessels, 2001). Számunkra azonban ideje továbblépni a következő témánkra.
        
        Kiszolgálók többszörözése A tárgyorsítás az ügyfél oldalán gondoskodik a teljesítmény növeléséről, de emellett léteznek kiszolgálóoldali módszerek is. A kiszolgálók a leggyakrabban azt a megkö­ zelítést használják a teljesítmény fokozására, hogy tartalmukat több, egymástól távol elhelyezkedő helyen is megismétlik. Ezt a módszert tükrözésnek (mirroring) is ne­ vezik. A tükrözés egyik tipikus esete az, amikor egy vállalat központi weboldalán van né­ hány hivatkozással ellátott kép, mondjuk a vállalat keleti, nyugati, északi és déli regi­ onális weboldalaira. A felhasználó ekkor a hozzá legközelebb esőre kattint, hogy el­ jusson az adott kiszolgálóhoz. Ettől kezdve minden kérés ehhez a kiválasztott kiszol­ gálóhoz érkezik. A tükrözött webhelyek általában teljesen statikusak. A vállalatnak csak azt kell el­ döntenie, hogy hová akarja elhelyezni a tükörkiszolgálókat, aztán minden régióban felállít egy kiszolgálót, és mindenhová többé-kevésbé ugyanazt a tartalmat viszi fel (esetleg kihagyja a hómarókat a miami webhelyről, a strandlepedőket pedig az anchorage-i helyről). Az oldalválaszték hónapokig vagy akár évekig is változatlan maradhat. Sajnos a Webnek van egy hirtelen tömeg (flash crowds) nevű jelensége, amikor is egy addig ismeretlen, nem látogatott, holtágat képző oldal hirtelen az ismert világegye­ tem középpontjává válik. A floridai kormányhivatal weboldala, a www.dos.state.fl.us, például egészen 2000. november 6-ig békésen közölte Florida állam kormányülései­ nek jegyzőkönyveit, valamint az útmutatásokat arra vonatkozóan, hogy hogyan lehet valakiből Floridában közjegyző. 2000. november 7-én azonban, amikor az amerikai elnökválasztás kérdése egy maroknyi floridai megye pár ezer vitatott szavazatán múlt,
        
        AZ ALKALMAZÁSI RÉTEG
        
        709
        
        ez az oldal bekerült a világ öt legfontosabb oldala közé. Mondani sem kell, hogy nem bírta ezt a terhelést, és majd' megszakadt az erőfeszítésektől. Mindebből az következik, hogy ha egy weboldal hirtelen drámai forgalomnöveke­ dést észlel, akkor valamilyen módon lehetővé kell tenni számára azt, hogy automati­ kusan klónoztathassa magát több helyen, ahogy az igények megkívánják. Az ilyen helyek aztán addig működnek, amíg a vihar el nem múlik; ezután pedig többségüket vagy akár az összest megszüntetik. Ehhez az adott webhelynek előre meg kell álla­ podnia egy céggel, melynek sokfelé vannak kiszolgálóhelyei, hogy igény szerint ké­ szítsen neki másolatokat, cserébe pedig fizetnek neki az aktuálisan igénybe vett kapa­ citás után. Ennél is rugalmasabb stratégia az, ha a dinamikus másolatokat oldalanként készítik el, attól függően, hogy honnan származik a forgalom. (Pierre és mások, 2001; vala­ mint Pierre és mások, 2002) számolnak be az ilyen irányú kutatásokról.
        
        Tartalomközvetítő hálózatok A kapitalizmus csodája az, hogy valaki még azt is kitalálta, hogy hogyan lehet pénzt csinálni a Világméretű Várakozásból. Valahogy így: a CDN- (Content Delivery Networks - tartalomszállító hálózatok) vállalatok megkeresik a tartalomszolgáltató­ kat (zenei oldalakat, újságokat és minden olyan szolgáltatót, aki a tartalmát könnyen és gyorsan szeretné hozzáférhetővé tenni), és felajánlják nekik, hogy tartalmukat - bi­ zonyos díj ellenében - hatékonyan eljuttatják a végfelhasználóhoz. Miután megkötöt­ ték a szerződést, a tartalom tulajdonosa átadja a CDN-nek a webhelyének tartalmát előfeldolgozásra (ezt rögtön tárgyaljuk), majd azt követően terjesztésre. A CDN ezután megkeres sok internetszolgáltatót, és megkéri őket, hogy jó pénzért engedélyezzék neki egy értékes tartalommal megtömött, távolról felügyelt kiszolgáló elhelyezését a LAN-jukon. A szolgáltatónak ez nemcsak bevételi forrás, mert ezáltal az előfizetői kitűnő válaszidővel érhetik el a CDN tartalmát, a szolgáltató tehát ver­ senyelőnyre is szert tesz azokkal szemben, akik nem fogadták el a CDN-től az ingyen pénzt. Ilyen feltételek mellett a CDN-nel való szerződés nem lehet kérdéses egy internetszolgáltató számára. Nem csoda, hogy a legnagyobb CDN-ek máris több mint 10 000 kiszolgálót telepítettek szerte a világon. Ha a tartalmat világszerte több ezer helyen megismétlik, akkor nyilvánvalóan re­ mek lehetőség nyílik a teljesítmény növelésére. Persze ahhoz, hogy ez működjön, az ügyfél kérését valahogy a legközelebbi CDN-kiszolgálóhoz kell átirányítani, lehetőleg egy olyanhoz, amelyik az ügyfél internetszolgáltatójánál van felállítva. Ennek az át­ irányításnak ráadásul úgy kell működnie, hogy ne kelljen módosítani sem a DNS-t, sem a megszokott internet-infrastruktúra bármely más részét. Következzék tehát a legnagyobb CDN, az Akamai némileg egyszerűsített leírása. Az egész folyamat ott kezdődik, hogy a tartalomszolgáltató átadja a CDN-nek a webhelyét. A CDN ezután minden oldalt keresztülvisz egy előfeldolgozón, amely módosítja az URL-eket az oldalakon. A stratégia mögött az az elgondolás húzódik meg, hogy a tartalomszolgáltató webhelye sok apró oldalból áll (csak HTML-szöveggel), de ezek az oldalak gyakran hivatkoznak nagy állományokra^ például képekre,
        
        710
        
        SZÁMÍTÓGÉP-HÁLÓZATOK
        
        hangra, mozgóképekre. A módosított HTML-oldalakat ezután is a tartalomszolgáltató kiszolgálóján tárolják, és onnan a megszokott módon lehet letölteni azokat; csak a ké­ pek, a hang és a mozgóképek kerülnek a CDN kiszolgálóira. A séma tényleges működésének szemléltetésére vegyük a Bundás Videó webolda­ lát a 7.46.(a) ábrán. Az előfeldolgozás után ez a 7.46.(b) ábra alakját ölti, és felkerül a Bundás Videó kiszolgálójára a www.bundasvideo.com/index.html címen. Amikor a felhasználó begépeli a www.bundasvideo.com URL-t, a DNS megadja a Bundás Videó weboldalának IP-címét, hogy a központi (HTML) oldalt a megszokott módon le lehessen tölteni. Ha valamelyik hiperhivatkozásra rákattintanak, a böngésző' kikeresteti a DNS-sel a cdn-server.com címét. Ezután elküld egy HTTP-kérést erre az IP-címre, és egy MPEG-állományt vár vissza. Az azonban nem jön, mert a cdn-server.com nem szolgáltat semmilyen tartalmat. Ez ugyanis a CDN hamis HTTP-kiszolgálója, és annyit tesz, hogy megvizsgálja az állomány és a kiszolgáló nevét, hogy kitalálja, melyik tartalomszolgáltató melyik ol­ dalára van szükség. Megnézi még a bejövő kérés IP-címét is, és kikeresi egy adatbá­ zisból, hogy nagyjából merre lehet a felhasználó. Ezen információk birtokában meg­ határozza, hogy a CDN melyik kiszolgálója tudja a felhasználónak a legjobb szolgál­ tatást biztosítani. A döntés nem könnyű, hiszen a földrajzilag legközelebbi kiszolgáló nem biztos, hogy a hálózat topológiájában is a legközelebb van, a hálózati topológiá-
        
        

        Bundás Videó terméklista

        Kattintson az alábbi ingyenes termékmintákra!

        Mai medvék
        Vicces nyuszik
        Kedves egerek
        
        
        (a)

        Bundás Videó terméklista

        Kattintson az alábbi ingyenes termékmintákra!

        Mai medvék
        Vicces nyuszik
        Kedves egerek
        (b) 7.46. ábra. (a) Az eredeti weboldal, (b) Ugyanaz az oldal az átalakítás után
        
        711
        
        AZ ALKALMAZÁSI RÉTEG
        
        DNS-kiszolgáló 1 2 www.bundasvideo.com
        
        ,
        
        3
        
        5
        
        6
        
        Ügyfél
        
        4
        
        7
        
        .
        
        8 1C)
        
        9
        
        Gyorstár a mere
        
        1
        
        Helyettes CDN-0420.com 1. A www.bundasvideo.com kikeresése 2. Bundásék IP-címe visszaküldve 3. HTML-oldal elkérése a Bundástól 4. Visszakapott HTML-oldal 5. Kattintás után a cdn-server.com kikeresése
        
        cdn-server (hamis HTTP)
        
        -S
        
        6. A cdn-server IP-címe visszaküldve 7. A medvek.mpg állomány elkérése a cdn-server-től 8. Az ügyfelet átirányítják a CDN-0420.com-ra 9. medvek.mpg elkérése 10. A gyorstárból megérkezik a medvek.mpg
        
        7.47. ábra. Egy URL felkeresésének lépései CDN használatával
        
        ban legközelebb levő pedig nagyon elfoglalt is lehet abban a pillanatban. A döntés meghozatala után a cdn-server.com visszaküld egy választ 30l-es állapotkóddal és egy Hely fejrésszel, ami megadja az ügyfélhez legközelebb eső CDN-kiszolgálón lévő állomány URL-jét. Tegyük fel, hogy a példánkban ez az URL a www.CDN0420.com/bundasvideo/medvek.mpg. A böngésző ezt követően a szokásos módon dol­ gozza fel az URL-t, és megkapja a tényleges MPEG-állományt. Az ehhez szükséges lépéseket a 7.47. ábra szemlélteti. Az első lépésben kikeresik a www.bundasvideo.com IP-címét. Ezután a HTML-oldal letölthető és megjeleníthető a szokásos módon. Az oldalon három hiperhivatkozás található a cdn-server-re [lásd a 7.46.(b) ábrát]. Amikor kiválasztják mondjuk az elsőt, akkor kikeresik ennek a DNScímét (5. lépés), és visszaadják azt (6. lépés). Amikor a medvek.mpeg-ve, vonatkozó kérést elküldik a cdn-server-nek (7. lépés), akkor az ügyfél azt az utasítást kapja, hogy menjen inkább a CDN-0420.com címre (8. lépés). Amikor ezt végül megteszi (9. lé­ pés), megkapja az állományt a helyettes gyorstárából. Az egész mechanizmust a 8. lé­ pés működteti, amikor is a hamis HTTP-kiszolgáló átirányítja az ügyfelet a hozzá kö­ zel lévő CDN-helyetteshez. Az a CDN-kiszolgáló, ahová az ügyfelet átirányítják, rendszerint egy helyettes, melynek nagy gyorstára van, benne a legfontosabb tartalommal. Ha pedig valaki egy olyan állományt kér, ami nincs meg a gyorstárban, akkor azt letöltik az eredeti kiszol­ gálóról, és későbbi felhasználásra berakják a gyorstárba. A tartalom, kiszolgálója tehát csak egy helyettes, és nem egy teljes másolat, ezáltal a CDN-nek lehetősége nyílik a
        
        712
        
        SZÁMÍTÓGÉP-HÁLÓZATOK
        
        tárterület, az eló'feldolgozási idó' és más különböző' teljesítményparaméterek közötti kompromisszum megtalálására. A tartalomközvetítő hálózatokat bővebben tárgyalják (Hull, 2002; valamint Rabinovich és Spatscheck, 2002) művei.
        
        7.3.6.
        
        A vezeték nélküli Web
        
        Manapság figyelemre méltó érdeklődés övezi a webet vezeték nélküli úton elérni ké­ pes kicsi, hordozható eszközöket. Valójában már meg is történek az első, bizonytalan lépések ebben az irányban. Nem kétséges, hogy ez a terület sokat fog változni az el­ következő években, de addig is érdemes megvizsgálni a vezeték nélküli Web jelenlegi elgondolásait, hogy lássuk, hol vagyunk most, és merre tarthatunk a jövőben. Vizsgá­ latunk középpontjában a piacon megjelent első két vezeték nélküli webes rendszer áll: a WAP és az i-mód.
        
        WAP - a vezeték nélküli alkalmazások protokollja Az Internet és a mobiltelefonok mindennapossá válása után nem telt el sok idő, mire valakinek az az ötlete támadt, hogy ötvözni kellene a kettőt egy olyan mobiltelefon­ ban, melynek beépített képernyőjén vezeték nélkül is elérhető az e-mail és a Web. Ebben az esetben ez a „valaki" egy konzorcium volt, melyet eredetileg a Nokia, az Ericsson, a Motorola és a phone.com (régebben Unwired Planet) vezetett, mára pedig már több száz taggal büszkélkedhet. A rendszer neve WAP (Wireless Application Protocol - vezeték nélküli alkalmazások protokollja). Egy WAP-készülék lehet egy kibővített mobiltelefon, egy PDA vagy egy hangát­ viteli képességekkel nem rendelkező hordozható számítógép, sőt a specifikáció még más eszközöket is megenged. Az alapötlet az, hogy a már meglevő digitális vezeték nélküli infrastruktúrát kell használni. A felhasználók szó szerint felhívják a WAPátjárót a vezeték nélküli kapcsolat segítségével, és weboldalakra vonatkozó kéréseket küldenek neki. Az átjáró ekkor a gyorstárában néz utána a kért oldalnak. Ha ott meg­ van, elküldi, ha nincs, akkor letölti a vezetékes Internetről. A WAP 1.0 lényegében te­ hát egy vonalkapcsolt rendszer, viszonylag magas percdíjakkal. Nem megyünk bele a részletekbe, a lényeg mindenesetre az, hogy az emberek nem szívesen használták az Internetet parányi képernyővel és percdíjak fizetésével, úgyhogy a WAP tulajdonképpen bukás volt (egyébként voltak más problémái is). Úgy tűnik azonban, hogy a WAP és a versenytársa, az i-mode (lásd később) egy hasonló technológia felé haladnak, szóval a WAP 2.0 még akár nagy siker is lehet. Mindazonáltal a WAP 1.0 volt a vezeték nélküli Internet irányába tett első kísérlet, ezért érdemes legalább röviden szót ejteni róla. A WAP alapjában véve egy, a web elérésére szolgáló protokollkészlet, amit a kis sávszélességű kapcsolatokra és a lassú processzorral, kevés memóriával és kis képer­ nyővel rendelkező vezeték nélküli eszközökre optimalizáltak. Ezek a követelmények nyilvánvalóan különböznek a megszokott asztali PC-s környezet követelményeitől, és ez a protokollok terén is eltéréseket eredményez. A rétegeket a 7.48. ábra mutatja.
        
        AZ ALKALMAZÁSI RÉTEG
        
        713
        
        Vezeték nélküli alkalmazási környezet (WAE) Vezeték nélküli viszonyprotokoll (WSP) Vezeték nélküli tranzakciós protokoll (WTP) Vezeték nélküli szállítási réteg biztonsági funkciói (WTLS) Vezeték nélküli datagramprotokoll (WDP) Hordozó réteg (GSM, CDMA, D-AMPS, GPRS stb.)
        
        7.48. ábra. A WAP-protokollkészlet A legalsó réteg az összes létező mobiltelefon rendszert támogatja, beleértve a GSM-et, a D-AMPS-t és a CDMA-t. A WAP 1.0 adatsebessége 9600 b/s. Efölött van a datagramprotokoíi, a WDP (Wir eless Datagram Protocol - vezeték nélküli datagramprotokoll), ami lényegében véve az UDP-nek felel meg. Ezt egy biztonsági réteg követi, amire nyilvánvalóan szükség van egy vezeték nélküli rendszerben. A WTLS a Netscape SSL-jének részhalmaza, melyet a 8. fejezetben fogunk megtárgyal­ ni. Efölött van a tranzakciós réteg, mely a kéréseket és a válaszokat kezeli, vagy meg­ bízhatóan, vagy sem. Ez a réteg a TCP-t helyettesíti, amit hatékonysági okokból nem használnak rádiós összeköttetéseken. Ezután jön a viszonyréteg, ami hasonlít a HTTP/1.l-hez, de van benne pár korlátozás és optimalizálási célú bővítés is. Legfelül pedig a mikroböngésző (WAE) található. A magas költségek mellett kétségkívül az a tény sem tett jót a WAP elfogadottsá­ gának, hogy a protokoll nem HTML-t használ. A WAE-réteg ehelyett egy WML (Wireless Markup Language - vezeték nélküli jelölőnyelv) nevű jelölőnyelvet használ, ami az XML-nek egy alkalmazása. Ebből következően egy WAP-eszköz el­ vileg csak azokat az oldalakat tudja elérni, melyeket átalakítottak WML formátumra. Ez azonban nagyban csökkenti a WAP értékét, így a rendelkezésre álló oldalak szá-
        
        7.49. ábra. A WAP működése
        
        714
        
        SZÁMÍTÓGÉP-HÁLÓZATOK
        
        mának növelésére az architektúra egy szűrővel röptében átalakítja a HTML-oldalakat WML-re. Ezt a működést szemlélteti a 7.49. ábra. Az igazat megvallva a WAP kicsit megelőzte a korát. Amikor elindult, az XML-t még alig ismerték a W3C berkein kívül, ezért a sajtó úgy számolt be a kezdetekről, hogy A WAP nem használja a HTML-t, pedig pontosabbak lettek volna, ha ezt írják a szalagcímbe: A WAP máris az új HTML-szabványt használja. Az így okozott kárt azonban már nemigen lehetett jóvátenni, és a WAP 1.0 sosem kapott életre. A témára később még visszatérünk, de előbb lássuk a WAP legfontosabb versenytársát.
        
        I-mód Miközben a távközlési cégek és a számítógépgyártók konzorciuma egy olyan nyílt szabvány kigondolásán fáradozott, mely a HTML lehető legújabb verzióján alapszik, Japánban más irányú fejlesztések zajlottak. Egy japán hölgy, Mari Matsunaga a veze­ ték nélküli Web egy új megközelítését dolgozta ki, melyet i-módnak (informationmode - információs mód) nevezett el. Elgondolásával sikerült meggyőznie a volt ja­ pán telefonmonopólium vezeték nélküli leányvállalatát is, és 1999 februárjában az NTT DoCoMo (szó szerint: Japán Telefon és Telegráf Társaság bárhová is mész) megindította szolgáltatásait Japánban. A társaságnak három év múlva már több mint 35 millió japán előfizetője volt, akik több mint 40 000 speciális i-mód oldalhoz fér­ hettek hozzá. A világ távközlési cégei csak a nyálukat csorgatták eme üzleti siker lát­ tán, annál is inkább, mert úgy tűnt, a WAP-ból nem lesz semmi. Vessünk hát most egy pillantást az i-módra és annak működésére! Az i-mód rendszerének három fő összetevője van: egy új átviteli rendszer, egy új kézikészülék és egy új nyelv a weboldalak leírására. Az átviteli rendszer két különálló hálózatból áll: a meglevő vonalkapcsolt mobiltelefon-hálózatból (ez többé-kevésbé a D-AMPS-hez hasonlítható) és egy új csomagkapcsolt hálózatból, melyet külön az imódos szolgáltatásnak építettek ki. A beszédátviteli üzemmód a vonalkapcsolt hálóza­ tot használja, és percdíjas alapon számlázzák a kapcsolat ideje után. Maga az i-mód a csomagkapcsolt hálózatot használja, és folyamatosan on-line kapcsolatban van (mint az ADSL vagy a kábel), azaz nem a kapcsolat ideje, hanem az elküldött csomagok alap­ ján számláznak. A két hálózatot egyelőre nem lehet egyszerre használni. A kézikészülékek úgy néznek ki, mint a mobiltelefonok, csak rendelkeznek még egy kis képernyővel is. Az NTT DoCoMo a reklámjaiban egyre csak jobbfajta mobil­ telefonoknak állítja be az i-módos készülékeket, nem pedig vezeték nélküli webtermináloknak, pedig voltaképpen inkább ez utóbbinak számítanak. Az előfizetők többsége valószínűleg még annak sincs tudatában, hogy valójában az Internetet hasz­ nálja. Úgy tekintenek i-módos készülékükre, mint valamilyen bővített szolgáltatásokat nyújtó mobiltelefonra. Az i-módot csak egy szolgáltatásnak tekintik, ezzel összhang­ ban maguk a készülékek sem programozhatók, pedig megfelelnének egy 1995-ös PC színvonalának, és valószínűleg képesek lennének Windowst vagy UNIX-ot futtatni. Egy i-módos készülék bekapcsolásakor a felhasználó a hivatalosan is jóváhagyott szolgáltatások témalistájával találja szembe magát. Jóval több mint 1000 szolgáltatás érhető el, körülbelül 20 kategóriába osztva. A szolgáltatások lényegében kisebb
        
        AZ ALKALMAZÁSI RÉTEG
        
        715
        
        i-módos weboldalak, és mindegyiket egy külön vállalat kínálja. A hivatalos menü főbb kategóriái közt olyanok vannak, mint az e-levél, hírek, időjárás, sport, játékok, vásárlás, térképek, horoszkópok, szórakoztatás, utazás, útikalauzok, csengőhangok, re­ ceptek, szerencsejátékok, otthoni bankügyletek és részvényárfolyamok. A szolgáltatások többé-kevésbé a tinédzserekre és a huszonévesekre összpontosítanak, akik odavannak az elektronikus kütyükért, főleg, ha azok divatos színekben pompáznak. Önmagáért beszél a tény, hogy több mint 40 cég foglalkozik csengőhangok eladásával. A legnépszerűbb alkalmazás azonban az e-levél, mely legfeljebb 500 bájtos üzenetek küldését teszi lehe­ tővé, ami nagy előrelépésnek számít a 160 bájtos SMS-sel (Short Message Service - rö­ vid üzenet szolgáltatás) szemben. A játékok szintén népszerűek. Létezik még körülbelül 40 000 i-módos weboldal, de ezeket nem egy menüből való kiválasztással, hanem az URL-jük beírásával lehet elérni. Ebben az értelemben a hi­ vatalos oldal egyfajta internetes portál, melyről a kattintgatások mellett egyéb oldala­ kat is el lehet érni az URL-ek beírásával. Az NTT DoCoMo szigorúan ellenőrzi a hivatalos szolgáltatásokat. Ahhoz, hogy fölkerüljön a listára, egy szolgáltatásnak sokféle kiírásnak kell eleget tennie. Egyik szolgáltatás sem gyakorolhat például káros hatást a társadalomra, a japán-angol szótá­ raknak kellően sok szót kell tartalmazniuk, a csengőhang-szolgáltatásoknak gyakran kell új hangokat közzétenniük, és egy oldal sem tanúsíthat uszító magatartást, továbbá nem szabad az NTT DoCoMo-t rossz színben feltüntetni (Frengle, 2002). A 40 000 internetoldalon azonban mindenki azt tesz, amit akar. A i-mód üzleti modellje annyira eltér az Internet hagyományos üzleti modelljétől, hogy érdemes bővebben is kifejtenünk. Az i-mód alapvető előfizetési díja pár dollár havonta. Mivel a számlázás a vett csomagok alapján történik, az alap-előfizetés kevés csomagra elég. Az előfizető választhat olyan több, ingyenes csomagot tartalmazó elő­ fizetést is, ahol a csomagonkénti díj meredeken csökken, ahogyan a havi 1 MB-tól a 10 MB felé haladunk. Ha az ingyenes csomagok elfogynak a hónap közepén, akkor on-line lehet továbbiakat vásárolni. A szolgáltatás használatához elő kell rá fizetni, ami mindössze egy kattintásból és a PIN kód megadásából áll. A legtöbb hivatalos szolgáltatás díja havi 1-2 dollár körül mozog. Az NTT DoCoMo a telefonszámlával együtt számlázza ki ezt az összeget, és abból 91%-ot átad a szolgáltatás nyújtójának, 9%-ot pedig megtart magának. Ha egy nemhivatalos szolgáltatásnak egymillió előfizetője van, akkor ott egymillió számlát kell kiküldeni (kb. 1 dollárról) minden hónapban. Ha a szolgáltatás hivatalossá válik, az NTT DoCoMo veszi át a számlázást, és szépen átutal 910 000 dollárt a szolgáltató bankszámlájára minden hónapban. A szolgáltatók számára óriási ösztönző erő az, hogy nem kell a számlázással foglalkozniuk, ha hivatalossá válnak, ez pedig megint csak az NTT DoCoMo-nak hajt hasznot. A hivatalos oldalak ráadásul a kezdőmenübe is belekerülnek, így sokkal könnyebb megtalálni őket. Az előfizető telefonszámláján pedig a telefonhívások, az i-módos előfizetési díjak, a szolgáltatások előfizetési díjai és az extra csomagok jelennek meg. Az elsöprő japán siker ellenére nem tudni, hogy a rendszer elterjed-e az Egyesült Ál­ lamokban és Európában is, a japán körülmények ugyanis sok tekintetben eltérnek a nyu­ gatiaktól. Először is, a legtöbb potenciális nyugati előfizető (pl. tinédzserek, egyetemi hallgatók, üzletemberek) már rendelkezik nagyképernyős PC-vel az otthonában, és
        
        716
        
        SZÁMÍTÓGÉP-HÁLÓZATOK
        
        szinte biztos, hogy van legalább 56 kb/s sebességű vagy sokszor még jobb internetkap­ csolata. Japánban keveseknek van internetkapcsolattal rendelkező PC-je otthon, részben a helyhiány miatt, de köszönhető ez az NTT csillagászati helyi szolgáltatási díjainak is (körülbelül 700 dollár egy vonal bekötése, és 1,5 dollárba kerül egy óra helyi beszélge­ tés). A felhasználók többségének itt az i-mód az egyetlen internetkapcsolata. Másrészt a nyugati emberek nincsenek hozzászokva ahhoz, hogy havonta 1 dollárt fizessenek a CNN weboldalának eléréséért, 1 dollárt a Yahoo weboldaláért, egyet a Google-ért és így tovább, nem is beszélve a letöltött megabájtok utáni pár dollárról. Ma a legtöbb nyugati internetszolgáltató rögzített havi díjat számít fel, függetlenül a használattól. Ez nagyrészt a fogyasztói igények miatt alakult így. Harmadrészt sok japán ember leginkább a munkába vagy iskolába járás közben, vonaton vagy metróban használja az i-módot. Európában nem utaznak annyian vona­ ton, mint Japánban, Amerikában pedig szinte senki sem. Annak pedig nincs sok ér­ telme, hogy otthonról használja az ember az i-módot, amikor ott van a számítógép a 17 colos monitorral, 1 Mb/s-os ADSL-kapcsolattal és egy csomó ingyenes megabájt­ tal. Persze a mobiltelefonok átütő sikerét se jósolta volna meg senki, úgyhogy az imód még akár meg is találhatja a helyét a Nyugaton. Ahogy a fentiekben említettük, az i-módos készülékek a meglevő vonalkapcsolt hálózatot használják a beszédátvitelre, és az új csomagkapcsolt hálózatot az adatátvi­ telre. Az adatátviteli hálózat a CDMA-n alapszik, és 128 bájtos csomagokat visz át 9600 b/s sebességgel. A 7.50. ábra mutatja be a hálózat vázlatos felépítését. A kézikészülékek az LTP (Lightweight Transport Protocol - egyszerű szállítási pro­ tokoll) segítségével beszélnek a rádiós összeköttetésen keresztül a protokollokat át­ alakító átjáróval. Az átjárónak szélessávú optikai kapcsolata van az i-módos kiszol­ gálóval, mely az összes szolgáltatáshoz kapcsolódik. Amikor a felhasználó kiválaszt
        
        A hivatalos menüben levő szolgáltatások ,.
        
        Bázisállomás I-módos kiszolgáló
        
        <
        
        ,'''Bérelt Szolgáltató X x / — >=^ \ c=^ \
        
        Jk
        
        •
        
        000
        
        :::
        
        -módos készülék
        
        ' A beszédátviteli hálózat felé
        
        1 Protokoll- \ átalakító \ átjáró \
        
        Közvetlen összeköttetés az Internettel
        
        7.50. ábra. Az i-mód adatátviteli hálózatának felépítése a szállítási protokollokkal együtt
        
        717
        
        AZ ALKALMAZÁSI RÉTEG
        
        egy szolgáltatást a hivatalos menüből, a kérést elküldik az i-módos kiszolgálónak, ahol az oldalak többsége megtalálható a gyorstárban a teljesítmény növelése érdeké­ ben. A hivatalos menüből kimaradt szolgáltatásokra vonatkozó kérések elkerülik a ki­ szolgálót, és közvetlenül az Interneten keresztül haladnak. A jelenlegi kézikészülékek processzora körülbelül 100 Mhz-en fut, van bennük több megabájtnyi flash ROM, talán 1 MB RAM, és egy kis beépített képernyő. Az i-mód legalább 72 x 94 képpontból álló képernyőt követel meg, de néhány felső kate­ góriás készülék már 120 x 160 képpontnál tart. A képernyők színmélysége általában 8 bit, ami 256 színt tesz lehetővé. Ez még nem elegendő a fényképek számára, de meg­ felel a vonalas rajzoknak és az egyszerűbb ábráknak. Egér nincsen, ezért a képernyőn a nyílbillentyűk segítségével lehet navigálni. Felhasználói felület modulja Plug-in-ek
        
        cHTML-értelmező
        
        Java
        
        Egyszerű ablakkezelő Hálózati kommunikáció Valós idejű operációs rendszer
        
        7.51. ábra. Az i-mód szoftverének felépítése A szoftverfelépítést a 7.51. ábra mutatja. Az alsó réteg egy egyszerű valós idejű operációs rendszerből áll, mely a hardvert kezeli. Ezt követi egy olyan modul, mely a hálózati kommunikációt végzi, az NTT DoCoMo saját LTP-protokolljának használa­ tával. E fölött egy egyszerű ablakkezelő található, mely a szöveget és az egyszerű áb­ rákat (GIF-állományok) kezeli. Egy - a legjobb esetben is csak - 120 x 160 képpontos képernyőn nem is lehet sok mindent kezelni. A negyedik réteg a weboldalak értelmezőjét (vagyis a böngészőt) tartalmazza. Az i-mód nem a teljes HTML-t, hanem annak egy részhalmazát, az ún. cHTML-t (compact HTML - kompakt HTML) használja, ami némileg a HTML 1.0-n alapszik. Ez a réteg is lehetővé teszi a segédalkalmazások és a plug-in-ek használatát csakúgy, mint a PC-s böngészők. Az egyik szabványos segédalkalmazás a JVM némileg mó­ dosított verziójának egy értelmezője. Legfelül a felhasználói felület modulja van, mely a felhasználóval való kapcsolat­ tartásért felelős. Vessünk most egy közelebbi pillantást a cHTML-re! Mint mondtuk, ez nagyjából megegyezik a HTML 1.0-val, pár kihagyással és néhány, a mobil készülékek számára fontos bővítéssel. Szabványosítás céljából benyújtották a W3C-hez is, de a W3C nem mutatott nagy érdeklődést iránta, úgyhogy valószínűleg megmarad saját terméknek. Az alapvető HTML-címkék többsége itt is engedélyezett, beleértve a , ,