PDF formátumban letölthető

web2007borito.qxd 3/22/2007 11:01 AM Page 1

Szeretettel üdvözöljük immár második Web Konferenciarendezvényünkön. A korábbi PHP Konferencia rendezvé-nyek és RoadShow állomások megvalósításában szerzetttapasztalatainkat sikeresen ötvöztük tavalyi elsõ WebKonferenciánk megszervezésekor, és reméljük ez idénsem lesz másképp. A fejlesztõi és tervezõi témakörök szé-les skáláját igyekszünk felvonultatni a szemantikus webaprólékos kérdéseitõl a biztonságos rendszerek kialakítá-sáig. Igyekeztünk megtalálni az egyensúlyt a napjainkbanigencsak népszerû kliens oldali dinamikus megoldások, ésa közelmúltban valamelyest háttérbe szorított szerver ol-dali fejlesztõi platformok között. Mivel ezek együtteshasználata vezet a legjobb eredményre, már az elõzetesfelmérésekbõl is látható volt, hogy éppen ez a témakörszámíthat a legnagyobb népszerûségre.

A konferencia célja a szakmai tapasztalatszerzésen túla témával foglakozó szakemberek és csoportok összegyûj-tése és bemutatása. Idén is bemutatkozik az NJSZT Web-alkalmazások Fejlesztése Szakosztálya, a névkártyákonolvasható becenevek és cégnevek pedig a fórumokon,levelezõlistákon és IRC csatornákon megismert közösségitagok egymásra találását segíthetik.

A helyszín kiállításain szakkönyveket, folyóiratokat, a kon-ferenciához kapcsolódó emléktárgyakat vásárolhatnakaz érdeklõdõk.

A programfüzet, melyet kezében tart, ezúttal is segítségetnyújt az érdekesebb programpontok kiválasztásához, éshosszú távon is hozzá fordulhat, ha összefoglaló jellegûszakmai információkra van szüksége a tárgyalt témákatilletõen. Bizonyos elõadások meglátogatása elõtt különö-sen ajánlott a kapcsolódó ismertetõ átfutása, hiszen a be-mutató megértését jelentõsen könnyítheti.

Rendezvényünk nem jöhetett volna létre a számos támo-gató odaadó segítsége nélkül, melyek lehetõvé tették,hogy idén is megvalósíthassuk merész álmainkat. Ennekköszönhetõen várakozásunk szerint idén is olyan rendez-vényen vehet részt, melyre még sokáig hivatkozni fog.

Reméljük, hasznos információkkal és új kapcsolatokkal leszgazdagabb a mai nap végére.

AA kkoonnffeerreenncciiaa sszzeerrvveezzõõii

Tisztelt Látogató!

web2007.qxd 3/22/2007 11:33 AM Page 1

Neumann János Számítógép-tudományi Társaság

A hazai informatikai élet meghatározó szereplõ-jeként a Társaság legfontosabb feladata megõriz-

ni azokat az értékeket, amelyek beilleszthetõk a most ala-kuló új tudásalapú társadalomba, napjaink követelmé-nyeinek megfelelõ új szakmai irányok kijelölése és a (kö-zel) jövõ informatikai társadalmának aktív formálása. AzNJSZT 1968 óta mûködik, jelenleg 2300 egyéni és száz jo-gi taggal, 1999. január 1-tõl közhasznú szervezetnek mi-nõsül. Céljai elérése érdekében a Társaság központi, 19területi-, valamint 24 szakmai szervezetében a következõközhasznú tevékenységeket végzi:• tudományos tevékenység, kutatás, fejlesztés,• nevelés és oktatás, képességfejlesztés, ismeretterjesztés,• szakmai kulturális tevékenység,• szakmai kulturális örökség megóvása,• munkaerõpiacon hátrányos helyzetû rétegek képzésé-

nek, foglalkoztatásának elõsegítése és a kapcsolódószolgáltatások,

• euroatlanti integráció elõsegítése.A Társaság intézményektõl független szakmai fórumkéntsegíti hazánkban, illetve a magyar nyelvterületeken• az informatika alkalmazását, fejlesztését, az eredmé-

nyek elterjesztését; • a szakma presztízsének, minõségi színvonalának és eti-

kájának megõrzését, illetve emelését; • az informatikával hivatásszerûen foglalkozók, illetve

az informatikai eszközöket és módszereket más szakte-rületen alkalmazók véleményének és szakmai érdekei-nek érvényre jutását;

• a széles körû részvételt a nemzetközi szakmai köz-életben;

• az informatikai szakemberek tájékoztatását és tapasz-talatcseréjét;

• az informatikai kultúra terjesztését, az informatikaioktatást.

AA TTáárrssaassáágg tteevvéékkeennyyssééggii kköörreeA Társaság, célkitûzéseink megvalósítása érdekében köz-hasznú szervezetként szolgáltatásokat nyújt, illetve vál-lalkozásoknak ad keretet, ezeken belül:• szakmai közéleti munkára ad lehetõséget; • kutatási, fejlesztési, oktatási és továbbképzési programo-

kat véleményez, és részt vállal azok kidolgozásában; • állami szervek, gazdálkodó szervezetek, társadalmi szer-

vezetek felkérésére, megbízására vagy tagjainak kezde-ményezésére állást foglal fontos szakmai és az informati-kával kapcsolatos társadalmi kérdésekben, koncepciókat,tanulmányokat, szakvéleményeket dolgoz ki nyilvántar-tott egyesületi szakértõk közremûködésével;

• elõadásokat, ankétokat, konferenciákat, kongresszuso-kat, szemináriumokat, szakmai bemutatókat, kiállításo-kat, tanfolyamokat rendez;

• szakmai tanácsadást végez, szakértõi rendszert mû-ködtet, pályázatot hirdet, díjakat alapít és adományoz,célfeladatok elvégzését jutalmakkal ismeri el;

• törekszik arra, hogy a diákokat és a fiatal szakembere-ket bevonja a szakmai közéletbe;

• tevékenységi területén kapcsolatokat tart fenn külön-féle bel- és külföldi szervezetekkel, tagként képviseliMagyarországot hazai, ill. nemzetközi tudományosszervezetekben, terjeszti az informatikai írástudást, azECDL hazai irányítását végzi.

A Társaság testületeirõl, bel- és külföldi kapcsolatairól,aktuális szakmai eseményekrõl részletes információ talál-ható a http://www.njszt.hu/ honlapon és az évenkénttíz alkalommal nyomtatásban is megjelenõ „Mi Újság” cí-mû hírlevélben.

A World Wide Web ConsortiumA World Wide Web Consortium-ot (W3C) 1994-ben alapí-totta Tim Berners-Lee, a Web szülõatyja. A cél elsõsorbanaz volt, hogy a webtechnológiák fejlesztésével foglalkozóvállalatok és kutatóintézetek a jövõben ne forgácsolják szétfeleslegesen energiájukat, elért eredményeiket, hanemegymással vállvetve, egymást segítve teremtsék meg az in-formatika jövõjét.A W3C egymással együttmûködõ technológiákat (specifiká-ciókat, szoftvereket) dolgoz ki, ezzel is megkönnyítve a fej-lesztõk és a felhasználók munkáját. Ezen fejlesztések alap-ján születnek meg a W3C ajánlásai, melyekhez bárki hozzá-férhet (http://www.w3.org/TR/#Recommendations). A W3Cajánlások (pl.: HTML, CSS, XML) alapján készült termékekszabványosak, széles körben felhasználhatók, ezért a gyár-tóknak érdekükben áll az ajánlásoknak megfelelõ terméke-ket elõállítani, ha vásárlóik igényeit ki akarják szolgálni.Az elmúlt évben a W3C 15 új webes szabványt jelentetettmeg, megnyitotta a Kínai Irodát, két új fejlesztési területetindított el (Biztonság, Inkubátor) és négyet újított meg(XML, Nemzetköziesítés, Webszolgáltatások és Szemanti-kus Web). Életre hívta a Biztonságos böngészés kezdemé-nyezést (Secure Browsing Initiative), a WAI-ARIA (Road-map for Accessible Rich Internet Applications) és a DIAL(Device Independent Authoring Language) fejlesztést.Nyolc új munkacsoportot, egy érdeklõdési- és öt inkubátor-csoportot alapított, többek közt a biztonság (Security),a mobil Web (Mobile Web), a térinformatika (Geospatial) ésaz érzelmek (Emotion) területen.AA WW33CC MMaaggyyaarr IIrrooddaaA Konzorciumnak ma már több mint 430 tagja van a világminden részérõl (IBM, Microsoft, Nokia, Honda, Citibank,

Fuji, CERN…; teljes taglista: http://www.w3.org/Consor-tium/Member/List). Az MTA SZTAKI 1995 óta tagja a Kon-zorciumnak. A W3C itt nyitotta meg egyetlen kelet-közép-európai irodáját, a W3C Magyar Irodát. Ma a SZTAKI-nkívül Magyarországon két közvetlen W3C-tag is van:a BME és a KOPINT-DATORG Zrt.Az Iroda elsõdleges célja az, hogy a magyar intézményekés vállalatok minél szélesebb körében megismertessea W3C tevékenységét, segítse az azokba való bekapcsoló-dást, és azon információkhoz való hozzáférését, amelyeksegítségével a jövõben képesek leszünk növelni szere-pünket a Web világában. További információk a http://www.w3c.hu/ honlapontalálhatókMMiitt jjeelleenntt aa WW33CC--ttaaggssáágg?? A W3C ma közel 40 területen végez fejlesztéseket(HTML, XML, HTTP, P3P, RDF, …). Ezeket a különbözõmunkacsoportjai végzik, melyekbe a W3C-tagok delegál-hatnak munkatársakat, s így részt vesznek a Web jövõjé-nek alakításában, valamint elsõ kézbõl – jóval a hivatalosbejelentés elõtt – jutnak hozzá olyan információkhoz,melyek a webtechnológiákkal kapcsolatos stratégiai dön-tésekben helyzeti elõnyt jelentenek. Ha egy tag a fejlesztésekben nem is vesz részt, a friss in-formációkat a hírleveleken keresztül folyamatosanmegkapja és hasznosíthatja, mely már önmagában na-gyon értékes lehet. Ezen kívül delegálhat tagot a Ta-nácsadó Testületbe, s ezáltal beleszólhat az ajánlások ki-dolgozásába. További információk a következõ címen találhatók:http://www.w3c.hu/forditasok/why_join.html

web2007.qxd 3/22/2007 11:33 AM Page 2

A Neumann János Számítógéptudományi Társa-ság Webalkalmazások Fejlesztése Szakosztályá-ban (NJSZT WFSZ) immár közel négy éve azonmunkálkodunk, hogy a webes környezetek fej-

lesztésével foglalkozó szakemberek és érdeklõdõk szá-mára a legaktuálisabb és szakmailag legkorrektebb infor-mációkat közvetítsük. A 2003-ban alapított független,szakmai közösségünk célja a webalkalmazások fejleszté-sére használható technológiák népszerûsítése, szakmaianyagok írása, fordítása, azok támogatása, továbbáa programozási nyelvekkel és a kapcsolódó technológi-ákkal foglalkozó konferenciák és versenyek szervezéseés lebonyolítása.Egyik fontos tevékenységünk a nagy érdeklõdéssel kísértbudapesti tavaszi konferenciák megszervezése, melyeken

a webes technológiák legújabb megoldásairól informá-lódhatnak az érdeklõdõk, rálátva a különbözõ megközelí-tésekre, a technológia eltérõ vetületeire. Ezeket az orszá-gos eseményeket a kisebb, vidéken megrendezettroadshow rendezvények kísérik, köszönhetõen a helyilelkes szervezõgárdáknak.Amellett, hogy bevált rendezvényeinket és fuó projektje-inket fenn szeretnénk tartani, számos érdekes ötletünkvan, melyek megvalósításához segítõ kezekre van szük-ség. Szívesen látunk körünkbe bekapcsolódni szándéko-zó új tagokat. Amennyiben sikerült felkeltenünk érdeklõ-dését szakosztályunk iránt, látogassa meg közösségi talál-kozónkat az ebédszünetben, kísérje figyelemmel hírein-ket a http://weblabor.hu/ oldalon, és látogassa mega http://wfsz.njszt.hu/ címen elérhetõ honlapunkat.

A Weblabor a magyarul beszélõ webfejlesztõkegyik legkedveltebb célpontja, hiszen itt infor-málódhatnak az õket érintõ aktualitásokról, el-mondhatják véleményüket és megoldást talál-

hatnak problémáikra. Az 1999 elején indult webhely köréaz évek során kiforrott, de folyamatosan alakuló közösségszervezõdött.A Neumann János Számítógéptudományi TársaságWebalkalmazások Fejlesztése Szakosztálya által támo-

gatott független szakmai lapunkon olvasható, a közös-ség által beküldött tartalmak mutatják, hogy az egyestagok kis egyedi befektetéssel együttesen komoly ered-ményeket tudnak elérni. Ezeknek a közösségekneka katalizátorai a Weblabor keretében mûködõ szakmailevelezõlisták és fórumok, melyek lehetõséget adnaka felmerülõ problémák megvitatására, megoldására. Va-lójában a szakosztály alapítói is egy ilyen közösségi ke-mény magból kerültek ki.

NJSZT Webalkalmazások Fejlesztése Szakosztály

Weblabor – a fejlesztõi forrás

TTaarrttaalloommjjeeggyyzzéékkAAzz aalláábbbbiiaakkbbaann aa kkoonnffeerreenncciiaa tteemmaattiikkuuss pprrooggrraammjjaa oollvvaasshhaattóó.. AA kkoonnffeerreenncciiaa eellõõaaddáássaaiihhoozz,, bbeemmuuttaattóóiihhoozzkkaappccssoollóóddóó cciikkkkeekkeett aazz aalláábbbbii oollddaallaakkoonn ttaalláálljjaa mmeegg..

AA sszzeerrvveerr ééss aa kklliieennss oollddaall ttaalláállkkoozziikkAlkalmazásfejlesztés Djangóval és GWT-vel – Török Gábor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4COMET webalkalmazás fejlesztés – Tóth Ádám . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Felhasználói felületek Ruby on Rails alapokon – Fekete Ferenc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Flash és PHP kommunikáció – Ferencz Tamás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Microsoft és az AJAX – ASP.NET alkalmazások AJAX-osítása – Balássy György . . . . . . . . . . . . . . . . . . . . . . . . . 9Portletek és AJAX, az allaslehetosegek.hu újjászületése – Karóczkai Krisztián. . . . . . . . . . . . . . . . . . . . . . . . . 11Webalkalmazás fejlesztés Java EE környezetben NetBeans segítségével... – Varga Péter, Zsemlye Tamás . . . . . 12

AAkkttíívv wweebbffeellüülleetteekkAJAX framework építés – Nagy Attila Gábor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Böngészõ- és szerver független AJAX programozás – Balássy György . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Creating a Cinematic User Experience™ with OpenLaszlo – Raju Bitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18OpenLaszlo – váltsunk szemléletet – Kiss-Tóth Marcell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Netvibes modul fejlesztés – Bártházi András . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Interaktív webfelületek fejlesztése Windows Presentation Foundation/Everywhere alapokon – Bátorfi Zsolt 21Windows Presentation Foundation: az OS következõ generációs prezentációs platformja – Bátorfi Zsolt . 22

SSOOAABPEL nyelvû üzleti folyamatok modellezése és formális ellenõrzése – Kovács Máté, Gönczy László . . . . . 23Java Business Integration... – Simon Géza, Zsemlye Tamás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

SSzzeerrvveerr oollddaallFejlesztés támogatás Xdebuggal – Török Gábor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Java Persistence API... – Molnár István, Zsemlye Tamás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27S mint secure – Hozzáférések kezelése biztonságosan és kényelmesen – Nagy Attila Gábor . . . . . . . . . . . . 29

WW33CC sszzeekkcciióóA W3C és a Mobilweb – Pataki Máté . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31A rokonsági fogalmak ontológiája – Szakadát István . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33A szemantikus világháló alapjai – Szeredi Péter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Az AJAX és az akadálymentesség – Károly György Tamás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Szörfözõ varázscápa... – Dvariecki Bálint, Torma Zsolt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36What do they think they are doing? When Usability and Security meet on the Web – Thomas Roessler . . 37

web2007.qxd 3/22/2007 11:33 AM Page 3

Az AJAX a webkettõ néven illetett korszak technológiaiaspektusában lett meghatározó fogalom, noha elgondolá-sát tekintve már korábban is léteztek különféle imple-mentációk, mint adatcsere beágyazott keretekkel vagya korai MS Remote Scripting megvalósítások. Az AJAXszéles spektrumon terjeszett el egy újfajta gondolkodásimódot. Definíciója szerint a hagyományosnak tekinthetõteljes oldal lekérések helyett az aszinkron adatátvitelreépít. Ésszerû alkalmazása keretein belül ennekköszönhetõ, hogy csökkenti a felemésztett sávszélessé-get, kevesebb a válaszok idõköltsége, jobban közelítia webalkalmazások reagálását az asztali programoknálmegszokotthoz, nem utolsó sorban pedig élesebben szét-válik a felhasználói felület fejlesztése az üzleti logikáétól.Az AJAX mindamellett, hogy hatékonyabbá tesziaz összetett webalkalmazások mûködését üzemeltetõi ésfelhasználói szempontok alapján egyaránt, helyes fel-használása esetén kiváló eszköz az amúgy statikus,brossúra jellegû weblapok dinamikus funkcióbeli kiegé-szítéséhez (pl. ûrlapok, keresés) is.

A JavaScript az AJAX-nak köszönhetõ ilyettébb felvirágzá-sa több problémát is felszínre hozott: egyfelõl hiányoztaka JavaScript fejlesztést támogató komoly eszközök, kódtá-rak, továbbá rávilágított a kód karbantarthatóság versusa böngészõ felé szolgáltatott kimenet méretének kérdés-körére is. Az idõ elõre haladtával számos library (Yahoo!YUI), fejlesztõ környezet (JSide), debugger (Firebug) sa-többi született a JS programozók munkáját segítendõ.

2006 elején jelentette meg a Google nyíltforrású eszköz-készletét, amely Java nyelven fejlesztett kódból állít elõnatív XHTML/JS kimenetet. A Google Web Toolkit sikeré-nek biztos alapja, hogy – az immáron GPL licenc alattelérhetõ – Javát vállalati megoldásként tartják számon,továbbá az okos JS eszközök támogatása mellett isfellépõ, böngészõk közötti inkompatibilitás terhét is leve-szi a fejlesztõ válláról. A GWT a Swing API-jához hasonlófelületet ad a programozó kezébe webalkalmazások ké-szítéséhez. A Java nyelvû fejlesztés egyfelõl a Java nyelvjellemzõinek birtoklását, továbbá a Javához elérhetõ vala-mennyi fejlesztõ eszköz támogatását jelenti. Mindemel-lett a fordítás (compile) szükségességének származékoselõnye, hogy a rendkívül kicsi, emberek által igen nehe-zen olvasható, generált JavaScript forráskód közvetvemégis tökéletesen kézben tartható marad. A GWT kliensoldali felületek készítésére alkalmas, frontendkéntmûködhet egy már meglévõ szerver oldali interfész fö-lött. A kommunikáció lebonyolításához egy saját RPCcsomagot tart fent. A GWT támogatja JavaScript kódoknatív beágyazását, így a korábban megszokott, kitapasz-talt kódtárak elõnyeitõl sem kell megfosztanunk magun-

kat. A keretrendszer mintájára készült a Python nyelvûPyjamas környezet.

A Django Python alapú, „from the scratch” metodikávalfejlesztett alkalmazás és fejlesztõi keretrendszer (CMS,WAF). Automatizmusával számos ponton segíti a prog-ramozó munkáját. Kiváló felület fórumok, blogok, por-tálok, brossúrák, közösségi webhelyek, illetve összetet-tebb (intranetes) webalkalmazások (például groupware,CRM, Business Logic) fejlesztéséhez. A Django eseté-ben jól elkülöníthetõ a backend és a frontend, ennek fé-nyében pedig igen sokrétû lehet a felhasználása az ép-pen aktuális fejlesztési modell függvényében. Általá-nosságban véve a Django Python nyelven az, amia Rails Rubyban, vagy a Drupal (ill. CakePHP) PHP-ben. Természetesen nem svájci bicska, de jól átgondolttervezés esetén könnyen megtalálható a megfelelõ he-lye a fejlesztési modellben. A Django teljesítményébenmeghatározó ereje van a Python hagyaték bájtkódnak.

Míg mind a Drupal (JQuery), a Rails (Prototype) vagya szintén Pythonban evezõ TurboGears (MochiKit) gyárikiszerelésben nyújt JS kódtárat, a Djangohoz semmilyenhivatalos kiegészítés nem érhetõ el – a fejlesztõre van bízvaa megfelelõ függvénycsokor kiválasztása. A Django modu-láris felépítésébõl fakadóan egy külsõ ajaxos toolkit beépí-tése lehetséges, így bármikor alkalmunk nyílik egy mármeglévõ alkalmazás „ajaxosítására”. Django terminológiá-ban az MVC-nek megfeleltetett MTV (Model-Template-View) View építõkockája az a pont, ahol a keretrendszerlehetõséget teremt az AJAX API kifejtésére (Ajax Views).A válaszok tálalásáért a Template-ek a felelõsek, de azokteljesen transzparens voltának köszönhetõen az AJAX vá-laszok formátumát tekintve teljes mértékben szabad kezetkapunk: lehet XML, XHTML, JSON vagy bármi egyéb.

A Django szerepét tekintve mind backenden, mindfrontenden megállja a helyét, de kitûnõen alkalmazhatótisztán backendként is, így a felületet bízhatjuk a GoogleWeb Toolkitre vagy a Python-klón Pyjamasra is. Back-end szerepét tovább erõsíti adatmodelljeibõl származta-tott automatikusan generált adatbázis API-ja és adminfelülete. További részletek:http://code.google.com/webtoolkit/

http://www.djangoproject.com/

TTöörröökk GGáábboorr

Mûszaki informatikus hallgató, jelenleg a Webma InternationalWeb Marketingnél web alapú alkalmazás fejlesztõ. Nem hisza svájci bicska eszközökben, így PHP mellett Python, C és shellszkript nyelveket is használ munkája folyamán. Rajong a nyíltforrású megoldásokért.

4 Magyarországi Web Konferencia 2007

AAllkkaallmmaazzáássffeejjlleesszzttééssDDjjaannggóóvvaall ééss GGWWTT--vveell

AA sszzeerrvveerr ééss aa kklliieennssoollddaall ttaalláállkkoozziikk

web2007.qxd 3/22/2007 11:33 AM Page 4

5Magyarországi Web Konferencia 2007

Az elmúlt évek során a webalkalmazás fejlesztés valódiforradalmának lehettünk szemtanúi. A mai korszerûwebalkalmazásokban már nyoma sincs a régi fapadosság-nak, mind tudás, mind használhatóság terén felnõtteka klasszikus asztali (vastagkliens) alkalmazásokhoz. To-vábbra is vannak azonban problémás területek, melyekbeazért ütközünk bele elõbb-utóbb, mert kezdjük kimerítenia webes alaptechnológiák által biztosított lehetõségeket.

Az egyik ilyen probléma annak megoldása, hogy alkal-mazásunk szerver oldali komponense (továbbiakban:a szerver) anélkül is küldhessen adatokat a kliens oldalikomponensnek, hogy az kérelmezte volna. Miért is olyanjelentõs probléma ez? Elsõsorban azért, mert az adott al-kalmazás állapota nem csak a kliens oldalon változhatmeg, hanem a szerver oldalon is (pl. az adatbázis tartal-mának módosulása révén) – errõl azonban a szerver nemtudja értesíteni a klienst, hiszen a HTTP protokoll kérés-válasz jellegû kommunikációs modelljében csak a klienskezdeményezheti a kommunikációt. Ez a korlátozás sokesetben más, alternatív megoldások használatára (Flash,Java) készteti a legtöbb fejlesztõt.

Léteznek azonban olyan módszerek, amelyek az AJAX ésvalamely szerveroldali technológia ügyes használatával kí-sérelik megoldani ezt a problémát, így nem szükséges a fel-használónak egyéb alkalmazásokat telepítenie a gépén. Azelõadásomban ezen technikákat kísérelem meg bemutatni.

AJAX PollingA szerveroldali változások lekérdezésének legtriviálisabbmegoldása a szerver adott idõközönként történõ lekérdezé-se tûnik. Mivel szeretnénk, ha mindez a háttérben történ-ne, kézenfekvõnek tûnik az XMLHttpRequest objektumhasználata. A megoldás alapelve tehát a következõ: állít-sunk be egy idõzítõt a kliens oldalon, ami a megadottidõközönként az XHR objektumon keresztül meghívja aszerveroldali szkriptet. A szerverrõl érkezõ új eseményeketa lekérdezés végeztével kiolvashatjuk a XHR objektumból,és meghívhatjuk a kívánt eseménykezelõ függvényt.

A megoldás legnagyobb elõnye az egyszerûsége, és plat-form (böngészõ) függetlensége. Megvalósítása kevés kez-deti erõfeszítést igényel, különösen, ha valamilyen fejlettJavascript osztálykönyvtárat is használunk. A méltánnépszerû Prototype osztálykönyvtár például beépített támogatással rendelkezik az AJAX Polling-hoz, azAjax.PeriodicalUpdater objektum révén.

Az AJAX Polling azonban több sebbõl is vérzik, így essennéhány szó a hátrányokról is. Mint a legtöbb Polling meg-oldás, az AJAX Polling is meglehetõsen pazarlóan bánikaz erõforrásokkal. Ez leginkább akkor lehet probléma,amikor az események bekövetkezése változó periodicitá-sú, hiszen ilyenkor lehetetlen meghatározni az optimálislekérdezési intervallumot. Amikor sokáig nem következikbe esemény, a Polling feleslegesen terheli a szervert, építki HTTP és esetleges adatbázis kapcsolatokat. Ez a megol-dás tehát ebben a megvalósításban csak körültekintõen

használandó, azonban mint azt késõbb látni fogjuk, né-hány ügyes trükk használatával egy elég jól skálázhatómegoldást is kiépíthetünk a segítségével.

AJAX COMETA COMET megoldások más irányból közelítik meg a prob-lémát. Az alapgondolat, hogy építsünk ki egy kapcsolatota kliens és a szerver között, ezt a kapcsolatot azonban fo-lyamatosan nyitva tartjuk, így azon keresztül a szerver fo-lyamatosan küldhet a kliensnek adatokat. A technológiaialapot a HTTP 1.1-ben bevezetett perzisztens (keep-alive)HTTP kapcsolat teremti meg, mely lehetõséget biztosít arra,hogy egy kapcsolaton keresztül több HTTP kérést/választ le-hessen küldeni ill. fogadni, ezáltal csökkentve az új kapcso-latok létrehozásával járó overhead-et.

Az elsõ probléma, amibe belefutunk a COMET-tel kapcso-latban pont a perzisztens kapcsolatok kapcsán merül fel.Egyrészt szerveroldali szkriptjeink nem futhatnak tetszõ-legesen hosszú ideig; noha ezen néhány paraméter módo-sításával változtatni tudunk, teljesítmény szempontjábólrosszul skálázódik a rendszer, különösen, ha sok száz fel-használó használná az alkalmazást egyidõben (pl. egy chatprogram esetében). További problémát jelentenek a tûz-falak, melyek a legtöbb esetben úgy vannak konfigurálva,hogy bontsák azokat kapcsolatokat, melyek túl hosszú ide-ig vannak nyitva.

A kapcsolatok hosszát tehát korlátozni kell. Itt érdemes fi-gyelembe venni a szerveroldali szkriptek maximálisanmegengedett futási idejét, a tûzfal beállításokat, illetve mé-réseket végezni arra vonatkozóan, hogy az egyesböngészõk mennyi üresjárási idõ után bontják meg a kap-csolatot. A kapcsolat lezárása után egyszerûen kezdemé-nyezhetjük kliens-oldalon egy újabb létesítését.

Korlátot jelentenek maguk a böngészõk is: a HTTP 1.1-esspecifikációja szerint egy egy-felhasználós kliens nem léte-síthet kettõnél több párhuzamos kapcsolatot egy szerverrelvagy proxyval. Ezt a szabványt valamennyi modernböngészõ követi, beleértve az Internet Explorert és a Firefox-ot. Ez azért probléma, mert a perzisztens kapcsolat miattcsak egy további kapcsolat marad szabadon egyéb kommu-nikációra, amely teljesítmény szempontból problémákat vetfel AJAX-ot használó alkalmazásoknál, mivel így például né-hány kép letöltése közben a szerver nem tud más felhaszná-lói kérésre reagálni. Erre egy lehetséges megoldás, haa stream kapcsolatokat egy másik hosztnév alatt létesítjük.

A legnagyobb probléma azonban, hogy a megoldás nemmûködik Internet Explorer alatt. Ennek oka a következõ.Az Internet Explorer a saját XHR implementációját, egyActiveX objektumot használja, aminek megvan az a visel-kedése, hogy nem engedi kiolvasni a válaszadatokat egé-szen addig, amíg az objektum readyState indikátora nemveszi fel a 4-es (Complete) állapotot – ezt azonban csaka kapcsolat lezártával teszi meg. Ez gyakorlatilag lehetet-lenné teszi az AJAX alapú COMET technika alkalmazásátezen a platformon.

CCOOMMEETT wweebbaallkkaallmmaazzááss ffeejjlleesszzttééss

web2007.qxd 3/22/2007 11:33 AM Page 5

Hogy vajon mindezek ellenére van-e az AJAX COMET-nek létjogosultsága, jó kérdés. Preparált környezetben,ahol kikényszeríthetõ egy adott böngészõtípus használa-ta (tipikusan belsõ, céges környezet), minden bizonnyaljól használható technika. Széles körû internetes haszná-latra azonban jelen körülmények között nem alkalmas.

Smart PollingA Smart Polling technika a Polling és az AJAX COMETelõnyös tulajdonságait egyesíti, kissé jobban skálázhatóvá– és egyben kevésbé pazarlóvá – téve a Pollingot, ugyanak-kor megtartva annak platformfüggetlenségét. Ezzel egy re-latíve jól skálázható, platform független megoldáshoz jut-nunk. Továbbra is probléma azonban, hogy abban az eset-ben, ha a kliensek tudomására hozandó események gyak-ran követik egymást, nagyon nagyszámú kapcsolatot kella webszervernek kezelnie.

A Google-féle megoldás: Forever FrameVégezetül egy olyan megoldást fogok bemutatni, amelymár egy ideje ismert a fejlesztõk körében, bár a többséga Gmail fejlesztõinek tulajdonítja az ötletet, mivel a tech-nika a Google levelezõjében debütált, és vált ismerttéa nagyközönség számára.

A Google megoldása egy böngészõ-viselkedésbeli sajá-tosságot használ ki, nevezetesen, hogy amennyiben egyHTML keretbe töltünk egy tartalmat, a benne találhatóJavascript-ek automatikusan végrehajtódnak. Így azAJAX COMET-hez nagyon hasonló megoldáshoz ju-tunk, ez a verzió azonban minden olyan böngészõ alattmûködik, amely támogatja a beágyazott kereteket – az-az gyakorlatilag minden korszerû böngészõ alatt hasz-nálható a megoldás. Mindössze arra kell figyelnünk,

hogy a stream-et bizonyos idõközönként újraindítsuk,mivel itt is fennállnak az AJAX COMET esetébena hosszú ideig nyitva tartott kapcsolatok konstellációjá-ban vázolt problémák.

Kapcsolódó linkek• http://prototypejs.org (AJAX Polling)• http://xajaxproject.org (AJAX Comet és Polling)• http://www.lightstreamer.com (kereskedelmi)• http://www.pushlets.com (Java)• http://en.wikipedia.org/wiki/Comet_(programming)

TTóótthh ÁÁddáámm

A Budapesti Mûszaki Egyetemen végeztem villamosmérnökként,egyetemi tanulmányaim idején, 2001 tájékán kezdtem el webesfejlesztéssel foglalkozni. Kezdetben szabadúszóként, késõbb azegyetem szervezésében vettem részt különbözõ projektekben,elsõsorban mint szerveroldali programozó. Bár fõ szakterületem-nek a PHP-t tartom, mindig is nyitott voltam más technológiákmegismerésére, így a PHP mellett J2EE–IBM WebSphere platfor-mokon is rendelkezem fejlesztõi tapasztalatokkal. Munkáim sorána webes technológiák alkalmazásának számos lehetõségét volt al-kalmam kipróbálni; a szokásosnak mondható portálfejlesztéstõl aBPEL szabványt támogató, üzleti folyamatokat irányító szoft-veren át, a valós idejû folyamat-monitoring rendszerig a lehetõlegkülönfélébb felépítésû és célú webes alkalmazások fejlesztésébenvettem részt. Jelenleg a Jasmin Media Group-nál dolgozom vezetõfejlesztõként, feladatom a cég belsõ adminisztrációs rendszereinekfejlesztése és karbantartása. Munkám során kerültem elsõ ízbenkomolyabb kapcsolatba a korszerû AJAX technikákkal, PHP nyel-vû AJAX keretrendszerekkel, valamint az AJAX-ra épülõ HTTPstreaming megoldásokkal – jelenleg ezek képezik érdeklõdési köröm– és egyben elõadásom – középpontját.


web2007.qxd 3/22/2007 11:33 AM Page 6

A Rails keretrendszer struktúrája, metódusai, erõs AJAXtámogatása illetve a Ruby nyelv egyszerûsége és szintak-tikája miatt kiválóan alkalmas webalkalmazások „villám-gyors” kifejlesztésére (rapid development).

A keretrendszer azonban nem csak a backend fejlesztése-kor nyújt segítséget: az úgynevezett JavaScript Helper-eklehetõvé teszik, hogy mindössze pár perc alatt gazdagít-suk a felhasználói felületet autocomplete-mezõkkel, drag& drop rendezhetõ listákkal stb. A gyakorlati elõadásezek létrehozását mutatja be.

Ruby és JavaScript

A jól ismert és népszerû Prototype JavaScript függvény-könyvtárt, és az erre épülõ Script.aculo.us effekt-gyûj-teményt a Rails-szel párhuzamosan fejlesztették, ha úgytetszik, hozzá írták. A szimbiózisnak köszönhetõena rendszer JavascriptHelper modulja segítségével a Ruby-kódban írt metódushívások a kimeneten JavaScript-kéntjelennek meg, így az AJAX kéréseket, effekteket tisztaRuby kódban írhatjuk.

Az elõadás során bemutatott példákon látni fogjuk,ahogy az egy-két soros Ruby parancsok legeneráljáka szükséges JavaScript függvényhívásokat. Az így létre-hozott widget-ek egyszerûsége ne tévesszen meg ben-nünket, hiszen azok percek alatt kibõvíthetõk, átírhatók(akár az „alap” metódusok is override-olhatók)!

Egyszerû és gazdag felület

Egy hatékony webalkalmazás nehezen képzelhetõ elegyszerû, átlátható, ugyanakkor hasznos funkciókbangazdag felhasználói felület nélkül. A cél nem az, hogytelepakoljuk a felületet felesleges funkciókkal! Olyanminimális szolgáltatásokat kell nyújtani a felhasználószámára, amelyek nem hátráltatják, hanem segítika munkáját.

Mi történik a felhasználóval, miközben egy webalkalma-zást használ?

Tartalmat keres az adatbázisban, ûrlapokon keresztül lét-rehozza vagy szerkeszti azt, esetleg megváltoztatja egylistába rendezett tartalom sorrendjét. Az adott mûveletsikeres elvégzésérõl, egy folyamat állapotáról visszajel-zést vár. Milyen segítséget nyújt nekünk a Rails?

LiveSearch

A probléma adott: adatbázisban szeretnénk keresni, még-hozzá gyorsan. Olyan gyorsan, ahogy gépelünk a billen-

tyûzeten. Az alapértelmezett LiveSearch egy beviteli me-zõbõl és egy observe_field helperbõl épül fel.

A mindössze egysoros helpernek megadjuk, hogy melyikmezõ változásait figyelje, milyen gyakorisággal és a szer-vertõl az AJAX kérésre visszakapott találatokat melyikHTML elembe töltse be. Az observe_form helper haszná-latakor egy egész form-ot „figyelhetünk”, így akár szûrõ-feltételeket is rendelhetünk a kereséshez.

Autocomplete

Amikor a felhasználó ûrlapot tölt ki, az autocomplete me-zõ javaslatot tesz, megpróbálja kiegészíteni a beírt szót.Gyakran alkalmazzák például tartalom címkézésekor:a címkék beírásakor a megjelenõ javaslatokra kattintvakiegészíti a beírt szöveget.

A text_field_with_autocomplete helper mindössze kétparamétert vár, amellyel hivatkozunk az objektumra illet-ve annak egy tulajdonságára, pl. :user, :name.

Drag & Drop listák

Ha tartalmi egységeket kell valamilyen szempont sze-rint sorrendbe állítani, akkor a legkézenfekvõbb egyrendezhetõ lista létrehozása, amely elemeinek sorrend-jét drag & drop módszerrel változtathatjuk. A megol-dást a sortable_element metódus nyújtja.

InPlace editor

Tartalom szerkesztésére dinamikusan generált ûrlapokszolgálnak: a szerkesztendõ szövegre kattintva az bevitelimezõvé alakul. A megváltozott tartalom mentése a szer-ver felé indított AJAX hívással történik, a beviteli mezõa mentést követõen eltûnik.

Periodikusan frissülõ elemek

Elõfordulhat, hogy a webalkalmazás felületének egy tar-talmi egységét folyamatosan frissíteni kívánjuk: aktuali-zált adatokkal szeretnénk feltölteni azt, egy folyamat vál-tozását kell megmutatni, egy rádióban éppen játszottszám adatait kell megjeleníteni stb.

Ehhez a periodically_call_remote helper-t hívhatjuksegítségül, amely megadott idõközönként AJAX kérést in-dít a szerver felé, a szerver válaszát pedig a megadottHTML elembe illeszti.

A metódus segítségével könnyedén hozhatunk létre akára DiggSpy-hoz hasonlóan frissülõ listákat.


FFeellhhaasszznnáállóóii ffeellüülleetteekk RRuubbyy oonn RRaaiillss aallaappookkoonn

web2007.qxd 3/22/2007 11:33 AM Page 7

RJS – Remote JavaScript

A Rails 1.1-es változatában mutatkozott be az RJS temp-laterendszer. A technika lényege, hogy az alkalmazásunkJavaScript-et ad vissza eredményül a böngészõnek, amelyaz eval() függvény segítségével kerül kiértékelésre.

Ezzel a megoldással egy adott weboldal több eleme is fris-síthetõ, egyetlen AJAX kérés eredményeként: a megadottelemekbe HTML-t renderelhetünk.

A script.aculo.us könyvtár effektjeit alkalmazhatjuk raj-tuk, vagy akár a saját JavaScript függvényeinket is meg-hívhatjuk, ezért kiváló eszköz lehet saját JavaScripthelper-ek írásához.

Összefoglaló

A gyakorlati bemutatón látni fogjuk, mire képes a Rubyon Rails: a felhasználói felületen alkalmazott egy-két so-ros metódushívások a szerveroldalon is csak néhány kód-sorral egészülnek ki, így egy-egy ötlet percek alatt kipró-bálható, alkalmazható vagy elvethetõ. Ne feledjük, hogya bemutatott példák könnyedén továbbfejleszthetõkvagy akár kombinálhatók is.

FFeekkeettee FFeerreenncc

Lelkes fejlesztõ, aki 2005-ben váltott Ruby on Rails-re, PHP-velmár csak ritkán dolgozik. Több Rails alapú alkalmazás fejleszté-sében is részt vett. Tapasztalatait blogján publikálja, szabadide-jében a Dolgomvan.hu startup-ját heggesztgeti.


FFllaasshh ééss PPHHPP kkoommmmuunniikkáácciióó

A „gazdag” internetes programok világában jelenlegugyan az AJAX-os rendszerek számítanak a követendõpéldának, ugyanakkor a Flash méltó vetélytársa ezekneka megoldásoknak. A weben a Flash sokáig csak a mozgó,zenélõ, villogó reklámok megjelenítési eszköze volt.

Az újabb verziók már jelentõsen kibõvült eszköztárral,professzinális programozási nyelvvel felszerelkezve ér-keztek, amik alkamassá tették a nyelvet akár teljes kliensoldali megjelenítõ rendszerek írására.

Ez azonban felveti a kérdést, hogy a szerverrõl hogyanjutnak el az adatok a kliensig. Az elõadás igyekszik egyrövid áttekintést adni az elsõ elég kezdetleges próbálko-zásoktól a mai kifinomult technológiákig.

Rövid betekintést kapunk az egyszerû, egyirányú adatkommunikációtól kezdve (embed, flashvars) a rövid,ámde zavaros múltú loadvars rendszereken át a maiszemmel sokkal megfelelõbbnek tünõ XML kommuni-káción keresztül az Adobe által fejlesztett AMF kommu-nikációig.

Szó lesz az AMF elõnyeirõl, hátrányairól, és be fogok mu-tatni egy PHP-ben megírt keretrendszert, mely a kommu-nikáció egyszerûsítését, gyorsítását szolgálja.

Bemutatom az AMFphp rendszert, amely jelenleg az 1.2.5változatnál tart, és képes az AMF2 protokol teljes használa-tára. Szóba kerülnek a napi üzemeltetés folyamán fellépõérdekes események is.

Ezen felül egy rövid ízelítõ is helyet kap az AMFphp 2.0-sváltozatából, amely jelentõsen módosított belsõ felépítésemellett több új funkciót is nyújt, számos új kommunikációsmetódust támogat.

Az elõadás végén röviden áttekintem más nyelvek AMFtámogatását is.

Kapcsolódó linkek • AMF:http://livedocs.macromedia.com/flashremoting/mx/

�� Using_Flash_Remoting_MX/intro2.htm

• AMFphp: http://www.amfphp.org/

• RubyAMF: http://www.rubyamf.org/

• OpenAMF, a Java alapú megvalósitás:http://sourceforge.net/projects/openamf/

FFeerreenncczz TTaammááss

2004 óta foglalkozom webfejlesztéssel, szerver üzemeltetéssel,elõször saját fejlesztõ studiómban készültek a weblapok, majd2005 elején csatlakoztam jelenlegi cégemhez, ahol a világ vezetõAdult LiveCam oldalának vezetõ fejlesztõjeként dolgozom.Feladatom a háttér rendszerek integrációja, a Flash / FlashMedia Server és a weblapok / adatbázisok kapcsolatainak fel-ügyelete. Fõ érdeklõdési köröm a nagy terhelhetõségû, nagyrendelkezésre állású rendszerek fejlesztése, üzemeltetése.

AMFphp 2.0 kommunikációs metódusok

• Flash és Flex támogatás az AMF2 ésAMF3 képességeinek kihasználásával

• JavaScript és AJAX támogatás a JSONmódszerrel

• XML kliens támogatás XML-RPC szabá-lyok szerint

web2007.qxd 3/22/2007 11:33 AM Page 8

Amikor 2001-ben megjelent az ASP.NET 1.0, gyökeresenúj megközelítést alkalmazott a webprogramozói felada-tok megoldására: szerver oldali vezérlõelemek haszná-latával a webalkalmazások fejlesztését a már megszo-kott vastag kliens fejlesztéshez tette hasonlóvá és elrej-tette a programozó elõl a háttérben dolgozó HTTP pro-tokoll és a HTML kód generálásának részleteit. Ígyaz ASP.NET fejlesztõknek a webalkalmazások fejleszté-séhez csak a .NET platform ismeretére volt szükségük,a manuális rutinmunkát a futtatókörnyezet automati-kusan elvégezte, ami óriási hatékony-ságnövelésnek számított a korábbitechnológiákhoz képest.

Azóta természetesen az ASP.NET plat-form továbbfejlõdött és bár a 2.0 verzi-óval további szolgáltatások kerülteka keretrendszerbe, az alap programo-zói megközelítés nem változott, to-vábbra is szerver oldali vezérlõkkeldolgozhatunk, melyek a háttérben tel-jes HTTP kéréseket és oldalletöltéseketgenerálnak.

Idõközben a Web 2.0 jelenség megszü-letésével a webfejlesztõk új kihívások-kal szembesültek, felmerült az igényugyanis új, interaktívabb felhasználóifelületek készítésére. Ezeknek a meg-alkotásához elkerülhetetlenné vált azAJAX (Asynchronous JavaScript AndXML) technológia használata, amelya gazdag felhasználói felületet elsõsor-ban kliens oldali JavaScript kód alkal-mazásával valósítja meg. Báraz ASP.NET 2.0 platform már kezdettõlfogva fel volt készülve a JavaScript és az AJAX-jellegûfunkciók kezelésére (gondoljunk csak a client callbackszolgáltatásra), azok használatához elengedhetetlenülszükséges volt a JavaScript közelebbi ismerete.

Mivel az ASP.NET fejlesztõk abban a kényelmes hely-zetben voltak, hogy elsõsorban szerver oldali kódot ír-hattak C# vagy Visual Basic .NET nyelven, az új igé-nyeknek csak kevesen tudtak megfelelni, helyette so-kan maradtak a hagyományos szinkron felhasználói fe-lületek készítésénél.

Ezen a helyzeten jelentõsen változtat az a tény, hogy2007. januárjában elkészült az ASP.NET 2.0 AJAX plat-form, amely az AJAX funkcionalitással úgy egészíti kiaz ASP.NET keretrendszert, hogy a korábbi szerver oldaliprogramozási modell változatlan marad: a fejlesztõk to-vábbra is szerver oldali vezérlõkkel és a korábbi eszköze-

ikkel a már megszokott nyelven kódolhatnak, az ered-mény mégis aszinkron, interaktív felhasználói felületlesz. Mindez azt jelenti, hogy mivel a programozói mo-dell változatlan, a korábbi ASP.NET alkalmazások egysze-rûen terjeszthetõk ki az AJAX funkcionalitással, azazgyorsan, új technológia elsajátítása nélkül tudjuk elvé-gezni a felhasználói felület modernizálását.

A következõ ábra az ASP.NET 2.0 AJAX platform fonto-sabb komponenseit tekinti át:

Az ábrán látszik, hogy a rendszernek két jól elkülöníthetõrésze van, egy szerver oldali és egy kliens oldali keret-rendszer (az utóbbiról részletesen olvashat a Böngészõ-és szerver független AJAX programozás címû cikkben).

A szerver oldali rész az ASP.NET 2.0 alapokra épül és elsõ-sorban új vezérlõelemekkel egészíti ki azt. Ezek közüla legfontosabb az új UpdatePanel kontroll, amely tetszõ-leges más vezérlõelemek konténereként viselkedve a be-ágyazott vezérlõk számára aszinkron frissítést biztosít.

Ha például van egy olyan oldalunk, amely egy Grid-View vezérlõ és egy DataSource kontroll segítségéveljelenít meg adatokat, elég ezeket a kontrollokat egyUpdatePanel elemmel körülvennünk és az oldalunknakez a része máris AJAX jelleget ölt. Ilyenkor természete-sen általában felmerül az igény, hogy a felhasználót ér-tesíteni kell arról, hogy az oldal a háttérben adatokat


MMiiccrroossoofftt ééss aazz AAJJAAXX –– AASSPP..NNEETT aallkkaallmmaazzáássookk AAJJAAXX--oossííttáássaa

AASSPP..NNEETT AAJJAAXX aarrcchhiitteekkttúúrraa

KKlliieennss kkeerreettrreennddsszzeerr SSzzeerrvveerr kkeerreettrreennddsszzeerr

web2007.qxd 3/22/2007 11:33 AM Page 9

vár a szervertõl, amit egyszerûen megtehetünk azUpdateProgress vezérlõvel, amely az UpdatePanellelegyüttmûködve akkor jelenik meg, amikor aszinkronkommunikáció folyik.

Az is elõfordulhat, hogy az oldal egy részét rendszere-sen szeretnénk frissíteni, ez esetben használhatjukaz új Timer kontrollt, amely képes az UpdatePanel mû-ködését megadott idõközönként triggerelni.

Mindhárom új vezérlõt a már ismert módon, példáula Visual Studio vagy az ingyenes Visual Web DeveloperToolbox-áról helyezhetjük az oldalunkra, a kliens oldalifunkciót biztosító JavaScript kódot a vezérlõk automa-tikusan generálják.

A keretrendszer részeként megjelenõ Application ServiceBridge az ASP.NET 2.0-ban megjelent Membership ésProfile szolgáltatás elérését biztosítja kliens oldalról. En-nek segítségével JavaScript kódból tudjuk elvégezni a fel-használó bejelentkeztetését a webalkalmazásunkba vagyelérni a szerver oldali adatbázisban tárolt profil tulajdon-ságait – a szükséges webszolgáltatás hívásokról a rend-szer automatikusan gondoskodik a háttérben.

Ezen túlmenõen a Web Services Bridge-nek köszönhe-tõen tetszõleges webszolgáltatást is egyszerûen hívha-tunk közvetlenül a kliensrõl. Ez a komponens a web-szolgáltatás WSDL leírása alapján képes JavaScriptproxy osztály generálására, amely elfedi a hívó elõl

a webszolgáltatás meghívásához szükséges XMLHttp-Request alkalmazását.

Az ASP.NET 2.0 AJAX platform az ASP.NET-hez hasonló-an ingyenesen tölthetõ le a Microsoft weboldaláról, sõta Microsoft Reference License-nek (Ms-RL) köszönhetõ-en a forráskódja is elérhetõ, amely sokat segíthet a mû-ködés megértésében.

Az új funkcionalitás az ASP.NET platform következõ ver-ziójának már alapértelmezetten beépített része lesz.

Kapcsolódó linkek

• ASP.NET: http://ajax.asp.net/• Böngészõ- és szerverfüggetlen AJAX programozás

címû cikk, lásd késõbbiekben.• Microsoft: http://microsoft.hu/

BBaalláássssyy GGyyöörrggyy

Villamosmérnök, a BME Automatizálási és AlkalmazottInformatikai Tanszékén webportálok fejlesztését oktatja. 2000óta foglalkozik a Microsoft .NET platformjával, melynek meg-honosításában jelentõs szerepet vállalt elõadóként, konzu-lensként és A .NET Framework és programozása címû könyvtársszerzõjeként. Az MSDN Kompetencia Központon belül aPortál Technológiák Csoport vezetõje, a www.devportal.huközösségi honlap szakmai gazdája. 2005 óta a Microsoftmagyarországi regionális igazgatója.


web2007.qxd 3/22/2007 11:33 AM Page 10

Amikor elkezdtük a www.allaslehetosegek.hu kialakítá-sát, alapvetõen saját elképzelések alapján építkeztünk.Egy olyan komplett vállalkozásfejlesztési programot való-sítottunk meg, mely egy regisztráció és egy egységes felü-let segítségével lehetõséget ad a cégek számára, hogy egykomplett irodát nyithassanak az interneten. Egy felületenküldhették el a teljes cégismertetõt, jelentethették meg üz-leti, és állásajánlataikat, valamint az ingatlanértékesítésifeladatok intézésében is segítséget nyújtottunk számukra.

Az oldalak középpontjába a keresést helyeztük. Úgy gon-doltuk, hogy a legfontosabb kritériumok, és az összetett ke-resés megoldást jelent a felhasználóknak arra, hogy megta-lálják a számukra értékes információkat. Ennek az elképze-lésnek megfelelõen kerültek kialakításra a weboldalak meg-jelenési formái is. Természetesen olyan problémákat is megkellett oldanunk mint az adminisztrációs felület, a bekül-dött tartalmak engedélyezési mechanizmusai, vagy a meg-jelenõ ûrlapok összeállítása. A tartalmi megjelenítés mellettkiemelt szerepet kaptak az oldalon a reklámfelületek. Mivelnem találtunk olyan kész alkalmazást, ami megfelelt volnaigényeinknek, ezért PHP-ben készítettünk egy saját rend-szert. Alapvetõen nem volt elhibázott az elképzelésünk, detudtuk, hogy változtatni kell rajta minél elõbb. Ennekaz alapja egyszerûen a felhasználók igényeirõl szerzett tu-dásunk volt. Amit elsõként fel kellett ismernünk, hogy a fel-használók nem szeretik, ha egyszerre mindent elintézhet-nek. Elsõsorban a keresõknek köszönhetõen is célirányosszándékkal érkeznek a weboldalra, így ha valaki az „állás-ajánlat feladása” keresõszóra érkezik, hiába rendelkezikcéggel, és különbözõ üzleti ajánlatokkal, csupán álláshirde-tést fog feladni. Emiatt döntöttünk úgy, hogy a weboldalrendszert részekre bontjuk, és külön-külön vertikális, témaszerint szétosztott egyedi portálokat hozunk létre.

Azért tartjuk különösen fontosnak a megújulást, merta portál középpontjába helyezett keresési megoldást nemtartottuk elég hatékonynak. A keresõi szokások változásá-val fontos lett, hogy az eredmények azonnal láthatóak le-gyenek, de azonnal módosíthatóak is, tehát a különbözõkeresési megoldások helyett azonnali szûrési lehetõségetdolgoztuk ki, mely gyorsan eredményt ad a felhasználó-nak, és az csak azt látja, amire szüksége van. A saját ma-gunk által fejlesztett és az elérhetõ PHP-s rendszerekbennem találtuk meg a jövõre vonatkozó további gyorsfejlõdési lehetõséget, ezért inkább a Java portletek irányábakeresgéltünk. A Java portlet specifikáció egy egységes por-tál építési szabvány, melyet több kereskedelmi és nyílt for-rású rendszer is támogat. Ezzel gyakorlatilag az egyedi por-tálok által megvalósított funkcionalitások egymás rendsze-rei között is hordozhatóvá válnak. Ezen portlet konténerekképességei, és alkalmazási területeik folyamatosan egyrenõnek, azonban még egy ideig valószínûleg az ingyenestárhelyszolgáltatók Java támogatottságának köszönhetõen

nem fognak PHP-s társaikkal versenyre kelni. Portálunk ésleendõ látogatóink vélhetõ igényeit figyelembe véve megkellett állapítanunk, hogy a Java-s világ jelenleg elérhetõwebes megoldásai sem nyújtanak jelentõsen többet máskörnyezeteknél. A Java nyelvhez kapcsolódó nyílt szabvá-nyok, specifikációk, minta implementációk azonban arróltanúskodnak, hogy ez egy átgondolt, elõre mutató környe-zet, ahol a kompatibilitás az egyik központi gondolat.Ez az, amire éppen szükségünk volt. Egy stabil, szabvá-nyos alap, amire úgy építkezhetünk, ahogy megálmodjuk.Mindezt úgy, hogy nem szükséges újra feltalálni a spanyolviaszt, de megtarthatjuk az elképzelt fejlesztõi és alkalma-zói szabadságot, némi plusz munka árán.

Miután kiismertünk pár portlet alapú rendszert (pl.:Pluto: http://portals.apache.org/pluto/), megállapítot-tuk, hogy ezen rendszerek eseménykezelése sokkal in-kább kifinomultabb, mint amelyekkel eddig dolgoztunk.Számos olyan portlet érhetõ el, melyek elsõsorban kliens-oldalon történõ megjelenítésre használnak fejlettJavaScript-es eszközöket, azonban egyik rendszer semrendelkezik a kereséseinkhez szükséges AJAX-os kom-munikációs támogatással. Egyes AJAX-os komponensek(progress bar-os feltöltés, dinamikus menüelemek) különérhetõek el. Ezen elemek portletkonténerekhez illesztésenagyon nehézkes, és könnyû biztonsági réseket létrehoz-ni a portáljainkon ilyen látszólag össze nem illõ technoló-giák alkalmazásával. Ezért a portlet specifikáció(http://www.jcp.org/en/jsr/detail?id=168) alapján be-lefogtunk egy saját keretrendszer megvalósításába.A Sirius megpróbálja összekötni a magas szintû esemény-kezelést az AJAX alapú dinamikus tartalmak megjeleníté-sével. Az egyes háttérben végbemenõ folyamatok hagyo-mányos portlet eseményként képesek megjelenni a szer-veroldalon. A generált tartalom böngészõben akár egy divelembe vagy legördülõ listába is kerülhet anélkül, hogysérülne a kompatibilitást biztosító eredeti specifikáció.

Az elõadás során betekintés nyerhetõ a portletek világába.Felhasználói és fejlesztõi oldalról megvizsgáljuk néhányAJAX-os portlet mûködését, telepítését, fejlesztését Siriuskörnyezetben. Kiderül, hogy hol áll a világ eddig egyetlenmagyar fejlesztésû, egyetlen generikus AJAX alapú ese-ménykezelést nyújtó, JSR-168 kompatibilis portálrendszere.

KKaarróócczzkkaaii KKrriisszzttiiáánn

A Creators WebStudió kiszolgáló oldali fejlesztési vezetõje,valamint az MTA SZTAKI Párhuzamos és Elosztott RendszerekLaboratóriumában egy elosztott grid portál fejlesztését irányítja.Közel kilenc éve foglakozik Java-val a dinamikus webes felületekmegjelenése óta elsõsorban különbözõ szerveroldali Java-smegoldásokkal. Elsõsorban nagy teljesítményû elosztott web-alkalmazások fejlesztésére specializálódott az évek során.


PPoorrttlleetteekk ééss AAJJAAXX,,aazz aallllaasslleehheettoosseeggeekk..hhuuúújjjjáásszzüülleettééssee

web2007.qxd 3/22/2007 11:33 AM Page 11

Model 2-es architektúraA JSP szabvány megjelenésével együtt napvilágra kerül-tek olyan megoldások is, melyeknél a JSP oldalak a HTMLkód, az üzleti- és kérésfeldolgozó logika átláthatatlanegyvelegébõl álltak. A káosz megszüntetését a GUI alapúalkalmazásoknál jól bevált Model-View-Controller archi-tektúra webes modellre illesztése célozta meg: megszüle-tett a Model 2-es architektúra.

Ebben világos szerepköröket kapnak a komponensek:a Servletek a vezérlõ funkcionalitás (Controller) betöltésé-re hivatottak, míg a JSP-k vállalják magukra a megjelenítés(View) nehézségeit.

Ezekre az alapokra aztán jó néhány keretrendszer épült,melyek még egyéb tervezési minták alkalmazásával(például Front Controller, Application Controller, Com-mand, Context Object) a kérésfeldolgozási folyamatbóligyekeztek kiemelni az általánosítható részeket, hogya fejlesztõk a tényleges feladatra koncentrálhassanak.

A legelterjedtebbé az Apache Struts nevû nyílt forráskó-dú terméke vált, mely de-facto szabvánnyá lett a roha-mos ütemben növekvõ piacon, mindazonáltal mind-egyik ilyen keretrendszer ugyanazokra az alapokraépült. Ezek általános mûködését a következõ sequencediagram szemlélteti:

A JavaServer FacesA szabvánnyá váló JavaServer Faces (JSR 127) szintén egyModel 2-es framework, de egy gyökeresen új megközelí-tést választ a webalkalmazások nézeteinek (View) kialakí-tására. A JSF-ben a nézetek fa struktúrát alkotó, állapottalrendelkezõ komponensekbõl épülnek fel. A következõábrán egy táblázatot tartalmazó összetett nézet látható, ésaz ezt felépítõ komponensfa:

Látható, hogy a fenti táblá-zat felépítéséhez elegendõegy UIData komponensnégy column gyermekelem-mel, minden column pedigegy további gyermekelemettartalmaz. Hogyan lesz eb-bõl több soros táblázat?Honnan lehet majd tudnia Delete gomb megnyomá-sakor, hogy melyik sorbantörtént az esemény?

A kérdések megválaszolásá-hoz elõször nézzük meg a JSFkérésfeldolgozási ciklusát!


WWeebbaallkkaallmmaazzááss ffeejjlleesszzttééss JJaavvaaEEEE kköörrnnyyeezzeettbbeenn NNeettBBeeaannsssseeggííttssééggéévveell:: JJSSPP 22..11,,JJaavvaaSSeerrvveerr FFaacceess 11..22,, AAJJAAXXÉÉppííttkkeezzzzüünnkk kkoommppoonneennsseekkbbõõll GGUUII mmóóddrraa!!

web2007.qxd 3/22/2007 11:33 AM Page 12


A JSF életcikusa

A beérkezõ kérés alapján a JSF elõször létrehozza, vagyvisszaállítja a komponensfát (Restore View fázis). Ameny-nyiben elõször látunk egy nézetet, úgy ebbõl az állapotbólközvetlenül a Render Response állapotba jutunk (szagga-tott nyíl), ahol a komponens fa aktuális állapota alapjánjön létre a kimenet. Az így létrejött HTML oldalt a bön-gészõ megjeleníti, ahol a komponensek állapotát a fel-használó megváltoztathatja (pl. átírja a beviteli mezõk tar-talmát), bizonyos akcióinak hatására pedig újabb kérés in-dul a szerver felé, ahol a fenti ciklus újra elkezdõdik.

Ilyenkor elõször visszaáll a komponensfa utolsó állapota(Restore View), majd az Apply Request Values fázisbana böngészõben megváltoztatott állapot másolódik bea komponensekbe. Itt fontos tisztázni, hogy a komponen-sek nem csupán String értékeket tárolhatnak: tetszõlegesadattípus (akár saját osztály is) megadható. A HTTP ké-résben és válaszban szereplõ tisztán szöveges adatok ésa megadott típusok közötti oda- és visszaalakításérta Converterek felelnek. Ebben a fázisban tehát a konvertáltértékek íródnak be komponensekbe. Ha a konvertálás so-rán hiba lép fel, úgy a folyamat a Render Response fázis-ban folytatódik, ahol a módosított view jelenik mega konvertálás hibaüzeneteivel.

A Process Validations fázisban a bevitt adatok szintaktikaiés szemantikai helyességét vizsgáló validatoroké a fõszerep.A validátorok tipikusan a konvertált értékekkel dolgoz-nak, így például igazi dátum típussal, függetlenül a beírásformátumától. Validálási hiba esetén újfent a Render Res-ponse fázis következik, ahol a validálási hibaüzenetekkelkiegészített HTTP válasz készül el. Sikeres validáció ese-tén pedig eljutunk az Update Model Values fázisba.

Hogy megértsük ezt a fázist, tisztáznunk kell a modell fo-galmát a JSF értelmezésében. A modell Managed Bean-ek(HTTP kéréshez, sessionhöz, vagy az alkalmazáshoz ren-delt, névvel ellátott JavaBean-ek) halmaza. A komponen-sek definícióikor azok kezdeti tulajdonságait nem csupánkonstans értékekkel lehet megadni: össze lehet rendelniegy tetszõleges Managed Bean tetszõleges tulajdonságá-val, tehát közvetlenül a modellel. Az összerendelés a JSP2.0 szabványban megjelent Expression Language (EL) segít-ségével történik, a kialakított kapcsolat pedig folyamato-san élni fog a komponens további életútjában.

Az Update Model Values fázisban a komponensek model-lel összerendelt attribútumai másolódnak a modell meg-adott pontjára.

Az Invoke Application fázisbantörténik a vezérlõlogika (Control-ler) hívása. Ez a kód egy tetszõ-leges Managed Bean bármelyikmetódusa lehet, mely az üzleti lo-gika futtatása után visszatér a logi-kai továbbhaladási iránnyal (pl. si-ker vagy hiba), melybõl egy konfi-gurációs fájl alapján kiderül, hogymelyik nézetet kell megjeleníteni.

A Render Response fázisban pe-dig a kiválasztott nézet kompo-nensfája alapján generálódik akimenet.

A JSF lelke: a fabejárásAz állapottal rendelkezõ komponensekbõl álló fán tehátminden fázisban más és más mûveletet kell végezni, vi-szont minden fázisban egységes az a módszer, ahogy ezta fát a JSF bejárja. Minden komponens a mûvelet elvég-zése után delegálja a mûveletet a gyermekei felé. A fentitáblázatos példában szereplõ UIData viszont ebbõla szempontból különleges, hiszen ennek a komponens-nek valahogy végig kell iterálnia a megadott rekordokon.Az UIData annyiszor delegálja a kérést a gyermekeinek,ahány rekordja van az adatforrásának. A gyermekei álla-potát pedig õ maga tartja nyilván, minden egyes rekord-hoz külön-külön. Egy adott rekord esetében a delegáláselõtt ezt az általa nyilvántartott állapotot állítja be a belõlekiinduló részfán, delegálja az eseményt, majd az adott re-kordhoz tartozóan menti el a belõle kiinduló részfa új ál-lapotát. Így lehetséges, hogy virtuálisan legalábbis min-den rekordban külön állapottal rendelkezhetnek a táblá-zatban szereplõ komponensek.

LevezetésTerjedelmi korlátok miatt a komponensek nézetté valóösszeállításáról, az eseménykezelésrõl, komponens-fejlesztésrõl, a JSF AJAX-szal való összefûzõdésérõl ésa fejlesztõeszközökkel való barátságáról itt nem esik szó,ezekrõl az elõadásomban beszélek majd, ahol az elméletitudás átadásán túl mûködõ példákon mutatom majd bea technológiát.

VVaarrggaa PPéétteerr

A Budapesti Mûszaki Egyetem villamosmérnöki szakának 1999-es elvégzése után saját webfejlesztõ cég alapítása kezdetben PHPtechnológiára építve, majd áttérés a Java technológiakörre. Az azó-ta eltelt idõben több jelentõs Java és Java EE alapú rendszer fejlesz-tésében, architektúrájának tervezésében vettem részt. Az elmúltnégy évben – a fenti feladatok mellett – a Sun Microsystemsoktatási, konzultációs partnereként végzem a Sun Java, Java EE ésSun Java Enterprise System komponenseinek oktatását, konzul-tációját. Jelenleg a Sun Microsystems JavaMaster oktatásakeretében képzek fejlesztõket a Java EE 1.4, 5.0 (JSF, EJB 3.0, JPA),UML, tervezési minták, web szolgáltatások témakörökben.

ZZsseemmllyyee TTaammááss

Huszonkét éve foglalkozik programozással, ezen belül több minttíz éve foglalkozik a Java Platformmal a Sun Magyarországnál.

web2007.qxd 3/22/2007 11:33 AM Page 13

Rövid idõ alatt vált igen közkedveltté, mondhatni diva-tossá a JavaScript, XML, HTML és az ezekhez kapcsolódótechnológiák összegyúrásából álló gombóc, melyetaz egyszerûség kedvéért csak AJAX-nak szoktunk becéz-ni. A JavaScript, mely megjelenése idején figyelmeztetõüzenetek és popupok feldobálásán kívül másra nemigenvolt használható, mára többek között a W3C hathatósközremûködésének is hála, kezd felnõni, és életre kelteniaz eddig statikus weboldalakat.

Miközben elsodor minket az újdonságok vihara, vizsgál-juk meg azt, hogy az új technológiára való áttérés milyenelõnyökkel és hátrányokkal jár! Nincs általánosan hasz-nálható megoldás, egy mindenre jó készlettár, viszont na-gyon sok, jobb – rosszabb, univerzális vagy specializálteszköz közül kell kiválogatnunk a célunknak legmeg-felelõbbet. Elõfordulhat az is, hogy nem találunk a cé-lunknak igazán megfelelõt, vagy ami elérhetõ, nem felelmeg ízlésünknek. Ilyenkor nincs más hátra, mint a ki-sebb, rendelkezésre álló komponensekbõl összegyúrniazt, amire szükségünk van.

Jelen dokumentumban egy konkrét jegyértékesítõ rend-szer példáján keresztül nézzük végig, hogy milyen terve-zési lépések és döntések során áll elõ a kész rendszer, to-vábbá látni fogjuk azt, hogy az aszinkron JavaScript fel-használása milyen terheket tud levenni a kiszolgáló rend-szer válláról. Megismerkedünk a kliens oldalról letöltött ésösszeállított weboldalak készítésének módjával, és azzal,hogyan tartsuk a felhasználókat a rendelési folyamat elõremeghatározott útvonalán, miközben a felület mûködésétigyekszünk a lehetõ legmegszokottabb mederben tartani.

Célunk végig a felület egyszerû kezelhetõsége, a hiba-lehetõségek minimalizálása, és a rendszer átláthatóságamarad.

Elsõ dolgunk felmérni, miért is van szükségünk a hagyo-mányos request-response metodológia helyett AJAXhasználatára. Esetünkben a feladat egy nemzetközi busz-jegyeket értékesítõ rendszer megújítása volt. A vásárlásfolyamata itt a megszokott kosár modell helyett egy egy-irányú, varázsló-szerû útvonalat követ, ahol a vásárlólépésrõl lépésre keresi ki a számára legmegfelelõbb jára-tot, az arra váltható optimális jegyet, majd az adatai meg-adása után kifizetheti azt. A nehézséget az jelenti, hogya különbözõ jegyek korlátozott számban állnak rendelke-zésre, a limitek betartására pedig szigorúan törekednikell. A vásárló szemszögébõl viszont elfogadhatatlan az,hogy mire végigér a rendelésen, a rendszer közli vele,hogy az adott típusú jegy már elkelt. Ezért egy adott jegyfelajánlásakor azt azonnal zárolnunk kell, és gondoskod-ni arról, hogy ameddig az elsõ látogató azt ki nem fizette,vagy meg nem gondolta magát, addig másnak ne ajánl-

juk fel. Ráadásul a rendelés elsõ fázisában még nagyonsok választási lehetõsége van a vásárlónak, ami eseten-ként aránytalanul sok jegy fenntartását jelenti. Emiatt fo-lyamatosan arra kell törekednünk, hogy a fenntartott je-gyeket amilyen gyorsan csak lehet felszabadítsuk.

Mindezt csak bonyolítja az, hogy a klasszikus megoldásesetében a látogató a böngészõje elõre-hátra gombjai, ésa history segítségével bármikor oda-vissza tud ugrálnia rendelési folyamatban, ami rendkívül megnehezíti a zá-rolások kezelését, és pontos feloldását. A legkellemetle-nebb, amikor a látogató egyszerûen elhagyja az oldalt(bezárja a böngészõjét) a rendelési folyamat közepén, ígyzárolva hagyja a számára kiajánlott jegyeket, amik a záro-lás lejártáig nem eladhatóak.

E két utóbbi probléma tette esetünkben szükségesséaz aszinkron JavaScript használatát. A tervek szerint a ko-rábban több oldalon keresztülvezetõ rendelési folyamatotegyetlen lapon akartuk megoldani úgy, hogy az egyes lé-pések oldalait a JavaScript tölti le. Mivel minden egy web-oldalon belül történik, ezért a felhasználó nem tuda history-n keresztül lépéseket átugrani, a felületen elhe-lyezett gombokkal kell navigálnia. Nem újdonság az ilyenjellegû felület: az asztali alkalmazások varázslóiban islépésrõl lépésre kel haladnunk, nem ugrálhatunk azokközött kedvünkre.

Alkalmazásunk tehát két részre bontható: a kiszolgáló ol-dalon található üzleti logikára, és a kliens böngészõjébenfutó megjelenítõ rendszerre – ez utóbbi az AJAX feladata.A kliensnek a következõket kell tudnia megvalósítani:

• meghívja a rendelési folyamatot kiszolgáló metódusokközül a soron következõt

• letölti a következõ oldal HTML sablonját• a válaszul kapott tartalmak, és a sablon segítségével

összeállítja a megjelenítendõ oldalt, ûrlapot• a bekért adatokat ellenõrzés után tovább adja

a következõ oldal feldolgozó egységének, amivel a fo-lyamat kezdõdik elölrõl.

Ezekhez három JavaScript könyvtárra van szükségünk:

• A szerver és a kliens közötti aszinkron kommunikációtimplementáló könyvtárra

• A kliens oldali sablonok kezelését megoldó könyvtárra• És egy általános, a böngészõk közötti inkompatibilitá-

sokat eltakaró könyvtárra

Mondanom sem kell, mindezek nulláról történõ megírásabõven meghaladta volna a rendelkezésünkre álló kapaci-tásokat. A nyilvánosan elérhetõ és felhasználható könyv-tárak közül voltak olyanok (Google Web Toolkit, Yahoo


AAJJAAXX ffrraammeewwoorrkk ééppííttééss

AAkkttíívv wweebbffeellüülleetteekk

web2007.qxd 3/22/2007 11:33 AM Page 14

UI), amelyek mindezt egy csomagban ígérték, mégsemvoltak teljesen megfelelõek. Egy részrõl ezek a feladathozmérten túl nagyok, és összetettek voltak. A kliens oldalontörténõ HTML összeállításáról is eltérõ volt a koncepci-ónk: ezek az alkalmazások widgetekben gondolkodnak,míg mi szerettük volna megtartani a HTML kézzel szer-keszthetõségét.

A PHP esetében már régóta alkalmazzuk a Smartysablonkezelõ motort, egy ehhez hasonló megoldást ke-restünk a JavaScript-hez, amit a TrimPath JavaScriptTemplates csomagjában (http://trimpath.com/project/wiki/JavaScriptTemplates) találtunk meg. Ez utóbbiszintaxisában és alkalmazhatóságában is nagyon hasonlíta Smarty-ra, de teljes egészében JavaScript-ben íródott.

Mivel a böngészõk közötti inkompatibilitások máig nemteljesen megoldottak, ezért elengedhetetlen volt egy azokatelfedõ, és a programozást is egyszerûsítõ réteg alkalmazása.Ezen a téren jelenleg a Prototype (http://www.proto-typejs.org/) és a jQuery (http://jquery.com) versengegymással, a kettõ összehasonlítása túlmutatna ezen cikkkeretein, mi a Prototype-ot választottuk.

Bár a Prototype-pal is megvalósíthatóak az aszinkron le-kérések, ez utóbbira inkább egy harmadik csomagot, azAdvAJAX-ot (http://advajax.anakin.us/index-en.htm)használtuk. Ez utóbbi ugyanis talán áttekinthetõbbenkezelhetõ, és rengeteg extra szolgáltatást biztosít, az egy-séges hibakezeléstõl, a több párhuzamosan történõ leké-rés szinkronizációjáig.

Mindezeket végül egy közös keretrendszerbe gyúrtukössze. Ez egy JavaScript objektumot vár, aminek az egyestagváltozói rendre egy-egy oldalt leíró objektumok, ami-ken keresztül megadható az alkalmazandó oldalsablon,a tartalmakat elõállító metódusok, a megjelenítés soráncsatolandó eseménykezelõk stb.

Az ezt feldolgozó keretrendszer már viszonylag gyorsanés egyszerûen elkészíthetõ, csak követnünk kell a fentebbleírt lépéseket. Pár dologra azonban nem árt odafigyelni:kerülendõ például a megszokott link elemek használata.Ennek oka az, hogy könnyen kivezetnek az általunk ki-alakított rendszerbõl, elegendõ egy apró JavaScript hiba,vagy elfelejteni a visszatérési értéket az onClick esemény-ben. Éppen ezért mi (a Gmail-hez hasonlóan) egy egyediclass-szal ellátott <span> elemeket használtunk linkek he-lyett, amikre az oldal megjelenítésekor a keretrendszerrakja fel az onClick eseményeket. Így, ha valamirõl lema-rad, vagy hibás a JavaScript, akkor az adott gomb csakmûködésképtelenné válik, de az oldalon belül maradunk.

Érdemes még lekezelnünk az oldal onUnload eseményétis, innen értesülhetünk ugyanis arról, ha a látogató el-hagyja az oldalt, vagy bezárja a böngészõjét. Ilyenkormég gyorsan indíthatunk egy AJAX kérést, amiben jelez-hetjük a szerver számára, hogy a kliens oldali folyamatmegszakadt. Mi ezt az eseményt használtuk arra, hogya vásárló által zárolt jegyeket feloldjuk, így azok azonnalvisszakerülnek az értékesítésbe.

Utolsó lépésként a böngészõ elõre-hátra gombjainak tá-mogatása maradt. A tapasztalatok szerint ezt nem úszhat-juk meg, ugyanis a felhasználók egyfajta undo funkció-ként használják a vissza gombot: amint nem várt helyre

kerülnek, vagy nem megfelelõ eredményt kaptak, azon-nal ide kattintanak, hiába is helyezünk el a felületünkönkülön e célra szolgáló gombokat. Sajnos ez utóbbira vi-szont csak a nagy könyvtárak (GWT, YUI) biztosítanakkész megoldást, így ezt magunknak kellett elkészítenünk,ami sajnos az Internet Explorer esetében nem megy túlegyszerûen. Míg a Firefox, Opera esetében a problémakönnyen megoldható az URI hash részének ellenõr-zésével, addig ezen böngészõnél beágyazott keretekhezkell folyamodnunk. Ezután már látszólag oda jutottunk,mintha a teljes rendszert a hagyományos úton készítettükvolna el. Lényeges különbség azonban, hogy mostaz elõre-hátra gomb megnyomásakor nem a böngészõdönti el, hogy mely oldalt töltse le, hanem az abban futóJavaScript alkalmazásunk, így lehetõségünk nyílik az elõremeghatározott útvonal betartatására. Ezen felül informáci-óval rendelkezünk arról is, hogy mi volt az elõzõ pont,ahonnan vissza/elõre léptünk, ami a hagyományos útoncsak nehezen megoldható.

Végezetül, ha odafigyeltünk az általános, és a feladat spe-cifikus kódrészek megfelelõ szétválasztására, akkor márelõ is állt saját, igényeinknek megfelelõ AJAX keretrend-szerünk váza.

NNaaggyy AAttttiillaa GGáábboorr

Mérnök-informatikusként 2003-ban végzett a Budapesti Mûszakiés Gazdaságtudományi Egyetemen. Az internet és a World WideWeb világával valamikor 1995-ben, a PHP-val 1999-ben ismer-kedett meg. Egyetemi évei alatt már több közismert magyarweboldal tervezõje és fejlesztõje volt. Jelenleg a Wildom Kft PHPcsoportjának vezetõ fejlesztõjeként dolgozik. A Linux világ elkö-telezett rajongója, komoly gyakorlatot szerzett a nagy forgalmú,Linux alapú rendszerek tervezésében és megépítésében is.


web2007.qxd 3/22/2007 11:33 AM Page 15

Napjainkra egyértelmûvé vált, hogy a webalkalmazásokalap technológiái, a HTML és a szerver oldali alkalmazá-sok nem elégítik ki teljes mértékben a felhasználói igé-nyeket. A felhasználók olyan interaktív felhasználói felü-letekre vágynak a webalkalmazásokban is, melyekkel ko-rábban csak vastag kliens alkalmazásokban találkozhat-tunk.

A Google Suggest, a Google Maps és a GMail, majd ké-sõbb a Live.com, az MSN SoapBox és hasonló alkalmazá-sok bizonyították, hogy a feladat megoldható, mégpedigaz AJAX – Asynchronous JavaScript And XML – technoló-gia segítségével.

Sajnos az AJAX alaptechnológiái erõsen böngészõfüg-gõek. A kliens oldali logika megvalósításához szükségesJavaScript nyelvek különbözõ verzióit az egyes kliensekkülönbözõ szinten implementálják. A kommunikációhozhasznált XMLHttpRequest objektum a böngészõk többsé-gében natív objektum, míg az Internet Explorer 5 és 6 ver-zióiban ActiveX objektum formájában áll rendelkezésre.A szervertõl válaszként érkezõ XML feldolgozására szol-gáló értelmezõk szolgáltatásai és metódusai szintén eltér-nek egyes böngészõk esetén. A felhasználói felület kezelé-sére szolgáló Dynamic HTML (DHTML) pedig még csaknem is szabvány, nem meglepõ tehát, hogy a felhasználóiesemények kezelésére és a felület egyes részeinek elérésé-re böngészõnként eltérõ kódot kell írnunk.

A fent felsorolt problémák megoldására a webprogramo-zók tipikusan kliens oldali osztálykönyvtárakat fejleszte-nek és használnak. Ezeknek a könyvtáraknak a kifejlesz-tése komoly jártasságot igényel a kliens oldali programo-zás területén, ezért sokan használnak már kész, publi-kusan elérhetõ komponenseket.

Ezeknek a könyvtáraknak a sorában található meg a Mic-rosoft AJAX Library is, melynek két fontos – és talán a cégtörténetében szokatlan – jellemzõje van:

• A Microsoft AJAX Library egy olyan kliens oldali osz-tálykönyvtár, amely nem kapcsolódik semmilyen szer-ver oldali programozási nyelvhez, így egyszerûen il-leszthetõ nem csak Microsoft, hanem más szerver ol-dali programozási technológiákhoz.

• Bár a Microsoft AJAX Library a Microsoft egy teljes kö-rûen támogatott terméke, a könyvtár ingyenesen hoz-záférhetõ és nem csak hogy a forráskódja elérhetõ, dea Microsoft Permissive License-nek (Ms-PL) köszönhe-tõen még a módosítása, és a módosított változat fel-használása és terjesztése is engedélyezett!

A Microsoft AJAX Library szolgáltatásai öt nagyobb cso-portba sorolhatóak:

A Browser Compatibility réteg feladata, hogy az osztály-könyvtár többi komponense elõl elfedje az egyes böngé-szõk közötti eltéréseket, így megkímélve a programozó-kat a jelentõs energiákat igénylõ if..else blokkoktól.

A Script Core olyan nyelvi funkciókat biztosít a progra-mozók számára, amelyek lehetõvé teszik, hogy az ob-jektum alapú JavaScript nyelvben objektum orientáltkonstrukciókat használhassanak. Így megszületik pél-dául a névtér, az interfész, az öröklés, a felsorolt típusés a delegát fogalma közvetlenül JavaScriptben. Ennekköszönhetõen – más nyelvekhez hasonlóan – sokkal ha-tékonyabban tudjuk az alkalmazás logikát egységbezárni, ami a modern programozási megközelítés egyikalapelve.

A Base Class Library még tovább bõvíti a kliens oldalonelérhetõ funkciókat, azonban nem nyelvi elemekkel,hanem kész osztályokkal, melyek elsõsorban azoknaklesznek ismerõsek, akik használták a .NET keretrend-szert szerver oldalon. Itt található például a String-Builder, Trace, Debug osztály és az XMLHttpRequestfunkcióit burkoló WebRequest és WebResponse osztá-lyok, melyek tisztán kliens oldalon futnak, de szolgálta-tásaik nagyon hasonlóak a .NET Framework Base ClassLibrary-jéhez.


BBöönnggéésszzõõ-- ééss sszzeerrvveerrffüüggggeettlleenn AAJJAAXX pprrooggrraammoozzááss

AA MMiiccrroossoofftt AAJJAAXX LLiibbrraarryy eelleemmeeii

web2007.qxd 3/22/2007 11:33 AM Page 16

A Component Model and UI Framework feladata, hogybevezesse a nyelvbe az önleíró komponens fogalmát,amely aztán lehetõséget biztosít például vezérlõelemek,viselkedések és deklaratív, XML-Script alapú adatkötésdefiniálására.

A legfelsõ, Controls and Components réteg elhozza a kli-ens oldalra a szerver oldalon és vastag kliensekben márrégóta elérhetõ vezérlõelem alapú programozást. Ennekköszönhetõen az oldal minden egyes elemére egy specifi-kus osztály egy példányaként hivatkozhatunk, melynektulajdonságait és metódusait használva módosíthatjukannak tartalmát és viselkedését.

Végül nézzünk egy nagyon egyszerû példát a MicrosoftAJAX Library használatára, melyben egy szövegdoboztartalmát megformázva gombnyomásra egy <span> elem-be másoljuk. Készítsünk egy HTML oldalt és helyezzük elrajta a szükséges három elemet:

<input id="txtName" type="text" /><input id="btnWelcome" type="button"

�� value="Mondd szia!" onclick="greetMe()" />

<span id="lblMessage"></span>

A greetMe() metódus feladata, hogy a txtName mezõ tar-talmát formázva átmásolja a lblMessage azonosítójú<span> elembe, amelyhez a kliens oldali vezérlõelemeketés az osztálykönyvtárat felhasználva csak ennyi Java-Script kódot kell írnunk (a feladat egyébként megoldható

adatkötéssel és deklaratív formában, XML-Script segítsé-gével is):

function greetMe() {var txtName = �� new Sys.Preview.UI.TextBox( $get( "txtName" ) );

var message = String.format( "Szia, {0}!", �� txtName.get_text() );

var lblMessage = �� new Sys.Preview.UI.Label( $get( "lblMessage" ) );

lblMessage.set_text( message ); }

A Microsoft AJAX Library tehát elfedi a JavaScript ésa DHTML nehézségeit a programozók elõl, ezáltal elérhe-tõ közelségbe hozza a kliens oldali és az AJAX jellegûfunkcionalitás megvalósítását azon esetekben is, aholnincs idõ vagy kellõen mély szaktudás a böngészõfüggõkód implementálására.

BBaalláássssyy GGyyöörrggyy

Villamosmérnök, a BME Automatizálási és AlkalmazottInformatikai Tanszékén webportálok fejlesztését oktatja. 2000óta foglalkozik a Microsoft .NET platformjával, melynek meg-honosításában jelentõs szerepet vállalt elõadóként, konzu-lensként és A .NET Framework és programozása címû könyvtársszerzõjeként. Az MSDN Kompetencia Központon belül aPortál Technológiák Csoport vezetõje, a www.devportal.huközösségi honlap szakmai gazdája. 2005 óta a Microsoftmagyarországi regionális igazgatója.


web2007.qxd 3/22/2007 11:34 AM Page 17

The founders of Laszlo Systems had the vision of a pre-sentation server which makes it possible to create thefluid and dynamic interfaces we see on new devices likethe iPhone, and also on more and more websites on theInternet. That was in 2000, well before AJAX and Web 2.0where around.

But without the Laszlo Presentation Server, whichbecame the OpenLaszlo Server in 2004, it was impossiblefor software developers to create such interfaces based ontheir standard tools (IDEs) and established softwaredevelopment processes.

OpenLaszlo gives software developers the technology tocome up with some of the most fascinating interfaces fora wide range of devices. The OpenLaszlo server is anopen source platform for creating zero-install webapplications with the user interface capabilities of desk-top client software.

OpenLaszlo programs are written in XML and JavaScriptand transparently compiled to Flash and, withOpenLaszlo 4, AJAX. The OpenLaszlo APIs provideanimation, layout, data binding, server communication,and declarative UI. An OpenLaszlo application can be asshort as a single source file, or factored into multiple filesthat define reusable classes and libraries.

Laszlo Systems has a division called Laszlo Studios. LaszloStudios is an elite design and development team thatcreates custom rich Web applications using OpenLaszlo.Laszlo Studios employs seasoned project managers,engineers, user experience experts and QA engineers whoknow how to utilize the OpenLaszlo platform to itsoptimum potential.

The user experience which is created by the LaszloStudios team is branded as the Cinematic User Expe-rience. What does the term Cinematic User Experiencemean? It's characterized by the following:

• Continuous User Interface™: By featuring fluid applica-tion state changes, rather than today’s standard page-bypage format, a Laszlo-enabled site helps users stayoriented and efficiently complete multi-step online tasks.

• Universal Canvas: With the ability to view commonmedia data types including text, video and soundformats seamlessly on a single “universal canvas,” usersare able to work with integrated multimedia informationdisplays without the distraction of separate playbacksoftware for each media data type.Furthermore, Laszlo enables a wide array of media typeswithout requiring users to install additional plug-insoftware.

• Real Time Information: Traditional Web sites onlyupdate information when a page is reloaded. Laszloenables live data push into standard browsers. Thisreal-time messaging enables Laszlo-powered Web sitesto provide integrated instant messaging and real-timeinventory or financial information displays.

Our session will show how the OpenLaszlo technologysupports the user experience experts and the user expe-rience engineers in building applications with a Cine-matic User Experience.

RRaajjuu BBiitttteerr

Raju Bitter is an open source fan and a great supporter of theopen source community. Since January 2007 he’s the officialOpenLaszlo Evangelist and Community Manager for the globalOpenLaszlo community. Since the open sourcing of the LaszloPresentation Server in 2004 he’s been involved with theOpenLaszlo project and actively built up the Germancommunity. His interests are centered around the creation of aricher user experience, rich Internet applications and betterways of building Web 2.0 applications.


CCrreeaattiinngg aa CCiinneemmaattiicc UUsseerrEExxppeerriieennccee™™ wwiitthh OOppeennLLaasszzlloo

web2007.qxd 3/22/2007 11:34 AM Page 18

A Netvibes egy személyre szabható digitális adatközpont.Az ingyenes szolgáltatás keretében saját magunknak ké-szíthetünk több oldalból is álló „kezdõlapot” különféle tar-talmakkal, melyet bármikor elérhetünk egy internet kap-csolattal rendelkezõ számítógéprõl, mobiltelefonról, Nin-tendo Wii-rõl.

Az oldalakra tehetõ dobozok széles választékából vá-laszthatunk, az RSS olvasótól a különbözõ (pl. web,podcast, videó, blog) keresõkön keresztül az idõjárásig.A Netvibes API segítségével magunk is készíthetünk do-bozokat (sõt!), a Netvibes ecosystem segítségével pedigközzé is tehetjük azokat.

Szolgáltatás API-k fejlesztése

Számos szabványosított módszer létezik már arra, hogykülönbözõ távoli szolgáltatásokat elérjünk. Korábban ishasználatosak voltak, mostanában viszont egyre népsze-rûbbek. Mint web fejlesztõknek, több szempontból ishasznos végiggondolnunk, hogy mit is jelent egy API, ésmire lehet az jó nekünk is.

Elõadásom elsõ fele az API-k fontosságáról és szerepérõlszól majd. Két irányból közelíthetjük meg a kérdést: sajátfejlesztésû szolgáltatáshoz készíthetünk mi API-t, vagypedig felhasználhatjuk más API-ját szolgáltatásunkhoz.

Az OpenLaszlo egy nyílt forráskódú platform. Segítsé-gével hihetetlenül látványos és felhasználóbarát webes al-kalmazásokat tudunk fejleszteni, amelyek a Flash techno-lógia révén minden böngészõben és operációs rendszerenugyanúgy jelennek meg. Az elõadás fõként a személyestapasztalatokra helyezi a hangsúlyt: mire számítson a ha-gyományos webfejlesztés világából érkezõ fejlesztõ, aki átszeretne térni RIA (Rich Internet Application) fejlesztésre.

Személy szerint nem nagyon ismerek olyan webfejlesztõt,aki még ne hallott volna a bûvös web 2.0 fogalomról, amelya webes fejlesztés utóbbi egy-két évét nagyban meghatá-rozta. Mint azt sokan tudjuk, ez nemcsak az új technológi-ákról szól, hanem (legfõképpen) a közösség erejérõl, arról,hogy az átlag felhasználó is vegye ki a részét az internetestartalomalkotásból. Rátérve a téma technológiai oldalára,be kell hogy lássuk, hogy mindehhez egy újfajta megköze-lítése is szükséges. Most, 2007-ben olyan webalkalma-zásokat várnak el a felhasználók, amelyek ugyanazokkala szolgáltatásokkal, tulajdonságokkal bírnak, mint az aszta-li társaik. Teljesen természetes nekik. Ezeket pedig a hagyo-mányos weboldalakkal nem tudjuk megvalósítani. Fel kellismerünk, észre kell vennünk az igényüket; a gazdaginternetes alkalmazásoké (RIA – Rich Internet Application)a jövõ. És itt jön képbe az OpenLaszlo.

Az OpenLaszlo platformot eredetileg Laszlo PresentationServer (LPS) néven hívták, 2001-ben kezdõdött el a fej-lesztése a LaszloSystems cégnél. 2004-ben egy fontos lé-pés következett be: az addig kereskedelmi forgalombanelérhetõ platform nyílt forráskódúvá vált (GPL licenszalatt) és az OpenLaszlo nevet kapta. Azóta folyamatosan,töretlenül dolgoznak a fejlesztõk az újabb és újabb verzi-ókon. A platform két részbõl áll: az LZX programozásinyelvbõl és az OpenLaszlo szerverbõl.

Az LZX az XML leírónyelvre és a JavaScript-re épül.Az XML-t általában az alkalmazás kinézetének meghatá-rozásánál és objektumok létrehozásánál használjuk, míga JavaScript-et programozáskor alkalmazzuk, az XMLelemek által létrehozott objektumokat is JavaScript-en ke-resztül tudjuk befolyásolni. Ez azt jelenti, hogy nincsszükség egy teljesen új nyelv megtanulására, a korábbiwebes tudásunkat gond nélkül továbbvihetjük.

Az OpenLaszlo szerver egy Java szervlet (pl. Tomcatvagy Jrun alkalmazás szerver alá), ami az LZX kódota kiválasztott platform bináris formátumába fordítja le.Kiválasztott platform? Igen. Jelenleg egyedüliként csaka Flash (6, 7 és 8) érhetõ el, de a 2007. elsõ negyedév-ében megjelenõ új OpenLaszlo verzióban (amelyneka béta verziója már nyilvánosan hozzáférhetõ)a DHTML (AJAX) és a Flash 9 is meg fog jelenni a palet-tán. A késõbbiekben a Windows Presentation Foun-dation (pl. Windows Vista gadget-ek), a Java MicroEdition (mobiltelefonok) és a Flash Lite (egyes PDA-k)platformokra is elérhetõek lesznek az OpenLaszlo-banmegírt alkalmazásaink.

KKiissss--TTóótthh MMaarrcceellll

A web 2.0-ás megoldásokkal foglalkozó SandMark Solutionscommunity managere. A nyílt forráskódú OpenLaszlo elõtt azAdobe Flex-szel foglalkozott, tavaly ebben a témában tartottaelõadását. Az OpenLaszlo mellett öt éve használja a PHP-t és aFlash-t, a PHP Konferencia sorozat utolsó rendezvényén e kétfejlesztõeszköz kapcsolatáról beszélt. A Tiszaújvárosban rende-zett Második PHP Roadshow fõszervezõje. Személyes weboldalaa kiss-toth.hu címen érhetõ el.


OOppeennLLaasszzlloo –– vváállttssuunnkksszzeemmlléélleetteett

NNeettvviibbeess mmoodduull ffeejjlleesszzttééss

web2007.qxd 3/22/2007 11:34 AM Page 19

Marketing

Bármilyen furcsán is hangzik, ha egy szolgáltatásunkhozinformáció megosztó API-t készítünk, akkor az marketingértékkel bír. Több okból is. A hazai szolgáltatásoknál pél-dául alig van lehetõség API használatára (az iWiW mégcsak most vezeti be például), így üttörõk lehetünk ezena téren.

Általában is igaz, hogy egy API segít eljuttatni szolgáltatá-sunkat minél több helyre, minél több felhasználóhoz.Gondolhatunk itt az RSS/Atom hírforrásokra, de akára Google keresõ API-jaira is. A cél, hogy minél több he-lyen ott legyen, hogy ez tõlünk van, s hogy minél többembert a szolgáltatásunk oldalára szállítsunk.

Szintén marketing lehetõség, ha más szolgáltató ad közreolyan API-t, amivel szolgáltatásába be tudunk épülni.A Netvibes API ilyen, segítségével modulokat készíthe-tünk a Netvibes oldalaira, sõt, a Netvibes API-ját, a Uni-versal Widget API-t használva ezek a widgetek más plat-formokon is elérhetõek lesznek, mind Mac OS X, mindOpera, mind a Google hasonló szolgáltatása alatt.

Ha egy szolgáltatás népszerû, sok ember használja, és egykis fejlesztéssel lehetõségünk van a megjelenésre, akkorpedig nincs mese, azt ki kell használnunk – a szolgáltatásreklámfelületté fog válni számunkra, s egyszeri, jellemzõ-en nem túl nagy befektetéssel ott lehetünk. Az elõadásbanbemutatom, hogy ez a Netvibes API-t használva nagyonegyszerû feladat.

A Netvibes nagyon népszerû hazánkban, nem fogjukmegbánni ha elkészítjük hozzá szolgáltatásunk modul vál-tozatát (amire egyre több példa is van egyébként).

Külsõ fejlesztések, ingyen

Visszatérve az API-k lehetõségeihez, ha az elõzõ megol-dást megfordítjuk, vagyis ha mi készítünk olyan szolgál-tatást, ami kiegészíthetõ egy API-n keresztül, az szá-munkra is hasznos lehet, mivel úgy fejlõdik az alkalmazá-sunk, hogy mi konkrétan nem is végzünk fejlesztéseket.Külsõ fejlesztõk jelennek meg, és remélhetõleg hasznosszolgáltatásaikat kínálják a mi szolgáltatásunkon keresz-tül, ezzel egy gyûjtõhellyé, még hasznosabb szolgáltatás-sá emelve a miénket.

Végül bezárva a kört, információ megosztó API-t nemcsak írni, de felhasználni is lehet. Építsünk be bátran szol-gáltatásokat oldalunkba, a szolgáltatás várható stabilitá-sától függõen akár teljesen arra építve, vagy csak részbenfelhasználva azt.

Egy admin felületre érdekes lehet integrálni egy keresõ-szolgáltatás eredményeit a felhasználó termékét illetõen,vagy egy RSS/Atom hírforrást felhasználva névnapokat,híreket, idõjárást, TV mûsort stb. kitennünk oldalunkralátogatóknak.

Remixelés

A fentiek azt eredményezik, hogy kisebb-nagyobb mér-tékben integráljuk szolgáltatásunkba az internet adta le-hetõségeket. Az, hogy megnyitjuk a fejlesztésünket, a fel-használók számára egy jobb, könnyebben használható

szolgáltatást fog eredményezni, melyet szívesebben hasz-nálnak, illetve melyet megválaszthatnak, hogy hogyanhasználnak. A szolgáltatásunk különbözõ környezetbentud megjelenni.

Nem nagy fejlesztésekrõl beszélek. Egy RSS feed létrehozá-sa semmiképp sem több egy egy napos feladatnál. Az RSSformátum felhasználására is minden programnyelvre jópárkiváló lehetõség elérhetõ.

Ha XML formátumban adunk, vagy kapunk információt,ha webszolgáltatásként használjuk, vagy adjuk tovább,ha a „REST” megoldást alkalmazzuk, akárhogy legyen is,nem kell magunknak kitalálnunk a formátumokat, lehe-tõségeket.

Ha mi készítjük az API-t, nem árt, ha egy jó dokumentáci-ót is összeállítunk hozzá (még akkor sem, ha egy elvilegtriviális RSS feedrõl van szó).

Netvibes API / UWA

Az elõadás második részében a Netvibes API segítségévelfogunk egy kisebb modult kifejleszteni. A Netvibes máso-dik generációs API-jának neve Universal Widget API(UWA), mely egy általános fejlesztõi platformot kínála modulok/widgetek fejlesztéséhez.

Az univerzális jelentése, hogy az elkészített modul vál-toztatás nélkül mûködõképes lesz a Netvibes, a GoogleIG, Mac OS X és Opera alatt, illetve bármely hasonló ol-dalon, mely megvalósítja az UWA interfészt. Az inter-fész nyílt forráskódú, így könnyû lehet beépíteni (meg-fontolandó és érdekes lehetõség például egy alkalma-zás admin felületén megjeleníteni tetszõleges UWA mo-dulokat!).

Az UWA ezen cikk írásának idején még nem publikus,ezért egyelõre részleteket itt nem tehetek közzé róla. Akonferencia idejére azonban elérhetõ lesz az APIdokumentációja, példákkal illusztrálva. Általánosság-ban elmondható, hogy egy hatékony, egyszerû éskönnyen tanulható platformot fog kínálni az érdeklõdõfejlesztõk számára. Az elõadás második felében, körül-belül negyed órában pedig ezt az állítást megkísérlembe is bizonyítani.

Összefoglalás

Az elõadás célja, hogy a fejlesztõk és a vezetõk felismer-hessék, hogy milyen jelentõséggel bírnak az API-k, éshogy bemutassam: a Netvibes API-jával milyen egyszerûdolgozni, és használata milyen versenyelõnyt jelent.

BBáárrtthháázzii AAnnddrrááss

A Wish Internet Consulting ügyvezetõje, a Weblabor egyikfõszerkesztõje, az NJSZT-WFSZ titkára. Cégének vezetõjekéntars poeticája, hogy mindig a legfrissebb technológiáksegítségével, az ügyfelek igényeit messzemenõkig kielégítõmegoldásokat nyújtsanak, lehetõségek szerint alternatívákatkínálva. Számos portál, webalkalmazás létrehozásában ésmegújításában vett részt. Cége hosztolja a Weblabor.hu,Drupal.hu, Firefox.hu és RubyOnRails.hu oldalakat, kapcso-lódó levelezõlistákat.


web2007.qxd 3/22/2007 11:34 AM Page 20


IInntteerraakkttíívv wweebbffeellüülleetteekk ffeejjlleesszzttéésseeWWiinnddoowwss PPrreesseennttaattiioonnFFoouunnddaattiioonn//EEvveerryywwhheerree aallaappookkoonn

Minden komolyabb webfej-lesztési projekt egy adott pon-ton elérkezik ahhoz a pillanat-hoz, hogy bizonyos vizuálistrükköket (pl. animáció, vek-torgrafika) a böngészõ DOMkliens oldali szkriptbõl történõprogramozásával nem, vagycsak igen komoly erõfeszíté-sekkel tudunk megvalósítani.Vegyünk egy példát: egy pro-fesszionális kinézetû analógórát szeretnénk készíteni, amia pontos idõ függvényébenanimálja a kis- és nagymuta-tókat. Tegyük fel ehhez mégazt is, hogy a már jól megszokott JavaScript runtime kör-nyezeten kívül más technológiát nem szeretnénk használ-ni. Vagy mi van ha a designer-ünk olyan kreatív ötletekkeláll elõ, hogy alkalmazzunk valamilyen médiát (hang, vi-deó)? Ekkor el kell gondolkoznunk, hogy pontosan mithasználjuk (Flash, Windows Media ActiveX), amiknek per-sze megvan a maguk elõnye, de valljuk be: ha tisztánJavaScript alapokon akarjuk ezeket használatba venni,nincs könnyû dolgunk!

Itt a jön a képbe a Microsoft jelenleg Windows Presen-tation Foundation/Everywhere kódnéven futó projektje,mely számos, a kliens oldali fejlesztõ produktivitást tá-mogató újdonságot hoz:

• egy új XML alapú grafikus elemeket reprezentáló for-mátum (XAML = XML Application Markup Language)

• tervezõeszközök (Expression család)• egy rendkívül kisméretû böngészõmodul, amely képes

a XAML séma által specifikált vizuális elemek (vektor-grafika, szöveg, hang, videó) megjelenítésére és egyfejlett, úgynevezett tulajdonság animációs rendszer ál-tali mozgatására

• vizuális effektusok: 2D transzformációk, kivágás,áttûnéses maszkok, tollak, ecsetek, színátmenetek stb.

• új, a Windows Media formátukra és MP3-ra épülõ mé-dialejátszó komponens, amely támogatja az oldalbaágyazott zene és videó progresszív és sugárzott(streaming) lejátszását

Maga a WPF/E programozása rendkívül egyszerû. Hasz-nálatához csak annyit kell tennünk, hogy a webolda-lunkba teszünk egy plug-in hivatkozást, majd elkészít-jük – kézzel, vagy az Expression eszközökkel – azta XAML állományt, amely reprezentálja a felületünket.

Ezután már csak annyit kell tennünk, hogy paraméter-ként átadjuk a vezérlõnek a megjelenítendõ interfészURL-jét – opcionálisan be is ágyazhatjuk azt a web-oldalba –, majd megírjuk azokat a JavaScript eseményke-zelõket amelyek az egér és billentyûzet input hatására

mûködésbe lépnek (pl. animációt indítanak el, objektu-mokat transzformálnak).

Példaként álljon itt egy XAML, ami egy szövegdobozt egyperc alatt 90 pixellel jobbra mozgat az idõk végtelenségéig:

<Canvas x:Name="Layer"><Canvas.Triggers><EventTrigger RoutedEvent="Canvas.Loaded"><EventTrigger.Actions><BeginStoryboard><Storyboard

�� Storyboard.TargetName="MyLink"

Storyboard.TargetProperty= �� "(Canvas.Top)" >

<DoubleAnimation AutoReverse="True" �� RepeatBehavior="Forever"

BeginTime="0" �� Duration="0:0:1"

From="0" To="90"></DoubleAnimation>

</Storyboard></BeginStoryboard>

</EventTrigger.Actions>

</EventTrigger></Canvas.Triggers><TextBlock x:Name="MyLink" Canvas.Left="150"

�� Canvas.Top="0"

FontFamily="Verdana" FontSize="18" �� Width="250"

TextWrapping="Wrap">Hello Web Konferencia!

</TextBlock></Canvas>

BBááttoorrffii ZZssoolltt

Több mint nyolc éve a Microsoft rendszermérnöke, jelenleg a.NET keretrendszerre épülõ fejlesztési technológiák szakértõje.Munkája során számos hazai nagyvállalati rendszer – infrastuk-túrák, alkalmazások – elõkészítésében és bevezetésében vett részt.A Microsoft fejlesztõi rendezvényeinek gyakori elõadója, szûkebbszakterülete a következõ generációs prezentációs technológiák(WPF, WPF/E) és fejlesztõeszközök (Visual Studio, Expression).

AA WWPPFF//EE aarrcchhiitteekkttúúrráájjaa

web2007.qxd 3/22/2007 11:34 AM Page 21


WWiinnddoowwss PPrreesseennttaattiioonnFFoouunnddaattiioonn:: aazz OOSS kköövveettkkeezzõõggeenneerráácciióóss pprreezzeennttáácciióóssppllaattffoorrmmjjaa

A WPF a Windows Vista-val közel egyidõben megjelenõ.NET keretrendszer új prezentációs alrendszere, mely szá-mos, a Win32-ben használt grafikus szolgáltatást (GDI+,ActiveX, DirectX, DHTML) egyesít és hoz egy programo-zói szempontból magasabb szintre. A WPF gyakorlatilagegy olyan új, kliens oldali grafikus futtató környezet,amely elsõként használja ki teljes mértékben a modern 3Dgyorsított grafikus kártyákban lévõ képességeket, mind-ezt olyan formában, hogy azok alacsonyszintû programo-zásával kapcsolatos részletekkel a kliens oldali fejlesztõk-nek nem kell foglalkozniuk. Ez egy új irányt jelöl ki a kö-zeljövõ vonatkozásában: bárki szabadon használhat alkal-mazásában vagy webes alkalmazásában olyan lehetõsége-ket, amelyek eddig vagy külön technológia szigeteket (2D,3D, animáció, média, szövegkezelés) képeztek, vagy egy-szerûen nehéz volt õket programozni (lásd DirectX).

Egy WPF-es alkalmazás koncepcionálisan kétféle épí-tõelembõl áll: a felület XML alapú repzentációjából(XAML) és a mögötte lévõ kódból, amely tetszõleges.NET-es nyelvben (C#, VB, C++) íródhat. A megjele-nés és funkcionalitás tudatos szétválasztása, melyeta webes fejlesztésnél már megszoktunk, egy ilyen

rendkívül gazdag grafikus környezet szempontjából isnagyon fontos. Elõször válik lehetõvé az, hogy egyprofesszionális tervezõ, a megfelelõ eszköztámogatás-sal (Expression, Illustrator) ugyanazon fejlesztési pro-jektben részt tudjon venni, munkája eredményéta designer eszközbõl le tudja menteni olyan formá-tumban, amit a fejlesztõ közvetlenül felhasználhat.

Vége tehát annak a korszaknak, amikor a programozóúgy veszi át a design-t, hogy kap egy .JPG-t és elkezditeljes mértékben kód szinten megvalósítani a vizuáliselképzeléseket!

Mindezek melett, a web prezentációs képességeivelösszehasonlítva a WPF az alábbi újdonságokat hozza(nem teljes felsorolás):

• Gazdag vezérlõkészlet (layout panelek, szövemegjele-nítés, nyomógombok, választók stb)

• Fejlett testreszabási lehetõségek (adatelemek, vezérlõkstilizálása)

• Professzionális adatkötés (objektum vagy XML fájl)• Idõalapú tulajdonság animációs rendszer• Vizuális eseménykezelõk (property triggers)• Vektorgrafika (bezier görbék)• Grafikus effektek (transzformáció, maszkok, bitmap

manipuláció)• Fix és adaptív szövegmegjelenítés• 3D alrendszer (világítás, kamera, testek, anyagok)• Windows Media Audio/Video (High Definition)

BBááttoorrffii ZZssoollttTöbb mint nyolc éve a Microsoft rendszermérnöke, jelenleg a .NETkeretrendszerre épülõ fejlesztési technológiák szakértõje. Munkájasorán számos hazai nagyvállalati rendszer – infrastuktúrák, alkal-mazások – elõkészítésében és bevezetésében vett részt. A Microsoftfejlesztõi rendezvényeinek gyakori elõadója, szûkebb szakterülete akövetkezõ generációs prezentációs technológiák (WPF, WPF/E) ésfejlesztõeszközök (Visual Studio, Expression).

WWPPFF aallkkaallmmaazzááss bböönnggéésszzõõbbeenn TTeerrvveezzééss EExxpprreessssiioonn BBlleenndd--bbeenn ...... …… ééss mmeeggnnyyiittvvaa VViissuuaall SSttuuddiioo--bbaann

web2007.qxd 3/22/2007 11:34 AM Page 22

Keretrendszer folyamatok ellenõrzéséhez

A SENSORIA FP6 EU projekt keretében meglévõ akadé-miai és az iparban is használt eszközök összecsatolásávalegy olyan keretrendszer létrehozásában veszünk részt,amely magas szintû modellezõ nyelveken (pl. BPEL,UML) leírt rendszereken képes egyrészt modell-ellenõr-zésre (pl. biztonsági követelmények, teljesítmény, formá-lis helyességellenõrzés), másrészt legenerálja a telepítésikonfiguráció egyes elemeit. A SENSORIA keretein belülfoglalkozunk üzleti folyamatok formális ellenõrzésével is.

Az elektronikus munkafolyamat végrehajtásNapjainkban egyre nagyobb népszerûségnek örvende-nek az elektronikus munkafolyamat végrehajtó motorok.Ennek megfelelõen az utóbbi években az üzleti folyamatleíró nyelvek gyors fejlõdésének lehettünk tanúi. Megje-

lent többek közt a Web Service Flow Language (WSFL) ésa Microsoft féle XLANG. Végül a Business ProcessExecution Language vált általánosan elfogadottá, melytulajdonképp tartalmazza mind a WSFL, mindaz XLANG által nyújtott lehetõségeket.

A BPEL, ahogy a neve is mutatja egy végrehajtható nyelv.Segítségével elemi web szolgáltatás hívások sorrendjét le-het meghatározni, így implementálva egy web szolgáltatásalapú munkafolyamatot. A munkafolyamat megszervezé-sére azok az eszközök állnak rendelkezésünkre, melyeket

más imperatív nyelvek-ben megszokhattunk:szekvencia, szelekció, iterációvalamint a párhuzamosvégrehajtás.

A végrehajtható munka-folyamat általában ko-molyabb számítógépesinfrastruktúrával rendel-kezõ szervezetek üzlet-menetének egyes részeit,esetleg egészét irányítja.Látható, hogy egy meg-felelõen mûködõ mun-kafolyamat nagyon meg-könnyítheti a kooperáci-ót, a munkafolyamat hi-bája pedig nagy károkatokozhat. Ez adott moti-vációt arra, hogy mód-szereket dolgozzunk kiegy munkafolyamat for-mális ellenõrzésére.

A munkafolyamatokformális ellenõrzése

Célul tûztük ki, hogymódszert adjunk BPELnyelven megvalósítottüzleti folyamatok formá-lis verifikációjára. Ehhez

szükség van az ellenõrizendõ munkafolyamat egy mo-delljére, a követelményre, melynek igazságtartalmát el-lenõrizni akarjuk, valamint egy modellellenõrzõ eszköz-re, mely képes a modell állapotterének bejárásával kiérté-kelni, hogy a munkafolyamat modellje megfelel-e a tõlemegkívánt követelménynek.


BBPPEELL nnyyeellvvûû üüzzlleettii ffoollyyaammaattookkmmooddeelllleezzééssee ééss ffoorrmmáálliisseelllleennõõrrzzééssee

FFeejjlleesszzttééss aa SSEENNSSOORRIIAA pprroojjeekkttbbeenn

SSOOAA

web2007.qxd 3/22/2007 11:34 AM Page 23

A munkafolyamat modellje egy tranzíciós rendszer,melynek állapottere tükrözi a vizsgálandó munkafolya-mat vezérlési szerkezetét. A munkafolyamattal szem-ben támasztott követelményt temporális logikai kifeje-zések formájában fogalmazhatjuk meg. A kiértékelésta Symbolic Analysis Laboratory (SAL) segítségével kivi-telezhetjük.

A módszer segítségével a vizsgálandó munkafolyamatéletbevágó tulajdonságairól gyõzõdhetünk meg matema-tikai precizitással, például ellenõrizhetjük egy változó„életútját”, egy hibás adatbevitel lehetséges hatásait vagya folyamat holtpontmentességét.

KKoovvááccss MMááttéé

2006. szeptemberében kezd-tem meg doktoranduszi ta-nulmányaimat a Budapesti Mûszaki és Gazdaságtudo-mányi Egyetem, Méréstech-nika és Információs Rend-szerek Tanszékén. A 2005-bena Villamosmérnöki és informa-tikai kar által rendezett TDKkonferencián elsõ helyezéstszereztem dolgozatommal,melynek címe: Munkafolya-matok szimulációja és formálisanalízise. Konzulenseimmeltöbb publikációt is készítet-tünk a témában, melyeketrangos konferenciákon adtunkelõ. A kutatási területem en-nek megfelelõen munkafolya-

matok magasszintû modellezése, szimulációja, formális verifikáció,követelmény specifikáció és formalizálás.

GGöönncczzyy LLáásszzllóó

Gönczy László mérnök-informatikus, jelenleg a BudapestiMûszaki és Gazdaságtudományi Egyetem Méréstechnika ésInformációs Rendszerek Tanszékén dolgozik nemzetközi kuta-tási projekteken, kutatási témája a szolgáltatás-orientált rend-szerek. Emellett az OptXware Kutatás-Fejlesztési Kft. egyikalapító tagja. Az OptXware a tanszék kutatói által létrehozottvállalkozás, mely IT rendszerek szolgáltatásbiztonságánaknövelésében hasznosítja az elméleti kutatási eredményeket.


MMuunnkkaaffoollyyaammaattookk ffoorrmmáálliiss eelllleennõõrrzzééssee

JJaavvaa BBuussiinneessss IInntteeggrraattiioonn–– aazzaazz sszzoollggáállttaattáássaallaappúú aarrcchhiitteekkttúúrraa JJaavvaa EEEE kköörrnnyyeezzeettbbeenn

SOA – áttekintés

Cikkemben a Java Business Integration szabványról leszszó. Ez a szabvány a manapság gyakran emlegetett SOA,azaz Service Oriented Architecture Java-beli megvalósu-lása. Igaz, hogy a SOA betûszót gyakran emlegetik, nemmindenki ugyanazt érti alatta. Így jogos némi történelmiáttekintéssel kezdeni.

A kihívás az integráció. Különféle korú, technológiájú,heterogén rendszerek összekötése. A nagyon régmúlttóleltekintve (amikor vagy nem volt számítógép, vagy voltnéhány, de senki sem akarta összekötni õket) ez a feladatörök. Ami változik, az a ráfordítható idõ/pénz.

Ma integrációra nagyon kevés erõforrás jut. Egyrészt azért,mert a rendszerek, technológiák nagyon gyorsan változ-nak, fejlõdnek, és elavulnak, újak születnek; másrésztazért, mert az üzlettõl jövõ igények gyorsan változnak.

A legkorábbi megoldás a teljesen egyedi integráció, ha kétrendszert össze kell kötni, valamelyik fejlesztõcsapat kifej-leszti a kommunikációt. Tipikus példák voltak: közös adat-bázistáblák, DB-link; illetve ad-hoc hálózati protokollok.

A második fázis a gyártófüggõ, ún. integration server ter-mékek használata volt. Sok nagy szoftvercégnek voltilyen vagy hasonló nevû terméke. Ezek általában egyközponti magból és adapterekbõl állnak. Az adaptereketáltalában az integrációs termék fejlesztõje adta, és így sokismert terméket össze lehetett kötni. Ha nekem volt mégX termékem is, amelyhez nem kaptam adaptert, akkorbajban voltam, jó esetben írhattam magamnak.

A SOA tekinthetõ a harmadik fázisnak. A fentiek alapjántovábbmenve, azt mondhatjuk, hogy ez egy hasonló ar-chitektúra, viszont nem gyártófüggõ, hanem szabványo-kon alapuló központi maggal. Így adaptert bárki írhat,az adapterfejlesztõi tudás hordozható, nem csak egygyártó szerveréhez hasznos.

Technológiai szemmel nézve a SOA egy architekturálispattern, egy újrahasznosítható tervezési minta. Laza csa-tolást határoz meg az integrálandó rendszerek között,minimális függõséget egymástól (a komponensek szaba-don kicserélhetõk más – ugyanolyan funkciójú progra-mokra). A komponensek egymást csak mint szolgáltatá-sokat veszik igénybe, kérnek valamit, megkapják a vá-laszt, dolgoznak tovább magukban. Sokszor ezt kiegészít-

web2007.qxd 3/22/2007 11:34 AM Page 24

jük még valamilyen vezérlõvel, aki ezt a szép, sok részt-vevõs társalgást vezényli.

Elmélet: szabványok, specifikációkTehát a SOA egyfajta hozzáállás a sok független részbõlálló nagy összetett rendszerek architekturális tervezésé-hez. Ahhoz, hogy a SOA-tudás hordozható, termékektõlfüggetlenül megszerezhetõ érték legyen, a gyakor-latban szabványok is kellenek, ezt az elvet nagyonkonkrét specifikációkkal kell megvalósítani.

Bár szolgáltatásalapú rendszert lehet többféle tech-nológiával megvalósítani (sõt, léteztek és léteznekegyedi megoldások is erre a patternre; mi több,a pár éve divatos MoM – Message OrientedMiddleware megoldások is tekinthetõk SOA-nak),a gyakorlatban a webszolgáltatásokon alapuló rend-szereket hívjuk SOA rendszereknek.

A webszolgáltatások vagy web service-ek használa-tát indokolja, hogy nyelvfüggetlenek, szabványo-kon alapulnak, gyorsan fejleszthetõk. Mindennekalapja a SOAP szabvány, XML üzenetek küldésé-hez, amit többnyire HTTP-n keresztül teszünk.Az igénybe vehetõ szolgáltatásokat WSDL szab-vány szerint írjuk le, és vesszük igénybe. A rész-rendszerek egymást megtalálhatják szinte automa-tikusan is valamely registry (pl. UDDI) szabványszerint.

Java programozóknak szerencsére nem kell a SOAP éstársai alacsony szintjével sokat foglalkozniuk, az XML-ekösszerakása, átküldése, értelmezése egy univerzális, egy-szer elkészítendõ kód feladata. Ilyen kód van minden Ja-va EE alkalmazásszerverben, sõt a Java SE 6 platformnakis része. Ezzel a kóddal a JAX-WS szabványon keresztülbeszélhetünk.

A SOA két fontos elemérõl kell még beszélni. Az egyikelem az ESB, az Enterprise Service Bus, amelyen a kom-munikáció zajlik, a másik pedig az a vezénylõ, amelya komponenseket rábírja, hogy egymás szolgáltatásait egynagy, komponenseken felül álló üzleti elv szerint használ-ják. Ez utóbbi feladatot orchestration-nek nevezzük.

Az, hogy ESB, így magában nem egy specifikáció, sokkalinkább csak egy elv, miszerint legyen egy központi csa-torna, amelyen kommunikálhatnak a résztvevõk. A JavaCommunity Process JSR-208 számú szabványa (Java Busi-ness Integration) viszont konkrét programozói felülete-ket ad ehhez.

A vezénylésre is több szabvány és módszer létezik. A leg-elterjedtebb szerint egy külön komponens feladata a töb-biek vezénylése. Ez egy univerzális komponens, a konk-rét üzleti szabályokat a BPEL nyelven írhatjuk le.Ez a komponens is az ESB-n keresztül kommunikálhat.

Gyakorlat: nyílt forrású SOA-eszközökAki SOA-szakértõ szeretne lenni, annak természetesenérteni kell a cikk elején fejtegetett elveket. Magától értetõ-dõ, hogy meg kell ismernie az imént felsorolt szabványo-kat, a konferencián ezekkel sokat is fogunk foglalkozni.

Igazi tapasztalatot viszont csak próbálgatással, kisérle-tezéssel szerezhetünk. Szerencsére ma mindehhez létez-

nek jó minõségû, nyílt forrású eszközök. Ezeket fogomaz elõadás második részében demonstrálni. A NetBeansfejlesztõeszközzel definiáljuk az ESB-t és a hozzá kap-csolt komponenseket. Elkészítünk egy BPEL programot,mely vezérli ezeket. A kész alkalmazást telepítjük a Glass-fish alkalmazásszerverbe, melyben az OpenESB nevû JBIimplementáció fut.

Hivatkozások

WWeebb sseerrvviiccee sszzaabbvváánnyyookk• http://www.w3.org

• http://www.oasis-open.org

• http://www.ws-i.org

SSppeecciiffiikkáácciióókk• BPEL: http://www-128.ibm.com/developerworks/

�� library/specification/ws-bpel/

• JBI: http://jcp.org/en/jsr/detail?id=208

EEsszzkköözzöökk• http://www.netbeans.org

• https://open-esb.dev.java.net/

• https://glassfish.dev.java.net/

SSiimmoonn GGéézzaa

A Budapesti Mûszaki Egyetemen 1995-ben diplomáztam,ezután néhány évig kutatási projektekben vettem részt, Buda-pesten, Erlangenben és Delftben. 1996-tól a Drótposta Kft ala-pító tagjaként fejlesztettem és irányítottam a DrótPostaGalambelektronikus levelezési rendszer megvalósítását. Az azóta elteltidõben több jelentõs Java és Java EE alapú rendszer fejlesz-tésében, architektúrájának tervezésében vettem részt. Az elmúltnégy évben a fenti feladatok mellett a Sun Microsystemsoktatási, konzultációs partnereként végzem a Sun összes Java,Java EE és Sun Java Enterprise System tanfolyamánakoktatását, konzultációját. Jelenleg a Sun Microsystems 8 hetes„Java Mesterkurzus” keretében képzek fejlesztõket a Java EE1.4, 5.0 (JSF, EJB 3.0, JPA), UML, RUP, tervezési minták, webszolgáltatások, SOA témakörökben.




web2007.qxd 3/22/2007 11:34 AM Page 25

A hatékony alkalmazás fejlesztés alapvetõ követelménye,hogy már a fejlesztés folyamán az alkalmazás gyengébbpontjaira, hibáira, teljesítménybeli keresztmetszeteire fényderülhessen. A helyes fejlesztési metodológia része olyandebugger és profiler rendszer használata, amellyel lehetõ-sége nyílik a fejlesztõnek az alkalmazás teljesítményénekpontos mérésére, a kritikus pontok feltárására – mégaz implementálás, illetve tesztelés idõszakában. A szeman-tikai és szintaktikai jellegû hibák felderítésére egyaránta legtöbbet alkalmazott eszköz a PHP programozók köré-ben az echo(), print_r() és var_dump() függvények. Adotthelyezetben a hiba pontos ismeretében, valamint igen jólkörülhatárolható, zártnak tekinthetõ környezetben ezekaz eszközök valóban gyors megoldást jelenthetnek, de al-kalmazásuk nem helyettesíti a magasabb szintû nyomköve-tõ eszközök ismeretét, szakszerû használatát.

PHP-hez több – nyílt forrású és kereskedelmi – debuggeris elérhetõ. Tulajdonképpen maga a PHP interpreter isnyújt alapvetõ visszajelzési felületet a felmerült hibákról,de természetesen aki ennél precízebb szerszámot óhajt,az vagy elkészíti a saját hibakezelõ (error handler) keret-rendszerét, vagy válogat az elérhetõ, kiforrott eszközökközül. Egy ilyen kész megoldás az Xdebug lehet, amelyelõadásom tárgyát képezi.

Az Xdebug nyílt forrású, BSD licencelésû, általános célú fej-lesztést támogató eszköz. Komoly vétek lenne hibakeresõ,vagy szakterminológiával minõsítve PHP debuggerkéntfelcímkézni – ennél a skatulyánál jóval tovább mutat.Az Xdebug a programkód érintése nélkül, vagy annak mi-nimális módosítása mellett biztosítja az alkalmazás nyom-követését (debug), a programkód folyamatának megfigye-lését (trace), teljesítményének kiértékelését (profiling). Le-hetõséget teremt arra, hogy alkalmazásunk mûködését in-teraktívan kövessük figyelemmel: remote debuggeréhezkülsõ ügyfél eszközzel is csatlakozhatunk; mind a GDB-t,mind pedig a korszerûbb DBGp protokollt támogatja.A projektet a PHP közösség jól ismert alakja, DerickRethans (eZ systems) gondozza.

Az Xdebug elérhetõ Linux, Mac, Windows és kompatibilisplatformokra a PEAR/PECL csatornából, vagy a projekthonlapjáról forráskódként. A már felépített PHP fejlesztõkörnyezetben Zend kiterjesztésként csatolható a webszer-verhez. Támogatja a mod_php és FastCGI illesztõt is, 4.3-as PHP verzió felett mûködik. Fedora/RedHat alatt a hiva-talos tárolóból csomagként telepíthetõ.

(/home/gabor) apt-cache search xdebugphp-pecl-xdebug – PECL package for debugging �� PHP scripts

Jelenleg a hivatalos és nem hivatalos Zend kiterjesztéssek-kel (pl. Zend Optimizer, APC) nem tud együttmûködni –ezen hiányosság pótlása a késõbbiekben várható. A bõvít-mény általános viselkedését a php.ini-ben, ahhoz hozzá-

férési jogosultság hiányában a .htaccess-ben, illetve alkal-mazásunk inicializáló kódjában az ini_set() függvénnyelszabályozhatjuk. A modul jelenlétérõl a phpinfo()-valgyõzõdhetünk meg a legegyszerûbben. Az Xdebug össze-kapcsolható a PHPEclipse, Komodo és további néhányfejlesztõ eszközzel.

A lentebb látható kódblokk egy bõbeszédû példa konfi-guráció, amely betölti az xdebug.so modult, hiba eseténa képernyõre dobja valamennyi helyi, GET-tel és POST-tal érkezõ változó tartalmát, továbbá a 9000-es portonmegnyitja a debuggert a kliensek számára:

zend_extension="/usr/local/php/modules/xdebug.so"

xdebug.collect_params=1xdebug.show_local_vars=1xdebug.dump.GET=*xdebug.dump.POST=*

xdebug.remote_enable=1xdebug.remote_host=localhostxdebug.remote_port=9000xdebug.remote_handler=dbgpxdebug.extended_info=1

Általánosságban az Xdebug véd a verem túlcsordulás és avégtelen iterációk ellen, felülbírálja a PHP hibakijelzésétkönnyen áttekinthetõ, a futás környezeti változóit is tartal-mazó üzenettel, felületet biztosít az egyes kódrészletek erõ-forrás igényeinek monitorozására (xdebug_time_index(),xdebug_memory_usage() stb.), támogatja a cachegrind állo-mány formátumot, amelyet ismerõ profiling alkalmazással(KCacheGrind, WinCacheGrind) még áthatóbb vizsgálatalá vonhatjuk a programkódunkat. Beépített trace mecha-nizmussal lépésrõl-lépésre figyelemmel kísérhetõ alkalma-zásunk élete; a kimeneti fájlokban rögzítésre kerül vala-menyi függvényhívás, azok memória és idõ költsége is.

Az Xdebug jellemzése során nem tértem ki a projektegyes verzióbeli eltéréseire. Alapvetõen a jelenleg mégstabil 1-es szériát csak komoly indokkal célszerû választa-ni, a fejlesztés hansúlya már egy ideje a 2-es, már RC fá-zisban lévõ kiadáson van. Ezen széria újdonsága a DBGpprotokoll támogatása, de szintén a 2-es verzióban szakadel végleg Rethans reményei szerint az Xdebug PHP-sgyökereitõl, így lehetõvé válhat majd, hogy Perl, Pythonvagy akár egyéb más nyelvû környezetben is használhatókomponens lehessen.

További részletek• http://xdebug.org/

• http://kcachegrind.sourceforge.net/

TTöörröökk GGáábboorr

Mûszaki informatikus hallgató, jelenleg a Webma InternationalWeb Marketingnél web alapú alkalmazás fejlesztõ. Nem hisz asvájci bicska eszközökben, így PHP mellett Python, C és shellszkript nyelveket is használ munkája folyamán. Rajong a nyíltforrású megoldásokért.


FFeejjlleesszzttééss ttáámmooggaattááss XXddeebbuuggggaall

SSzzeerrvveerr oollddaall

web2007.qxd 3/22/2007 11:34 AM Page 26

Az EJB 3.0 specifikáció Java Persistence API része – a ko-rábbi EJB entitás bean-ek helyett – egyszerû Java objek-tumok (POJO – Plain Old Java Objects) használatát de-finiálja, mint az objektum/relációs mapping Java oldala,egységesítve ezzel az adatok tárolásának módját a JavaEE alkalmazásszerverben és az önálló Java SE alkalma-zásokban. A szabvány és a megjelenése óta történõ vál-tozások azt ígérik, hogy az open-source világ és a kü-lönbözõ gyártók implementációikkal felsorakoznak mö-götte és a jelenleg létezõ sok különbözõ megoldás (JDO,Toplink, Hibernate, …) egy egységes API-n keresztülválik elérhetõvé.

Ebben az elõadásban szeretném felcsillantani enneka technológiának az érdekes és szép pontjait, bemutatniaz alapvetõ ötleteket, demonstrálni Netbeans IDE, Glass-fish alkalmazásszerver, Toplink Entitás manager segítsé-gével a technológiát.

A Java Persistence specifikáció egy olyan Java API speci-fikáció amely meghatározza a perzisztencia rendszerekkezelését és az objektum/relációs megfeleltetés problé-májának megoldását mind Java EE, mind Java SE kör-nyezetben. A specifikációs munka nem titkolt technoló-giai célja a Java fejlesztõk kezébe adni egy olyan objek-tum/relációs megfeleltetési lehetõséget, ahol a fejlesztõkaz objektum-orientált domain modellen végeznek mû-veleteket és ez változtatja meg a relációs adatokat. An-nak a kódnak a megírása, amely egy objektum-orientáltdomain modellbõl elõállítja a relációs modellt, nagyonidõigényes lehet.

Az objetum/relációs megfeleltetést (ORM) kezelõ prog-ramok megpróbálják ezt a problémát lehetõség szerintkevés egyedi fejlesztéssel vagy teljesen anélkül megol-dani. Gyakran csak némi konfigurációs információravan szükség, melyet a kódban elhelyezett annotáció,esetleg XML konfigurációs leíró specifikál az ORM rend-szer számára.

A technológiát az teszi még inkább elérhetõvé, hogyminden Java EE alkalmazásszervernek kötelezõen kellnyújtania a Java Persistence API egy implementációját,de maga a JPA az alkalmazás szerver nélkül, akárstandalone alkalmazásban is használható. Az elsõ eset-ben „Container-Managed Persistence”-rõl beszélünk,míg a második esetet „Application-Managed Persis-tence”-nek nevezzük.

EJB 3.0 követelményekA JPA specifikáció, amely a JSR-220-as EJB 3.0 specifiká-ció része, azt tûzte ki célul, hogy a perzisztencia modelltegyszerûsítse, egy könnyû súlyú, POJO-kra építõ mo-dellt adjon, melyet mind a fejlesztés, mind a telepítés,mind a futás idejû tulajdonságai, teljesítménye vonzóvátesz. Cél volt, hogy a konténeren kívül is mûködjön, ami

a standalone felhasználás mellett a könnyû tesztelhetõ-séget is magában hordozza.

Ennek az új modellnek támogatnia kellett az öröklés ésa polimorfikusság objektum-orientált fogalmak lekép-zését is relációs modellre, valamint a lekérdezhetõségrugalmas és gazdag lehetõségét. Ezen tulajdonságok


JJaavvaa PPeerrssiisstteennccee AAPPII–– aazzaazz sszzaabbvváánnyyooss OObbeejjttuumm--RReelláácciióóss mmaappppiinngg JJaavvaa ééss JJaavvaa EEEE kköörrnnyyeezzeettbbeenn

EEnnttiittááss áállllaappoottookk

web2007.qxd 3/22/2007 11:34 AM Page 27


alapján a JPA gyakorlatilag a Java programozók szá-mára a „nagy” specifikációvá fejlõdött, melyetstandalone, webes és EJB-s alkalmazásokban is jóllehet használni.

Entitások és az Entitás Manager API

Az Entitások egyszerû Java objektumok, melyeketa new operátorral hozunk létre, és nem kívánják sem-milyen speciális interface implementálását. A konté-neren kívül is használhatóak, a detached állapot se-gítségével szerializált formában akár át is adhatóakJVM-ek között, majd újra visszakapcsolhatóaka perzisztens tárolóban lévõ párjukhoz (merge). Köte-lezõ, hogy elsõdleges kulccsal rendelkezzenek, de le-hetnek absztrakt osztályok is, amelyek a perzisztensmezõk mellett nem perzisztens, azaz tranziens mezõ-ket is tartalmazhatnak.

A perzisztens állapot primitív és wrapper, szeria-lizálható, enum, byte[], char[], String osztályokat tar-talmazhat, de összetett (@Embedded) osztályok ishasználhatóak. EAGER és LAZY betöltési mód is tá-mogatott, ahol az EAGER az alapértelmezett az egy-több és a több-több kapcsolatok esetét kivéve.

Az Entity Manager feladata az Entitások életciklu-sának és perzisztenciájának kezelése az ábrán lát-ható módon. Az õ feladata továbbá a keresõ mûve-letek (find, getReference), a Query objektumok(createNamedQuery, createQuery, createNative-

Query) és más a perzisztenciát kezelõ mûveletek(flush, clear, lock, …) végrehajtása.

Relációk

Az enitások támogatják az 1–1 (@OneToOne), 1–több(@OneToMany), több–1 (@ManyToOne), több–több(@ManyToMany) relációk leképzését, amelyheza Collection, Set, List, Map Java típusok használható-ak fel. A kétirányú kapcsolatokat az alkalmazásnakkell kezelnie. Ezen kapcsolatoknak van tulajdonos ésinverz oldala, ahol a tulajdonos oldal feleltethetõ megaz idegen kulcsnak, az inverz oldalon pedig meg kelljelölni a tulajdonos oldalt a mappedBy kifejezéssel.

Lekérdezések

A Java Persistence Query Language az EJB QLnyelv igen jelentõs bõvítése. Segítségével az entitá-sok hatékonyan kérdezhetõek le. Az új szolgáltatá-sok: projekciós lista, explicit JOIN-ok (inner, outer,fetch), al-lekérdezések, GROUP BY, HAVING, EXISTS,ALL, SOME/ANY, UPDATE, DELETE és számos új függ-vény. Lehetõség van statikus lekérdezések definiá-lására mind annotációk, mind az XML leírók segít-ségével, de adott a lehetõség ezek dinamikus össze-állítására is.

A JPA megengedi, hogy akár natív SQL lekérdezé-seket is végre lehessen hajtani. A query objektumokmetódusokat biztosítanak a maximális rekordszám,a lapozás és a flush mód beállítására is.

Objektum/relációs megfeleltetés

Cél a Javás domain modell könnyû megfeleltethetõ-sége a relációs modellhez, de cél az is, hogy a valósélet bonyolult relációs szerkezeteit is meg lehessen fe-leltetni Java osztályoknak. Ezt számos metaadat meg-adásával nagyon finoman lehet szabályozni.

Az öröklés is támogatott a domain modellben. Lehetmás entitás osztályból, nem entitás osztályból és„mapped superclass”-ból származtatni. Támogatottaz egy tábla /öröklési hierarchia, join-nal összekap-csolt leszármaztatott osztály és külön tábla mindenosztályhoz stratégia is.

Összefoglaló

A JPA legfontosabb tulajdonságai tehát a következõk:az entitások egyszerû Java osztályok, az Entity Mana-ger API támogatja mind a „Container-Managed

// @Entity egy annotáció

// Entitássá annotálja az Employee POJO osztályt

// lehetõség van XML leíróban való megadására is

@Entity

public class Employee {

// Persistent/transient fields

@Id private Long id;

// Property accessor methods

// Persistence logic methods

}

@Entity public class Department {

@Id protected Integer id;

@OneToMany(mappedBy="dept")

protected Set<Employee> members = new HashSet();

... }

@Entity public class Project {

@Id protected Integer id;

@ManyToMany(mappedBy="projects")

protected Set<Employee> emps = new HashSet();

... }

@PersistenceContext EntityManager em;

...

public List findByZipcode(String personType,

�� int zip) {

return em.createQuery( "SELECT p FROM "

�� + personType + " p WHERE p.address.zip

�� = :zipcode").setParameter("zipcode",

�� zip).setMaxResults(20)

�� .getResultList();

}

...

@Entity public class Employee {

@Id @GeneratedValue protected Integer id;

@ManyToOne protected Department dept;

@ManyToMany Set<Projects> projects

�� = new HashSet();

... }

web2007.qxd 3/22/2007 11:34 AM Page 28

Az elmúlt évek során ugrásszerûen nõtt a magyar web-oldalak száma, és ez a tendencia örvendetesen sokmunkát adott azok létrehozóinak is. Ugyanakkor nagyfelelõsséget is, hiszen mára a weboldal részévé vált a cé-gek, intézmények arculatának, és annak esetlegeskompromittálódása a tulajdonosra is igen kínos hatás-sal lehet.

Mindennapi munkája során a webfejlesztõ újabb ésújabb szerverekkel kerül kapcsolatba, ahol oldalakat te-lepít, módosít, tart karban, és ezek mindegyikéhez kü-lön hozzáférést kap. Ez leggyakrabban egy felhasználó-név és jelszó párost jelent, amit ki-ki vérmérséklete ésparanoiája függvényében többé, vagy kevésbé biztonsá-gosan tárol. Egy idõ után a legjobbak sem képesekugyanis az összeset fejben tartani.

Miért is élvez a mai napig szinte teljes kizárólagosságotez az azonosítási technika, hiszen már jó pár éve létez-nek e célra biztonságosabb megoldások? Tapasztalataimszerint a rendszergazdák és webfejlesztõk nem ismerik,vagy túl bonyolultnak/drágának tartják az alternatívmegoldásokat.

Magáról az SSL protokollról is sajnos sokan csak annyittudnak, hogy a webszerver és a kliens közötti kapcso-lat titkosítására szolgál, esetleg még azt, hogy ahhoz,hogy a böngészõ ne dobáljon fel figyelmeztetõ üzene-teket, tanúsítványt kell vásárolni egy erre szakosodottcégtõl.

Azonban, ha mélyrehatóbban megismerkedünk ezzela protokollal és a tanúsítványok rendszerével, rájö-

vünk, hogy a korábban gondoltnál jóval több lehetõsé-get rejt.

Az SSL protokoll két fõ feladatot lát el: titkosítást és ta-núsítást. A titkosítás jelentésével mindannyian tisztá-ban vagyunk, a tanúsítás viszont már ködösebb foga-lom. Pedig nem jelent mást, mint hogy a kommunikáci-óban részt vevõ egyik, vagy mindkét fél ellenõriznitudja, hogy a túloldalon lévõ megegyezik-e azzal, aki-vel beszélni szeretne.

Az SSL aszimmetrikus, kliens-szerver alapú protokoll,mely megköveteli a szerver azonosítását, míg a kliensszámára opcionális önmaga azonosítása.

Gyakori feladat, hogy egy elkészült portál adminisztrá-ciós felületét kell biztonságosan elérhetõvé tenni.Ilyenkor általában az alkalmazásban implementáljuka felhasználók azonosítását és a jogosultságok ellenõr-zését. Mivel azonban a HTTP nyilvános, lehallgathatóprotokoll, ezért az egész adminisztrációs felületetHTTPS csatornára rakjuk, ami nem más, mint egy szab-vány SSL csatornán keresztül közvetített HTTP kap-csolat. Ehhez azonban létre kell hoznunk egy tanúsít-ványt a webszerver számára, és ha ezt nem valamelytanúsítvány szolgáltatótól vásároljuk, akkor a böngé-szõ a csatlakozás során figyelmeztetésekkel fog bom-bázni minket.

Ezen hibaüzenetek kiiktatása pedig nem túl bonyolultfeladat. Az SSL által is használt X.509 szabványnakmegfelelõ tanúsítványok két digitális aláírásból állnak:a tanúsított és a hitelesítõ aláírásából.


SS mmiinntt sseeccuurreeHHoozzzzááfféérréésseekk kkeezzeellééssee bbiizzttoonnssáággoossaann ééss kkéénnyyeellmmeesseenn

Persistence”, mind az „Application-Managed Persistence”lehetõségét, azaz Java EE konténerben, de azon kívül ishasználható. Standardizált O/R megfeleltetést biztosíta teljes Java platformon és nyújtja a Java PersistenceQuery Language szolgáltatásait statikus és dinamikus le-kérdezések összeállításához is.

Ezek alapján bízom abban, hogy a fejlesztõi közösség ér-deklõdését és tetszését felkeltettem ez iránt a technoló-gia iránt és a jövõben az adatbázis kezelés végre elnyeriméltó helyét a Java világban.

MMoollnnáárr IIssttvváánn

A Budapesti Mûszaki Egyetem mérnök-informatikus szakának1995-ös vörös diplomás elvégzése és az MIT, Boston, USAegyetemen végzett kutatási projekt után a Drótposta Kft alapító

tagjaként fejlesztettem és irányítottam a DrótPostaGalambelektronikus levelezési rendszer megvalósítását. Az azóta elteltidõben több jelentõs Java és Java EE alapú rendszerfejlesztésében, architektúrájának tervezésében vettem részt.Munkám része, hogy projektek mentoraként, a Java technológia„evangelistájaként” elõsegítsem a rendszert bevezetõ fejlesztõicsoportokban a Java EE komponenseinek helyes használatát. Azelmúlt négy évben – a fenti feladatok mellett – a SunMicrosystems oktatási, konzultációs partnereként végzema Sun teljes Java, Java EE és Sun Java Enterprise Systemkomponenseinek oktatását, konzultációját. Jelenleg a SunMicrosystems JavaMaster oktatása keretében képzek fejlesztõketa Java EE 1.4, 5.0 (JSF, EJB 3.0, JPA), UML, RUP, tervezésiminták, web szolgáltatások, SOA témakörökben.



web2007.qxd 3/22/2007 11:34 AM Page 29

A kliens rendelkezik azon hitelesítõk aláírásainak pub-likus kulcsával, akikben megbízhat, és ha általuk aláírt ta-núsítvánnyal találkozik, akkor azt figyelmeztetés nélkülelfogadja. Tehát annyit kell csak tennünk, hogy a szerve-rünkre telepített tanúsítvány aláírójának tanúsítványáttelepítjük az általunk használt kliens gépekre, és a figyel-meztetés azonnal meg fog szûnni. Ezt egy admi-nisztrációs felület esetén könnyen megtehetjük, tekintet-tel a felhasználók körének ismeretére.

Gyakori gond, hogy a példánkban említett portált töb-ben, több helyrõl is el szeretnék érni, esetleg dinamikusIP címekrõl, ami miatt nem tudjuk a hozzáféréseket IPcím alapján korlátozni.

A teljes internet felé nyitott felület azonban bármikortámadásnak lehet kitéve, még akkor is, ha azt SSL felü-leten keresztül érjük el. Ilyen esetekben azonban hatha-tósan csökkenthetjük a támadási felületünket, ha beve-zetjük a kliens oldali tanúsítványok használatát.

Ilyenkor a kapcsolódó kliensnek is be kell mutatnia egytanúsítványt, amit a szerver ellenõriz, hogy annak kiál-lítója szerepel-e a számára megbízható felek listájában.Ha nem, akkor már a HTTP kapcsolat sem jöhet létre.

Mindez a szolgáltatás évek óta megbújik például a köz-kedvelt Apache szerverben, csak engedélyezni kell, éselhelyezni az elfogadott hitelesítõk listáját.

A módszer elõnye, hogy jóval kevésbé függünk a fel-használóink által választott (gyakran gyenge) jelszavak-tól, a tanúsítvánnyal történõ azonosítás nem lehallgat-ható, és kompromittálódás esetén egy-egy tanúsítványkönnyen letiltható.

Az X.509-es tanúsítványok ráadásul minden esetbentartalmaznak egy lejárati dátumot, ami után azok hasz-nálhatatlanná válnak, így nem kell attól tartanunk,hogy egy valamikori, ideiglenesen hozzáférést szerzettfelhasználó belépési azonosítóival fognak visszaélni.

Az Apache-on keresztül használt szerver oldali eszközök-bõl (CGI, PHP) lekérdezhetõek a kliens tanúsítványánakadatai, így például nem szükséges a felhasználó azonosí-tóját bekérnünk, akár egyenesen be is engedhetjüka rendszerbe, vagy használhatjuk a jelszó bekérésselegyütt, így két független csatornán keresztül gondoskod-hatunk a kliens azonosításáról.

Hasonló régóta létezõ, mégis a többség számára eddigismeretlen lehetõségeket tartalmaz az SSH protokoll,mely a UNIX/Linux világ mára egyeduralkodóvá válttávoli elérést biztosító alkalmazása.

Vajon hányan vannak tisztában az SSH-agent fogalmá-val, pedig az összes elterjedt SSH alkalmazás rendelke-zik ilyen komponenssel?

Az elv lényegében megegyezik az SSL protokollnálhasznált kliens oldali tanúsítványokkal, de itt a teljesX.509-es tanúsítvány helyett csak az RSA vagy DSAkulcspárokat cseréljük ki.

Gyakori eset napjainkban, hogy a webfejlesztõnek egyúj gépen kell oldalakat elhelyeznie. Ilyenkor a gép

rendszergazdája általában elküldi a fejlesztõnek a hoz-záféréshez szükséges belépési azonosítót és jelszót,jobb esetben személyesen, telefonon, vagy sms-ben,rosszabb esetben csak egyszerûen e-mailben.

A kulcspárok segítségével azonban megfordul ez azirány: ilyenkor a fejlesztõ küldi el a saját publikus kul-csát a rendszergazdának, aki ezt a kiszolgálón elhelyez-ve biztosítja a hozzáférést a kiszolgálóhoz. A lényegeskülönbség az, hogy a publikus kulcs a jelszóval ellentét-ben nem érzékeny információ, nem kockáztatunk sem-mit, ha azt esetleg valaki megszerezné.

Persze mindez csak akkor jelent védelmet, ha a titkoskulcsainkat jelszóval védjük. Ilyenkor viszont már úgytûnik, nem nyertünk semmit, hiszen a fárasztó jelszó-gépelgetés megmarad.

Erre nyújt megoldást az SSH-agent, amely egy olyan al-kalmazás, amibe elhelyezhetjük a titkos kulcsunkat, éselegendõ csak egyszer megadni az ahhoz tartozó jel-szót, amíg az agentet ki nem kapcsoljuk, az SSH csatla-kozások során ez fogja a titkos kulcsot átadni, így nemkell a jelszóval többet bíbelõdni.

Az ajánlott napi rutin a következõ: reggel, a munka kez-detén egyszer megadjuk a kulcsot és a jelszót az agent-nek, és a nap végi hazamenetelig nem kell vele többetfoglalkozni, a szervereket azonnal, jelszógépelgetés nél-kül tudjuk elérni.

Innen pedig már csak egy lépés választ el minketa hardvertokenek megismerésétõl. Ezek olyan eszkö-zök, melyek alkalmasak a titkos kulcs elõállítására ésa kliens oldali tanúsítások elvégzésére, miközben a tit-kos kulcsot soha nem teszik elérhetõvé, még annak tu-lajdonosa számára sem, így a titkos kulcs ellopásátólsem kell tartanunk.

Ezután már nincs más hátra, mint hogy letiltsuk szerve-reinken a jelszóval történõ authentikálást, és búcsútmondjunk a korábbi hatalmas jelszógyûjteményeinknek.

NNaaggyy AAttttiillaa GGáábboorr

Mérnök-informatikusként 2003-ban végzett a Budapesti Mû-szaki és Gazdaságtudományi Egyetemen. Az internet és aworld wide web világával valamikor 1995-ben, a PHP-vel1999-ben ismerkedett meg. Egyetemi évei alatt már többközismert magyar weboldal tervezõje és fejlesztõje volt. Jelenlega Wildom Kft PHP csoportjának vezetõ fejlesztõjeként dolgozik.A Linux világ elkötelezett rajongója, komoly gyakorlatotszerzett a nagy forgalmú, Linux alapú rendszerek tervezésébenés megépítésében is.


web2007.qxd 3/22/2007 11:34 AM Page 30

A W3C Magyar Iroda a Web Konferencia keretébenidén elindította a W3C-szekciót, mely témájábanszorosan kötõdik a World Wide Web Consortiumtechnológiáihoz.

A szekció célja az, hogy megismertesse az érdeklõdõketa W3C legújabb technológiáival és aktív fejlesztési terüle-teivel, valamint, hogy lehetõséget biztosítson a magyarszakembereknek, hogy a témában szerzett értékes ta-pasztalataikat és tudásukat megoszthassák.

Idén egy kiemelt elõadás keretében a W3C BiztonságiFejlesztési Területének (W3C Security Activity) vezetõje,Thomas Roessler, tart elõadást „What do they think theyare doing? When Usability and Security meet on theWeb” címmel.

Reméljük, a Web Konferenciák sorában a késõbbiekben islegalább ilyen szoros lesz a kapcsolat a W3C Magyar Iro-dával. A szekció létrejöttéhez idén a CasaGroup(http://www.casagroup.hu/) nyújtott támogatást.


WW33CC--sszzeekkcciióó

AA WW33CC ééss aa MMoobbiillwweebb

Napjainkban egyre jobban kezd terjedni a mobil készü-lékekrõl történõ webes böngészés. A ma kapható mobil-telefonok és kézi számítógépek döntõ többsége képesvalahogyan az internetre kapcsolódni, és egyre többfelhasználó fedezi fel a mobil böngészésben rejlõ elõ-nyöket. Ennek ellenére még sok a kompatibilitási, meg-jelenítési és kezelhetõségi probléma, mert a legtöbb ol-dal nem úgy készült, hogy figyelembe vették volnaa mobil készülékeket is, mint lehetséges megjelenítõket.

A W3C-nek napjainkra már több mint 80 Web-szabványa(ajánlása) van, melyek közül számos kapcsolódik a mo-bil webezéshez, ezeket a fejlesztéseket a Mobil Web Ini-tiative kezdeményezés (MWI: http://www.w3.org/Mobile/) keretében fogták össze. Ennek a kezdeményezésnek a 19 fõ támogatója között olyan nagy cégek található-ak, mint: Ericsson, France Telecom, HP, Nokia, NTTDoCoMo, Vodafone Group Services Limited, Opera Software.

web2007.qxd 3/22/2007 11:34 AM Page 31

A trendeket jól mutatja, hogy mára már a mobil adatfor-galom legnagyobb részét a böngészés teszi ki, a 3G-s fel-használók körében ez az arány több mint 60%. A BBC-honlapjáról közel 250 millió lapot töltenek le napontamobilos böngészõvel. A felhasználók jelentõs részéneka készüléke képes a mobil webezésre, és ugyan a legtöb-ben ezt a funkciót még nem használják, de az aktívwebezõk száma évrõl évre nõ.

Az MWI célközönségébe tartoznak a webfejlesztõk ésa tartalomszolgáltatók is, az egyszemélyes kis vállalko-zástól kezdve egészen a legnagyobb cégekig. A W3Cajánlásai nekik nyújtanak segítséget a honlapjuk kiala-kításában, úgy, hogy az azon elérhetõ tartalmakat mobilkészülékekrõl is el lehessen érni.

A MobilOK munkaterv kétmegfelelõségi szintet jelöl meg(http://www.w3.org/TR/mobileOK/),melyeknek teljesítése esetén a hon-lap mobilos megjelenítésre alkal-masnak minõsíthetõ (megkaphatjaa MobilOK Emblémát).

Az elsõ szinten (Level-1) olyanegyszerûen teljesíthetõ feltételekvannak, amelyek algoritmikusanis ellenõrizhetõek, ezzel lehetõvéválik az oldalak robotok általi mi-nõsítése. A második szinten(Level-2) lévõ feltételek teljesíté-sét már kézzel lehet csak ellen-õrizni, és még szigorúbb feltétele-ket szab a jobb kompatibilitás ér-dekében.

Már ma is találkozhatunk hûtõ-szekrénybe, falba, gépkocsibaépített böngészõkkel, és a jövõ-ben várhatóan ez a trend folyta-tódni fog, és egyre több készülékrendelkezik majd beépített webeléréssel, melyek esetén lényegeslesz a megfelelõ tartalom biztosí-tása, és annak a minõségellenõr-zése.

A Mobilweb fejlõdése sok hason-lóságot mutat a Web fejlõdésével,és a problémák jelentõs része ha-sonló, mint a Web esetében:

Web 1996. Mobilweb 2006.Nagyon Lassú Nagyon LassúInteroperabilitás hiánya Interoperabilitás hiányaGyermekek védelme Gyermekek védelmeNem elérhetõ Nem elérhetõ (nem akadálymentes) (nem akadálymentes)

Ugyanakkor sok szempontból egyszerûbb a helyzet, mintakkor:

Web 1996. Mobilweb 2006.Kevés felhasználó Sok potenciális felhasználóTartalom hiánya Sok potenciális tartalom és

fejlesztõNincs ipar mögötte Hatalmas ipar

PPaattaakkii MMááttéé

Négy éve az MTA SZTAKI Elosztott Rendszerek Osztályándolgozik. A webes szabványokkal foglalkozó nemzetközi szer-vezet, a W3C egyetlen közép európai irodája is itt mûködik(W3C Magyar Iroda), melynek két éve koordinátora. A DSD sokhazai és nemzetközi projekt tagja, webes rendszerekkel fog-lalkozik. Úttörõ szerepet játszott a magyar Web kialakításában,az elsõ intézményi honlap is a nevéhez fûzõdik. Több ingyenesszolgáltatást is biztosít a magyar netezõknek, olyanokat mintpéldául a KOPI Plágiumkeresõ Portál, vagy a közkedveltSZTAKI Szótár.


AAzz aakkttíívv wweebbeezzõõkk sszzáámmaa rroohhaammoossaann nnõõ

web2007.qxd 3/22/2007 11:34 AM Page 32

A logikai tankönyvekben igen gyakran hivatkoznak ro-konsági fogalmakra (tipikus feladatként szokták adni azanyai nagyapa, a nagybácsi, az anyós stb. fogalmak logikaileírását). Az antropológusok már több, mint egy évszázadasokat írtak és írnak arról, hogy a különbözõ törzsek, népekés nyelvek rokonsági és házassági fogalmai mennyire el-térnek egymástól. Az is jól ismert tény, hogy a különbözõnyelveken olykor egészen eltérõ dimenziók mentén ragad-ják meg ezeket a fogalmakat. Ennek kapcsán gyakran hi-vatkoznak a magyar nyelvre, amely bizonyos esetekbenaz érintettek korkülönbsége szerint különböztet megegyes rokonsági fogalmakat: az angol brother/fiútestvéregyetlen terminusával szemben nálunk elõfordul a fiata-labb és öregebb fivér, azaz a báty és az öcs fogalma is(ugyanez igaz a nõvér, illetve a húg és néne eseteire is).Az viszont kevéssé ismert és talán meglepõ, hogy a rokon-sági fogalmak univerzumát durván 350 fogalommal lehetcsak leírni. Pontosabban: legalább ennyi – nyelvfüggetlen –fogalomra van szükségünk, ha minden, az általunk ismertés feldogozott nyelvben elõforduló rokonsági terminus-hoz, szóhoz önálló fogalmi entitást akarunk rendelni, va-gyis egy olyan rokonsági ontológiát akarunk felépíteni,amely a vizsgálatba vont nyelvek bármelyikén megjelenõbármely rokonsági terminus tartalmát meg akarja jeleníte-ni az ontológia fogalmi szintjén.

Ez a rokonsági ontológia elkészült, és az elõadásban en-nek néhány érdekes részletét, illetve az ontológiaépítésbelsõ logikáját, szintaxisát mutatja be. Ha legalább egynyelven olyan terminus jelent meg, amelynek nem voltpontos megfelelõje a rokonsági ontológiánkban, akkorannak új fogalmat kreáltunk. A fogalmak legnagyobb ré-szét elsõrendû nyelven le lehetett írni, de persze akadtnéhány kivétel is.

Az ontológiaalkalmazás egyik hasznát szépen be lehetmutatni a rokonsági fogalmak ontológiájára támaszkod-va, amikor is egy formális logikai nyelven leírt fogalom-rendszert arra lehet használni, hogy egyfajta viszonyítási,„fordítási” alapként szolgáljon a különbözõ természetesnyelvek között. Egy ilyen ontológia segíthet rámutatnia nyelvek eltérõ fogalomképzési gyakorlatára, illetveaz ebbõl fakadó „értelmezési, fordítási nehézségekre” is,ami már messze túlmutat a konrét ismeretterület specifi-kumán (és az egyik legfontosabb ontológiai probléma-ként definiálható). A nyelvek közötti eltéréseket a szerb-horvát és a kínai mandarin nyelv segítségével szemléltet-hetjük a legjobban: a szerb-horvát terminológiára húzha-tó gráfnak a legnagyobb az átmérõje (15 generációt átíve-lõ terminológiája van), míg a mandarin nyelv univerzu-ma a legsûrûbb a vizsgált természetes nyelvek közül (leg-alább 150 terminust használnak). A rokonsági ontológiasegítségével azt is tudjuk szemléltetni, hogy miként lehetkövetkeztetési feladatokra használni egy ilyen rendszert.

Tanulságos lehet az a részelemzés is, amely azt mutatja be,hogy milyen alapfogalmakra, fogalmi primitívekre támasz-

kodva lehet felépíteni a rokonsági fogalmak univerzumát,melynek során kiderülhet, hogy a leggyakrabban használtfogalmakhoz elegendõ csupán négy alapfogalmat axióma-ként felvenni, ám akadnak olyan fogalmak is, melyekhezszükség van idõkezelésre (tehát valamilyen temporális logi-kára) vagy modális logika alkalmazására. Nagyon sok ro-konsági fogalom definiálásához elegendõ a „gyereke” (vagya „szülõje”) reláció, a „nõ” (vagy „férfi”) tulajdonság ésaz „idõsebb” reláció, amelyek biológiai fogalmak (és az ún.biológiai család fogalmai felépíthetõk velük). Ezek melléazonban fel kell még venni legalább egy társadalmi fogal-mat is, hogy a házasság intézményéhez kapcsolódó rokon-sági fogalmakat is kezelni tudjuk (vagy másként: a társadal-mi családhoz köthetõ fogalmakat is formalizálhassuk).Ha a „házastársa” relációt primitív fogalomként definiáljuk,akkor a rokonsági fogalmak legalább 90 százalékát mármeghatározhatjuk, de a maradék tíz százaléknyi fogalom-hoz egyre több ontológiai elkötelezettség szükséges (ezena gondolati íven látványosan szemléltethetjük az ontológiaielkötelezettség Quine-i kategóriáját is). Tanulságos lehetszembesülni azzal, hogy milyen pontokon, milyen társadal-mi tartalmak mentén használjuk ezeket a fogalmakat, ésezek mennyire könnyen változhatnak társadalomról, társa-dalomra, kultúráról kultúrára. A példa kedvéért: a logikaformalizmus használata segíthet megérteni, hogy a házas-társa fogalom terjedelmébe beletartozik-e, beletartozhat-ea meleg házasságban elõ, azonos nemû párok kapcsolata.

Az elõadás végén kitérünk arra is, hogy milyen mérték-ben és miként lehet a Szemantikus Web programjáhozkapcsolódó OWL-nyelven kifejezni a szóbanforgó fogal-mi rendszert, és milyen részterületeken nem alkalmasaz OWL nyelv a tudásunk reprezentálására, illetve meg-mutatjuk röviden azt is, hogy a rokonsági ontológia mi-lyen pontokon és mit hasznosít a Magyar Egységes Onto-lógia (MEO) projekt eredményeibõl.

SSzzaakkaaddáátt IIssttvváánn

Szakadát István elõbb matematikus mérnökként végzett a Mû-egyetemen 1982-ben, majd szociológus diplomát szerzett az ELTEBölcsészkarán 1985-ben. 1987 óta a BME Szociológia Tanszékéndolgozik, de a tudományos és oktatói feladatai mellett más irányútevékenységet is folytatott. 1993-ban Nyírõ Andrással együttmegcsinálta az elsõ magyarországi multimédia CD-ROM-ot,amit még 15 másik követett az elkövetkezõ években (köztük azABCD negyedéves CD-ROM-os periodika), majd 1997 és 2004között a Matáv internetes fejlesztéseiben, vállalkozásaiban vettrészt különbözõ szerepekben. 2002-tõl az egyik vezetõje lett aMatáv és a Mûegyetem által közösen alapított Média Oktatási ésKutató Központnak (MOKK). A digitális kultúra hazai építésénekgyakorlati feladatai mellett mindvégig foglalkozott az új hálózatimédia sajátosságainak elméleti kutatásával is, melynek eredmé-nyeként megjelent egy könyve errõl a témáról „Egyben az egész”címmel. Az új média hatásainak vizsgálata mellett foglalkozik méga számítógépek szövegértelmezési képességeivel kapcsolatosszemantikai, ontológiai problémákkal.


AA rrookkoonnssáággii ffooggaallmmaakkoonnttoollóóggiiáájjaa

web2007.qxd 3/22/2007 11:34 AM Page 33

A szemantikus világháló (Semantic Web, http://web.conf.hu/�� 2006/program/i/szemantikusweb) a számítástudomány egyúj kutatási-fejlesztési területe, amelynek célja, hogy a világhálóntalálható temérdek információ elérését egyszerûbbé, pontosabbá,kényelmesebbé tegye.

Mindenki találkozott már azzal a problémával, hogya web-es keresõk csak a szövegeket vizsgálják, a mögöttüklevõ tartalmat nem. Ha a kutyákat keresünk, nem kapjukmeg az eb szót tartalmazó oldalakat, ha vizi emlõsökre kér-dezünk, az eredményben nem lesznek benne a delfinekrõlszóló oldalak.

Ahhoz, hogy a web-es keresõk intelligensebbé válhassa-nak, szükséges, hogy a weblapokon lévõ információta számítógép számára is érthetõ módon, úgynevezettmetaadatokkal írjuk le.

Emellett arra is szükség van, hogy a számunkra nyilván-való háttértudást a számítógép számára is hozzáférhetõ-vé tegyük. Például metaadatként leírhatjuk, hogy egyadott weblapon levõ adott kép Bojtárt, Kovács István kutyá-ját ábrázolja.

Háttértudásra példa az, hogy a kutya szinonímája az eb,a delfin az egy olyan emlõs, amelynek élettere a víz. De idetartozik az a triviálisnak tûnõ állítás, hogy a kutyája kap-csolat jobboldalán levõ egyed egy kutya.

Az ilyen jellegû háttértudást szokás ontológiának is ne-vezni: ez egyrészt egy fogalmi hierarchiát jelent,például:

delfin -> emlõs -> gerinces -> állat -> élõlény

másrészt beszél a fogalmak közötti kapcsolatokról, mintaz élettere, szülõje, kutyája, nyelvvizsgája, diplomája stb. Fej-

lettebb ontológiákban összetett állításokat is megfogal-mazhatunk, például formalizálhatjuk a következõ állás-ajánlatot: az adott állás betöltéséhez legalább két nyelv-vizsga és mérnöki vagy tanári diploma szükséges.

A metaadatok és a háttértudás leírására a W3C két szab-ványt is megalkotott. Az RDF (Resource DescriptionFramework, http://www.w3.org/RDF/) a metaadatok le-írására alkalmas. Az erre épülõ RDF séma nyelv egysze-rûbb állítások megfogalmazását teszi lehetõvé.

Az OWL (Web Ontology Language, http://www.w3.org/�� 2004/OWL/) viszonylag összetett háttértudás ábrázolá-sát teszi lehetõvé.

Az elõadás során informálisan bemutatjuk az OWL nyel-vet és a mögötte álló matematikai formalizmust, azúgynevezett leíró logikák területét. Szólunk arról is, hogymilyen módszerekkel lehet gépi következtésre felhasz-nálni az így formalizált háttértudást.

Az elõadás megértéséhez elegendõ a középiskolai mate-matika ismerete.

SSzzeerreeddii PPéétteerr

Szeredi Péter a BME Villamosmérnöki és InformatikaiKarának docense. Oktatási és kutatási területe a logikai éskorlát-programozás valamit a szemantikus világháló ésontológiakezelés. Társszerzõje és szerkesztõje a nagysikerû„A Szemantikus Világháló elmélete és gyakorlata” címûkönyvnek. Korábban a NIM IGÜSZI, az SZKI és IQSOFTmunkatársa volt, és több évet dolgozott angliai és svédországikutatóhelyeken is. 1975-ben készítette el az elsõ magyarProlog interpretert és szakmai vezetõje volt az MPROLOGrendszer fejlesztésének, amely az 1980-as évek egyiknemzetközi sikerterméke volt.


AA sszzeemmaannttiikkuuss vviilláágghháállóó aallaappjjaaii

EEggyy mmaaggaassaabbbb rreennddûû kkiijjeelleennttééss ggrrááffjjaa

web2007.qxd 3/22/2007 11:34 AM Page 34


AAzz AAJJAAXX ééss aazz aakkaaddáállyymmeenntteesssséégg

AA pprroobblléémmaa ffeellvveettééssee

Napjainkban a weboldalak több, mint felét vezérli Java-Script, minden fórumon új kifejezések sorát halljuk az inter-netes honlapokkal kapcsolatban, mint például AJAX(Asynchronous JavaScript and XML), Web2, Rich (gazdag)Internet stb. Terjed az a szándék, hogy a weboldalak kielé-gítsenek mindenfajta média-igényt. Beágyazott videókrólmár elég régen beszélhetünk, hiszen ezeknél a technológi-áknál egy év már történelmi távlat. Sorra hozzák (hozzuk)létre az új és új ötleteket és technológiai furcsaságokat felso-rakoztató portálokat. Gondoljunk csak arra, hogy az egyikvezetõ magyar kereskedelmi televíziócsatorna (RTL Klub)megújult webarculata milyen alkalmazásokat és megvalósí-tásokat vonultat fel! Ez jó, de nekünk, aki ismerjük a sötétoldalt is, újabb kihívásokat jelent.

Ezek a technológiák bizonyos szinten eddig is léteztek, csaknem jelentkeztek ilyen dömpingszerûen, és nem egyszerrehasználták ezeket a weboldalakon. Ahhoz, hogy akadály-mentessé tudjunk tenni egy gazdagon felépített portált,vagy már eleve akadálymentesen építsük fel, célszerû elõ-ször egyenként vizsgálni az alkalmazott megoldásokat,majd, ha ezzel végeztünk, összefüggésében is a kapotteredményt. Sajnos elmondható, hogy ez utóbbi ellenõrzéssorán sokszor javíthatatlan akadályokba is ütközhetünk, hi-szen a mai média elsöprõ erejét fõleg az adja, hogy az infor-mációk nagy tömegben zúdulnak ránk. Ez egyben áthidal-hatatlan problémát is jelenthet bizonyos célcsoportjaink-nak, gondolok itt elsõsorban az értelmi fogyatékosokra.

Az akadálymentes weblapok készítése tulajdonképpenmondható egyszerûnek is, meg bonyolultnak is. Egyszerû,hiszen nem kell mást tenni, mint megismerni a célcsoporto-kat, azok igényeit és a rendelkezésre álló webes és asszisztívtechnikákat, szabványokat. Bonyolult, hiszen nem elég, haa saját szakmánkat megtanuljuk rendesen (sõt annál kicsitjobban, mint egyéb esetben kellene), ezen túl orvosi, pszi-chológusi, ergonómusi ismereteinket is elég magas szintrekell fejleszteni az átlagos állampolgárokhoz képest. Kutató-munkánkkal egy percig sem pihenhetünk, mert egyre-más-ra jelennek meg a weben is és a fogyatékosok használatábanis újítások és új gyakorlatok.

MMiillyyeenn sseeggééddeesszzkköözzeeiinnkk vvaannnnaakk??

A W3C, vagyis a World Wide Web Consortium számosolyan ajánlást, felmérést, kutatást készített, amelyek tám-pontot adhatnak a webfejlesztõk számára az akadálymente-sítés során. Ezeket a munkákat összefoglalva a WAI címszóalatt találhatjuk meg. A WAI (Web Accessibility Initiative, va-gyis: Világháló akadálymentesítési kezdeményezés) egyolyan átfogó program, amely megoldásokat mutat a célcso-portok problémáinak felismerésére, megismerésére és az is-meretek birtokában való megoldására. Eddig leginkábba WCAG (Web Content Accessibility Guidelines; Világhálótartalmainak akadálymentesítési vezérfonala) elsõ és máso-

dik verziója volt a legfontosabb eszköz a fejlesztõk kezében,az új kihívásokra válaszul egy ideje új eszközkészlet is ren-delkezésünkre áll. Ez az eszközkészlet az ARIA (AccessibleRich Internet Applications, magyarul: Akadálymentes gaz-dag világhálós alkalmazások).

El kell mondjam az ARIA nem is olyan új, mint amilyenneklátszik, hiszen már 2006 szeptemberétõl megismerhetteaz érintett közösség. Sajnos, mint mindenben, ebben a té-makörben is megmutatkozott a programozók és informati-kusok fõ erénye, a lustaság. Persze még nem késõ, hiszen(bár a csili-vili fejlesztésében minden gyorsvonati sebesség-gel halad) az alapszabványok sem terjedtek el oly gyorsan,és ma mégis elmondható, hogy egy valamirevaló webembermár álmából felkeltve is tudja a (több, mint hét éves) HTMLés CSS egyes elemeinek lehetséges paraméterezését, formá-zásának lehetõségeit... Mindenesetre jó volna, ha az aka-dálymentesség szabályait kicsit gyorsabban sikerülne a tisz-telt fejlesztõi társadalom fejében tudni.

MMiirrõõll sszzóóll aazz eellõõaaddááss??

Elõadásomban nem csupán az ARIA és a WCAG megol-dáscsomagjára támaszkodom, de mindenképpen célom-nak tartom, hogy felhívjam a figyelmet ezekre a lehetõsé-gekre. Konkrét példákon keresztül meg fogom mutatniazokat a legfontosabb akadálymentesítési lépéseket, ame-lyek elengedhetetlenül szükségesek ahhoz, hogy a por-tálok könnyebben használhatóak és egyáltalán használ-hatóak legyenek a különféle célcsoportok által is. Rávilá-gítok olyan esetekre, amelyek egy-egy fogyatékos emberés az információ közé falat emelnek.

Manapság nagyon népszerû a (már említett) Web2 és AJAXkifejezés, illetve a mögöttük álló technológia, egyesek na-gyon szeretik, mások ki nem állhatják. Mégis mire használ-ható és mire nem az akadálymentes oldalakon? Példát mu-tatok olyan technikákra, amelyeket nyugodt szívvel aján-lok a fejlesztõk figyelmébe, és amelyek nemhogy rontanákaz akadálymentességet, hanem akár arra is képesek, hogyjavítsák azt. Egyik ilyen példában megismertetem az ûrlap-ok használat közbeni ellenõrzésének egy olyan korszerûmódszerét, amely akár ergonómiai, akár akadálymentessé-gi szempontból nézzük, javít a weboldalaink minõségén.

Leginkább az idõzítéssel, a dinamikus tartalomcserével ésa felhasználói interakciók kezelésével kívánok foglalkozni,az idõ szûkössége nem engedi meg egy komplett bemuta-tó tartását, ahhoz egy teljes konferenciára volna szükség.

KKáárroollyy GGyyöörrggyy TTaammááss

Programozó és webdesigner. 1993-ban kezdett weblapokat ter-vezni hobbiból, ma már ez a fõ tevékenysége. Jelenleg a weboldalakakadálymentesítését és akadálymentes honlapok tervezését tartja alegfontosabb ügynek. Honlapja a kgyt.hu címen található. Szabad-idejében feleségével, Bertával tervezgeti a jövõt.

web2007.qxd 3/22/2007 11:34 AM Page 35


SSzzöörrfföözzõõ vvaarráázzssccááppaa–– aavvaaggyy wweebboollddaallaakk hhaasszznnáállaattaa llááttáásssséérrüülltteekkeett sseeggííttõõ eesszzkköözzöökkkkeell

Napjainkban a webes szabványok és a böngészõk fejlõ-dése egyre több újdonságot kínál a weboldalakat látogatófelhasználóknak. Ahhoz, hogy a látássérült felhasználókis részesülhessenek az új tartalmak nyújtotta informáci-ókban, az szükséges, hogy az õket segítõ technológiák isfejlõdjenek, új lehetõségeket kínáljanak.

Az új fejlesztések eredményeként két területen is jelentõselõrelépések történtek az elmúlt év során:

1. Elkészült a már eddig is nagy népszerûségnek örven-dõ JAWS for Windows képernyõolvasó program újverziója, mely már egy új technológiával (DOM server)segíti és teszi még hatékonyabbá a látássérültek számá-ra a weboldalak böngészését.

2. Teljes átalakításon ment keresztül a MAGic képernyõ-nagyító program, mely sokkal funkciógazdagabb, minta korábbi verziók, emellett sok olyan technológiáthasznál, mely megtalálható a fent említett képernyõol-vasó programban is. Azt mondhatjuk, hogy közös mo-duljaik segítségével ugyanazon technológiákat hasz-nálják fel két látássérülésükben különbözõ csoport se-gítésére.

Elõadásunk e két területre koncentrál, mely területekkelelsõként hazánkban a 2007-es Web konferencia résztvevõiismerkedhetnek meg.

Megismertetjük az érdeklõdõket azzal a technológiával,mely lehetõvé teszi, hogy ne csak a zárt Microsoft Inter-net Explorer böngészõt lehessen képernyõolvasóval ésképernyõnagyítóval használni, hanem egy nyílt forrásúalternatívát is: a Firefox-ot. Bemutatjuk, hogy az egyesfunkciókat, melyek eddig nem voltak elérhetõk az IE 6-othasználók számára (füles böngészés, keresõ eszköztárhasználata, RSS olvasás) miként lehet képernyõolvasóvalés képernyõnagyítóval elérni és használni.

Az elmúlt években többször igyekeztünk felhívni az ér-deklõdõk figyelmét arra, hogy miképpen készíthetnekolyan akadálymentes oldalakat, melyek látássérültek,ezen belül gyengénlátók számára is hozzáférhetõk. Elõ-adásunkban bemutatunk egy olyan eszközt, mely képes-ségei révén segíti a gyengénlátó felhasználó képernyõnvaló tájékozódását, (kiemelési színek, stílusok használa-tát), ezen felül pedig beszéd funkcióval segíti a hosszabbdokumentumok, weboldalak felolvasását.

Rávilágítunk arra is, hogy bár a fenti technológiák a lá-tássérültek rendelkezésére állnak, mégis, ezen technoló-giáknak is szükségük van arra, hogy a weboldalak aka-dálymentesek legyenek, ellenkezõ esetben a technológi-ák adta lehetõségek is korlátoltá válnak, hatékonyságukcsökken.

DDvvaarriieecckkii BBáálliinntt

31 éves gyengénlátó informatikus vagyok. Jelenleg az ELTETanító- és Óvóképzõ Fõiskolai Karon dolgozom mint az infor-matika csoport vezetõje. Emellett projektvezetõi feladatokat látokel az „Informatika a látássérültekért” Alapítvány megbízásából:a MAGic képernyõnagyító program honosítási munkálatait vég-zem és irányítom. Minthogy magam is használója vagyok a kép-ernyõnagyító programnak, saját és sorstársaim tapasztalataitfelhasználva készítem el a honosított változatot.

TToorrmmaa ZZssoolltt

Harmincegy éves látássérült informatikus vagyok. Rendszer-gazdaként dolgozom, valamint a JAWS for Windows képernyõ-olvasó program honosítási projektjét vezetem az „Informatika alátássérültekért” Alapítvány megbízásából.

web2007.qxd 3/22/2007 11:34 AM Page 36


Security Protocols vs. User Needs: 0 : 1

Many of the security issues on the Web today come fromcompeting and contradictory user requirements, fromthe difficulty of making the right choices when designingsoftware and protocols, and from the difficulty ofcommunicating security questions to the user, andsecurity decisions from the user.

As a case in point, HTTPs is, in theory, a useful protocol toensure the authenticity, confidentiality, and integrity ofmaterial submitted to a Web Site or retrieved from one. Butphishing attacks demonstrate daily how this protocol can becircumvented: Users trust Web Sites blindly, based onindicators such as the perceived professionality of a site'sdesign. Dedicated security indicators are ignored (and, evenwhen they are not ignored, often spoofable). Where theprotocol detects possible attacks (e.g., a mismatch betweenthe domain name in a certificate and the domain name usedin the URI that is being dereferenced), users are given thepossibility to override the error. The tacit assumptionbehind this user interface choice is that the user might havesome information that gives him good reasons to trust thatthe error condition that has occured is really innocuous (orthat the user might be a site administrator who aims totroubleshoot his Web Site). The practical result is that usershave no idea how to respond to the question they are asked,and very quickly learn that "override this warning" will givethem the ability to continue with the task at hand, whileclicking "no" will leave them with no useful way ofsucceeding with that task.

Even where TLS works effectively, it securely binds a Webtransaction to a domain name – not to whatever mentalnotion the user might have of the entity that he reallydesires to interact with.

As a net result, an effective security protocol is renderedmoot since users are given the instruments and incentivesto ignore and even override it.

Where security models and policies aren't aligned withusers' immediate needs, the users' immediate needs win,and users are secure only by accident. They will,however, successfully download what they think is themovie that they want to play – and complain about theconsequences later.

Security on the Web Must be Designed ForUsers, Not Against Them.

W3C's Web Security Context Working Group (WSC WG) islooking at what we call the user's "Security Context", in thecurrent Web browsing environment: What is happening

around the user, and how can we tell the user about this ina way which is understandable and usable? How can weask questions in a way that the user understands? Whatquestions should software possibly not ask?

"Designing security for users and in a user-centric way" iseasily said, and much harder done: What choices dousers need? What choices, when taken away from theuser, limit her ability to use the Web – possibly in acreative, novel and unexpected way? What models doreally work?

Designing security on the Web for the user and withusability in mind also requires empirical research andwork: What models and notions do really work? What isgoing to be ignored by users, despite designers' bestintentions?

The WSC Working Group will therefore aim to validateits work using prototyping and user studies, and makethe results of these studies available to the public. TheWorking Group has already led to initial work on anadvanced prototyping platform for browser userinterfaces.

Next Steps: Ubiquitous Web ApplicationSecurity

Questions similar to those asked above will become evenmore critical as the use of Web Technologies broadens:Where cool mash-ups and murky cross-site-scriptingattacks become virtually indistinguishable, and whereWeb Applications have real-life side effects, the demandson sandbox models become more complex and morecritical at the same time. Developing new models withusers' needs and abilities in mind will be a significantchallenge for researchers and the Web Community atlarge as the Web continues to evolve.

TThhoommaass RRooeesssslleerr

Thomas Roessler joined the W3C Team in November 2004 towork on security, privacy, and European policy issues. Hecurrently serves as Security Activity Lead, Team Contact of theWeb Security Context Working Group, and also spends time onthe PRIME project. Prior to joining W3C, Thomas worked atthe University of Bonn on numerics of partial differentialequations, and collected programming, systems administrationand computer forensics experience. He is the lead maintainer ofthe free software mail user agent mutt, and was involved withICANN for several years. Thomas has published and given talkson topics including anonymization services, legal questions ofdigital signatures, and online privacy. He holds a degree inmathematics.

WWhhaatt ddoo tthheeyy tthhiinnkk tthheeyy aarreeddooiinngg?? WWhheenn UUssaabbiilliittyy aannddSSeeccuurriittyy mmeeeett oonn tthhee WWeebb

web2007.qxd 3/22/2007 11:34 AM Page 37


web2007.qxd 3/22/2007 11:34 AM Page 38


web2007.qxd 3/22/2007 11:34 AM Page 39


web2007.qxd 3/22/2007 11:34 AM Page 40

web2007borito.qxd 3/22/2007 11:01 AM Page 1

PDF formátumban letölthető

Documents