Audyt wewntrzny systemu ELA-enT raport

Audyt wewntrzny systemu ELA-enT raport Spis treci 1. O tym dokumencie...1 2. Metoda przeprowadzenia audytu...1 3. Informacje dotyczce projektu...2 4. Zidentyfikowane załoenia i wymagania...2 4.1 Załoenia ogólne...2 4.2 Wymagania funkcjonalne...2 4.3 Wymagania niefunkcjonalne...3 5. Audyt realizacji załoe i wymaga...4 5.1 Załoenia ogólne...4 5.2 Wymagania funkcjonalne...4 5.3 Wymagania niefunkcjonalne...6 6. Na co naley zwróci uwag lub co naley dopracowa...8 7. Podsumowanie...9 1. O tym dokumencie Raport zawiera opracowane wyniki audytu wewntrznego przeprowadzonego w projekcie Protokoły i prototyp platformy umoliwiajce działanie elektronicznego rynku usług, z uwzgldnieniem osób zagroonych wykluczeniem z rynku pracy. Dotycz one realizacji w wyej wymienionym projekcie załoe ogólnych, wymaga funkcjonalnych, niefunkcjonalnych, identyfikacji miejsc wymagajcych dopracowania oraz uwzgldniania w dalszych pracach i podsumowania. 2. Metoda przeprowadzenia audytu Audyt został przeprowadzony w trzech fazach. Pierwsza faza zawierała wyjazd autora raportu do Akademii Podlaskiej w Siedlcach, gdzie nad realizacj projektu pracuje zespół badawczo - rozwojowy pod kierownictwem Dr. Mikułowskiego. Faza składała si z zebrania wszystkich informacji i dokumentów dotyczcych projektu, transferu wiedzy wewntrznej, która w momencie przeprowadzenia audytu nie była jeszcze udokumentowana, zapoznania si od wewntrz z uywanymi technologiami i narzdziami. Faza druga składała si z pracy samodzielnej autora nad zebranymi informacjami przeanalizowano: ksik entish: An Approach to Service Description and Composition autorstwa dr hab. Stanisława Ambroszkiewicza jako podstaw i wersj wstpn do uywanych w systemie protokołów i architektury, schematy ontologii zrealizowanych usług i ich dokumentacj, artykuł o dokumentach elektronicznych e-dokumenty w Polsce Prawo a Technologie autorstwa dr Dariusza Mikułowskiego, baz kodów ródłowych prototypu systemu, Wersja z dnia 9/04/2008 autor: Lev Belava strona 1 z 9

prac uruchomionej czci projektu. W trzeciej czci autor operujc wiedz nabyt w pierwszej i drugiej czci audytu zidentyfikował wymagania postawione projektowi jako platformie informatycznej oraz sprawdził ich realizacj. 3. Informacje dotyczce projektu Tytuł projektu Protokoły i prototyp platformy umoliwiajce działanie elektronicznego rynku usług, z uwzgldnieniem osób zagroonych wykluczeniem z rynku pracy Dziedzina nauki i dyscyplina naukowa (zgodnie z wykazem dziedzin i dyscyplin) 02 Dział gospodarki wg PKD 72.6 Informatyka Słowa kluczowe: elektroniczne rynki usług, społeczestwo informacyjne, zapobieganie wykluczeniu z rynku pracy, technologie C2B, B2B i B2G Kierownik projektu: dr hab. Stanisław Ambroszkiewicz 4. Zidentyfikowane załoenia i wymagania Rozdział, opracowany na podstawie dokumentów projektowych is, opisuje kluczowe załoenia postawione projektowi oraz dotyczce go wymagania funkcjonalne i niefunkcjonalne. 4.1 Załoenia ogólne 1. Projekt zakłada opracowanie protokołów umoliwiajcych prac elektronicznego rynku usług. 2. Projekt zakłada powstanie działajcego prototypu platformy, uywajcego protokołów umoliwiajcych prac elektronicznego rynku usług.. 3. Elektroniczny rynek usług powinien uwzgldnia osoby zagroone wykluczeniem z rynku pracy ( jest to przewidywane poprzez włczenie ich do rynku pracy jako wiadczycieli usług). 4.2 Wymagania funkcjonalne 1. Projektowany system, jako cało, powinien udostpnia moliwo publikowania przez wykonawców swoich usług. 2. Funkcjonalno dotyczca zleceniodawcy powinna udostpnia mu moliwoci wyszukiwania usług. 3. Wykonanie usług powinno by automatycznie aranowane (pomidzy zleceniodawc a wykonawc usługi) 4. System powinien udostpnia funkcjonalno zawierania umów na wykonanie zaaranowanych usług. Wersja z dnia 9/04/2008 autor: Lev Belava strona 2 z 9

5. System powinien automatycznie przygotowywa faktury elektroniczne, które bd podpisywa zleceniodawcy i wykonawcy usług lub, w przypadku braku kwalifikowanego certyfikatu klucza u której ze stron, w jej imieniu bdzie to robił system. 6. System powinien posiada funkcj podpisywania elektronicznych faktur poprzez zleceniodawców i wykonawców usług. W przypadku braku kwalifikowanego certyfikatu klucza u której ze stron w ich imieniu bdzie to robił system. 4.3 Wymagania niefunkcjonalne 1. System powinien by uniwersalny ze wzgldu na komponenty, tak aby ich implementacje mona było wymienia. 2. Koncepcja infrastruktury systemu powinna by skalowalna. 3. Powinny powsta specyfikacje słuce do niezalenych implementacji poszczególnych komponentów platformy. 4. System powinien by realizowany jako otwarty i rozproszony. 5. Komponentami systemu zrealizowanego poprzez platform ELA musz by: a) Serwery Zada (reprezentujce klientów, czyli zleceniodawców); b) Serwery Usług (reprezentujce usługodawców); c) InfoService (jako rozproszone repozytoria do publikacji i wyszukiwania usług); d) EntishDictionary jako rozproszony słownik implementujcy jzyk opisu usług. 6. System powinien realizowa nastpujce protokoły: a) protokół do publikacji usług pomidzy Serwerem Usług a InfoService; b) protokół do wyszukiwania usług pomidzy Serwerem Zada a InfoService; c) protokół do aranacji warunków wykonania usługi pomidzy Serwerem Zada a Serwerem Usług; d) protokół do przygotowywania umów (e-faktur) pomidzy Serwerem Zada a Serwerem Usług. 7. Poszczególne procesy publikowania usług, ich wyszukiwania, aranacji wykonania i w kocu zawierania umów na wykonanie usług, powinny by niezalene od samych usług. 8. Taksonomia (klasyfikacja) typów usług powinna by otwarta i skalowalna. Taka klasyfikacja musi odbywa si na podstawie ustalonego uniwersalnego jzyka opisu usług. 9. Bezpieczna komunikacja w platformie powinna by zrealizowana poprzez wykorzystanie TLS/SSL, czyli poprzez implementacj na gniazdach SSL. Wersja z dnia 9/04/2008 autor: Lev Belava strona 3 z 9

5. Audyt realizacji załoe i wymaga Rozdział zawiera wyniki sprawdzenia projektu pod ktem wymaga i załoe zidentyfikowanych w rozdziale 4. 5.1 Załoenia ogólne Realizacja załoe przedstawiona jest w poniszej tabeli. Tabela 1 - realizacja załoe projektowych Załoenie 1. Projekt zakłada opracowanie protokołów umoliwiajcych prac elektronicznego rynku usług. 2. Projekt zakłada powstanie działajcego prototypu platformy uywajcego protokołów umoliwiajcych prac elektronicznego rynku usług. 3. Elektroniczny rynek usług powinien uwzgldnia osoby zagroone wykluczeniem z rynku pracy ( jest to przewidywane poprzez włczenie ich do rynku pracy jako wiadczycieli usług). Realizacja Protokoły te wymienione midzy innymi w wymaganiach niefunkcjonalnych 4.3 punkt 6 podpunkty a,b,c,d s zaimplementowane w prototypie systemu.ich starsze wersje s opisane w ksice entish: An Approach to Service Description and Composition autorstwa dr hab. Stanisława Ambroszkiewicza. Dowodem pracy tych protokołów jest uruchomiony na stronie https://ent.ipipan.waw.pl prototyp. Szczegółowe sprawdzenie protokołów znajduje si w rozdziale 5.3 Prototyp na moment audytu był w trakcie budowy, jednak powstała dotychczas wersja w pełni funkcjonalna i dostpna dla kadego uytkownika internetu pod adresem https://ent.ipipan.waw.pl. Elektroniczny rynek usług (ERU) uwzgldnia osoby zagroone wykluczeniem z rynku (OZW) poprzez moliwo wiadczenia usług, których warunki wykonania s dostosowane do ogranicze/potrzeb danej osoby, na przykład podajc tylko okrelone godziny lub zaznaczajc e usługa bdzie wiadczona w okrelonym miejscu (np. zdalnie u siebie w domu). Wane jest równie to, e OZW mog swobodnie korzysta z takiego rynku usług jako usługodawcy i usługobiorcy poprzez interfejs webowy i w zwizku z tym, ryzyko dyskryminowana zanika. Podsumowujc, mona stwierdzi, e załoenia ogólne dotyczce projektu zostały spełnione. 5.2 Wymagania funkcjonalne Realizacja wymaga funkcjonalnych przedstawiona jest w poniszej tabeli. Wymaganie 1. Projektowany system, jako cało, powinien udostpnia moliwo publikowania przez wykonawców swoich usług. Realizacja Zostało to zrealizowane za pomoc protokołu publikacji usług pomidzy komponentami: Serwer Usług a InfoService. Wykonawca usługi za pomoc menadera usług moe ogłosi typ swojej operacji w InfoService, po czym bdzie dostpny dla wyszukiwania poprzez usługodawców. Mechanizm ten Wersja z dnia 9/04/2008 autor: Lev Belava strona 4 z 9

2. Funkcjonalno dotyczca zleceniodawcy powinna udostpnia mu moliwo wyszukiwania usług. 3. Wykonanie usług powinno by automatycznie aranowane (pomidzy zleceniodawc a wykonawc usługi). 4. System powinien udostpnia funkcj zawierania umów na wykonanie zaaranowanych usług. 5. System powinien automatycznie przygotowywa faktury elektroniczne. 6. System powinien posiada funkcj podpisywania elektronicznych faktur poprzez zleceniodawców i wykonawców usług. W przypadku braku kwalifikowanego certyfikatu klucza u której ze stron w jej imieniu bdzie to robił system. dokładniej jest opisany w ksice entish: An Approach to Service Description and Composition rozdziały 4.1 oraz 4.2 str. 62-63. Zostało zrealizowane. Usługi mona wyszukiwa za pomoc przegldarki www uywajc uruchomionego prototypu systemu pod adresem https://ent.ipipan.waw.pl. Proces wyszukiwania z punktu widzenia uytkownika kocowego jest tylko abstrakcj tego co si naprawd dzieje w systemie. Nie musi on wiedzie, które komponenty współpracuj midzy sob, aby da mu do wyboru opcj spełniajc podane kryteria. Sam proces składa si natomiast ze współpracy pomidzy Serwerem Zada reprezentujcym uytkownika, Serwerami Usług oraz InfoServicem. Jest to realizowane w fazie aranacji, kiedy Serwer Zada wysyła do Serwera Usług intencj. Nastpnie Serwer Usług oblicza czy moe spełni intencj i wysyła informacje o tym jakie warunki musz by spełnione. Jeli usługa posiada braki uniemoliwiajce poprawn prac, to taki zasób jest wyszukiwany w InfoService i rekurencyjnie aranuje si jego dostarczenie. Jeli natomiast usługa nie posiada braków to aranacja dobiega koca i rozpoczyna si wykonanie workflow które, przyjmuje posta drzewa w korzeniu, którego znajduje si usługa, której potrzebuje usługobiorca. Tak, zostało to wykonane. Prototyp systemu przygotowuje umowy na wykonanie zaaranowanych usług. Dzieje si to w sposób zautomatyzowany i nie wymaga wiedzy prawnej czy ekonomicznej od usługodawców i usługobiorców. Informacje dotyczce postaci umowy i jej parametrów s pobierane ze słownika EntishDictionary, nastpnie na ich podstawie tworzona jest faktura uzupełniona o dane kadej ze stron. Na samym kocu usługodawca i usługobiorca mog zawrze umow, poprzez jej podpisanie. Prototyp systemu ju potrafi przygotowa faktur elektroniczn dla zaimplementowanych usług. Sposób jej przygotowania jest podobny do przygotowania umowy. Posta ogólna znajduje si w słowniku EntishDictionary i na jej podstawie po uzgodnieniu szczegółów dotyczcych wykonania usługi oraz płatnoci, generowane s przypadki szczególne. Póniej faktura jest podpisywana elektronicznie przez usług i przesyłana do uytkownika. Tak, jest to uwzgldnione w koncepcji i architekturze platformy ELAEnt. W formacie wiadomoci uwzgldnione jest miejsce na podpis cyfrowy. Koncepcyjnie Menader Zada powinien podpisywa dokumenty w imieniu usługodawców, a Menader Usług w imieniu usługobiorców. Wersja z dnia 9/04/2008 autor: Lev Belava strona 5 z 9

5.3 Wymagania niefunkcjonalne Realizacja wymaga niefunkcjonalnych przedstawiona jest w poniszej tabeli. Wymaganie Realizacja 1. System powinien by uniwersalny ze wzgldu na komponenty, tak aby ich implementacje mona było wymienia. 2. Koncepcja infrastruktury systemu powinna by skalowalna. 3. Powinny powsta specyfikacje słuce do niezalenych implementacji poszczególnych komponentów platformy. Poniewa komunikacja midzy komponentami systemu przebiega zgodnie z protokołem w jzyku entish z wykorzystaniem jzyka XML, to nie ma adnych przeszkód aby komponenty były wymieniane midzy sob. Dla nowego komponentu wystarczy tylko zaimplementowa odpowiedni obsług jzyka entish zapisanego w notacji XMLowej. Skalowalno architektury została wzita pod uwag. Projekt systemu uwzgldnia moliwo połczenia hierarchicznego wielu jednostek InfoServie (w prototypowej implementacji nie zostało to jednak zrealizowane). Kolejnym atutem jest moliwo rozdzielenia Serwerów Usług i postawienia na rónych jednostkach obliczeniowych oraz ich praca w ramach systemu poprzez sie. Serwer Zada równie jest encj nie zalen i moe pracowa tylko komunikujc si przez sie z reszt systemu. Takie podejcie gwarantuje bezbolesne dodawanie kolejnych maszyn gdy zajdzie taka potrzeba oraz wzrost ogólnej wydajnoci. Dokładne specyfikacje potrzebne do implementacji komponentów przez osoby trzecie jeszcze nie powstały. Biecej dokumentacji projektowej zdaniem autora audytu nie wystarczy do podjcia takiej pracy, poniewa niektóre informacje zawarte w ksice entish: An Approach to Service Description and Composition uległy zmianom nie odzwierciedlonym w innej dokumentacji projektowej (a tylko w kodzie prototypu), istniej równie obszary całkowicie nowe nie opisane we wspomnianej ksice (np. procesy przygotowywania faktur, umów i ich podpisnia). 4. System powinien by realizowany jako otwarty i rozproszony. 5. Komponentami systemu zrealizowanego poprzez platform ELA musz by: a) Serwery Zada (reprezentujce klientów, System jest systemem rozproszonym, poniewa koncepcja skalowalnoci systemu (patrz 5.3 punkt 2) zakłada swoj realizacj poprzez rozproszenie komponentów w sieci komputerowej. Natomiast otwarto systemu osiga si poprzez otwarto protokołów komunikacji oraz samego jzyka entish. Poniewa nie stanowi one tajemnicy, koncepcja działania systemu staje si przejrzysta dla wszystkich którzy chc si z ni zapozna. Koncepcja systemu jak równie jej budowany prototyp posiadaj wszystkie wymienione komponenty. To załoenie zostało spełnione. Wersja z dnia 9/04/2008 autor: Lev Belava strona 6 z 9

czyli zleceniodawców); b) Serwery Usług (reprezentujce usługodawców); c) InfoService (jako rozproszone repozytoria do publikacji i wyszukiwania usług); d) EntishDictionary (jako rozproszony słownik implementujcy jzyk opisu usług). 6. System powinien realizowa nastpujce protokoły: e) protokół do publikacji usług pomidzy Serwerem Usług a InfoService; f) protokół do wyszukiwania usług pomidzy Serwerem Zada a InfoService; g) protokół do aranacji warunków wykonania usługi pomidzy Serwerem Zada a Serwerem Usług; h) protokół do przygotowania umów (e-faktur) pomidzy Serwerem Zada a Serwerem Usług. Protokół publikacji usług pomidzy Serwerem Usług a InfoService został uwzgldniony w koncepcji systemu i zrealizowany (równie w prototypie) za pomoc formuł jzyku entish jak równie kilkakrotnie opisany na przykładach w ksice entish: An Approach to Service Description and Composition. Naturalnie nie jest on ograniczony ze wzgldu na rodzaje usług lub potrzebne im zasoby wejciowe. Patrz równie 5.2.1 Protokół wyszukiwania usług został uwzgldniony w koncepcji systemu (i zrealizowany w prototypie) w oparciu o formuły jzyka entish. Wskazówki i opis go dotyczcy mona znale we wspomnianej ksice. Jest prostym i rozszerzalnym narzdziem dla wyszukiwania odpowiednich usług. Patrz równie 5.2.2 Protokół fazy aranacji jest jedn z kluczowych koncepcji wyróniajcych architektur badanego projektu, poniewa pozwala na automatyczne przygotowanie wielu składowych usług do jednego procesu powstania usługi kocowej zadowalajcej usługobiorc. Jest prosty ze wzgldu na uywan logik oraz uniwersalny i niezaleny od usług istniejcych w systemie. Patrz równie 5.2.3 7. Poszczególne procesy publikowania usług, ich wyszukiwania, aranacji Protokół przygotowania umów polega na tym, e Menader Zadania tworzy kontrakt na podstawie schematów umieszczonych w EntishDictionary i wysyła go bezporednio pod podany adres usługi. Menader Usług na jego podstawie tworzy odpowiedni rachunek i wysyła go bezporednio pod podany adres klienta. Faza ta została zaimplementowana w systemie. Patrz równie 5.2.4 Procesy te s niezalene midzy sob gdy oparte s na wymianie komunikatów w standardzie jzyka XML Wersja z dnia 9/04/2008 autor: Lev Belava strona 7 z 9

wykonania i w kocu zawieranie? umów na wykonanie usług, musz by niezalene od samych usług. 8. Taksonomia (klasyfikacja) typów usług powinna by otwarta i skalowalna. Taka klasyfikacja musi odbywa si na podstawie ustalonego uniwersalnego jzyka opisu usług. 9. Bezpieczna komunikacja w platformie powinna by zrealizowana poprzez wykorzystanie TLS/SSL, czyli poprzez implementacj na gniazdach SSL. pomidzy komponentami systemu (patrz wymagania 5.3.1, 5.3.4, 5.3.6). Komunikaty te zawieraj formuły jzyka entish, które powstaj jedynie na podstawie automatycznego procesowania definicji usług, kontraktów oraz faktur zawartych w słowniku EntishDictionary. Dlatego procesy wymienione w wymaganiu nie s w cale zalene od usług. Klasyfikacja typów usług zawarta jest w rozproszonym słowniku EntishDictionary, który składa si z odpowiednich schematów XSD okrelajcych składnie definicji funkcji, typów zasobów itd. EntishDictionary przewiduje udostpnienie interfejsu graficznego dla usprawnienia dodawania poszczególnych definicji. Komunikacja usługodawców i usługobiorców z systemem jest szyfrowana za pomoc SSL (HTTPS). Połczenie midzy komponentami w prototypie, póki co, nie jest szyfrowane. Bdzie to przedmiotem kolejnych etapów realizacji projektu. 6. Uwagi W tym rozdziale zebrane s niektóre uwagi dotyczce projektu i realizacji prototypu, które mog by przydatne w realizacji kolejnych wersji systemu. 1. Sposób rozsyłania agentem informacji 1-n podczas wyszukiwania usług uyty w prototypie systemu jest niebezpieczny z punktu widzenia skalowalnoci. W przypadku kiedy znalezionych w InfoService usług bdzie 10000 i wicej spowoduje to znaczny wzrost konsumpcji zasobów sieciowych oraz procesora. Warto zastanowi si, czy nie lepiej uy kolejek komunikatów. Dodatkowo mona przemyle, czy nie lepiej czeka tutaj na upływ czasu, zamiast oczekiwa od wszystkich odmowy, co pozwoliłoby zmniejszy zuycie zasobów komputerowych. 2. Numeracja typów wiadomoci protocolorder, zdaniem autora raportu, nie ma zbyt wielkiego sensu. Przy uyciu XML jako kontenera wiadomoci lepiej byłoby nadawa słowne identyfikatory, poniewa s czytelne i zredukuj ryzyko pomyłek osób implementujcych komponenty systemu. 3. Przy budowie wersji produkcyjnej systemu warto byłoby przenie konfiguracj komponentów systemu do osobnych plików konfiguracyjnych. Biorc pod uwag dalszy bezproblemowy rozwój i pielgnacj systemu, zaszywane w kodzie tych parametrów jest niebezpiecznie 4. Przy budowie wersji produkcyjnej, warto równie zastanowi si nad ujednoliceniem nazw i komentarzy w kodach ródłowych, poniewa rozbieno stylów kodowania i nazywania zmiennych oraz komentowania kodu jest niebezpieczna. Przykładem moe by tutaj cz kodu z komentarzami po angielsku, a cz po polsku Wersja z dnia 9/04/2008 autor: Lev Belava strona 8 z 9

5. Schematy ontologii oraz inne dokumenty xsd, xml nie nale do kodowania, które jest podane jest jako kodowanie dokumentu (<?xml version="1.0" encoding="iso-8859-2"?>) s one natomiast w kodowaniu cp-1250 7. Podsumowanie Podsumowujc, mona stwierdzi, e projekt zmierza w dobrym kierunku. Jdro systemu realizujce główn logik zostało ju pomylnie zaimplementowane i działa. Załoenia oraz wymagania projektowe s w znacznej mierze spełnione. Z punktu widzenia technicznego koncepcja działania infrastruktury zaproponowanej w projekcie jest nowatorska i nie grozi jej starzenie si wraz z upływem czasu. Wersja z dnia 9/04/2008 autor: Lev Belava strona 9 z 9