Spagetti:
szabad információ-áramlást megvalósító
szoftver-infrastruktúra
Az alábbiakban
egy tervezés alatt álló szoftver-infrastruktúrát fogunk ismertetni, mely
elképzelésünk szerint nagy előrelépést jelenthet az informatika számos
területén. Meglátásunk szerint erre nagyon-nagy szükség van, ugyanis
számítógépek és általában véve az informatikai rendszerek használhatósága,
sokoldalúsága az információ-kezelés és felhasználás terén jelenleg
meglehetősen alulmúlja azt a szintet, melyet maga a technológia
lehetővé tenne. Valóban használható rendszerek csak a sci-fi filmekben
léteznek, olyanok melyek egységes egészként –
nem sok-sok nehézkesen kommunikáló különálló rendszerként –, partnerként
működnek, bármilyen helyzetben megfelelő eszközöket nyújtanak feladataink
megoldására. A hardverekben, a hálózatokban rejlő bámulatos
lehetőséget a jelenlegi szoftverek többsége nem képes kiaknázni.
Ezért a
felhasználói programok készítői csak részben okolhatóak. A valódi probléma
szerintünk a megfelelő általános célú alaptechnológiák hiánya, valamint a
szűklátókörűen, alkalmazás-specifikusra tervezett szabványok sokasága
okozza. Ugyan a programok nagy többségének feladata információcsere, –
manipuláció és megjelenítés, mégsem létezik egy közös, de mégis sokoldalúan
használható infrastruktúra, melynek használata, az abba való beépülés a
szoftverfejlesztés során célszerű, hasznos és könnyű – röviden:
szükséges lenne.
Elképzelésünk
szerint alapos, körültekintő tervezéssel létre lehet hozni egy olyan
szoftvertechnológiát, amely betöltené az imént hiányolt űrt. Nem egy-egy
adott alkalmazási területet fedne és nem egyetlen területen használható
szabványokat alkotna. Ehelyett infrastruktúrát teremtene ezek megvalósításához,
leegyszerűsítené az ezeket megvalósító programok fejlesztését, s mintegy
mellékesen közelebb hozná őket egymáshoz. Ezen alap megléte feleslegessé
tenné, hogy a fejlesztők újra és újra alkalmazás-specifikus szabványokat,
és ezáltal zártabb rendszereket hozzanak létre, majd ennek további
következményként cél-specifikus, eseti kommunikációs megoldásokat alkossanak
ezek összekapcsolásához.
Tervünk az
informatikának azon – köztudomásúlag elnyomó részét alkotó – területén akar
tehát változtatni, mely adatkezeléssel foglalkozik. Ilyenek az összetett
statisztikai, vállalatirányítási, könyvtári rendszerek, a címtárak,
katalógusok, üzenetküldő rendszerek, e-boltok, naptárak és csak Webes
felülettel rendelkező alkalmazások is. Ezen területetek alkalmazásai
elképesztően változatos és hatalmas mennyiségű adatot tárolnak,
rendszereznek és tesznek elérhetővé felhasználóik számára. Minket ez az
elérhetőség izgat, de nem a felhasználói felületek oldaláról. Azok ugyanis
csak „emberi” felhasználásra lettek alkotva, a belőlük kinyerhető
tudás további felhasználása (például más forrásokkal való kombinálása) csak
nehézkesen, „manuális” eszközökkel lehetséges. Érdeklődésünket inkább
alkalmazásfejlesztői szempontok irányítják, s így inkább a rendszerek
külvilág felé nyitó programozói interfészei (API - Application Programming Interface)
és hálózati protokolljai izgatnak. Úgy véljük hogy ezek a kritikus pontok,
melyek nagymértékben meghatározzák a rájuk épülő alkalmazások
használhatóságát, szabadságát és természetesen azok fejlesztéséhez szükséges
ráfordítások nagyságát is.
Helyzetkép
Először azt
szeretnénk megmutatni hogy a sok-sok egyedinek tűnő rendszer és
alkalmazási terület elérésének módszerei nagyfokú rokonságot mutatnak
egymással. Ha ezt már beláttuk, könnyen megérthetjük majd, miért lehetséges,
fontos és előnyös is egyben őket egy megfelelően megtervezett,
általánosabb variánssal kiváltani. A hasonlóságok megfigyeléséhez egy kicsit el
kell távolodnunk az egyes területektől, a jól ismert fától az erdőt
effektus elkerülése érdekében. Láthatjuk majd, hogy szinte minden említett
terület funkcionalitása és jellemző képességei leírhatóak néhány
alapvető motívummal, s hogy a velük szemben támasztott követelményeink is
többnyire azonosak. Meglátszik, hogy többnyire hasonló elemekből is
építkeznek, és sajnos, többségük hasonló gyengeségekkel is bír. Ehhez nagyban
hozzájárul az is, hogy a fenti azonosságok nincsenek igazán kiaknázva. Lássunk
egy példát is rögtön. Az NIIF Névtár projekt keretében építenek közös címtárat,
ennek eszköze az LDAP-t (Lightweight Directory Access Protocol). A közös könyvtári
katalógus, a KÖZELKAT épít a Z39.50-re. Az IMAP (Internet Message Access
Protocol) pedig a mindannyiunk által használt elektronikus postai rendszer
egyik alkotóeleme, a postaládák kezelésére hivatott.
Vizsgáljuk meg
először egy kicsit az említett szabványokhoz tartózó programok
felhasználói felületét – hiszen ezek egyenes következményei a mögöttük megbúvó
technológiáknak. Miből is állnak ezek? Először is a szolgáltatásba
való bejelentkezésből (név + jelszó). Keresőablakból, ha van. Itt
megadjuk, hogy az éppen elérhető dolgok közül (tehát: cím, könyv, email)
melyek érdekelnek minket. Ehhez azok tulajdonságait kell legalább részlegesen
megadnunk (címtárnál: név, beosztás, telefon; katalógusnál: szerző, kiadó,
lelőhely; levélnél: postaláda, feladó, feladás ideje, stb.). Az eredményt
egy listában kapjuk meg. Általában böngészhetünk is az elemek között, melyek
ilyenkor hosszú-hosszú listában vannak, ezt többnyire rendezhetünk is. Esetleg
lehetőségünk van az elemekből vagy a találatokból csoportokat
képezni, azokat címkékkel látni el. Ennyi. Összefoglalva, ha van jogunk hozzá,
akkor dolgok között böngészhetünk, s keresgélhetünk azok tulajdonságai alapján.
Hasonló funkcionalitás, mégis eltérő felületek, különböző nehézségek,
többszöri tanulási folyamat. Minek? Miért nem lehet egy „ablakban” elintézni
mindezt? Ha mint alkalmazás fejlesztő a színfalak mögé látunk, mert
mondjuk a fenti rendszerekre támaszkodva kell egy könyvtárközi kölcsönző
rendszert építenünk, már a tervezéskor rádöbbenhetünk az említett hasonlóságokra.
Részletesebben megismerve magukat a szabványokat, protokollokat ez még inkább
nyilvánvaló lesz – mindegyik ugyanazokat a sémákat alkalmazza. Ennek ellenére
mégis eltérő módon kell őket kezelni, külön meg kell tanulni
mindegyik használatát, külön kell felismerni és kijátszani hiányosságaikat és
összehangolni biztonsági elemeiket. (Ráadásul – igaz itt komplexebb
kérdésről van szó – egyik szabvány sem elég „nyílt” ahhoz, hogy a
megvalósítandó könyvtárközi kölcsönzés megvalósításában különösebben segítségünkre
legyen.) Kutatásaink során többtucat szabvány programozói interfész (API) és
Internetes protokoll felépítését, működési mechanizmusát tanulmányoztuk –
ezeket tekintve az információ-áramlás elsődleges eszközeinek.
Azonosságokat, különbségeket, „egyéniségüket” és szükségességüket vizsgáltuk,
elsősorban alkalmazásfejlesztői szemmel. Ennek során különítettük el
az alábbi építőelemeket és jutottunk arra a megállapításra is, hogy szinte
mindegyik ezekből építkezik. Az egyes szabványok közötti eltéréseket inkább
ezek megvalósításának foka vagy teljes hiánya különbözteti meg.
Építőelemek
De akkor lássuk
inkább mik is ezek az alapelemek. Mindegyik interfész rendelkezik tehát
valamiféle azonosítási elemmel, melyen keresztül be kell jelentkeznünk, név és
jelszó, digitális aláírás, valamilyen szabvány szerinti megadásával –
ezekről az biztonsággal foglalkozó szekcióban sokat megtudhatnak. A
következő elem a metaadatok köre. Ezen keresztül egyrészt megismerhetjük
hogy milyen adathalmazok (objektumok, tulajdonságok, értékkészletek,
formátumok) állnak rendelkezésünkre. Az egyes szabványok szinte mindig csak egy
területet fednek le. Ezen kívül a metaadatok körébe tartózik az elérhető
kiegészítő szolgáltatások felsorolása, ezek általában a szabványok kiterjesztésének
módját szokták adni, és alkalmazásukra a kliens alkalmazásnak külön-külön fel
kell készülnie. Ilyen például az LDAP egyik kiterjesztése, mely a keresések
eredményhalmazának rendezését teszi lehetővé. Ugyancsak ide tartózik a
jogosultságaink megismerése is. A harmadik építőelem a keresés és
listázás. A tárolt információra jellemző tulajdonságok alapján kereséseket
indíthatunk, majd a megtalált elemeknek kiválasztott tulajdonságait kaphatjuk
meg. Ha az információ hierarchikusan szervezett, általában ezt is
kihasználhatjuk a keresésekben. Néhány szabvány támogatja az aktív kereséseket,
melynek segítségével a passzív kliensek is folyamatos jelentéseket kaphatnak az
elvárásaiknak megfelelő elemek változásairól – pld. a bejövő
postaládában megjelenő új levelekről vagy az üzenetküldő
szolgáltatásról (ICQ...) éppen távozó ismerőseinkről. A negyedik elem
az adatok módosítását teszi lehetővé. Szerkeszthetjük a már meglévő
elemeket, törölhetünk vagy éppen újakat vehetünk fel. Ezt a szolgáltatások
többsége támogatja, de meglepő módon a Z39.50 például nem. Tömeges
módosítás lehetősége, tehát mondjuk az összes elveszett könyvpéldány
törlése, szinte sehol sincs megvalósítva.
Az
építőelemeket az egyes alkalmazási területekhez való viszonyukat alapján
vizsgálva megállapíthatjuk, hogy az elérhető információk tartalma – hogy
elektronikus levelek (IMAP), szervezetek és személyek között (LDAP) vagy bármi
más között kutakodunk éppen –
egyáltalán nem teszi szükségessé egyedi, újabb elemek használatát a fent
említetteken kívül. Ellenben az hogy alkalmazás-specifikusan valósítják meg eme
építőelemeket, az magukat a szabványokat is alkalmazás-specifikussá
redukálja. Az pedig sokszor visszaüt használatuk során hogy a szabványok nem
valósítják meg teljes mértékben az egyes építőelemeket. A Z39.50 nem
támogatja az adatok szerkesztését – ez az egyirányúsága eleve korlátozza a
használhatóságát például egy közös katalógus építésében, hiszen ahhoz
feltehetően másodlagos infrastruktúra is van szükség.
Egységesítés
Az igazán érdekes
megállapítás viszont az, hogy szinte mindegyik vizsgált szabvány
funkcionalitása kiváltható lenne a relációs adatbázis-kezelés már meglévő
eszközkészletének csekély kiterjesztésével valamint az hogy valódi eltérés
köztük csak az őket leíró adatbázis sémában van. Szinte minden
elérhető információ-forrás szerkezete leírható táblákkal, mezőkkel és
kapcsolatokkal ami egy adatbázis-tervezésben jártas szakember számára nem nagy
feladat. Fontos ismét megemlítenünk, hogy jelen terv csak az adatok elérésével
foglalkozik, azok tárolása a már meglévő rendszerek feladata lenn továbbra
is – így a relációs sémával való leírás sem jelenti azt, hogy megkövetelnénk az
SQL szerverek használatát vagy az adatok konvertálását.
Sok ilyen
rendszer adatai ugyan már eleve relációs adatbázis-kezelőkben vannak
tárolva – tudvalevőleg a legtöbb LDAP, Z39.50 és IMAP szerver mögött is
ilyen szoftverek állnak. Találkoztunk olyan érvelésekkel az ilyen szabványokkal
kapcsolatban, melyek azokat előnyösebbnek tudják bemutatni a relációs adatbázisokkal
szemben. A megállapítások közül sok alapvetően tévedés, a
végkövetkeztetések viszonylagos helyessége pedig visszavezethető arra hogy
nem létezik szabadon felhasználható szabvány-infrastruktúra a relációs
adatbázis-kezelés területén. Csak cég-specifikus protokollok vannak, a termékek
saját szabványai (TDS, OCI) melyek viszont nem használhatóak fel az adott
terméktől (Sybase, Oracle, MSSQL, stb.) függetlenül. Így annak ellenére
hogy ezeket a szoftvereket sok esetben alkalmazzák a háttérben, az egyes
alkalmazási területek fejlesztői arra kényszerültek hogy csupán az
adatkommunikáció céljára új szabványokat alkossanak. Az már csak egy további
ballépés, hogy ezt szinte kizárólag a saját alkalmazási területükre és annak
specifikus adatsémájára fókuszálva tették, így újabb „nyílt de mégis zárt”
szabványokat hoztak. Ezekben természetesen mindig csak egy töredékét voltak
képesek nyújtani a relációs adatbázis-kezelésben megszokott funkcionalitásnak.
Sajnos az ODBC-jellegű próbálkozások sem nem értek el áttörést, az egyen-kliens
(egységes lekérdezőnyelv és protokoll) amit a Web-technológiának sikerült
elérnie az adatbázis-kezelés területén nem jött létre, holott az már eredeti
ODBC tervben még benne volt. Az alapvető gond tehát az, hogy nem létezik
olyan nyílt szabvány melyen keresztül bármilyen adatforrás elérhető lenne.
Mi úgy véljük
tehát hogy egyetlen alapoktól újragondolt interfész lefedhetné a sokfélre
rendszerhez való hozzáférés teljes spektrumát, és ez sok szempontból is hasznos
lenne. A legszembetűnőbb az lenne, hogy ha ezt a szabványt egyszer
megismerjük, akkor később bármilyen rendszerrel kommunikáló alkalmazást
könnyen tudunk majd írni. Az általános fejlesztések pedig nem csak egy-egy
területen jelentenének továbblépést. Ennek egyrészt a keresés és a szerkesztés jellegű funkciók terén van
jelentősége, hiszen ha az egyes alkalmazási területeket valamiféle
adatbázis sémává „redukáltuk” azok is könnyebben fejlődhetnek Másrészt ennek kiemelt fontossága van az adatbiztonság
területén is. A külön-külön fejlesztett szabványok összességükben csak lassan
reagálnak a felmerülő problémákra, megoldásokra. Jó példa erre az SSL/TLS
szabványok viszonylag lassú beépülése a HTTP-n túli protokollokba vagy az SRP
(Secure Remote Password) viszonylagos ismeretlensége. Az elképzelés nem új:
alkossunk olyan általános rendszert melynek segítségével könnyedén és
egységesen hozzáférhetünk bármilyen lokális vagy távoli adatforráshoz,
szolgáltatáshoz, így váltsuk le a cél-specifikus megoldásokat. Miután.
Alapelvek, részletek
Ezzel eljutottunk
a legnehezebb részig, elképzelésünk ismertetéséig. Ha az előzményeket
ismerjük, akkor elképzelésünk szükségessége és módja szinte már magától adódik.
Olyan protokollt szeretnénk alkotni, mely nem egy adott területet fed le, hanem
általánosan használható a strukturált adatok kezelése terén. Ahhoz hogy ez
valóban használható legyen, s elkerülje néhány hasonló próbálkozás
gyermekbetegségeit már a kezdetekkor szabvány programozói interfészt és
lekérdező nyelvet is definiálni kell hozzá. „Spagetti” infrastruktúra
alatt ezeken túl a segítségükkel, sőt kizárólagos használatukkal
létrehozott, további szolgáltatásokat értjük. Nagyon fontos, hogy néhány
alapvető elvet következetesen végig szeretnénk vinni minden egyes
komponens megtervezésekor – ennek megvalósíthatósága volt eddigi kutatásaink
egyik fő területe – ezek közül a fontosabbakat ismertetjük alább.
Az első,
hogy a már említett API, nyelv és protokoll hármason túl semmilyen eszközt nem
alkalmazunk – például kiegészítő formátumokat, leíró nyelveket, speciális
címtárakat (DTD, WSDL, MIB, stb.). Minden feladatra csak ezeket az eszközöket
alkalmazzuk, így a rendszer „önjáró” maradhat. Ez önkorlátozó lépésnek is
tűnhet, de ezzel elérjük, hogy a technológiát alkalmazó rendszerek között
később sem keletkeznek felesleges szakadékok. Az is emellett szól hogy így
nem odázzuk el a rendszer valós helyzetben történő alkalmazását, önmaga
megismertetését – ha ez nem sikerül, más sem fog. Lássunk néhány példát! Ha a
felhasználók azonosítását publikus kulcsokkal operálva is lehetővé akarjuk
tenni, akkor maguknak a kulcsoknak a közvetítésére is a saját rendszerünket
vesszük igénybe. Nem látjuk értelmét külön PKI (Public Key Infrastructure)
rendszer kialakításának, hiszen magukat a
kulcsokat ugyanúgy elérhetővé tehetjük adatbázis-szerűen.
Ugyanígy használhatjuk a saját rendszerünket az elérhető szolgáltatók
(információ-források) katalogizálására is. A Z39.50 esetében a szolgáltatások
felfedezésének nehézsége évek óta fennálló probléma, melyet több sikertelen
kísérlet és Webes katalógus után jelenleg a ZeeRex szabvánnyal próbálnak
megoldani, ami az XML formátum bevezetésével
bonyolítja a helyzetet – de ez már nem a min dolgunk.
Nagyon fontos
hogy a metaadatok, jogosultságok és a hibák kezelését is teljes mértékben az
alap lekérdező parancsok – SQL-es terminológiát használva a DML (Data
Manipulation Language) parancsokkal kb. SELECT/UPDATE/DELETE/INSERT –
segítségével kívánjuk megoldani. Ez könnyebbé teszi a forrás rendszertől
független leképezést a relációs sémára. A táblák, mezők, relációk leírása
ugyanúgy egy (esetleg virtuális) táblában helyezkedik el. A relációs elv
követése – vagyis az hogy minden tábla és mező, valamint hogy bármilyen
mezőkombináció alapja lehet a relációknak – olyan műveleteket fog lehetővé
tenni az adatok és a metaadatok kombinációjával, amelyek a hagyományos SQL
szerverekben jelenleg nem lehetségesek.
Egy másik elv a
kommunikáló felek egyenrangúsága. A rendszer „Peer-to-Peer” jellege ellenére
természetesen lesznek több tudással rendelkező (szerver jellegű) és
kíváncsibb (kliens jellegű) felek, de ez nem fog technikai nehézségeket
okozni olyan helyzetekben, ahol ellentétes irányú aktivitásra is szükség van.
Eseményekre való passzívan várakozó fél értesítéseket kaphat, vagy kérésre
további személyes információkat adhat át a másik félnek – természetesen a
felhasználó engedélyével. A meglévő protokollok többsége nem ilyen, hanem
aszimmetrikus felépítésű, a szigorú kliens-szerver megosztást követi. A
HTTP is ilyen, és ez komoly hiányosság több rá épülő szolgáltatás
megvalósításakor, mint például a SOAP. Emiatt kiskapukat kell kitalálni,
további trükkös megoldásokat, mint például fejlécekben való üzengetés. A
tervezett Spagetti rendszer ilyetén irány-függetlensége további elegáns
megoldásokat is lehetővé tesz majd, mint például adatok másolásának
kezdeményezését két távoli gép között, vagy a hibaüzenetek egyszerűbb
„visszaadását” a kérdező félnek.
Hasonló próbálkozások...
Mondhatnánk:
ilyen már készül, ilyen már lényegében van is és különben is minek? Nos ezekben
a kifogásokban van valami, de rá kell mutatnunk további megfigyelésekre is
melyek alátámaszthatják kezdeményezésünk szükségességét. Először is
mondhatnánk hogy mindez már megvalósult az ODBC-ben (vagy legalábbis valamelyik
variánsában: ADO, DAO, OLE DB)? Sajnos nem. Ezek ugyan lehetővé teszik
hogy különféle adatbázisokat elérjünk, de csak akkor ha ismerjük annak típusát
valamint rendelkezünk megfelelő meghajtó programmal hozzá. Az ODBC nem
tartalmaz gyártó-független protokollt és nem sikerült valóban egységes nyelvet
sem alkotniuk hozzá, így nem felel meg a céljainkra. Az adatforrások
kombinálása sem új ötlet, több egyetemi kutatási projekt is céljául tűzte
ki megvalósítását. Ezekkel az a gond, hogy bár nagyon jó ötleteket, módszereket
vetettek fel, elérhető, kipróbálható szoftver sehol sincs, csak elvi
dokumentáció (Garlic / IBM DB2, Mariposa, Nomenclator, Tukwila / Nimble,
Singapoore). Egyesek később kereskedelmi termékekké váltak eszméletlenül
magas árakkal és ehhez illően homályos dokumentációval vagy standard
szoftverek részeivé készülnek válni (DB2 Xperanto). A gond az hogy ebből
sosem lesz olyan közhasznú szoftver amelyet az Internetes közösség elvárna,
amely kreatív fejlesztőket is be tudna vonni az elérhető adatforrások
adaptálójaként – röviden amely valóban hasznos lehetne.
Az XML
természetesen elkerülhetetlen vetélytárs (vagy partner), szólnunk kell róla.
Nehéz hitelesen megmutatni, hogy miért nem tartjuk hatékony megoldásnak – nem
is magát az XML-t, hanem a köré csoportosuló szabványok halmazát, az általa
teremtett infrastruktúrát – és hogy miért tartunk szükségesnek egy másik, talán
konzervatívabb hozzáállást. Az XML-t alapvetően nem adatbázisok kezelésére
hanem strukturált szöveges állományok kezelésére, újszöveges leíró formátumok
kialakítására. A kapcsolódó szabványok is többnyire az XML „formátum” jellegét
használják ki, nem interfészeket alkotnak, nem adnak konkrét implementációkat.
A DOM (Document Object Model) jól használható ilyen dokumentumokhoz, de nem
adatbázisok ilyetén való manipulálására. Az XML adatstruktúrák leírására jól
használható ugyan, de inkább „emberi emésztésre”, hierarchikus szerkezete
technikai értelemben visszalépés. Az ilyen szerkezet csak egy lehetséges
összeállítása az adatelemeknek – ugyanúgy ahogy a fájlrendszerben a könyvtárak
is csak egy lehetséges csoportosításai a fájloknak. Az XML még a
kiegészítő szabványokkal együtt sem teremt olyan teljes és kiforrott
infrastruktúrát mint a hagyományos SQL adatbázis-kezelő szoftverek. A
hagyományos API, protokoll és lekérdező nyelv hármas felosztás itt nem
tiszta, a társ szabványok esetenként ugyanazokat a területeket fedik le, néha
pedig egy területet sem teljesen – az XQuery lekérdező nyelv például nem
képes módosításokat leírni csak kérdéseket, ezt a SOAP (Simple Object Access
Protocoll) szabvánnyal eszközeivel próbálják elfedni, amely az RPC szabványokat
hivatott kiváltani. A SOAP viszont ugyancsak nem életképes önmagában,
használatához egy újabb szabvány, a WSDL (Web Service Description Language)
szükséges. Véleményünk szerint a legfontosabb gond, hogy az alkotók kihagyták a
kezdeti tiszta lappal való kezdés előnyeit, a fentebb említett alapelemek
felismerését, és csak egy magasabb szintre vitték a már meglévő
problémákat. Újraimplementálnak de közben keveset lépnek előre. Vagy ami sokkal
valószínűbb egyáltalán nem gondoltak teljes körű adatbázis-kezelésre
a kezdetekkor.
Megvalósítás...
Ezen kitérő
után térjünk vissza ismét a saját tervünkhöz. Mit is akarunk létrehozni tehát?
Hogyan fog ez megjelenni a programozók, fejlesztők számára? Milyen nehéz
megvalósítani és milyen segítségre számítunk. Talán úgy tűnhet, hogy
tervünk megvalósíthatatlanul komplex és szerteágazó feladatot állít maga elé.
Mindent be akar kebelezni, mindent elérhetővé akar tenni, mindent
egységesíteni akar. Ez egyrészt igaz, bár inkább egy távlati cél, és ehhez mi
csak az alapokat akarjuk megteremteni. Azt adatok felhasználói és szolgáltatói
tudjanak mibe kapcsolódni és hogy meg tudják találni egymást. Az egyes
információ-források adaptálása nem a mi feladatunk. Hogy mindezt hogyan
képzeljük mindezt el, az könnyen levezethető a Web infrastruktúra
kialakulásának példájából.
A Web, vagyis a
HTTP és a HTML technológia kutatói környezetben jött létre, nem
profit-orientált alkalmazásként. Célja egyszerű volt, de azt jól ellátta.
Lehetővé tette képekkel, hangokkal kiegészített szöveges dokumentumok
megosztását. A használatához szükséges szoftverek ingyenesek és jogilag is
szabadon felhasználhatóak voltak. Véleményünk szerint ez elengedhetetlen volt
az elterjedésében. Ez a jelleg a további fejlődése során is megmaradt, a
Web-böngésző (IE, Netscape) és kiszolgáló szoftverek (Apache) továbbra is
szabad-szoftverek maradtak, még ha meg is jelentek kereskedelmi verzióik.
További támogatás nyújtott a Web beindulásának az Interneten szerveződő
csoportos szoftverfejlesztés tömegessé válása is. Számtalan ember látott neki
az említett szoftverek tökéletesítésének, javításának és kiterjesztésének. A
CGI (Common Gateway Interface) szabvány segítségével ezek a fejlesztők az
alkalmazások széles körét tették Webről elérhetővé – kezdetben talán
divatból is – és teszik még ma is. A felhasználók és a szolgáltatások számának
növekedése erősen ösztönzően hatott egymásra. A hatalmas felhasználói
réteg aztán a profitorientált szektort is ráébresztette, hogy érdemes
beszállnia, adaptálnia termékeit az új trendhez. Ekkor kezdődött a
Webesedés. Manapság már ciki ha valami nem babrálható Webes felületen –
véleményünk szerint már lassan a ló túlsó oldalán tartunk. Fontos tudni, hogy
az üzleti haszon jelenleg is inkább a technológia kihasználásából, a Weben
nyújtott kereskedelmi jellegű szolgáltatásokból, azok építéséből
valamint reklámokból jön össze és nem pedig az azt megvalósító szoftverek
fejlesztéséből. A Web technológia kifejlesztése tehát üzleti értelemben
nem érte meg a CERN kutatóinak, ők ebből fix hogy nem gazdagodtak meg
- a szellemi haszon mégis elképesztően nagy számukra is.
Úgy véljük, hogy
az általunk tervezett Spagetti infrastruktúra is csak ilyen jelleggel
életképes. Ezért tartjuk elképesztően fontosnak a nonprofit szféra
támogatását, mert ők nem csak képesek lehetnek belátni ez, hanem ez is a
feladatuk. Az olyan próbálkozások melyek kereskedelmi szoftver létrehozását
tűzik ki célul, széleskörű fejlődést technológiai sosem tudnak
elérni az Interneten. A rendszer egyes elemeit ezért alapos tervezés és zárt
jellegű kezdeti fejlesztés után szabad-szoftverként kívánjuk közzétenni.
Az egyes információ-források, vagyis forrás típusok (különféle adatkezelő
rendszerek, melyeket korábban említettünk) adaptálását pedig megfelelő
interfész és fejlesztői eszközkészlet létrehozásával kívánjuk
elősegíteni. Mi csak a magot akarjuk létrehozni (elvetni) a munka
nagyobbik része már mások feladata. Azt viszont már most látni lehet, hogy az
ezt kihasználó szolgáltatások hatalmas lehetőséget nyújtanak mind az
üzleti vállalkozások számára is. De nem csak nekik, nekünk is.
Ha a leírtak felkeltették a
kíváncsiságát, kérdései vannak, esetleg kedve támad segítni valamiképp eme terv
megvalósításában, kérjük jelentkezzen. Örömmel fogjuk venni bármilyen
észrevételét.
© Kardos András (andris@pronet.hu
/ 06-30-275-4660)