Zajištění efektivního přístupu k informacím v prostředí univerzity

Zajištění efektivního přístupu k informacím v prostředí univerzity

Jan Pazdziora, Fakulta informatiky, Masarykova univerzita, Brno
adelton@fi.muni.cz

Kategorie: Technologie a služby -- Univerzitní informační systémy

Ve svém příspěvku ``Administrativní server'' prezentoval na loňském RUFISu Ing. Michal Brandejs, vedoucí Centra výpočetní techniky Fakulty informatiky MU v Brně, řešení administrativních a komunikačních potřeb členů fakulty. V tomto článku se zaměříme jednak na technické aspekty takového řešení, jednak uvedeme obecné zásady, které dovolují s malými náklady značným způsobem zpružnit výměru informací v organizaci, a tím i celý její chod.

Abstrakt

Zkušenost Fakulty informatiky MU ukazuje, že stávající komunikační technologie a otevřenost ve standardech dovoluje přenést značnou část administrativních a komunikačních úkonů prováděných studenty, učiteli i ostatními členy fakulty na informační systém, postavený na otevřeném protokolu Secure HTTP. Takové řešení by mělo mít rozumný počáteční návrh a podporu vedení, pak není ani nákladné, ani náročné na implementaci, samozřejmě pokud zvážíme jeho přínos. Základní podmínkou využití Internetu jako média pro provoz informačního systému organizace je zajištění soukromí uživatelů -- uživatel musí mít povoleno pracovat jen s těmi údaji, se kterými ze své pozice v organizaci pracovat smí, na druhé straně by měl být schopen přistupovat neomezeně ke všem takovým datům. Zaměříme se na technologie z oblasti free softwaru, které se ukazují být výhodnými nejen z finanční stránky, ale i proto, že díky své otevřenosti dovolují snadné propojení s existujícími (i proprietárními) systémy i rozumnou rozšiřitelnost při měnících se požadavcích organizace. A v neposlední řadě je to právě duch poznávání, který by měl vést univerzity k otevřeným a progresivním technologiím.

První impuls

Prvním úkolem, který dal vzniknout Administrativnímu serveru FI, byla registrace předmětů v nově zavedeném kreditním systému studia, někdy v polovině roku 1995. Každý student měl ještě před začátkem semestru vyjádřit své přání navštěvovat jisté předměty, a tyto údaje se měly stát podkladem jak pro tvorbu rozvrhu, tak například i pro nevypsání předmětů, o které nikdo neprojeví zájem. Základními požadavky bylo zajištění rozumného přístupu pro všechny studenty fakulty a ošetření toho, aby si až na některé definované předměty typu angličtina student nemohl znovu registrovat předmět, který již jednou úspěšně absolvoval.

Kromě těchto funkčních zadání jsme chtěli zajistit co nejširší použitelnost systému, a proto byl od začátku zvolen protokol Secure HTTP, který se později stal de facto standardem pro podobné aplikace. Díky tomuto řešení se může vývojář spolehnout na jednotné prostředí na straně klienta (prohlížeč HTML) a svou energii může soustředit na vývoj aplikace na serveru. Po celou dobu, od chvíle, kdy většina uživatelů používala terminálový Lynx či Netscape ve verzi 1.1, až po stávající verzi 4.05, jsme se snažili o maximální konzervativnost -- na straně klienta tedy nepředpokládáme nic více než HTML prohlížeč. Java či jiné ``aktivní'' technologie, které průběžně zvažujeme, nejsou dostupné ve všech používaných prohlížečích či na všech platformách. Proto bychom je nemohli použít na základní funkce, které musejí být dostupné vždy, byly by stále jen rozšířením či alternativou.

Identifikace uživatelů

Zadání požadovalo, aby si předměty mohl registrovat každý student. Bylo tedy zapotřebí zajistit autentikovaný přístup všem studentům fakulty. Navíc bylo nutné povolit registraci jen studentům řádně studujícím. Zde jsme využili faktu, že takřka všichni studenti v té době měli uživatelský účet na Unixových stroji, kde mimo jiné přijímali poštu. Začali jsme tedy se seznamem těchto uživatelů, a na jeho základě vystavěli tzv. databázi People. Tato obsahuje jednak základní osobní údaje, jednak data o studiích osoby, později přibyly údaje o zaměstnání. Zpětně se evidence Unixových účtů stala jednou z aplikací na touto databází. Podstatné je, že se podařilo již v počátku vybudovat databázi fyzických osob. Tento fakt může znít triviálně, ale stávající agendy jak studijní, tak personální, na Masarykově univerzitě používané, tento pojem neznají. Pokud student zároveň (či po sobě) studuje vícekrát, je pro každé toto studium veden separátní záznam, ale bez vztahu k ostatním záznamům této osoby. (Pomineme-li nejednoznačné, nespolehlivé a třeba u cizinců úplně chybějící rodné číslo.)

Naším cílem ale od počátku bylo vytvořit jeden vstupní bod administrativních agend fakulty, kde uživatel najde záznamy o všech svých studiích, zároveň se záznamy o pracovních poměrech a zbývající dovolené, atd.

Uživatelé navíc mají na Administrativním serveru stejný login a počáteční heslo, jako na Unixových strojích fakulty, což je pro většinu studentů i zaměstnanců základní pracovní prostředí, už jen třeba kvůli příjmu elektronické pošty. I tato jednotnost přispěla značným dílem k akceptování této služby jako důležitého komunikačního prostředku členů fakulty.

Propojení a zastřešení stávajících agend

Požadavek, aby si každý student registroval předměty ke svému studiu, znamenal propojení s agendami studijního oddělení, vedenými v aplikacích napsaných ve FoxPro. Po zvážení možných přístupů jsme zvolili styl dávkového zpracování, kdy pracovnice studijního oddělení po provedení změn či zadání nových záznamů spustí přenos DBF souborů na Administrativní server, kde jsou případné změny detekovány a zpracovány. Přenos spouští na studijním oddělení dle svého uvážení, vždy po takových změnách se svých evidencích, které mohou mít vliv i na chování Administrativního serveru. O těchto dávkových změnách jsou generovány a e-mailem zasílány zprávy, což umožňuje snadnou zpětnou kontrolu.

I přesto, že na Administrativním serveru vzniklo postupně mnoho nových aplikací, spolupráce se stávajícím softwarem na univerzitě je stále důležitá. Jak studijní, tak personální oddělení fakulty jsou primárními producenty některých dat, která Administrativní server pouze přejímá. Tato data jsou dokonce v mnohém ohledu ta nejdůležitější, neboť jsou to data o osobách, na nich tedy staví systém identifikace a autentikace. Na jejich správnosti a aktuálnosti záleží, zda uživateli bude správně zpřístupněno vše, co mu zpřístupněno být má.

Stejně tak existují systémy, které přebírají výstupy z Administrativního serveru, opět buď dávkově, či přímo v reálném čase.

Pro stávající aplikace, které jsou důležité pro běh organizace a musejí být podporovány, se používá termín legacy systems. Administrativní server je do značné míry pouze komunikačním kanálem a pojítkem mezi těmito systémy. Pro každou takovou aplikaci bylo nutné najít způsob propojení (ruční, automatické, dávkové) a pečlivě zvážit detaily přenosu dat, technické aspekty takového propojení i jeho důležitost, která například určuje, jak častou aktualizaci potřebujeme. Přenos údajů o realizovaných hovorech z telefonní ústředny je spouštěn jednou denně, aktualizace hromadných seznamů elektronické pošty podle databází lidí se aktualizuje po každé změně, přenos nových fotografií potřebných pro identifikační karty spouští pracovník, který studenty a učitele fotografuje. Zajímavou aplikací je propojení se zabezpečovacím systémem budovy. Je realizováno daemonem, který využívá modemového spojení s ústřednou, takže oprávnění zaměstnanci fakulty mají možnost třeba z domu v prohlížeči zkontrolovat zastřežení jednotlivých částí budovy, prohlížet historii i v reálném čase zastřežovat či odstřežovat. Většina aplikací vytvořených v rámci Administrativního serveru pracuje samozřejmě v reálném čase, ať již jde o registraci a zápis, zápisník učitele a hodnocení, evidence identifikačních karet, nejrůznější seznamy, včetně rozvrhu hodin, který (díky znalosti toho, co si daný student zapsal a které předměty učitel vyučuje) je možno zobrazit přímo šitý na míru pro každou osobu zvlášť.

Pro uživatele je zásadní, že informace, ke kterým se na serveru dostává, jsou prezentovány konzistentně, že server stírá rozdíly mezi různými aplikacemi. Uživatele totiž příliš nezajímá, že z důvodu hierarchického či jiného členění organizace pocházejí data z různých zdrojů -- pokud jsou to data, ke kterým má právo přístupu, musí tento přístup být co nejjednodušší, nejlépe z jednoho či několika jasně definovaných vstupních bodů. Administrativní server tento vstupní bod poskytuje.

Praktické nasazení technologie

Přijetí Administrativního serveru, který nyní v sobě koncentruje většinu komunikačních a administrativních procesů, které na fakultě mezi jejími členy probíhají, nebylo okamžité a automatické. Existovali uživatelé, kteří měli pocit, že zadáváním údajů přímo do systému a nikoli na papír, který pak musí někdo jiný přepsat, zvyšuje nároky na ně kladené. Pozitivní přístup ale nakonec převážil, nejen kvůli mnoha dodatečným funkcím, které systém poskytuje, ale i proto, že uživatelé brzy zjistili, že pracují v reálném čase s aktuálními údaji, že je odstraněna nutnost žádat o data, která jsou tak jako tak v počítači uložena, že práce je mnohem flexibilnější.

K tomu přispívá i množství výstupů, které systém dává k dispozici -- uživatel má například ve svém prohlížeči aktuální telefonní seznam, může ho ale jedním stiskem tlačítka myši vytisknout pěkně zformátovaný na fakultní tiskárně.

Zde je třeba říci, že studijní oddělení na jiných fakultách naší univerzity jsou typicky mnohem méně vstřícná než studijní na FI. Teprve na nich by se pravděpodobně ukázalo, jak velký význam má odstranění úředníků z procesu komunikace mezi studenty a učiteli. Na druhou stranu se ale dá předpokládat, že méně osvícený úředník by rozšíření počítačů bral jako útok na svou osobní pozici, nikoli jako pomoc ve své práci, jak je tomu u nás.

Volně šiřitelné softwarové nástroje

Při volbě prostředí, ve kterém bude Administrativní server vyvíjen a provozován, hrála nezanedbatelnou roli zkušenost autorů s Unixovými systémy. Tvorba skládáním z více produktů je zde zcela běžná (klasický příklad sort | uniq | wc -l), výsledkem je pak aplikace s definovanými rozhraními, která umožňuje jak postupný vývoj jednotlivých modulů, tak jejich případnou snadnější náhradu. Svou roli sehrála samozřejmě cena i podpora volně šiřitelných produktů, a také fakt, že v roce 1995 komerční firmy začínaly s Internetem teprve pouze lehce koketovat.

Uvedeme zde jak produkty, které jsme použili, tak ty, které jsou vhodnou alternativou.

WWW server:

Apache -- http://www.apache.org/

Nejrozšířenější WWW server, s aktivním vývojem, s modulární architekturou. Díky ní je možno použít moduly mod_html či mod_czech, které automaticky provádějí převod mezi znakovými sadami HTML odpovědi podle požadavku klienta, případně podle jeho typu. Výhodná je i možnost alternativních jazykových verzí odpovědí.

Bezpečnou komunikaci pod Apachem zajistíme pomocí SSLeay.

Skriptovací jazyky, CGI skripty, aktivní obsah stránek:

Perl -- http://www.perl.com/

Jazyk se silnou podporou regulárních výrazů, s mnoha objektovými moduly, které zjednodušují často opakované činnosti. Tentýž modul či skript je možno použít jak pro CGI skripty, tak pro terminálové aplikace. Pomocí rozhraní DBI je možno přistupovat k veliké šíři databázových serverů. Integraci Perlu přímo do kontextu Apache umožňuje mod_perl, existuje i možnost vložit Perlovský kód přímo do HTML, a tento nechat provádět jako SSI.

PHP/FI, PHP3 -- http://www.php.net/

Jazyk určený pro začlenění akcí přímo do HTML. Poskytuje rozhraní na mnohé databázové systémy.

Relační databáze:

MySQL -- http://www.mysql.com/

PostgreSQL -- http://www.postgresql.org/

MiniSQL -- http://www.hughes.com.au/

Všechny zahrnují základní SQL funkce a operace, liší se v rozšířeních, a také podporou, kterou autoři poskytují. Různé jsou také licence a cena pro komerční použití.

Při vývoji se ukázalo, že je vhodné často opakované postupy zapsat v modulech, čímž vznikne centrální místo pro provádění klíčových změn, a také různí autoři budou používat kompatibilní rozhraní. Nejvýrazněji se to projevilo v modulu pro generování vizuálních prvků výstupních HTML stránek. Autoři skriptů se mohou soustředit na programování vlastních funkcí, otázky typu ``jaký font používáme na titulek'' řeší modul transparentně a automaticky. Důležitou je také otázka dokumentace, neboť po vytvoření centrálního modulu na jisté akce je zdokumentování výsledného díla přirozené, neboť pomáhá jak původnímu autorovi, tak ostatním.

Obecná doporučení

Při budování informačního systému univerzity je důležité se předem rozhodnout, zda má systém sloužit pouze vedení a úředníkům, nebo všem členům. Stávající systémy jsou vesměs omezeny na velice úzkou skupinu uživatelů, jako je studijní, personální či ekonomické oddělení, nanejvýš přidávají některé funkce pro management, typu ``kolik studentů máme dnes v oboru chemie''. Administrativní server zavedený na FI MU ale představuje kvalitativně novou úroveň, neboť jeho uživateli jsou potenciálně všichni lidé, o nichž systém vede jakékoli údaje. Pokud studijní oddělení (či učitel) zadává studentovi do počítače výsledné hodnocení předmětu, je nanejvýš vhodné, aby tuto informaci mohl student získat bez nutnosti komunikovat se studijním, třeba v deset hodin večer, prostřednictvím modemu ze svého domu. Tím, že lidé, dosud pouze záznamy v databázích, se stávají aktivními uživateli, se systém stává vskutku funkčním, neboť informace jsou stále a okamžitě dostupné, bez lidských prostředníků.

Největším problémem u obdobných systémů, které musejí korektně rozlišit a obsloužit tisíce uživatelů, je jednoznačná identifikace osob. Vyčištění duplicit, překlepů a nedostatků nebylo triviální ani na (tehdy) malé a začínající fakultě, v kontextu celé univerzity se zatím zdá být tvrdým oříškem. Pořádek v datech je ale nutný, neboť v elektronickém informačním systému o zpřístupnění informací rozhoduje nikoli úředník podle znalosti (obličeje) osoby, ale stroj, na základě loginu a hesla, a na základě znalosti atributů dané fyzické osoby. Fakt, že uživatel není vystaven libovůli úředníků -- správců dat, je příjemný, systém ale musí neustále reflektovat co nejpřesněji faktický svět.

Budovaný systém, tím, že zasahuje všechny lidi na škole, musí velice přesně vyhovovat jejich požadavkům. Je možné představit si, že po nákupu a zavedení nového ekonomického software projdou pracovníci ekonomických oddělení školením, takové školení je ale u celé fakulty či univerzity nemyslitelné. Z tohoto důvodu považuji za velmi vhodné, aby se škola na vývoji takového systému alespoň jistou měrou podílela. Informační systém univerzity není systém o cihlách, je to především systém o lidech (jako klientech organizace a produktech zároveň) a pro velké množství lidí.

Jako vývojové nástroje se velmi osvědčily volně šiřitelné softwarové produkty. Podpora poskytovaná prostřednictvím newsových skupin či konferencí, je nesrovnatelná s podporou, kterou typicky poskytují producenti komerčního software, podstatná je velmi rychlá oprava nalezených chyb i otevřenost garantovaná dostupností zdrojových textů. Neříkáme, že systém není možno vytvořit za pomoci komerčních nástrojů -- jejich zvládnutí je pravděpodobně důležitější než kvalita či cena sama. Pouze považujeme za nutné zmínit, že takový informační systém je možné rozumně rychle a kvalitně pomocí volně šiřitelného software vybudovat a udržovat. Univerzity mají navíc možnost získat bez finančních nákladů i produkty, které třeba pro komerční použití zdarma nejsou.

Literatura

Jan Pazdziora, *1974, absolvoval Fakultu informatiky Masarykovy univerzity v Brně v roce 1997, nyní je postgraduálním studentem na téže fakultě.