Zprava o projektu VOMS

Obsah

1 Uvod 11.1 Cıl projektu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Charakteristika resenı . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Strucna specifikace 2

3 Architektura systemu 53.1 VOMS Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.2 Certifikacnı autority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.3 Business modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.4 Klientske aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.5 Prehled systemu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.6 Konkretnı resenı . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.7 Moznosti deploymentu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4 Delba prace uvnitr projektu 10

5 Stav projektu 10

6 Odhad termınu dokoncenı 10

7 Prehled znamych rizik 12

1 Uvod

Vetsina firem disponuje katalogy svych nabıdek (ev. pozadavku) prostrednictvım vlastnıch informacnıchsystemu, typicky s rozhranım do sıte internet. Tento zpusob je v nekterych prıpadech neefektivnı afirmy musejı zmınene katalogy duplikovat do systemu zprostredkovatelu, kde se teprve shleda nabıdka spoptavkou. To prinası nemale ztraty kapacit pri exportech dat a na platbach zprostredkovatelum, ale take

1

na ukor bezpecnosti - obcas je totiz nutne exportovat data, ktera by firma jinak mohla ponechat v tajnosti(napr. jmeno a adresu odpovedne osoby, telefonnı spojenı na konkretnı zamestnance apod.). Projektby mel realizovat prostredı umoznujıcı one-to-one marketing i prodej, tj. prıme propojenı nabıdky apoptavky.

1.1 Cıl projektu

Cılem tohoto projektu je vytvorit elektronicke prostredı trhu. To jest zajistit automaticke shledavanınabıdky s poptavkou a zajistit provedenı obchodnı transakce mezi nemi.

Prınosem projektu by mela byt implementace prostredı trhu s ohledem na maximalnı konfigurovatelnosta adaptibilitu systemu podle narodnıho prostredı, druhu nabızenych resp. poptavanych statku a typuosob vyuzıvajıcıch systemu. Dalsımi vlastnostmi systemu by mely byt bezpecnost, distribuovanost (sohledem na celosvetove vyuzitı), prenositelnost a znovu pouzitelnost systemu.

1.2 Charakteristika resenı

Projekt je resen jako trıvrstvy system. Prvnı vrstva zajist’uje zakladnı a pro vsechny uzly systemuVOMS spolecne sluzby publikovanı a vyhledavanı informacı a podporu pro komunikaci. Druha vrstva(aplikacnı, nebo take business vrstva) zajist’uje spravu profilu nabızejıcıch a poptavajıcıch osob. Do tetovrstvy tedy patrı vlastnı spojovanı nabıdky a poptavky a realizace obchodu. Tato vrstva muze byt prodany uzel specificka. Tretı vrstva (prezentacnı) zajist’uje komunikaci s uzivatelem, nebo integraci s jinymsystemem (naprıklad vnitropodnikovym IS).

Jako referencnı specializace systemu VOMS bude vytvoren system pro nabıdku a poptavku pracovnıchmıst. Jako specificky prıpad nabızejıcıch a poptavajıcıch osob budou uvazovany: uchazec o zamestnanı,zamestnavatel a zprostredkovatel zamestnanı. Zamestnanec, jako nabızejıcı osoba, bude prezentovatsvuj zivotopis. Jako poptavajıcı osoba bude zamestnanec vyhledavat v nabıdkach zamestnanı, nebobude poptavat ruzne sluzby jako jsou rekvalifikace, ruzna skolenı apod. Naopak zamestnavatel, nebozprostredkovatel zamestnanı budou vyhledavat vhodne zamestnance pro volne pracovnı posty, nebobudou sami nabızet pracovnı prılezitosti, nebo jine sluzby jako jsou skolenı, kurzy apod.

Z duvodu maximalnı prenositelnosti a moznosti integrace s jinymi systemy je system VOMS implemen-tovan v jazyce Java 2 za podpory technologiı EJB, Web Services, XML a RDF.

2 Strucna specifikace

V tomto oddıle bude popsan system VOMS z hlediska potreb uzivatelu, neboli budou zde strucne popsanyprıpady uzitı systemu VOMS. Na obrazku 1 je zobrazen strucny Use-Case diagram, ktery zobrazuje osobya jim prıstupne funkce.

Uved’me nejdrıve popis osob.

Osoba – je libovolna fyzicka, nebo pravnicka osoba vyuzıvajıcı system VOMS na uzivatelske urovni.Osoby rozlisujeme podle toho, na jake strane trhu operujı. Rozeznavame osoby

2

Obrazek 1: Prehled uzitı systemu VOMS.

3

poptavajıcı – ktere vyuzıvajı trhu ke koupi urciteho statku a

nabızejıcı – ktere vyuzıvajı trhu k prodeji svych statku.

Vyse uvedene oznacenı je zavedeno prave z duvodu pouzitı systemu VOMS jako elektronickehotrhu, i kdyz jeho uplatnenı muze byt mnohem vetsı. Pro poptavajıcı resp. nabızejıcı osobu by selepe hodilo oznacenı konzument resp. provider.

Dalsımi vyznamnymi pojmy projektu VOMS jsou profil, statek a obchodnı transakce.

Profil – je souhrn vlastnostı osoby (to mohou byt informace o osobe, nabızene statky, transakce, pre-ference apod.), ktere jsou v systemu VOMS pro tuto osobu vedeny. Nektere z techto vlastnostıjsou verejne dostupne (jinym osobam, zpravidla na opacne strane trhu), jine jsou naopak pouzeprivatnı.

Statek – je predmetem obchodu. Statkem muze byt zbozı, sluzba apod. Podobne jako v prıpade po-ptavajıcıh resp. nabızejıcıch osob muze byt statkem cokoliv. Neexistuje omezenı na druh objektuprezentovanych v systemu VOMS. Jelikoz je ale system VOMS primarne urcen pro vytvorenıelektronickeho trhu, budeme pouzıvat pojem statek.

Transakce (obchodnı) – je procesem vymeny informacı mezi nabıdkou resp. poptavkou za ucelemprodeje resp. koupe urciteho statku vrcholıcım bud’uzavrenım obchodu, nebo jeho zrusenım.

VOMS – Volny obchodnı a marketingovy system. Zkratka tohoto projektu.

Nynı muzeme prejıt k popisu systemu a jejich funkcı.

System VOMS – bude slouzit jako prostrednık styku osob nabızejıcıch a poptavajıcıch. Jeho funkcejsou

„Novy uzivatel“ – zajist’uje registraci novych uzivatelu,

„Operace s profily“ – dovolujı ruzne nastavovat preference pro praci v systemu, importovat aexportovat data apod.,

„Hledanı statku“ – zahrnuje zalozenı noveho dotazu, vyhledavanı, trıdenı vyhledanych statkupodle relevance a podle preferencı uzivatele u predchozıch dotazu, mazanı vysledku hledanıa samotnych dotazu,

„Obchodnı transakce“ – dovolujı zalozit novou obchodnı transakci, prochazet jednotlivymikroky, anebo ji poprıpade zrusit a nakonec smazat,

„Operace nabıdky“ – dovolujı publikovat nabızene statky prostrednictvım sıte VOMS, tj. prida-vat a rusit statky.

Dulezitou vlastnostı systemu je take zajistenı autenticity a ochrany dat. Pro zajistenı autenticitydat je zavedena certifikacnı autorita systemu VOMS. Ochrana dat je provedena jednak sifrovanımkomunikace pri transakci a jednak ochranou privatnıch dat osobnıch profilu.

Certifikacnı autorita (CA) – je garantem pravosti dat publikovanych v sıti VOMS. Konkretne musı bytkazda osoba vyuzıvajıcı sıt’VOMS registrovana u teto CA, aby mohla publikovat sva data. FunkceCA jsou

4

„Registrace osoby“ – dovoluje jiz zmınenou registraci osoby. Pri teto registraci osoba zada za-kladnı informace o sobe. Naopak od CA zıska certifikat jako overenı pravosti dat.

„Overenı autenticity“ – dovoluje dvema jednajıcım osobam vzajemne si overit pravost prezen-tovanych dat. (Naprıklad jmeno spolecnosti, danove, nebo identifikacnı cıslo apod.)

3 Architektura systemu

V tomto oddıle jsou popsany jednotlive casti systemu VOMS. Nejdrıve jsou uvedeny jejich strucnecharakteristiky. Dale v oddıle 3.5 je uveden prehled castı systemu VOMS a tok dat mezi nimi. Nakonecv oddıle 3.6 je uvedeno konkretnı rozvrzenı komponent a v oddıle 3.7 jejich mozny deployment.

3.1 VOMS Core

VOMS Core je nazyvan subsystem systemu VOMS, zajist’ujıcı pouze zakladnı sıt’ove a vyhledavacı sluzby,potrebne pro podporu aplikacnı logiky systemu (viz Business modul). Konkretne bude subsystem VOMSCore zajist’ovat tyto sluzby:

• publikovanı informacı v ramci sıte VOMS a

• zajistenı autentifikace publikovanych dat, dale

• zıskavanı publikovanych dat vyhledavanım v ramci cele sıte VOMS a

• zasılanı zprav jako podpurnou cinnost. (Nelze totiz pouzıt standardnıch technologiı, nebot’adresatnenı identifikovan adresou, jako naprıklad URL, ale obecnym identifikatorem URI.)

Urcitou podobnost tohoto subsystemu lze hledat u webovych vyhledavacıch serveru.

3.2 Certifikacnı autority

Certifikacnı autorita (zkracene CA) je specialnı sluzba, ktera overuje identitu osoby. Tyto autority mohoubyt usporadany ve stromove strukture. Naprıklad podnikova CA by osoby v ramci podniku neoverovala.Dokonce pri nasazenı pouze v ramci podniku resp. organizace nenı overovanı identity nutne - identita seoverı zalogovanım k serveru.

3.3 Business modul

Business modul zajist’uje aplikacnı logiku systemu VOMS. Ma za ukol spravovat profily uzivatelu sys-temu, publikovat nabızene zbozı prostrednıctvım subsystemu VOMS Core, nebo naopak zprostredkovatjejich vyhledanı a zprostredkovat obchodnı transakci mezi nabıdkou a poptavkou. Dalsı dulezitou vlast-nostı je moznost importu a exportu dat z profilu (naprıklad import seznamu nabıdek, nebo export seznamupotvrzenych obchodnıch transakcı).

5

3.4 Klientske aplikace

Pro verejne prostredı, nebo jako intranetovy klient bude vytvoren WWW klient pomocı JSP stranek,nebo Java Servlets.

Pro vnitrnı potreby organizacı/podniku muze byt vzhledem k velke skale ruznych run-time prostredıpouzito Java Beans technologie. Takove komponenty lze pouzıt bud’jako Java Beans, nebo jako Active Xkomponety.

3.5 Prehled systemu

Na obrazku 2 je zobrazen system VOMS v hrubych rysech. Kazdy obdelnık predstavuje nezavisly modulv systemu. Spojnice a sipky popisujı tok dat mezi moduly. V nasledujıcım oddıle jsou tyto modulykonkretizovany do komponent tak, jak jsou implementovany.

Obrazek 2: Prehled systemu VOMS.

V nasledujıcım seznamu je uveden popis modulu uvedenych na obrazku. Nektere z nich jiz byly zmınenyv predchozıch oddılech.

6

Client – Klientska aplikace. Prozatım bude implementovan tenky WWW klient. Serverova cast budeimplementovana pomocı JSP stranek. V budoucnu mohou byt vytvoreny bud’nejake komponentyintegrovane do IS zakaznıka, nebo samostatna Java aplikace (tlusty klient).

VOMS Site – Sıt’systemu VOMS. Obsahuje vsechny uzly systemu VOMS. Pro navigaci mezi uzly budepouzito specialnı routovanı, ktere bude smerovat pozadavky podle jejich obsahu a bude pouzıvatadresaci nezavislou na lokaci objektu (tj. obecnou URI namısto naprıklad URL).

Business Module – Modul, ktery bude implementovat logiku potrebnou pro zprıstupnenı sluzeb sys-temu uzivateli. Vıce viz predchozı oddıl 3.3.

VOMS Core – Jadro systemu VOMS. Obsahuje sluzby pro publikovanı dat, sluzby pro vyhledavanıa sluzby zasılanı zprav. Dalsı vlastnostı komponenty je zajistenı distribuovanosti systemu (tj.napojenı na sıt’VOMS). Vıce viz predchozı oddıl 3.1.

Admin Modul – Modul pro administraci. Bude provadet vyhrazene operace, jako udrzbu RDF Storage,nebo nastavovanı nekterych parametru subsystemu VOMS Core a Business Module.

RDF Storage – Datove uloziste formatu RDF s podporou rychleho vyhledavanı (matchovanı) dat.

Business data – Uloziste dat vyuzıvanych business modulem. V budoucnu muze byt pouzito i proreplikaci dat z VOMS Core (resp. z RDF Storage).

Admin data – Uloziste dat vyuzıvanych administratorem systemu.

3.6 Konkretnı resenı

Referencnı resenı se bude skladat z komponent uvedenych na obrazku 3. Jako klientska aplikace je zdeuveden WWW klient a JSP stranky. Administratorsky modul je rozdelen do dvou komponent. Pricemzkomponenta Company Admin je pouzita pouze v prıpade privatnıch business modulu (viz nasledujıcıoddıl 3.7). Uloziste dat jsou zde pouze dve a to privatnı a verejne. Privatnı je pouzıvano komponentouBusiness Module pro ulozenı uzivatelskych profilu. Verejne uloziste obsahuje data verejne publikovanapomocı subsystemu VOMS Core. Datova uloziste administrativnıch modulu zde nejsou uvedena, jelikoznejsou vyznamna. Spojnice mezi komponentami naznacujı zavislost a jejı smer.

Jelikoz je seznam komponent temer totozny se seznamem castı uvedenych v prehledu systemu, uvedemepouze strucny popis komponent.

VOMS Core – Jadro systemu.

Business Module – Business logika.

JSP Client – Konkretnı, webovy klient.

WWW Browser – Webovy prohlızec.

Public Storage – Uloziste dat pro komponentu VOMS Core.

Private Storage – Uloziste dat pro komponentu Business Module.

7

Obrazek 3: Prehled komponent.

8

Admin Module – Administrativnı modul.

Company Admin – Administrativnı modul pouze pro Business Module komponentu.

Vyhodou tohoto rozdelenı na komponenty je jejich nezavislost a moznost jejich spustenı na odlisnychpocıtacıch. Nejprirozenejsı umıstenı komponent si uvedeme na dvou prıkladech v nasledujıcım oddıle.Ale jak bylo receno, je mozne umıstit tyto komponenty zcela libovolne.

3.7 Moznosti deploymentu

Prvnım prıkladem je umıstenı vsech serverovych castı na jeden pocıtac. Tento prıklad, zobrazeny naobrazku 4, je typicky pro verejny server VOMS, ktery nabızı naprıklad prezentovanı volnych pracovnıchmıst na internetu.

Obrazek 4: Prıklad umıstenı komponent.

Modre, trojrozmerne kvadry na obrazku predstavujı pocıtac, konkretneji muzeme uvazovat jednu instanciJVM (Java Virtual Machine). Dvourozmerne dekorovane obdelnıky predstavujı komponenty a spojnicese sipkami tok dat a jeho smer mezi komponentami.

Zajımavostı tohoto modelu je snad pouze jednotna administrace serverovych komponent. KomponentyPrivate Storage a Public Storage mohou sdılet data.

9

Dalsım prıkladem rozmıstenı komponent je prıklad, kdy system VOMS vyuzıva nejaka firma. Tato firmachce mıt pevnejsı kontrolu nad svymi daty, upravovat si logiku systemu, nebo pristupovat k svym datumoff-line. Tento prıklad zobrazuje obrazek 5.

Komponenty Business Module a Private Storage jsou naprıklad umısteny na pocıtaci uvnitr firmy.Zaroven je v tomto prıpade nutne oddelit administraci komponenty Business Module. Klient je v tomtoprıklade opet webova (ale tentokrat intranetova) aplikace.

4 Delba prace uvnitr projektu

Jmeno Cast

Malenko Jaromır Routovanı pozavku nabıdka/poptavka. Resenı relokace resource (URI vs. URL).

Pravda Michal Klient: JSP provedenı.

Samek Jirı Certifikacnı autorita: Sprava uzivatelskych profilu a jejich certfikatu.

Starosta Arnost RDF: Prevod patterns do RDQL, vyhledavanı v RDF Storage.

Vavra Jan Implementace RDF Storage - pomocı knihovny Jena, vyhledavanı v RDF Storage.

Zd’ara Vıt Business Module. Specifikace rozhranı.

5 Stav projektu

Milestones aneb kam jsme to dopracovali...

duben 2003 Specifikace Certifikacnı autority VOMS.

brezen 2003 Specifikace rozhranı Server API.

rıjen 2002 Primitivnı prototyp business modulu.

rıjen 2002 Specifikace rozhranı Client API.

duben-kveten 2002 Prvotnı specifikace projektu.

15. dubna 2002 Prvnı schuzka. Zacatek projektu.

6 Odhad termınu dokoncenı

Prozatım prace na projektu probıhala prevazne v rovine specifikace. Byly naimplementovany nekterepodcasti, abychom zjistili, zda jsou spravne nase predstavy o nami pouzıvanych technologiıch. O prazd-ninach je planovano naimplementovat funkcnı prototyp, ktery lze ocekavat na podzim 2003. Nasazenı naobsahlejsıch datech na prelomu roku 2003/2004. Nejzassı termın pro odevzdanı planujeme na LS 2004.

10

Obrazek 5: Jiny prıklad umıstenı komponent.

11

7 Prehled znamych rizik

Projekt muze zpomalit cesta nekterych ze clenu tymu do USA. Dale pak chyby v knihovne Jena propraci s RDF modely v Jave. Celkove mame za to, ze projekt nenı nicım vaznym ohrozen.

Za projekt VOMS: Jan Vavra a Vıt Zd’ara,

29. kvetna 2003 v Praze.

WWW: http://lucy.troja.mff.cuni.cz/voms, mail list: mailto:voms-l@kolej.mff.cuni.cz.

12