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)