Szolgáltatás-felfededezésre alapozott
elektronikus oktatórendszer[1]
Dulai
Tibor, Medve Anna, Muhi Dániel, Dr. Tarnay Katalin
Absztrakt: Tanszékünkön
kidolgoztunk néhány web-alapú segédanyagot egyes
általunk oktatott tárgyak támogatására. A múlt évben azt tapasztaltuk, hogy a
hallgatók ezekből a tárgyakból lényegesen jobb eredményeket értek el, mint
a webes segédanyag által nem támogatottak esetében. Ez a tény indíttatta azt a
döntésünket, hogy második generációs elektronikus oktatórendszert (e-learning system)
fejlesszünk ki. Első lépésben megalkottuk a rendszer modelljét. Ebbe három
különböző technológiát integráltunk. A rendszer alapját az Elektronikus
Oktatási Rendszer (Electronic Education System - EES) nevű modell képezi.
Ezt mi szolgáltatás felfedezéssel egészítettük ki, mely előzetes
konfiguráció nélkül hálózati oktatási erőforrások felfedezésére ad
lehetőséget. Ezen erőforrások leírására az IEEE oktatási metaadat
specifikálására kidolgozott szabványát, a Learning Object Metadata-t (LOM)
használtuk. A cikkben ezt az integrált modellt mutatjuk be.
1. Bevezetés
Célunk bemutatni, hogyan fejlesztettünk ki egy elektronikus oktatási modellt három különböző technológia integrálásával, melyek a következők:
Azt várjuk, hogy e modell implementálásával létrehozhatóak, használhatóak és az oktatási rendszerbe integrálhatóak újrafelhasználható, kereshető és platform-független oktatási objektumok.
A világon egyetlen dolog állandó, ez pedig a folyamatos változás. A változás az oktatást sem kerüli el. Rosenberg szerint [1] az oktatás átalakulásának két fő tényezője van:
· Egyrészt egyre nő az igény a „bármit, bármikor, bárhol” [2] típusú tanulásra, ennek következtében megnő a számítógépes hálózatok – leginkább az Internet – szerepe az oktatásban.
· Másrészt egyre inkább elfogadottá válik az a tény, hogy a tanulás az ember egész életén át tartó folyamat.
E két tényező biztosítja az elektronikus tanulás elterjedését, melynek legfőbb előnyei a költséghatékonyság, a változások dinamikus követése, a konzisztencia, az egyszerű elérhetőség, interaktivitás és a személyre szabhatóság lehetősége. Sokan azt gondolják, hogy az e-tanulás káros jelenség, mert ki fogja szorítani a hagyományos, tantermi oktatást. Ez azonban nem igaz, egy e-tanulási rendszer célja az, hogy segítse a hagyományos oktatás munkáját, és a kettő egymással együttműködve olyan hátteret biztosít a diákok számára, mellyel tudásuk és képességeik biztosabbá válnak. [3] Ezért minden oktatási intézmény stratégiájában szerepelnie kell az e-tanulási technológiák kifejlesztésének, illetve a hagyományos oktatási rendszerbe való integrálásának.
Az EU e-Európa programjában [4,5] az elektronikus oktatás terjesztése a kiemelt feladatok közé került. Az ezirányú kutatások eredményei általános és konkrét képzésekre vonatkozóan is, a tanulást segítő intézmények megújítására adnak fő irányelvek köré csoportosított módszertani javaslatokat, a terjesztést segítő szabványokat és szoftveres eszközöket. Ennek fontosságát saját tanszékünkön is megtapasztaltuk: előző évben a már létező WEB-alapú segédanyag-gyűjteményhez kapcsolódó modulokból a vizsgázók látványosan jobban teljesítettek, mint az elektronikus segédanyaggal még nem támogatott modulokból.
Ezért döntöttünk egy könnyen használható elektronikus oktatási rendszer kifejlesztése mellett. Ennek eléréséhez már létező szabványokat és technológiákat alkalmaztunk. Megalkottunk egy modellt, mely a következő három fő komponensből áll:
A következő 3 fejezetben (2-4) a három komponenst, míg az ötödik fejezetben az integrált modellt mutatjuk be.
2. A Learning Object
Metadata (LOM)
Ezt a specifikációt oktatási objektumok leírására alkalmazzák. Metaadat alatt adatot leíró adatot értünk, vagy más szavakkal információról szóló információt. Metaadat segítségével egy objektum minden lényeges tulajdonsága (pl. tartalma, struktúrája, elérhetősége, stb.) leírható. Ez különösen lényeges nem szöveges objektumok esetén (pl. multimédiás erőforrások). Könnyebbé teszi az információ menedzselését a hálózati adminisztrátorok számára, míg a felhasználók a fontos információt a köztük való böngészés nélkül megtalálhatják.
Az oktatási metaadat oktatással kapcsolatos erőforrásokról nyújt információt. Ezek nem csak elektronikus erőforrások lehetnek, hanem akár könyvek, személyek vagy szervezetek is. Bár a fő feladata az oktatási metaadatnak az elektronikus erőforrások leírása, különösen a hálózaton elhelyezetteké.
Ezen erőforrások rohamosan növekvő száma különösen fontossá teszi a metaadatok alkalmazását. Egy erőforrás akármilyen kiváló is lehet, ha képtelenek vagyunk megtalálni a hálózaton. Az erőforrások leírása metaadattal viszonylag egyszerű, így azok megosztása, keresése, vagy akár személyre szabása szintén könnyebbé válik.
Oktatási környezetben használt metaadatra számos javaslat létezik. A legjelentősebb közülük az IEEE LTSC (Learning Technologies Standardization Committee [6]) munkacsoportja által készített Learning Object Metadata. Az LTSC munkája majdnem minden, az elektronikus oktatással kapcsolatos területet lefed.
Az oktatási erőforrások természetükből adódóan heterogének, ezt a tény tükrözi a metaadat leírása is. A LOM kilenc kategóriát tartalmaz (1. táblázat), több mint 60 különböző attribútummal (adatelemmel).
1.
táblázat: A LOM kategóriái |
A LOM az oktatási erőforrásokat leíró metaadatok szintaxisát és szemantikáját is specifikálja, azaz definiálja azokat az attribútumokat, melyek az erőforrások pontos leírásához szükségesek. Az attribútumoknak azt a minimális halmazát definiálja, mely elég az erőforrások menedzseléséhez. Az erőforrások legfontosabb attribútumai a típus, a szerző, a tulajdonos, a felhasználási mód, illetve a formátum. Amennyiben szükséges, a metaadat tartalmazhat pedagógiai attribútumokat is, mint a szükséges képzettségi fok, nehézségi szint vagy a szükséges előismeretek.
2002. június 12-én a LOM az IEEE által elfogadott szabvánnyá vált (IEEE-SA standard 1484.12.1). A LOM szabványt nemzetközileg jól fogadták és adoptálták, bár ez a folyamat még a kezdeti szakaszában van.
3. A szolgáltatás-felfedezés
és az SLP
Ha egy hálózati szolgáltatást szeretnénk használni, tudnunk kell annak hálózati címét, vagyis egy elektronikus magazin címét be kell gépelnünk ahhoz, hogy elolvashassuk. Minél több szolgáltatást szeretnénk használni, annál több címre kell emlékeznünk. Mitöbb előfordulhat, hogy egy szolgáltatás megszűnik és egy értelmetlen hibaüzenetet kapunk. Szükségünk van egy hálózati protokollra, mely kielégíti a következő kritériumokat:
A megoldást a szolgáltatás-felfedező protokollok szolgáltatják. A szolgáltatás-felfedezés azt jelenti, hogy a szolgáltatások "reklámozzák" magukat a hálózaton. A "reklám" a szolgáltatás típusát, tulajdonságait és elérési módját (pl. IP cím, elérési protokoll) tartalmazza. A kliens (pl. szövegszerkesztő) típusa (pl. nyomtató) alapján találja meg a kívánt szolgáltatást. Ha egy bizonyos típusú szolgáltatásnak számos képviselője található (pl. lézer és tintasugaras nyomtató), akkor a felhasználó a számára legmegfelelőbb tulajdonságút választhatja közülük.
Amikor felmerült az igény a szolgáltatás-felfedezésre, számos vállalat és konzorcium kezdte el kutatni a területet, az IETF pedig külön munkacsoportot hozott létre erre a célra. A legtöbb szolgáltatás-felfedező protokoll fejlesztése még most is tart. A legismertebbek a következők:
·
Az IETF
által kifejlesztett Service Location
Protocol (SLP)
·
A Jini, mely a Sun Java-alapú protokollja
·
A Salutation
·
A Microsoft Universal Plug and Play (UPnP)
nevű protokollja
Ezek összehasonlítása megtalálható [7]. Amiért mi az SLP mellett döntöttünk:
A következőkben vizsgáljuk meg az SLP felépítését! Az SLP-t azért érdemes tanulmányozni, mert gyakorlatilag az összes szolgáltatás-felfedező protokoll mintájául szolgált.
3.1
Az SLP architektúrája
Az SLP architektúrának három fő eleme van:
·
User Agent (UA):
A felhasználó gépén futó folyamat, mely lehetővé teszi a felhasználói
alkalmazás és a rendszer közötti kommunikációt. Ha valakinek szüksége van egy
szolgáltatásra, akkor megadja az alkalmazásnak, hogy milyen típusú
szolgáltatást szeretne, az alkalmazás pedig az UA-hoz fordul a kéréssel. Válasz
esetén az UA értesíti az alkalmazást az elérhető szolgáltatásokról. Az UA
hasonló szerepet játszik az SLP-ben, mint a resolver a DNS-ben.
·
Service Agent (SA): Minden
hálózati szolgáltatáshoz tartozik egy ilyen folyamat, feladata a szolgáltatás
hirdetése. A hirdetésnek többek között tartalmaznia kell a szolgáltatás típusát
és tulajdonságait. A szolgáltatás jellemzőit, ugyanúgy, mint az LDAP-ben, attribútumoknak nevezzük.
·
Directory Agent (DA):
Olyan folyamat, mely egyrészt fogadja az SA-k által küldött
szolgáltatás-hirdetéseket, és bejegyzi azokat egy adatbázisba, másrészt
feldolgozza az UA-k által küldött kéréseket, és válaszol rájuk. A rendszerben
lehet több DA is, ezért ez az elem biztosítja a protokoll skálázhatóságát.
Kisméretű hálózatok esetén az is előfordulhat, hogy egyáltalán nincs
DA, ekkor az UA rögtön az SA-khoz fordul kérésével. Ha nagyon sok szolgáltatás
van egy hálózaton, akkor meg lehet osztani a terhelést több DA között. Mivel a
szolgáltatáskeresés gyakoribb művelet, mint a szolgáltatásbejegyzés,
vagyis gyakrabban kell az adatbázist olvasni, mint módosítani, ezért a DA
könyvtár-alapú adatbázist használ, melyet az LDAP segítségével valósít meg.
Felhasználó Alkalmazás Szolgáltatás Service Agent User Agent Directory Agent LDAP
A
fenti elemek közötti kapcsolatokat a következő ábrán láthatjuk:
1. ábra: Az SLP felépítése
3.2 A szolgáltatás leírása SLP-ben
A szolgáltatás-leírás [8] a szolgáltatás
legfontosabb tulajdonságait tartalmazza: az egyedi azonosítóját, a típusát és a
szolgáltatás attribútumait. A szolgáltatás azonosítóját Service URL-nek hívják.
Ez egy speciális URL a következő szintaxissal:
„service:” service_type „:”
network address/path
A szolgáltatás típusa lehet absztrakt vagy
konkrét. Az absztrakt típus osztályozza a szolgáltatást, míg a konkrét típus
meghatározza az elérési protokollt. Például az "eszközmeghajtó"
absztrakt típus lehet. Ez eszközmeghajtókat nyújtó szolgáltatásokat azonosít.
Ennek a szolgáltatásnak a használatához ezt ki kell egészítenünk az elérési
protokollal, így egy konkrét típust kapunk. A konkrét típus mindig egy absztrakt
típusból származik.
Az absztrakt típus az objektum-orientált
technológia absztrakt osztályával állítható párhuzamba, a konkrét típus egy
ebből származtatott osztálynak, míg a Service URL egy osztály
megvalósulásának, azaz egy objektumnak felel meg.
|
II. táblázat:
Példák Service URL-re |
A II.a táblázatban szereplő Service URL az
"eszközvezérlő" szolgáltatás egy példányát specifikálja. Egy
ebből származtatott konkrét szolgáltatás példányát (egy letölthető
eszközvezérlőt) tartalmazza a II.b táblázat, mely közvetlenül
elérhető. Amint látható, a konkrét szolgáltatás típus az absztrakt
típusból és az azt követő ":" után írt elérési protokollból áll
elő.
3.3 Az SLP attribútumai
Folytatva az előző példát, képzeljük
el, hogy az "eszközvezérlő" szolgáltatásnak két attribútuma van:
·
driver az eszköz típusát jelenti
·
os pedig az operációs rendszert azonosítja
A II.c táblázatban
szereplő Service URL egy Linux alatti SCSI eszköz meghajtóját
specifikálja. Ez a szolgáltatásról minden információt tartalmaz és ez az
információ szabványos úton (egy URL-ben) van tárolva. Az SA ezt az URL-t
beregisztrálja a DA-nál, ami ezt küldi válaszként az UA szolgáltatás kérésére.
3.4 Template SLP esetén
A protokoll elemei és a felhasználók kell, hogy
ismerjék minden szolgáltatás-típus lehetséges attribútumait. Ez az információ a
template-ekben van tárolva. A template egy egyszerű szöveges file, mely
mind az ember, mind a számítógép számára érthető.
A template első sora a szolgáltatás típusát
tartalmazza, a további sorok az attribútumait definiálják. Például az eszközmeghajtó
konkrét szolgáltatás-típus egy lehetséges template-jét mutatja be a III.
táblázat.
template-type=service:device-drivers:ftp driver= string os= string |
III. táblázat: Az eszközmeghajtó konkrét típus
template-je |
Ha egy attribútum egy absztrakt
szolgáltatás-típusban szerepel, akkor annak az ebből a típusból
származtatott minden egyes konkrét típusban is szerepelnie kell.
A template egy szolgáltatás interface-eként is
felfogható.
3.5 Az SLP üzenetei
Az
SLP-ben a következő üzeneteket definiálták:
·
Service Request:
Az UA küldi ezt az üzenetet, ha információt szeretne kapni valamilyen
szolgáltatásról. Az üzenet paramétereként meg kell adnia a szolgáltatás
típusát.
·
Service Reply:
Az UA kapja a DA-tól vagy az SA-tól, tartalmazza a keresett szolgáltatások
adatait.
·
Service Registration:
Amikor egy új szolgáltatás elérhető lesz, akkor a hozzá tartozó SA küldi
ezt az üzenetet a DA-nak. Hatására a DA bejegyzi a szolgáltatást.
·
Service Deregistration:
Az SA küldi a DA-nak, ha megszűnik az általa képviselt szolgáltatás. A
DA-nak ilyenkor törölnie kell a szolgáltatást az adatbázisából.
·
Service Acknowledge:
A DA küldi az SA-nak egy sikeres szolgáltatásbejegyzés vagy -törlés után.
·
Attribute Request:
Az UA ezzel az üzenettel lekérdezheti egy adott szolgáltatás attribútumait,
vagy egy szolgáltatástípushoz tartozó összes attribútumot.
·
Attribute Reply:
Válasz az előbbi üzenetre.
·
DA Advertisement:
A DA küldi periodikusan az UA-nak és az SA-nak, hogy tudomást szerezzenek róla.
·
Service Type Request:
A hálózaton elérhető összes szolgáltatástípust tudja lekérdezni az UA
ezzel az üzenettel.
·
Service Type Reply: Válasz
az előbbi kérésre.
Az SLP architektúrája, valamint komponensei
közti üzenetváltás látható a 2. ábrán.
2. ábra: Az SLP üzenetcseréi |
3.6 Felfedezés az SLP-ben
A legalapvetőbb művelet az SLP-ben az, amikor egy felhasználó információt szeretne kapni valamilyen hálózati szolgáltatásról. Kisebb méretű implementációkban minden szolgáltatás SA-ja külön-külön válaszol az UA kérésére. Nagyobb hálózatok esetén a szolgáltatások bejegyzik magukat egy vagy több DA adatbázisába, és az UA-nak a DA-hoz kell fordulnia, ha meg szeretne találni egy szolgáltatást.
Az UA kétféleképpen kezdheti el a szolgáltatáskeresést:
·
Ha van a
hálózaton DA, akkor elküld neki egy Service Request üzenetet, és paraméterként
megadja a szolgáltatás típusát. Ekkor a DA kikeresi az adatbázisából az adott
típushoz tartozó szolgáltatások adatait, és elküldi azokat az UA-nak.
·
Ha egyetlen
DA sincs a hálózaton, akkor multicast-tal kell elküldenie a kérést, vagy ha ez
nem lehetséges, akkor broadcast-tal.
A broadcast és a multicast üzenetszóró szolgáltatás. A broadcast-tal egy lokális hálózaton minden gépnek elküldhetjük ugyanazt az adatcsomagot, függetlenül attól, hogy szüksége van-e rá, vagy sem. A multicast viszont lehetővé teszi, hogy csak azok a hosztok kapják meg az adatcsomagot, melyeknek szükségük van rá.
Tegyük fel, hogy az Interneten van négy számítógép, melyek rendelkeznek IP-címmel, és mind a négynek el szeretnénk küldeni egy adatcsomagot. Megtehetjük azt is, hogy külön-külön elküldjük mind a négy címre az üzenetet, de ez nem jó megoldás, mert mi van akkor, ha ötven címre szeretnénk elküldeni?
Erre a problémára a multicast ad megoldást. Segítségével csoportokat tudunk létrehozni, és megadhatjuk, hogy egy csoportba mely hosztok tartozzanak. Minden csoportnak lesz egy IP-címe, és ha erre a címre küldünk egy adatcsomagot, akkor azt a csoportba tartozó összes hoszt meg fogja kapni.
Egy hoszt több csoportnak is tagja lehet. Egy csoport címére általában azok is küldhetnek adatot, akik nem tagjai a csoportnak. Nem minden esetben van szükség új csoport létrehozására, mert vannak állandó csoportok is, melyeknek címe előre adott. A multicast címek D osztályúak, tehát első négy bitjük 1-es. Ez azt jelenti, hogy a multicast címtartomány a 224.0.0.0 és a 239.255.255.255 címek közé esik. A multicast elvileg nem korlátozódik a lokális hálózatra, egy csoport tagjai az Interneten bárhol elhelyezkedhetnek. A gyakorlatban ez nem így van, mert ehhez az kellene, hogy az Internet összes routere ismerje a multicast címzést.
Tehát ha nincs a hálózaton DA, akkor az UA multicast-tal küldi el a kérést. Az SLP-ben definiáltak 1024 darab állandó multicast címet. Ezeket szolgáltatás-specifikus multicast címeknek nevezzük. A szolgáltatástípus neve alapján egy hash függvény segítségével minden szolgáltatástípushoz hozzá lehet rendelni egy specifikus címet. Az alkalmazás megadja az UA-nak a szolgáltatás típusát, az UA pedig ebből a típusból a hash függvénnyel meghatároz egy multicast címet. Ez a cím lesz a szolgáltatás-specifikus multicast cím, és az UA-nak erre a címre kell elküldeni a kérést. Természetesen a helyes válasznak az az előfeltétele, hogy az SA-k csatlakozzanak a saját szolgáltatásukhoz tartozó multicast csoporthoz, és figyeljék az oda érkező üzeneteket. Ha valamelyik SA rendelkezik a kért szolgáltatással, akkor válaszol az UA-nak.
Ha a hálózaton már van DA, akkor az UA-nak az összes kérést hozzá kell küldenie. És az SA-nak is kötelező regisztrálnia magát legalább egy DA adatbázisába. Ekkor viszont felmerül az a kérdés, hogy a kliensek honnan tudják meg a DA címét? A következő megoldásokat lehet alkalmazni:
·
Ha a
hálózaton sem broadcast-ra, sem multicast-ra nincs lehetőség, akkor a
klienseknek előre meg kell adni a DA-k címét. Ez a statikus konfiguráció.
·
Van egy
olyan multicast csoport (Directory Agent Discovery Group), melyhez minden
DA-nak csatlakoznia kell. Ennek a csoportnak az IP-címe 224.0.1.35. Ha egy
kliens egy Service Request üzenetet küld erre a címre, és a szolgáltatás
típusaként „directory-agent”-et ad meg, akkor minden DA visszaküld a kliensnek
egy DA Advertisement üzenetet. A kliens ebből tudja meg a hálózaton
lévő DA-k címét.
·
Létezik egy
másik multicast csoport (Service Location General Group), melyhez minden UA-nak
és SA-nak csatlakoznia kell. Ennek a csoportnak az IP-címe 224.0.1.22. Amikor
egy DA elindul, DA Advertisement üzenetet kell küldenie erre a címre. Ezután a
DA-nak bizonyos időközönként meg kell ismételnie ezt az üzenetet. Így azok
a kliensek is tudomást szereznek a DA-ról, melyek később csatlakoztak a
hálózathoz.
Mielőtt egy szolgáltatás megszűnik, törölni kell a DA
adatbázisából. Ezt az SA teszi meg úgy, hogy elküld a DA-nak egy Service
Deregistration üzenetet. A DA akkor is törölhet egy szolgáltatás-bejegyzést, ha
nem érkezett erre vonatkozó kérés, mivel minden bejegyzéshez tartozik egy ún.
élettartam, melyet az SA ad meg. Ha az SA bejegyez a DA-nál egy szolgáltatást,
és letelik az élettartamban meghatározott idő, akkor a DA törli a
bejegyzést, kivéve ha az SA időközben megújítja azt.
4. Az Elektronikus Oktatási Rendszer (EES) modell
Az első elektronikus tanulási rendszerek
majdnem kizárólag a tanulási folyamat menedzselésére és mérésére koncentráltak,
anélkül, hogy ehhez bármilyen értéket adtak volna. Ezek voltak az első
generációs "Tanulási Menedzsment Rendszerek" ("Learning
Management Systems" - LMS). Ezek képesek voltak megjeleníteni bármilyen
oktatási erőforrást, de azok szervezése és újrafelhasználása nem volt
megoldott. Ismail [9] alapján a következő
generációs rendszereknek képesnek kell lenniük az újrafelhasználható,
kereshető és platform-független oktatási objektumok menedzselésére.
Cloete [10] egy olyan elektronikus
oktatási modellt javasolt, mely alkalmas lenne a második generációs eLearning
rendszerek megvalósítására. Javaslata, az Electronic Education System Model
(EES) e-tanulási rendszereket tervező szakemberek számára nyújt segítséget
egy specifikus tanulási szituáció megtervezése és implementálása során.
Modellje négy rétegből áll, a rétegek pedig objektumokra vannak bontva.
Minden réteg jól meghatározott feladatot hajt végre, és egy réteg az alatta
lévő réteg szolgáltatásait használhatja. Az objektumok egy-egy
szolgáltatás biztosításáért felelősek, ezért szolgáltatás-objektumoknak is
hívják őket.
A következő ábrán az EES részei láthatóak:
3. ábra: Az EES modell
A rétegek funkciója a következő:
5. Munkánk: A kiterjesztett
EES
Amint látjuk, a legfelső rétegben oktatási szolgáltatások vannak. Tudjuk, hogy lokális hálózatokban gyakran okoz problémát a megfelelő szolgáltatás megtalálása. Erre a problémára fejlesztették ki a szolgáltatás-felfedező protokollokat, melyek előzetes konfiguráció nélkül lehetővé teszik a hálózati szolgáltatások felfedezését egy lokális hálózaton.
Rögtön adódik tehát a gondolat: illesszük be a szolgáltatás-felfedezést az EES modellbe, megkönnyítve ezzel a különböző oktatási szolgáltatások megtalálását. Ehhez először is szétbontottuk a 4. réteget két alrétegre: a komplex szolgáltatásokra és a szolgáltatásokra (4. ábra). Erre azért van szükség, hogy modellezni tudjuk azokat az eseteket, amikor egy szolgáltatás több rész-szolgáltatásból tevődik össze. Ezután a réteg aljára harmadik alrétegként beillesztettük a felfedezést, mely a szolgáltatások és ezeken keresztül a komplex szolgáltatások számára biztosítaná a felfedezhetőséget. Ezután a szolgáltatásokat dinamikusan lehetne módosítani, a felfedezés alréteg nyomon követné a változásokat, és jelezné a felhasználók számára:
4. ábra: A kiterjesztett EES modell
Ha az oktatási szolgáltatásokat az LOM segítségével jellemeznénk, és a jellemzést beillesztenénk az EES felfedezés alrétegébe, akkor egy olyan elektronikus oktatási rendszert kapnánk, melyben egy oktatási intézmény minden résztvevője egyszerűen megtalálná a számára fontos információt. Ez az információ szinte bármi lehet, a tananyagtól a terembeosztásokig. Mivel a szolgáltatás-felfedezés lényege az, hogy a felhasználó előzetes konfiguráció nélkül megtalálja az őt érdeklő erőforrásokat, ebből következően egy felfedezőklienst elindítva azonnal használni lehetne a rendszert.
Ezért az SLP-t alkalmassá kell tennünk a LOM kategóriák kezelésére. Először is létrehozunk egy absztrakt szolgáltatás-típust az oktatási szolgáltatásoknak. Ezt mi "edu.ve"-ként jelöljük, ahol "edu" az "education", a "ve" pedig a Veszprémi Egyetem rövidítése. Ezen szolgáltatás-típus attribútumai megegyeznek a LOM-ban definiáltakkal. Nevük is azonos a LOM-beliekkel, kivéve, hogy SLP-ben az attribútumok neveit kisbetűvel írjuk és szóköz helyett alulvonást használunk. Így például "Interactivity level" helyett "interactivity_level"-t írunk. Az attribútumok az "edu" szolgáltatás template-jében vannak specifikálva.
service:edu.ve:http://instructor.irt.vein.hu/gsm.pdf; interactivity_type=expositive; learning_resource_type=slide; interactivity_level=very
low; semantic_density=high; intended_end_user_role=learner; context=higher
education; typical_age_range=18-; difficulty=medium; typical_learning_time=2h; language=hu |
IV.
táblázat: egy oktatási URL része |
A konkrét szolgáltatás-típus az absztrakt típus leszármazottja. Az összes ott definiált attribútumot tartalmazza, valamint definiálja a szolgáltatás elérési protokollját. Egy Service URL (más néven "reklám") része a IV. táblázatban látható. Ez csak a szolgáltatás oktatás-specifikus attribútumait tartalmazza, mely szolgáltatás esetünkben egy slide-gyűjtemény. Az URL önleíró, minimális magyarázattal megérthető.
Ezzel a LOM szabványt
beillesztettük a szolgáltatás-felfedezés környezetébe, ami a kiterjesztett EES
modell része. Ez a három különböző technológia előnyeinek egyesítését
és eddig nem megvalósítható új vonások megszületését jelenti:
·
Könnyű használat: Mivel a
szolgáltatás-felfedezés lényege a felhasználó adminisztrációs
tevékenységektől való mentesítése, ezért modellünk a
"felhasználóbarát" fogalom új jelentését vezeti be: ha valaki
használni akarja a rendszert, csak futtatnia kell a szoftvert, minden más a
rendszer feladata. Semmi konfiguráció, semmi frusztráció, semmi
időveszteség.
·
Személyre szabás: Mindenki különböző, így
mindenkinek más az érdeklődési köre. Az alapos erőforrás-leírás
segítségével mindenki könnyedén megtalálhatja az érdeklődésének
megfelelő témát.
·
Kommunikáció: A hagyományos elektronikus oktatási
rendszerek a kommunikációs lehetőségek hiányától küszködtek, bár a
kommunikáció elkerülhetetlen a hallgatói visszajelzések esetén, továbbá ez a
kiértékelés alapja. Az általunk készített modell megkönnyíti a kommunikációt,
pl. a tanár e-mail címének felfedezésével.
Vizsgáljuk meg, hogyan elégíti
ki modellünk a második generációs oktatási rendszerek kritériumait!
·
Újrafelhasználhatóság: Ezt az alap és összetett
szolgáltatások külön rétegeinek megalkotásával értük el. Ez azt jelenti, hogy
egyszerű objektumok létrehozása után előállíthatunk belőlük
sokoldalú, összetett objektumokat is. Akkor használhatjuk fel ezeket az
egyszerű objektumokat, amikor csak szükségünk van rájuk.
·
Kereshetőség: Ezt a tulajdonságot a
szolgáltatás-felfedezés nyújtja, mitöbb a "felfedezhetőség"
kifejezést használhatjuk esetünkben.
·
Platform-függetlenség: Célunk Java nyelven
elkészíteni rendszerünket és az oktatási objektumokat. Még az objektum leírások
is platform-függetlenek, mivel egyszerű szöveges file-ban vannak tárolva.
6. Összefoglalás
Munkánk egy elméleti modell, célunk elkészíteni a követelményelemzést, az implementációt és az újrafelhasználhatósági mintákat egy elektronikus oktatási rendszer esetében erre a modellre alapozva, továbbá a rendszer alkalmazása és működtetése a tanszékünkön lévő telekommunikációs csoportunkban. Számos feladat van még a cél eléréséig, például jelenleg nincs publikus szolgáltatás-böngésző (User Agent az 1. ábrán) SLP-hez. Már kifejlesztettünk egy ilyen szoftvert C nyelven, de ezt Java-ba kell átültetnünk a platform-függetlenség biztosításához. A tananyag fejlesztés szintén egy fontos feladat. Végül, de nem utolsósorban a teljes rendszert be kell vezetnünk az oktatásba.
Elektronikus oktatási rendszer modellünk a hagyományos oktatási rendszer minden tagjának nyújt előnyöket. A hallgatók számára a haladásuknak megfelelő tananyagot biztosít személyre szabott ellenőrzéssel. Az információ dinamikus szolgáltatásként érhető el. Az automatikus ellenőrzés mellett a rendszer lehetőséget nyújt a tanárral vagy más hallgatókkal való kapcsolatfelvételre mintegy e-konzultáció keretében. Ezáltal gyors, kétirányú információcserét biztosít a hallgatók és a tanár közt a modern telekommunikációs technológiák felhasználásával.
Megoldja a tananyag-menedzsmentet könnyítve a tanár feladatát, és segít a hallgatók felkészültségének ellenőrzésében. Rugalmasságának köszönhetően alkalmas a létező rendszerek integrálására és megkönnyíti új szolgáltatások alkalmazását. A rendszer hordozható formában kínálja fel az információt, mivel figyelmet fordítottunk az elektronikus oktatás szabványosítására a kutatás során.
Az oktatási intézmények hallgatókért való harcában a rugalmas, személyre szabott képzésnek, a dinamikus tananyagnak és a speciális kurzusoknak nagy szerepük van. További jelentős feladat hárul azokra a módszerekre, melyek az eddig elérhetetlen tanulócsoportokat célozzák meg. Minél inkább személyre szabott egy kurzus, illetve minél több segítséget kap a tanuló, miközben hatékonyan és a lehető leggyorsabban tanul, annál valószínűbb, hogy a tanulóidejére az adott intézményt választja.
7. Köszönetnyilvánítás
Kutatómunkánkat az Oktatási Minisztérium támogatta (IKTA5-128/2002).
8. Irodalomjegyzék
[1] M. J. Rosenberg:
E-Learning: strategies for delivering knowledge in the digital age. New York:
McGraw-Hill Companies, Inc., 2001
[2] T. Vold: „Whatever,
whenever, wherever”-learning. Proceedings: 3rd International Conference on
Information Technology Based Higher Education and Training (ITHET 2002),
Budapest, 2002. július
[3] Kellog, D. W. Viehland,
Education and the Internet, Computers and Education, Vol. 30., No. 1-2.
[4] http://www.cordis.lu/
[5] Komenczi Bertalan:
Elektronikus Európa – Az Európai Unió akcióterve 2002-ig (Új Pedagógiai Szemle,
2000. 09.), http://www.oki.hu/
[6] http://ltsc.ieee.org
[7] C. Betstetter and C.
Renner (2000), “A Comparison of Service Discovery Protocols and Implementation
of the Service Location Protocol,”
http://www.lkn.e-technik.tu-muenchen.de/lkn/mitarbeiter/chris/publica-tions/eunice2000-slp.html
[8] E. Guttman, C. Perkins, J. Kempf, “Service
Templates and Service: Schemes”, RFC2609, Jun. 1999.
[9] J. Ismail, “The design of an e-learning system”, Internet and Higher Education, 4 (2002), pp. 329-336.
[10] E. Cloete:
Electronic education system model, Computers & Education, 36 (2001),
171-182