Modyfikacja systemu w ramach projektu Rozbudowa elektronicznej platformy usług administracji publicznej

TECHNICZNY SYSTEMU Modyfikacja systemu w ramach projektu Rozbudowa elektronicznej platformy usług administracji publicznej Ministerstwo Spraw Wewnętrznych i Administracji ul. Batorego 5, 02-591 Warszawa www.epuap.gov.pl

Założenia dla dokumentu Projekt Techniczny (PT): Szablon dokumentu PT jest wspólny dla wszystkich etapów. Dokument PT opracowywany w kolejnych etapach budowy Systemu będzie tworzony przyrostowo. Elementy nowowprowadzone w danym etapie będą oznaczone w sposób umożliwiający ich identyfikację (wyjątkiem jest rozdział dotyczący odniesień do wymagań etapu). W przypadku znacznej objętości dla danego elementu element może zostać wydzielony z dokumentu do załącznika Diagramy budowane będą z użyciem języka UML 2.0 z wykorzystaniem narzędzia Rational Software Architekt w dokumencie widoczny będzie efekt użycia narzędzie wizualizowany w postaci obrazu/raportu 2/95

1 Architektura Systemu 1.1 Architektura podsystemów Celem tego podrozdziału będzie opracowanie wewnętrznej architektury podsystemów, czyli wyodrębnienie komponentów składowych, interfejsów oraz elementarnych usług przez nie realizowanych. W punkcie tym zostanie zawarte elementy wymienione poniżej. Prezentacja wszystkich podsystemów realizowanych w etapie wraz z opisami usług, które dostarczają. Diagram i dokładny opis ilustrujący współpracę podsystemów zachodzącą podczas realizacji usług. Diagram i opis wewnętrznej budowy podsystemu wraz z komponentami wchodzącymi w jego skład. Opis tekstowy każdego komponentu z wyszczególnieniem interfejsów i usług udostępnianych przez komponenty. Diagram i opis ilustrujący współpracę komponentów podczas realizacji usług. 1.1.1 Pojęcia System epuap Podsystem epuap Interfejs Pojęcie Opis Ogół elementów wchodzących w skład platformy epuap. Część systemu epuap wyodrębniony w architekturze. Definicja zbioru operacji, które mogą być wywoływane przez dwa komunikujące się elementy. Komponent Element składowy systemu (podsystemu) realizujący pewien spójny zakres funkcjonalności. Komunikacja między komponentami odbywa się wyłącznie przy użyciu interfejsów. WebSerwis Jedna z form implementacji interfejsu. Cechą interfejsu jest jego dostępność może być wywołany zdalnie przez 3/95

system zewnętrzny. Usługa składowa Zagregowany zbiór tematycznie zgodnych funkcjonalności systemu. Usługi są udostępniane przez komponenty za pośrednictwem interfejsów. HSM Hardware Security Module sprzętowy moduł kryptograficzny TSA Time Stamping Authority usługi służące do oznaczania czasem SOPEL System Obsługi Podpisu ELektronicznego 1.1.2 Technologia wytwarzania Aplikacja epuap jest oprogramowaniem rozproszonym o architekturze wielowarstwowej. Komunikacja pomiędzy rozproszonymi modułami realizowana jest z wykorzystaniem web-serwisów. Wykorzystaną platformą programowania jest Java w wersji 1.4. Wykorzystaną bazą danych jest IBM DB2 9.1. Warstwa webowa została stworzona z wykorzystaniem technologii portletów uruchamianych na serwerze IBM WebSphere Portal 6.0. Strony aplikacji zachowują zgodność ze specyfikacją XHTML. Część wyglądu aplikacji realizowana jest poprzez wykorzystanie technologii XForms. W celu jej wykorzystania użyty został produkt o nazwie Orbeon Forms 3.6. Kod aplikacji zachowuje niezależność od używanego IDE i może być po wprowadzeniu zmian skompilowany z użyciem skryptów ANT pod warunkiem dostarczenia odpowiedniego zestawu bibliotek. Kod aplikacji utrzymywany jest za pomocą repozytorium CVS, które pozwala kontrolować zmiany do niego wprowadzane. 1.1.3 Model projektu technicznego Poniższy diagram prezentuje model projektu technicznego. 4/95

Rysunek 1 Model projektu technicznego Elementem o najszerszym zasięgu jest podsystem. Podsystem udostępnia zbiór interfejsów, którymi komunikuje się z innymi podsystemami. Podsystem zbudowany jest z komponentów implementowanych przy pomocy zbioru klas. Komponenty również udostępniają interfejsy, które używane są do komunikacji wewnętrznej w podsystemie. 1.1.4 Usługi składowe W wyniku analizy funkcjonalności implementowanych w poszczególnych etapach dokonano ich syntezy do listy usług składowych zaprezentowanych w tabelach. Pojęcie usług składowych wprowadzono wyłącznie w celu pogrupowanie funkcjonalności i nie ma żadnego związku z usługami opisanymi w dokumencie Koncepcja architektury epuap. 5/95

Tabela 1 Usługi składowe. Usługa Opis Zarządzanie słownikami referencyjnymi Obejmuje zakres funkcjonalności związanych z definiowaniem słownika, wprowadzaniem, wyszukiwaniem i dostępem do wartości słownikowych. Zasilanie słowników referencyjnych Obejmuje wszystkie czynności związane z zasilaniem słowników tzn. pobieranie danych z zewnętrznych systemów, przygotowanie harmonogramu, określenie arkusza transformacji i walidacji słownika. Zarządzanie treścią Obejmuje wszystkie funkcjonalności związane z zarządzaniem informacją dostępną na stronach portalu Zarządzenie i obsługa zdarzeń Obsługuje zagadnienia związane z tematem zdarzeń, czyli: konfigurację, rejestrację, dostęp i reakcję na incydenty. Zarządzanie parametrami usług bezpieczeństwa Zarządzenie tożsamościami Zarządzenie podmiotami Umożliwia określanie i dostęp do parametrów pracy usług bezpieczeństwa. Obejmuje funkcjonalności umożliwiające operacje na tożsamościach. Obejmuje funkcjonalności umożliwiające operacje na podmiotach. Zarządzanie zasobami Obejmuje zakres funkcjonalności związanych z tworzeniem, edycją i usuwaniem zasobów. Zarządzenie uprawnieniami do zasobów Obejmuje funkcjonalności związane z uprawnieniami do zasobów tzn. przypisywanie zasobów do ról \ podmiotów oraz delegacje uprawnień do osób \ systemów. Uwierzytelnianie osób/systemów Obejmuje wszystkie funkcjonalności związane z uwierzytelnieniem osoby \ systemu w platformie epuap. Autoryzacja osób/systemów Obejmuje funkcjonalności autoryzacji osób \ systemów Obsługa podpisu elektronicznego Obejmuje wszystkie funkcjonalności 6/95

związane z podpisem elektronicznym takie jak umożliwienie złożenia podpisu przez klienta, walidację i archiwizację podpisu, oznaczanie czasem itp. Zarządzanie wątkami prac Obejmuje zakres funkcjonalności związanych z wątkami prac nad rekomendacjami interoperacyjności Integracja z forami dyskusyjnymi Obejmuje zakres funkcjonalności związanych z wykorzystaniem funkcjonalności forów dyskusyjnych w systemie epuap Zarządzanie plikami Obejmuje zakres funkcjonalności związanych z przechowywaniem i udostępnianiem do pobrania plików podsystemów systemie epuap Zarządzanie wzorami formularzy elektronicznych Obejmuje zakres funkcjonalności związanych z publikowaniem i zarządzaniem wzorami formularzy elektronicznych Zarządzanie formularzami Obejmuje zakres funkcjonalności związanych z zarządzaniem formularzami Zarządzanie profilami podmiotów Obejmuje zakres funkcjonalności związanych z udostępnianiem informacji o podmiotach Zarządzanie składem Obejmuje zakres funkcjonalności związanych z zarządzaniem składami dokumentów Zarządzanie sprawami Obejmuje zakres funkcjonalności związanych z zarządzaniem sprawami Zarządzanie użytkownikami Obejmuje zakres funkcjonalności związanych z zarządzaniem użytkownikami Zarządzanie aplikacjami Obejmuje zakres funkcjonalności związanych z zarządzaniem aplikacjami 1.1.5 Współpraca podsystemów Usługi składowe zorganizowano w podsystemy zgodnie z koncepcją architektury epuap. Każdy z podsystemów w reprezentacji źródłowej kodu zajmuje odzielną gałąź repozytorium. Wyraźna rozdzielność kodu wprowadzona jest także na poziomie typów aplikacji, jakie udostępniane są przez podsystemy oddzielnie przechowywane są źródła web serwisów, a oddzielnie źródła portletów. 7/95

Klasy podsystemów zajmują odzielne przestrzenie nazw aby zapewnić globalna unikalność ich nazw. Z kodu każdego z podsystemów wydzielone są fragmenty, które tworzą tak zwany Core podsystemu, z którego tworzona jest biblioteka oprogramowania. Każda z aplikacji podsystemu może wykorzystywać tak zbudowaną bibliotekę. Aby możliwe było wykonanie kodu innego modułu niezbędne jest wykorzystanie biblioteki Proxy, dla której wywołanie jej funkcjonalności wiąże się z wywołaniem web serwisów wewnętrznych podsystemu udostępniającego funkcjonalność. 8/95

Rysunek 3 Struktura repozytorium kodu Wzajemne relacje między podsystemami przedstawiono na diagramie. 9/95

Rysunek 2 Struktura platformy epuap Podsystemy: Front End, Słowniki Referencyjne, Portal oraz Portal Interoperacyjności, Repozytorium Wzorów Formularzy, Płatności, Koordynator i Środowisko budowy aplikacji korzystają z usług składowych podsystemu bezpieczeństwa w celu uwierzytelnienia i autoryzacji osoby/systemu oraz weryfikacji jego uprawnień do zasobów. Wszystkie podsystemy korzystają również z podsystemu bezpieczeństwa w celu rejestracji występujących zdarzeń. Podsystem bezpieczeństwa korzysta z usług słownika referencyjnego w procesie zarządzania podmiotami. Repozytorium Wzorów Formularzy korzysta dodatkowo z podsystemu Portal Interoperacyjności w zakesie dostępu do repozytorium plików, w którym przechowywane są załączniki oraz pliki składające się na wzory formularzy. Środowisko budowy aplikacji korzysta dodatkowo z podsystemów: Front End, Podsystem komunikacyjnego, Koordynatora w celu umożliwienia użytkownikowi operacji związanej z zarządzaniem aplikacją. Podsystem Koordynator wykorzystuje pozostałe podsystemy poprzez możliwość wykorzystania wystawianych przez nie usług. 1.1.6 Procesy automatyczne sytemu W systemie epuap zdefiniowane są procesy, których działanie ma charakter automatyczny. Wymagają one zdefiniowanie parametrów startowych, które dostosowują szczegóły ich działania do potrzeb. 10/95

POWYKONAWCZY PROJEKT Koordynator proces realizowany w podsystemie Koordynatora mający na celu uruchamianie zdefiniowanych i zainstalowanych przez użytkowników procesów biznesowych opisanych językiem BPEL wykorzystujących zdefiniowane w epuap interfejsy web serwisowe. Robot PK proces w Podsystemie komunikacyjnym zarządzający przekazywaniem dokumentów w systemie epuap. Jego działanie opiera się na przeglądaniu kolejki zadań związanych z operacjami na dokumentach i wykonywaniu ich wg. opisanych przez zadanie reguł. Proces aktualizacyjny słowników proces w Podsystemie słowników referencyjnych, którego działanie ma na celu okresową aktualizację słowników na podstawie danych udostępnionych przez serwis TERYT w GUS. Proces aktualizacyjny opisów usług proces w Podsystemie katalog usług publicznych, którego działanie ma na celu aktualizację opisów usług zdefiniowanych w epuap na podstawie wystawionych przez ich twórców interfejsów zewnętrznych względem systemu epuap zgodnie z wyznaczonym harmonogramem. 1.1.7 Architektura komponentowa Usługi składowe przypisano do interfejsów komunikacji między podsystemami i komponentami. Usługa Zarządzanie słownikami referencyjnymi Interfejs IZarzadzanieSlownikami Zasilanie słowników referencyjnych Zarządzanie treścią Zarządzanie parametrami usług bezpieczeństwa Realizowana przez oprogramowanie standardowe WebSphere Portal. IKonfiguracja Zarządzanie zasobami Zarządzanie wątkami prac Integracja z forami dyskusyjnymi Zarządzanie plikami Zarządzanie wzorami formularzy elektronicznych Zarządzanie formularzami Zarządzanie składem Zarządzanie sprawami Zarządzanie aplikacjami IZarządzanieZasobami IZarzadzanieWatkamiPrac IZarzadzanieForami IZarzadzaniePlikami IZarzadzanieWzorami IZarzadzanieFormularzami IZarzadzanieSkladem IZarzadzanieSprawami IZarzadzanieAplikacjami 11/95

Organizację komponentową i przypisanie interfejsów do poszczególnych podsystemów zobrazowano na poniższym diagramie. [ ] Rysunek 3 Struktura komponentowa epuap [ ] 1.1.8 Komponenty systemowe Każdy podsystem posiada komponent implementujący interfejs standardowy ISystem, który jest punktem wejściowym do logiki i integratorem podsystemu. Komponent systemowy jest jedynym obiektem, który klient (interfejs użytkownika, system zewnętrzny) może bezpośrednio utworzyć. Implementuje interfejs ISystem umożliwiający dostarczenie każdego innego interfejsu eksponowanego przez pozostałe komponenty. Rysunek 4 Komponent epuap Implementacja komponentów systemowych UB, SR, PI i RW będzie realizowana przy pomocy klas zaprezentowanych na poniższym diagramie. 12/95

Rysunek 5 Implementacja komponentów systemowych Zastosowanie pojedynczego komponentu bramy umożliwia łatwą kontrolę nad dostępem do poszczególnych usług \ interfejsów oraz separuje klienta usług i pozostałe komponenty od faktycznej implementacji usługi. W szczególności mogą być rozmieszczane i konfigurowane w różnych lokalizacjach bez konsekwencji dla klienta usług. Implementacja metody dajinterfejs() będzie tworzyła instancję potrzebnego komponentu i zwracała szukany interfejs. 1.1.9 Podsystem bezpieczeństwa Podsystem odpowiedzialny za składowanie katalogu podmiotów, osób/systemów, zasobów podlegających kontroli dostępu oraz ich uprawnień oraz za realizację usług bezpieczeństwa. Podsystem bezpieczeństwa realizuje usługi składowe wymienione poniżej. Zarządzenie i obsługa zdarzeń Zarządzanie parametrami usług bezpieczeństwa Zarządzenie tożsamościami Zarządzenie profilami podmiotów Zarządzanie zasobami Zarządzenie uprawnieniami do zasobów Uwierzytelnianie osób/systemów Autoryzacja osób/systemów Obsługa podpisu elektronicznego 13/95

Podsystem bezpieczeństwa jest zbudowany z komponentów realizujących poszczególne usługi. Wzajemne zależności komponentów opisuje diagram poniżej. Rysunek 6 Zależności między komponentami podsystemu bezpieczeństwa Wszystkie komponenty korzystają z komponentu uwierzytelniania i autoryzacji oraz obsługi zdarzeń. Wyodrębniono dodatkowo komponent konfiguracyjny zarządzający parametrami usług bezpieczeństwa. Organizację i przypisanie interfejsów skojarzonych z usługami składowymi przedstawiono na diagramie. 14/95

Rysunek 7 Organizacja komponentów i interfejsów Wszystkie komponenty do prawidłowej pracy wymagają interfejsów IObslugaZdarzen, IZarzadzanieUprawnieniami oraz IUwierzytelnianieAutoryzacja. Komponenty uzyskują je od komponentu epuap implementującego interfejs ISystem. 1.1.1 UBAUTH: Uwierzytelnienie i autoryzacja Komponent jest pośrednikiem do usług świadczonych przez oprogramowanie standardowe DRACO i umożliwia przeprowadzanie uwierzytelnienia i autoryzacji. Umożliwia odseparowanie reszty systemu od fizycznej implementacji, czyli uniknięcie problemów związanych z: protokołem dostępu do oprogramowania standardowego, lokalizacją usług, zmianą interfejsu. Postać i interfejs komponentu prezentuje diagram poniżej. 15/95

Rysunek 8 Komponent UBAUTH Komponent będzie udostępniał interfejs pozwalający uzyskać adres strony, na który należy przekierować klienta w celu uwierzytelnienia - dajuslugeuwierzytelnienia() oraz ekstrakcję kontekstu bezpieczeństwa z wywołania usługi - dajkontekst(). Dodatkowe metody pozwalają uzyskać identyfikator zalogowanego użytkownika oraz podmiot w kontekście, którego pracuje użytkownik. Dane identyfikacyjne pobierane są z systemu DRACO. Każda usługa realizowana w systemie powinna uwierzytelnić klienta w następujący sposób: sprawdzanie, czy kontekst jest już utworzony, sprawdzanie czy wywołanie usługi zawiera informacje o kontekście, przekierować klienta na stronę logowania, jeśli powyższe sprawdzenia zakończyły się niepowodzeniem. Implementacja komponentu będzie realizowana przy użyciu klasy UwierzytelnianieAutoryzacja. 16/95

Rysunek 9 Implementacja komponentu UBAUTH Konstruktor klasy otrzymuje parametr ISystem, który integruje komponent UBAUTH z resztą systemu. Implementacja metod będzie wywoływać API DRACO. 1.1.2 UBSIG: Obsługa podpisu cyfrowego Komponent jest pośrednikiem usług świadczonych przez oprogramowanie standardowe SOPEL i umożliwia pełną obsługę procesów związanych z podpisem elektronicznym. Zalety komponentu pośredniczącego są identyczna jak w przypadku komponentu UBAUTH. Komponent i jego interfejs prezentuje diagram poniżej. 17/95

Rysunek 10 Komponent UBSIG Interfejs IPodpisCyfrowy umożliwia przeprowadzenie dokonanie podpisu i jego weryfikacji. Udostępnia także funkcjonalności oznaczania czasem, archiwizacji podpisu i obliczania skrótu. Implementacja komponentu będzie realizowana za pomocą klas ujętych w rysunku 11. Rysunek 11 Klasy implementacji komponentu UBSIG Interfejs IPodpisCyfrowy jest implementowany przez klasę PodpisCyfrowy. Funkcjonalności związane z archiwizacją podpisu i oznaczania czasem są dostępne poprzez wywołanie metod odpowiednio archiwizujpodpis i oznaczczasem. Obie metody przyjmują parametr dokument XML. Procedura składania podpisu i jego weryfikacji jest bardziej skomplikowana i składa się z następujących elementów: 18/95

POWYKONAWCZY PROJEKT utworzenie kontekstu obiektu KontekstPodpisuWeryfikacji, dodanie do kontekstu dokumentu i załączników dokonanie podpisu lub weryfikacji wywołanie metody sprawdzpodpis lub podpisz. Podobnie jak inne klasy PodpisCyfrowy zawiera konstruktor przyjmujący parametr ISystem, który umożliwia komunikację z pozostałymi komponentami systemu. Implementacje metod wywołują API oprogramowania standardowego SOPEL. 1.1.3 UBKONF: Konfiguracja Komponent dostarcza informacji na temat parametrów usług bezpieczeństwa wszystkim komponentom wchodzącym w skład podsystemu bezpieczeństwa. Interfejs IKonfiguracja umożliwia pobranie (metoda dajwartosc()) i ustawienie parametru konfiguracyjnego (metoda ustawwartosc()). Dostęp do zbioru parametrów konfiguracyjnych jest możliwy za pośrednictwem interfejsu IZestawyDanych. Organizację interfejsów komponentu zaprezentowano na diagramie poniżej. Rysunek 12 Komponent UBKONF 19/95

Funkcjonalność komponentu jest realizowana przy użyciu klasy Konfiguracja. Rysunek 13 Implementacja komponentu UBKONF Działanie metody ustawwartosc() tworzy nowy parametr, jeśli wcześniej nie istniał w bazie danych. Konstruktor klasy przyjmuje parametr ISystem, który umożliwia dostęp do pozostałych interfejsów platformy. 1.1.4 UBUPR: Zarządzenie uprawnieniami Komponent jest pośrednikiem do usług oprogramowania standardowego DRACO w zakresie zarządzania uprawnieniami. Zalety komponentu pośredniczącego do usług oprogramowania standardowego są identyczne jak w przypadku komponentów UBAUTH i UBSIG. Komponent UBUPR udostępnia interfejs zawierający metody weryfikujące dostęp użytkownika lub systemu do określonych zasobów. Umożliwia również jednorazowe pobranie pełnej listy dostępnych zasobów. 20/95

21/95

Rysunek 14 Komponent UBZU: Zarządzanie uprawnieniami Implementacja realizowana będzie z użyciem klasy ZarzadzanieUprawnieniami. Podobnie jak inne klasy będzie otrzymywać interfejs ISystem zapewniający dostęp do pozostałych usług platformy. Rysunek 15 Implementacja komponentu UBUPR Implementacja metod będzie wykorzystywać API oprogramowania standardowego DRACO. 1.1.5 UBZD: Obsługa zdarzeń Komponent jest pośrednikiem do usług oprogramowania standardowego, jakim jest TIVOLI Netcool Omnibus. Zalety komponentu pośredniczącego są identyczne jak w przypadku komponentów UBAUTH, UBUPR oraz UBSIG. Głównym zadaniem komponentu UBZD jest składowanie zdarzeń do tabeli bazie danych, które są następnie przechwytywane przez serwer TIVOLI i archiwizowane w centralnym logu, który raz dziennie jest podpisywany i oznaczany czasem. Konfiguracja i obsługa incydentów realizowana jest z poziomu narzędzia standardowego. Zdarzenia składowane są w bazie danych epuap przez 6 miesięcy. Po upłynięciu tego czasu są usuwane przez procedurę bazodanową UB.ZD_OCZYSZCZANIE(). Procedura wywoływana jest raz dziennie. Zdarzenia archiwalne przechowywane są w logu centralnym. 22/95

Implementacja komponentu będzie realizowana za pomocą klasy ObslugaZdarzen. Podobnie jak pozostałe klasy konstruktor będzie otrzymywał interfejs ISystem, który umożliwi komunikację z pozostałymi elementami systemu. W zależności od wykorzystywanej funkcji, czas zdarzenia określany jest na podstawie parametru lub czasu systemu operacyjnego, dlatego też wymagana jest synchronizacja czasu SO z zegarem atomowym. 1.1.6 UBZP: Zarządzanie tożsamością podmiotów Komponent zarządza informacją dotyczącą podmiotów. Udostępnia interfejs umożliwia tworzenie, edycję i usuwanie danych opisowych. Ze względu na audyt i rozliczanie transakcji dane dotyczące podmiotów nie są fizycznie usuwane. Model obiektów związany z funkcjonalnością zarządzania tożsamością podmiotów zawarto w dokumencie Specyfikacja Wymagań Etapu. Funkcjonalność zarządzania tożsamością podmiotów jest realizowana częściowo w dwóch miejscach. Komponent UBZP odpowiada jedynie za dane opisujące podmiot (profil). Tożsamość osoby/systemu oraz powiązanie z podmiotem jest realizowane przy pomocy narzędzia standardowego DRACO. Przystępujący do platformy epuap użytkownik musi założyć konto w DRACO gdzie otrzyma identyfikator osoby (użytkownika) oraz podmiotu. Dodatkowo zostanie mu przydzielone uprawnienie do nowo utworzonych zasobów. Następnie zostanie przekierowany na strony będące interfejsem użytkownika do komponentu UBZP gdzie będzie mógł dokonać pełnego opisu podmiotu, do którego ma dostęp. Oprogramowanie standardowe DRACO umożliwia przypisywanie do podmiotów osób(użytkowników), które będą go reprezentować. Podczas logowania użytkownik będzie mógł wybrać podmiotu imieniu, którego będzie prowadził interakcje z platformą epuap. Poniżej diagram prezentujący komponent i interfejsy przez niego realizowane. 23/95

Rysunek 16 Komponent UBZP: Zarządzanie tożsamością podmiotów Komponent implementuje fabrykę obiektów umożliwiając tworzenie nowych, edycję i usuwanie podmiotów. W celu usprawnienia wyszukiwania i utworzenia obiektu opisującego konkretny podmiot udostępniono metodą daj podmiot, która zwraca obiekt w sposób bezpośredni. Zaawansowane możliwości selekcji podmiotów umożliwia implementacja interfejsu IZestawDanych. Komponent zarządzania podmiotami umożliwia również zarządzaniem atrybutami dodatkowymi, które można przypisywać podmiotom. Odbywa się to przy pomocy dedykowanej fabryki zwracanej przez metodę dajfabrykeatrybutów. Sposób organizacji klas i interfejsów implementujących komponent przedstawia diagram poniżej. 24/95

Rysunek 17 Implementacja komponentu UBZP Klasą, która bezpośrednio implementuje funkcjonalności komponentu jest klasa ZarzadzaniePodmiotami. Zawarte w niej metody fabryki obiektów umożliwiają utworzenie i zwrócenie obiektu klasy Podmiot. Po dokonaniu edycji właściwości podmiotu można sprawdzić ich poprawność wywołując metodę waliduj() interfejsu IWalidacja a następnie po pozytywnej weryfikacji zachować jego stan wywołując metodę zapisz() będącą częścią interfejsu ISkladowanie. Klasa Podmiot udostępnia również metody pozwalające na przypisywanie atrybutów dodatkowych: ustawatrybutdodatkowy() i dajaatrybutdodatkowy. Przeglądanie zbioru atrybutów dodatkowych konkretnego podmiotu jest możliwe za pośrednictwem interfejsu IZestawyDanych implementowanego przez klasę Podmiot. Konstruktory wszystkich klas przyjmują parametr ISystem umożliwiający dostęp do reszty interfejsów platformy. Prototyp formatek korzystających z komponentu został zawarty w dokumentach Specyfikacji Wymagań Etapu. 1.1.7 Self-Care. Przypomnienie hasła Funkcja umożliwia przypomnienie hasła użytkownika na podstawie identyfikatora oraz adresu e-mail. Dostępna w portalu dla nieuwierzytelnionego użytkownika. SelfCareHasloPortlet - klasa zapewnia integrację z usługą sieciową podsystemu bezpieczeństwa realizującą funkcję: zresetowanie hasła dla podanego identyfikatora konta i wysłanie go na maila skojarzonego z tym identyfikatorem. 25/95

Przypomnienie identyfikatora Funkcja umożliwia przypomnienie identyfikatora użytkownika na podstawie adresu e-mail. Dostępna w portalu dla nieuwierzytelnionego użytkownika. SelfCarePortlet - realizującą funkcję: klasa zapewnia integrację z usługą sieciową podsystemu bezpieczeństwa wysłanie na podany adres mailowy skojarzonych z nim identyfikatorów. 1.1.8 Aplikacja do tworzenia reguł zaufania dla profili podmiotów. Funkcja umożliwia definiowanie reguł dla profilu podmiotu przy pomocy, których będzie następowała decyzja, czy dany profil może zostać uznany za zaufany, czy też nie. Samo zdefiniowanie reguły będzie sprowadzało się do nadania jej nazwy, wyspecyfikowania listy atrybutów, które muszą być potwierdzone, aby dany profil podmiotu mógł zostać uznany za zaufany oraz czasu na jaki potwierdzenie zostaje wydane na podstawie tej reguły. Wszystkie reguły tworzą uszeregowaną listę, która jest następnie wykorzystana w procesie zaufania profilu podmiotu. Jeśli, którakolwiek z reguł pozwala na uznanie danego profilu za zaufany, zostanie on wówczas jako taki oznaczony. Funkcja jest dostępna dla użytkownika uwierzytelnionego posiadającego uprawnienie Definiowanie reguł dla podmiotu. RulesManagerPortlet klasa portletu do zarządzania regułami użytkownika i podmiotu. Dostarcza podstawowe metody dodawania, edycji, zmiany priorytetu oraz usuwania reguły. Rule klasa przechowuje reguły zaufania profili podmiotów. Gromadzi dane o nazwie, priorytecie oraz czasie obowiązywania reguły. RuleToAttribute klasa reprezentująca powiązanie atrybutów profilu podmiotu z regułą. 1.1.9 Aplikacja do tworzenia reguł zaufania dla kont użytkowników. Funkcja umożliwia definiowanie reguł dla użytkownika przy pomocy, których będzie następowała decyzja, czy dane konto może zostać uznane za zaufane, czy też nie. Samo zdefiniowanie reguły będzie sprowadzało się do nadania jej nazwy, wyspecyfikowania listy atrybutów, które muszą być potwierdzone, aby dane konto użytkownika może zostać uznane za zaufane oraz czasu na jaki potwierdzenie zostaje wydane na podstawie tej reguły. Wszystkie reguły tworzą uszeregowaną listę, która jest następnie wykorzystana w procesie zaufania konta użytkownika. Jeśli, którakolwiek z reguł pozwala na uznanie danego profilu za zaufany, zostanie on wówczas jako taki oznaczony. Funkcja jest dostępna dla użytkownika uwierzytelnionego posiadającego uprawnienie Definiowanie reguł dla użytkownika. RulesManagerPortlet klasa portletu do zarządzania regułami użytkownika i podmiotu. Dostarcza podstawowe metody dodawania, edycji, zmiany priorytetu oraz usuwania reguły. Rule klasa przechowuje reguły zaufania profili podmiotów. Gromadzi dane o nazwie, priorytecie oraz czasie obowiązywania reguły. RuleToAttribute klasa reprezentująca powiązanie atrybutów profilu podmiotu z regułą. 1.1.10 Aplikacja do zarządzania atrybutami podstawowymi i dodatkowymi użytkowników. Funkcja umożliwia definiowanie i edycję atrybutów dodatkowych opisujących konto użytkownika. Przy definicji każdego z atrybutów będzie możliwość skojarzenia z polem certyfikatu, na które to dany 26/95

atrybut może się mapować. Możliwość ta została wykorzystana do realizacji funkcjonalności automatycznego zaufania konta użytkownika na podstawie informacji zawartych w certyfikacie. Definiowanie wartości atrybutów opcjonalnych odbywa się z poziomu portalu dla uwierzytelnionego użytkownika posiadającego uprawnienie Zarządzanie atrybutami. ActionProcessor klasa główna procesora akcji wykonywanych przez użytkownika w ramach funkcji panelu administracyjnego, mojego konta oraz słowników referencyjnych. Dostarcza podstawowe metody dodawania, edycji oraz usuwania atrybutów użytkownika. IZarzadzanieUzytkownikami - interfejs udostępnia funkcjonalności zarządzania użytkownikami i jest implementowany przez komponent UBZP: ZarzadzanieUzytkownikami. UserAttribute - klasa reprezentuje definicje atrybutów dla użytkowników. Gromadzi dane o nazwie atrybutu, typie oraz jego mapowaniu na pole certyfikatu. Możliwe typy atrybutów to: A - dodatkowy, P - podstawowy. UserAttributeValue klasa przechowuje wartość atrybutu użytkownika. Gromadzi informacje o użytkowniku i wartości atrybutu. 1.1.11 Aplikacja do zarządzania atrybutami podstawowymi i dodatkowymi profili podmiotów. Funkcja umożliwia definiowanie i edycję atrybutów dodatkowych opisujących profil podmiotu. Przy definicji każdego z atrybutów będzie możliwość skojarzenia z polem certyfikatu, na które to dany atrybut może się mapować. Możliwość ta została wykorzystana do realizacji funkcjonalności automatycznego zaufania profilu podmiotu na podstawie informacji zawartych w certyfikacie. Definiowanie wartości atrybutów opcjonalnych odbywa się z poziomu portalu dla uwierzytelnionego użytkownika posiadającego uprawnienie Zarządzanie atrybutami. ActionProcessor klasa główna procesora akcji wykonywanych przez użytkownika w ramach funkcji panelu administracyjnego, mojego konta oraz słowników referencyjnych. Dostarcza podstawowe metody dodawania, edycji oraz usuwania atrybutów profilu podmiotu. IZarzadzaniePodmiotami - interfejs udostępnia funkcjonalności zarządzania podmiotami i jest implementowany przez komponent UBZP: Zarządzanie tożsamością w podsystemie bezpieczeństwa. AtrybutDodatkowy - klasa reprezentuje definicje atrybutów dla profilu podmiotu. Gromadzi dane o nazwie atrybutu, typie oraz jego mapowaniu na pole certyfikatu. Możliwe typy atrybutów to: A - dodatkowy, P - podstawowy. WartoscAtrybutu klasa przechowuje wartość atrybutu profilu podmiotu. Gromadzi informacje o podmiocie i wartości atrybutu. 1.1.12 Aplikacja potwierdzania danych profili podmiotów na podstawie certyfikatu. Aplikacja umożliwia potwierdzanie (zaufanie) profilu podmiotu na podstawie certyfikatu przez zalogowany podmiot. Lista atrybutów jest pobierana z certyfikatu i jest mapowana na atrybuty podmiotu na podstawie mapowań zdefiniowanych w aplikacji do zarządzania atrybutami podstawowymi i dodatkowymi. Następnie następuje próba dopasowania atrybutów do reguł podmiotu zdefiniowanych w systemie. Reguły są przeszukiwane według priorytetów. Jeśli zbiór potwierdzonych atrybutów jest nie mniejszy niż zbiór atrybutów w regule to profil podmiotu zostaje zaufany na liczbę dni zdefiniowaną w regule. 27/95

TrustAccountPortlet klasa portletu obsługującego akcje zarządzania zaufaniem kont użytkowników oraz profili podmiotów. TrustManager klasa udostępnia główne funkcje ręcznego czy też poprzez certyfikat, zaufania konta użytkownika i profilu podmiotu. W przypadku potwierdzenia certyfikatem zostały zaimplementowane metody integracji z usługą sieciową SOPEL, weryfikującą wystawcę certyfikatu. Trust klasa przechowuje informacje o zaufanych profilach podmiotów. Gromadzi dane o typie potwierdzenia (certyfikat, ręczne) oraz dacie obowiązywania zaufania. TrustToAttribute klasa reprezentuje informacje o skojarzeniu atrybutów, które umożliwiły zaufanie danych profilu podmiotu. 1.1.13 Aplikacja potwierdzania danych kont użytkownika na podstawie certyfikatu. Aplikacja umożliwia potwierdzanie (zaufanie) użytkownika na podstawie certyfikatu przez zalogowanego użytkownika. Lista atrybutów jest pobierana z certyfikatu i jest mapowana na atrybuty użytkownika na podstawie mapowań zdefiniowanych w aplikacji do zarządzania atrybutami podstawowymi i dodatkowymi. Następnie następuje próba dopasowania atrybutów do reguł podmiotu zdefiniowanych w systemie. Reguły są przeszukiwane według priorytetów. Jeśli zbiór potwierdzonych atrybutów jest nie mniejszy niż zbiór atrybutów w regule to użytkownik zostaje zaufany na liczbę dni zdefiniowaną w regule. TrustAccountPortlet klasa portletu obsługującego akcje zarządzania zaufaniem kont użytkowników oraz profili podmiotów. TrustManager klasa udostępnia główne funkcje ręcznego czy też poprzez certyfikat, zaufania konta użytkownika i profilu podmiotu. W przypadku potwierdzenia certyfikatem zostały zaimplementowane metody integracji z usługą sieciową SOPEL, weryfikującą wystawcę certyfikatu. UserTrust klasa przechowuje informacje o zaufanych kontach użytkowników. Gromadzi dane o typie potwierdzenia (certyfikat, ręczne) oraz dacie obowiązywania zaufania. UserTrustToAttribute - klasa reprezentuje informacje o skojarzeniu atrybutów, które umożliwiły zaufanie danych konta użytkownika. 1.1.14 Aplikacja ręcznego potwierdzania danych kont użytkownika. Aplikacja umożliwia potwierdzanie (zaufanie) użytkownika na podstawie ręcznie wybranych atrybutów, na podstawie wcześniej wprowadzonego identyfikatora użytkownika. Operator potwierdza wybrane atrybuty (wyświetlane są tylko te, które mają wartości) i na ich podstawie następuje próba zaufania użytkownika. Polega ona na próbie dopasowania wybranych atrybutów do reguł użytkownika zdefiniowanych w systemie. Reguły są przeszukiwane według priorytetów. Jeśli zbiór potwierdzonych atrybutów jest nie mniejszy niż zbiór atrybutów w regule to użytkownik zostaje zaufany na liczbę dni zdefiniowaną w regule. Ręczne potwierdzenie danych konta użytkownika odbywa się z poziomu portalu dla uwierzytelnionego użytkownika posiadającego uprawnienie Potwierdzenie profilu dla użytkownika oraz Usuwanie potwierdzenia profilu użytkownika. TrustPortlet klasa portletu obsługuje główne akcje ręcznego zaufania konta użytkownika. TrustPortletSessionBean klasa przechowuje właściwości formatki zaufania konta użytkownika. 28/95

TrustManager klasa udostępnia główne funkcje ręcznego czy też poprzez certyfikat, zaufania konta użytkownika i profilu podmiotu. W przypadku potwierdzenia certyfikatem zostały zaimplementowane metody integracji z usługą sieciową SOPEL, weryfikującą wystawcę certyfikatu. UserTrust klasa przechowuje informacje o zaufanych kontach użytkowników. Gromadzi dane o typie potwierdzenia (certyfikat, ręczne) oraz dacie obowiązywania zaufania. UserTrustToAttribute - klasa reprezentuje informacje o skojarzeniu atrybutów, które umożliwiły zaufanie danych konta użytkownika. 1.1.15 Aplikacja ręcznego potwierdzania danych profili podmiotów. Aplikacja umożliwia potwierdzanie (zaufanie) profilu podmiotu na podstawie ręcznie wybranych atrybutów, na podstawie wcześniej wprowadzonego identyfikatora podmiotu. Operator potwierdza wybrane atrybuty (wyświetlane są tylko te, które mają wartości) i na ich podstawie następuje próba zaufania profilu podmiotu. Polega ona na próbie dopasowania wybranych atrybutów do reguł podmiotu zdefiniowanych w systemie. Reguły są przeszukiwane według priorytetów. Jeśli zbiór potwierdzonych atrybutów jest nie mniejszy niż zbiór atrybutów w regule to profil podmiotu zostaje zaufany na liczbę dni zdefiniowaną w regule. Ręczne potwierdzenie danych profilu podmiotu odbywa się z poziomu portalu dla uwierzytelnionego użytkownika posiadającego uprawnienie Potwierdzenie profilu dla podmiotu oraz Usuwanie potwierdzenia profilu podmiotu. TrustPortlet klasa portletu obsługuje główne akcje ręcznego zaufania profilu podmiotu. Udostępnia podstawowe metody zarządzania zaufaniem (potwierdzenie danych, usunięcie zaufania). TrustPortletSessionBean klasa przechowuje właściwości formatki zaufania profilu podmiotu. TrustManager klasa udostępnia główne funkcje ręcznego czy też poprzez certyfikat, zaufania konta użytkownika i profilu podmiotu. W przypadku potwierdzenia certyfikatem zostały zaimplementowane metody integracji z usługą sieciową SOPEL, weryfikującą wystawcę certyfikatu. Trust klasa przechowuje informacje o zaufanych profilach podmiotów. Gromadzi dane o typie potwierdzenia (certyfikat, ręczne) oraz dacie obowiązywania zaufania. TrustToAttribute klasa reprezentuje informacje o skojarzeniu atrybutów, które umożliwiły zaufanie danych profilu podmiotu. Opisy klas i pól zawarto w załączonym repozytorium RSA. 1.1.10 Portal epuap Portal epuap jest portalem publikacyjnym stanowiącym miejsce pierwszego kontaktu z epuap. Udostępnia szereg publikacji dotyczących epuap, sposobu korzystania z niego, profilowane przewodniki, FAQ i inne tego typu statyczne publikacje, jak również odniesienia do innych części epuap. Portal epuap realizuje usługi: Zarządzanie treścią Portal epuap jest realizowany przy pomocy oprogramowania standardowego WebSphere Portal. Standardowe portlety są przystosowane do korzystania z interfejsów uwierzytelniania, autoryzacji i obsługi zdarzeń. 29/95

1.1.11 Słowniki referencyjne Podsystem stanowi źródło słowników referencyjnych dla pozostałych podsystemów epuap oraz wykonuje wszystkie funkcje związane z ich zasilaniem. Podsystem słowników referencyjnych realizuje usługi składowe wymienione poniżej. Zarządzanie słownikami referencyjnymi Zasilanie słowników referencyjnych Model i opis podsystemu przedstawiono w dokumentach Specyfikacji Wymagań Etapu. Na diagramie zaprezentowano budowę komponentową podsystemu słowników referencyjnych. Rysunek 18 Budowa komponentowa podsystemu SR: Słowniki referencyjne Interfejsy, które udostępnia podsystem słowników referencyjnych to: IZarządzanieSlowników obsługuje pełen zakres funkcjonalności słownika, Interfejsy i ich funkcje konieczne do pracy podsystemu to: IObsługaZdarzeń obsługuje zgłaszanie zdarzeń, IZarządzanieUprawnieniami obsługuje weryfikację uprawnień, IUwierzytelnianieAutoryzacja obsługuje uwierzytelnienia użytkowników. Podsystem składa się z dwóch komponentów: SRKONF: Konfiguracja zarządza parametrami pracy słowników, SRZS: Zarządzanie słownikami zarządza słownikami. 30/95

Punktem wejścia komponentu jest klasa ZarzadzanieSlownikami implementująca interfejsy fabrykę umożliwiającą tworzenie i edycję słowników. Każdy słownik stanowi fabrykę obiektów klasy PozycjaSlownika. Dostęp i wyszukiwanie pozycji realizowane jest za pomocą interfejsu IZestawyDanych. Każdy słownik może mieć zdefiniowany typ pobierania, którego obiekt otrzymamy po wywołaniu metody dajtyppobierania(). Z typem pobierania skojarzony jest obiekt klasy HarmonogramPobierania, który uzyskamy przy pomocy metody dajharmonogrampobierania(). Dostęp do zbioru plików źródłowych jest dostępny z poziomu obiektu TypPobierania, który implementuje interfejs IZestawyDanych. Automatyczna aktualizacja słowników zgodnie z harmonogramem odbywa się przez cykliczne wywołanie metody zasilatomatycznie(), która iteruje słowniki i wywołuje ich własne metody walidujące zgodność czasu z kryteriami harmonogramu. Jeśli weryfikacja jest pozytywna następuje wywołanie procedury zasilającej (wywołanie URL) w wyniku, której otrzymamy plik XML lub transformacja pliku źródłowego składowanego w obiektach klasy PlikZrodlowy metoda zasil(plik) klasy TypZasilania. Zasilanie ręczne polega na wczytaniu pliku do bufora (metoda zapiszbuforplik) oraz wywołania zasilania metoda zasilzbufora(). Zasilanie można również uruchomić w sposób asynchroniczny wywołując zailzbuforaasynchronicznie. Stan aktualnego zasilania można obserwować w polu komunikat w klasie Slownik. Ustawiając właściwość bufordataaktualizacji wymuszamy zasilenie z bufora o określonej godzienie. Konstruktory wszystkich klas przyjmują parametr ISystem umożliwiający dostęp do reszty interfejsów platformy. Opisy klas i pól zawarto w załączonym repozytorium RSA. 1.1.12 Repozytorium wzorów formularzy Podsystem przechowuje wzory formularzy elektronicznych dla pozostałych podsystemów epuap oraz wykonuje wszystkie funkcje związane z ich publikowaniem. Repozytorium wzorów formularzy będzie realizowało usługi składowe wymienione poniżej. Zarządzanie wzorami formularzy elektronicznych Model i opis podsystemu przedstawiono w dokumentach Specyfikacji Wymagań Etapu Na diagramie zaprezentowano budowę komponentową podsystemu repozytorium wzorów formularzy. 31/95

Rysunek 19 Budowa komponentowa podsystemu RW: Repozytorium wzorów formularzy Interfejsy udostępniane przez ten komponent to: IZarzadzanieWzorami pozwala na dostęp do wzorów formularzy elektronicznych, Interfejsy i ich funkcje konieczne do pracy podsystemu to: IObsługaZdarzeń obsługuje zgłaszanie zdarzeń, IZarządzanieUprawnieniami obsługuje weryfikację uprawnień, IUwierzytelnianieAutoryzacja obsługuje uwierzytelnienia użytkowników, IZarzadzaniePlikami obsługuje dostęp do repozytorium plików, Podsystem składa się z dwóch komponentów: RWKONF: Konfiguracja zarządza parametrami konfiguracyjnymi podsystemu, RWZWF: Zarządzanie wzorami formularzy zarządza wzorami formularzy elektronicznych. 1.1.16 RWKONF: Konfiguracja Komponent zarządza parametrami pracy repozytorium wzorów formularzy i dostarcza je wszystkim komponentom wchodzącym w skład podsystemu. Poniżej zaprezentowano komponent implementuje i udostępniający interfejsy: IKonfiguracja składowanie i odczyt parametrów konfiguracyjnych IZestawDanych zwracanie listy parametrów konfiguracyjnych. 32/95

Komponent jest implementowany przy pomocy pojedynczej klasy Konfiguracja. Organizację klasy i interfejsów zaprezentowano na diagramie poniżej. Klasa Konfiguracja jest identyczna jak w przypadku komponentu UBKONF i jej definicja może być powtórnie wykorzystywana. 1.1.17 RWZWF: Zarządzanie wzorami formularzy Komponent realizuje funkcjonalności zarządzania wzorami formularzy elektronicznych jak przyjmowanie wniosków dotyczących opublikowania wzorów, ich weryfikację oraz publikowanie w postaci wzorów. Pozwala także na przeszukiwanie i dostęp do listy wzorów i wniosków. Komponent implementuje i jest widoczny poprzez interfejsy: IZarządzanieWzorami umożliwia utworzenie nowego wniosku oraz pobranie określonego wzoru lub wniosku IZestawyDanych umożliwia dostęp do wzorów oraz do listy wniosków Komponent RWZWF: Zarządzanie wzorami formularzy jest implementowany zbiorem klas, których organizację i interfejsy przedstawiono na diagramie poniżej.. Punktem wejścia komponentu jest klasa ZarzadzanieWzorami implementująca interfejs IZarzadzanieWzorami, rozszerzający interfejs IZestawyDanych, które umożliwiają tworzenie wniosków, pobieranie zestawów danych zawierających listę wszystkich wniosków oraz wszystkich opublikowanych wzorów, oraz pobieranie określonych obiektów klasy Wniosek lub Wzór. Wniosek implementuje interfejs standardowy IFabrykaObiektów, pozwalając na tworzenie komentarzy weryfikacyjnych do wniosku, reprezentowanych przez obiekty klasy Weryfikacja. Dodatkowo klasa Wniosek udostępnia funkcjonalności związane z weryfikacją i akceptacją wzoru formularza przed opublikowaniem. Klasa wniosek posiada także metodę opublikujwzór, która tworzy obiekty klasy Wzór. Klasa Wzór reprezentuje opublikowany wzór formularza elektronicznego. Implementuje interfejs IFabrykaObiektów, pozwalając na tworzenie dodatkowych atrybutów klasyfikacyjnych dla wzoru formularza. Aby umożliwić powiązania pomiędzy opublikowanymi wzorami typu Jest wersją i Ma wersję, zaprojektowano klasę Wersjonowanie przechowującą te informacje. Do klasy Wzór została dodana metoda dezaktualizujwzor, która jednorazowo i nieodwracalnie oznacza wzór jako niekatualny. Wzór może być wtedy niekatualny nawet bez wskazania nowej wersji. Klasa załącznik przechowuje informacje o identyfikatorach plików załączonych do danego wniosku o publikację wzoru formularza. Dostęp do plików przechowywanych w repozytorium plików realizowany jest za pomocą interfejsu IZarzadzaniePlikami. Konstruktory wszystkich klas przyjmują parametr ISystem umożliwiający dostęp do reszty interfejsów platformy. Opisy klas i pól zawarto w załączonym repozytorium RSA. 33/95

1.1.13 Portal Interoperacyjności Podsystem przechowuje wzory formularzy elektronicznych dla pozostałych podsystemów epuap oraz wykonuje wszystkie funkcje związane z ich publikowaniem. Repozytorium wzorów formularzy będzie realizowało usługi składowe wymienione poniżej. Zarządzanie wzorami formularzy elektronicznych Model i opis podsystemu przedstawiono w dokumentach Specyfikacji Wymagań Etapu Na diagramie zaprezentowano budowę komponentową podsystemu repozytorium wzorów formularzy. Rysunek 20 Budowa komponentowa podsystemu PI: Portal Interoperacyjności Interfejsy udostępniane przez ten komponent to: IZarzadzaniePlikami pozwala na dostęp do plików przechowywanych w repozytorium plików, Interfejsy i ich funkcje konieczne do pracy podsystemu to: IObsługaZdarzeń obsługuje zgłaszanie zdarzeń, IZarządzanieUprawnieniami obsługuje weryfikację uprawnień, IUwierzytelnianieAutoryzacja obsługuje uwierzytelnienia użytkowników, Podsystem składa się z czterech komponentów: PIKONF: Konfiguracja zarządza parametrami konfiguracyjnymi podsystemu, PIWP: ZarzadzanieWatkamiPrac zarządza wątkami prac nad rekomendacjami interoperacyjności, PIRP: RepozytoriumPlikow zarządza dostępem do plików przechowywanych przechowywanych i udostępnianych na platformie epuap, PIFI: ZarzadzanieForami zarządza forami dyskusyjnymi. 34/95

1.1.18 PIKONF: Konfiguracja Komponent zarządza parametrami pracy portalu interoperacyjności i dostarcza je wszystkim komponentom wchodzącym w skład podsystemu. Poniżej zaprezentowano komponent implementuje i udostępniający interfejsy: IKonfiguracja składowanie i odczyt parametrów konfiguracyjnych IZestawDanych zwracanie listy parametrów konfiguracyjnych. Komponent jest implementowany przy pomocy pojedynczej klasy Konfiguracja. Organizację klasy i interfejsów zaprezentowano na diagramie poniżej. Rysunek 21 Implementacja komponentu RWKONF Klasa Konfiguracja jest identyczna jak w przypadku komponentu UBKONF i jej definicja może być powtórnie wykorzystywana. 1.1.19 PIWP: Zarządzanie wątkami prac Komponent realizuje funkcjonalności zarządzania wątkami prac nad rekomendacjami interoperacyjności. Komponent implementuje i jest widoczny poprzez interfejsy: IZarządzanieWatkamiPrac umożliwia dostęp do obiektów reprezentujących wątki prac oraz wypracowywane rekomendacje. Pozwala także na tworzenie nowych wątków. IZestawyDanych umożliwia dostęp do zestawów danych zawierających listy wątków oraz rekomendacji IZarzadzaniePlikami umożliwia dostęp do repozytorium plików. 35/95

Komponent PIWP: Zarządzanie wątkami prac jest implementowany zbiorem klas, których organizację i interfejsy przedstawiono na diagramie poniżej. Punktem wejścia komponentu jest klasa ZarzadzanieWatkami implementująca interfejs IZarzadzanieWatkami, rozszerzający interfejs IZestawyDanych, które umożliwiają tworzenie wątków prac, pobieranie zestawów danych zawierających listę wszystkich wątków prac oraz wszystkich wypracowanych rekomendacji, a także pobieranie określonych obiektów klasy Watek lub Rekomendacja. Konstruktory klas implementującyh interfejs ISkladowanie przyjmują parametr ISystem umożliwiający dostęp do reszty interfejsów platformy oraz dostęp do połączenia z bazą danych. Opisy klas i pól zawarto w załączonym repozytorium RSA. 1.1.20 PIFI: Zarządzanie forami interoperacyjności Komponent realizuje funkcjonalności zarządzania forami dyskusyjnymi wykorzystywanymi rekomendacjami pracach nad rekomendacjami interoperacyjności. Opakowuje on zewnętrzny system JForum, będący opensource ową implementacją funkcjonalności forów dyskusyjnych napisaną w technologii Java. Komponent PIFI pozwala na integrację tego narzędzia z platformą epuap udostępniając podstawowe funkcje do manipulowania forami dyskusyjnymi i ankietami. Komponent implementuje i jest widoczny poprzez interfejsy: IZarządzanieForami umożliwia dostęp do obiektów reprezentujących wątki prac oraz wypracowywane rekomendacje. Pozwala także na tworzenie nowych wątków. IZestawyDanych umożliwia dostęp do zestawu danych zawierającego listę ankiet zdefiniowanych w zewnętrznym narzędziu JForum Komponent PIFI: Zarządzanie forami interoperacyjności jest implementowany zbiorem klas, których organizację i interfejsy przedstawiono na diagramie poniżej. 36/95

Rysunek 22 Projekt implementacji komponentu PIFI Punktem wejścia komponentu jest klasa ZarzadzanieForami implementująca interfejs IZarzadzanieForami, rozszerzający interfejs IZestawyDanych, które umożliwiają tworzenie nowych forów ich subskrybcję i generowanie adresów url, a także pobieranie zestawu danych zawierających listę wszystkich ankiet zdefiniowanych w JForum. Ponieważ w JForum ankieta związana jest bezpośrednio z jakimś tematem na forum, konieczne jest udostępnienie zestawu danych zawierającego listę wszystkich ankiet, w oderwaniu od tematów, by umożliwić zarządzanie ankietami po stronie komponentu PIWP w epuap. Konstruktory klasy ZarzadzanieForami przyjmuje parametr ISystem umożliwiający dostęp do reszty interfejsów platformy oraz dostęp do połączenia z bazą danych. Opisy klas i pól zawarto w załączonym repozytorium RSA. 1.1.21 PIRP: Repozytorium plików Komponent realizuje funkcjonalności dostępu do plików przechowywanych rekomendacjami repozytorium plików narzędzia WebSphere Portal Document Manager. Opakowuje on publiczne API systemu, pozwalające na przechowywanie, wersjonowanie i katalogowanie plików, zarówno tekstowych, jak i binarnych. Komponent implementuje i jest widoczny poprzez interfejs: IZarzadzaniePlikami umożliwia dostęp do plików przechowywanych w repozytorium. Komponent PIRP: Repozytorim plików jest implementowany zbiorem klas, których organizację i interfejsy przedstawiono na diagramie poniżej. Punktem wejścia komponentu jest klasa ZarzadzaniePlikami implementująca interfejs IZarzadzaniePlikami pozwalający na pobieranie obiektów klasy Plik reprezentujących pliki, ich tworzenie oraz generowanie adresów URL do pobrania pliku przez przeglądarkę. Klasa Plik opakowuje plik w repozytorium plików produktu WebSphere Document Manager w dodatkowe atrybuty wymagane przez podsystem PIWP, takie jak identyfikator funkcji biznesowej oraz 37/95

oznaczenie formatu pliku. Udostępnia także podstawowe manipulacje na pliku w repozytorium, t.j. blokowanie, pobieranie, czy zapisywanie nowych wersji pliku. Konstruktor klasy ZarzadzaniePlikami przyjmuje parametr ISystem umożliwiający dostęp do reszty interfejsów platformy oraz dostęp do połączenia z bazą danych. Opisy klas i pól zawarto w załączonym repozytorium RSA. 1.1.14 Podsystem komunikacyjny Podsystem odpowiedzialny jest za realizację następujących funkcjonalności: Przesyłanie dokumentów pomiędzy podmiotami i podsystemami z wykorzystaniem skrytek Realizacja doręczeń dokumentów za zwrotnym poświadczeniem Definiowanie zasad komunikacji poprzez definicje skrytek oraz reguły walidacyjne Wystawianie poświadczeń w imieniu podmiotu odbiorcy Usługi składowe realizowane przez podsystem: Skrytka asynchroniczna pracująca w trybie PUSH Skrytka asynchroniczna pracująca w trybie PULL Skrytka synchroniczna Usługa doręczyciela Na diagramie zaprezentowano budowę komponentową podsystemu komunikacyjnego. Rysunek 23 Budowa komponentowa podsystemu komunikacyjnego Interfejsy udostępniane przez ten podsystem to: IKomunikacja ISkrytka IDoreczyciel Interfejsy i ich funkcje konieczne do pracy podsystemu to: 38/95

POWYKONAWCZY PROJEKT IObsługaZdarzeń obsługuje zgłaszanie zdarzeń, IZarządzanieUprawnieniami obsługuje weryfikację uprawnień, IUwierzytelnianieAutoryzacja obsługuje uwierzytelnienia użytkowników, Podsystem składa się z następujących komponentów: PKKONF: Zarządza parametrami konfiguracyjnymi podsystemu PKSKR: Obsługa skrytek PKDOR: Obsługa doręczeń PKNARZ: Zestaw klas narzędziowych odpowiedzialnych za wewnętrzną funkcjonalność podsystemu 1.1.22 PKKONF: Konfiguracja Komponent zarządza parametrami pracy podsystemu komunikacyjnego i dostarcza je wszystkim komponentom wchodzącym w skład podsystemu. Poniżej zaprezentowano interfejsy implementowane i udostępniane przez komponent: IKonfiguracja składowanie i odczyt parametrów konfiguracyjnych IZestawDanych zwracanie listy parametrów konfiguracyjnych. Komponent jest implementowany przy pomocy pojedynczej klasy Konfiguracja. Organizację klasy i interfejsów zaprezentowano na diagramie poniżej. Klasa Konfiguracja jest identyczna jak w przypadku komponentu UBKONF i jej definicja może być powtórnie wykorzystywana. 1.1.23 PKSKR: Obsługa skrytek Komponent realizuje funkcjonalności obsługi skrytek i komunikacji z wykorzystaniem skrytek. Dla nowo tworzonego profilu podmiotu w epuap, tworzy się skrytka z przypisanymi domyślnymi wartościami konfiguracyjnymi. Skrytki dzielą się na dwa rodzaje: synchroniczna i asynchroniczna (użytkownik może dokonywać konfiguracji skrytek w ramach swojego podmiotu). W podsystemie można podzielić użytkowników na dwie grupy: instytucje publiczne oraz pozostałe podmioty. W systemie epuap dopuszczalna jest wyłącznie komunikacja, w której przynajmniej jedna ze stron jest instytucją publiczną. Komponent implementuje i jest widoczny poprzez interfejsy: IKomunikacja ISkrytka 39/95

Komponent PKSKR: obsługa skrytek jest implementowany zbiorem klas, których organizację i interfejsy przedstawiono na diagramie poniżej. Konstruktory klas implementującyh interfejs ISkladowanie przyjmują parametr ISystem umożliwiający dostęp do reszty interfejsów platformy oraz dostęp do połączenia z bazą danych. IKomunikacja Interfejs IKomunikacja udostępnia następujące metody: ladujkonfiguracje ustawienie konfiguracji skrytek podmiotu na podstawie pliku XML pobierzkonfiguracje pobranie konfiguracji skrytek podmiotu w formacie pliku XML usunskrytke usunięcie skrytki usunzasobypodmiotu usunięcie wszystkich zasobów podmiotu dajliste pobranie listy obiektów określonego typu konfiguruj wprowadzenie zmiany w konfiguracji wskazanego elementu dodajpodmiottestowy rejestruje podmiot testowy w kontekście adresu skrytki usunpodmiottestowy usuwa podmiot testowy w kontekście adresu skrytki Interfejs ISkrytka udostępnia następujące metody: przyjmijdokument przedłożenie dokumentu na skrytkę pulloczekujacedokumenty zwraca liczbę dokumentów oczekujących na pobranie w trybie PULL pullnastepnapozycja zwraca pierwszy dokument z kolejki oczekujących na pobranie w trybie PULL pullpotwierdzodebranie potwierdza odebranie dokumentu z kolejki w trybie PULL i powoduje usunięcie pozycji z kolejki oczekujących 1.1.24 PKDOR: Obsługa doręczeń Interfejs dostępny wyłącznie dla instytucji publicznych. Doręczyciel zajmuje się doręczaniem dokumentów do odbiorców w trybie postępowania administracyjnego. Wraz z przesyłanym dokumentem generowane jest UPD. Niezbędne jest podanie przez nadawcę terminu odbioru dokumentu. Niepodpisane UPD jest przekazywane do adresata i po jego podpisaniu w zamian za podpisane UPD doręczany jest dokument. Interfejs IDoreczyciel udostępnia następujące metody: zleceniedoreczenia utworzenie zlecenia doręczenia dokumentu odebraniedokumentu odebranie przez adresata dokumentu na podstawie podpisanego UPD 40/95

1.1.25 PKDOR: Komponent narzędziowy Komponent narzędziowy odpowiada za wewnętrzne działanie podsystemu komunikacyjnego, realizując takie zadania jak: Przetwarzanie kolejki zadań Weryfikacje reguł i schematów Obsługa powiadomień Komponent nie udostępnia żadnych interfejsów poza podsystem, wykorzystywany jest natomiast przez pozostałe komponenty oraz wykonuje czynności cykliczne. 1.1.15 Katalog usług publicznych Podsystem odpowiedzialny za składowanie w KUP usług oraz ich atrybutów. Umożliwia on także nawigację oraz wyszukiwanie usług w katalogu. Podsystem katalog usług publicznych będzie realizował następujące usługi składowe wymienione poniżej: Zarządzanie usługą Ręczna kategoryzacja usługi Automatyczna kategoryzacja usługi Nawigacja i wyszukiwanie w katalogu Organizację i przypisanie interfejsów skojarzonych z usługami składowymi przedstawiono na diagramie. 41/95

Komponent KUPZU oraz KUPNWK do poprawnej pracy wymagają interfejsu IKonfiguracja. Interfejsy udostępniane przez ten podsystem to: IZarzadzanieUsluga Interfejsy i ich funkcje konieczne do pracy podsystemu to: IObsługaZdarzeń obsługuje zgłaszanie zdarzeń, IZarządzanieUprawnieniami obsługuje weryfikację uprawnień, IUwierzytelnianieAutoryzacja obsługuje uwierzytelnienia użytkowników, Podsystem składa się z następujących komponentów: KUPKONF: Zarządza parametrami konfiguracyjnymi podsystemu KUPZU: Zarządzanie usługami 1.1.26 KUPKONF: Konfiguracja Komponent dostarcza informacji na temat parametrów Katalogu Usług Publicznych wszystkim komponentom wchodzącym w skład podsystemu KUP. Interfejs IKonfiguracja umożliwia pobranie (metoda dajwartosc()) i ustawienie parametru konfiguracyjnego (metoda ustawwartosc()). Dostęp do zbioru parametrów konfiguracyjnych jest możliwy za pośrednictwem interfejsu IZestawyDanych. 42/95

Organizację interfejsów komponentu zaprezentowano na diagramie poniżej. Rysunek 24 Komponent KUPKONF Funkcjonalność jest realizowana przy użyciu klasy Konfiguracja, która została przedstawiona na poniższym diagramie. 43/95

Rysunek 25 Implementacja komponentu KUPKONF Metoda ustawwartosc() pozwala utworzyć nowy parametr, jeśli jeszcze nie istniał w bazie danych. Metoda ustawwartosczlozona() sluzy do wstawiania wartości oddzielonych znakiem przecinka. Analogicznie metoda usunwartosczlozona() służy do usuwania jednej z wartości oddzielonych przecinkami. Parametr typu ISystem w konstruktorze klasy pozwala dostęp do pozostałych interfejsów systemu. 1.1.27 KUPZU: Zarządzanie usługą Głównym zadaniem komponentu KUPZU jest zarządzanie usługą rozumiane jako dodawanie, aktualizacja i usuwanie usług oraz przypisywanie do nich klasyfikacji. Udostępniany przez komponent KUPZU interfejs umożliwia następujące operacje: klasyfikujwgrequly() dokonuje klasyfikacji opisów usług wg określonej lub wszystkich reguł klasyfikacji, undoreguly(regula) powoduje cofnięcie zmian dokonanych przez regula, Rozszerzenie funkcjonalności komponentu stanowią: Ręczna kategoryzacja usługi zawiera metody służące do dodawania atrybutów terytorialnych usługi, Podobnie jak pozostałe klasy konstruktor będzie otrzymywał obiekt klasy ISystem, który umożliwi komunikacje z pozostałymi elementami systemu. 1.1.16 Frontend Podsystem odpowiada za zarządzanie składem podmiotu, formularzami, sprawami w ramach składów, wzorami lokalnymi oraz dokumentami zapisanymi w składzie. Na diagramie poniżej zaprezentowano budowę komponentową podsystemu. 44/95

Rysunek 26: Budowa komponentowa podsystemu FE: Frontend Podsystem udostępnia następujące interfejsy: IZarzadzanieSkladem pozwala na operacje wykonywane w ramach składu IZarzadzanieFormularzami obsługuje operacje na formularzach IZarzadzanieSprawami udostępnia operacje na sprawach IZarzadzanieWzorami udostępnia operacje na wzorach IZarzadzanieProfilami umożliwia pobranie informacji o podmiocie IPowiadomienia umożliwia obsługę i konfigurację powiadomień IZarzadzaniePlikami udostępnia podstawowe operacje na plikach Interfejsy innych podsystemów wykorzystywane przez podsystem FrontEnd to: IUwierzytelnianieAutoryzacja obsługuje uwierzytelnianie użytkowników ISkrytka w celu pobrania danych odbiorcy/nadawcy dokumentu IDoreczyciel obsługuje wysyłanie w trybie doręczenia / odsyłanie UPD IZarzadzanieUprawnieniami obsługuje weryfikację uprawnień IZarzadzanieWzorami obsługa wzorów dokumentów IObsługaZdarzen rejestracja zdarzeń 45/95

Podsystem składa się z następujących komponentów: FEKONF: Konfiguracja zarządza parametrami konfiguracyjnymi podsystemu FEDOK: Dokumenty zarządza dokumentami w składzie FESKL: Sklad obsługuje skład podmiotu FEFORM: Formularze zarządza formularzami służącymi do prezentacji i dokumentów FESPR: Sprawy zarządza sprawami w ramach składów FEWZOR: Wzory zarządza wzorami lokalnymi podmiotu FEPROFILE: Profile - odpowiada za pobieranie informacji o podmiotach FEPOW: Powiadomienia zarządza powiadomieniami generowanymi przez składy XML: Pomocniczy pomocniczy komponent do obsługi dokumentów XML 1.1.28 FEKONF: Konfiguracja Komponent zarządza parametrami pracy podsystemu FrontEnd i dostarcza je wszystkim komponentom wchodzącym w skład podsystemu. Poniżej zaprezentowano komponent implementujący i udostępniający interfejsy: IKonfiguracja składowanie i odczyt parametrów konfiguracyjnych IZestawDanych zwracanie listy parametrów konfiguracyjnych. Komponent jest implementowany przy pomocy pojedynczej klasy Konfiguracja. Organizację klasy i interfejsów zaprezentowano na diagramie poniżej. Klasa Konfiguracja jest identyczna jak w przypadku innych komponentów systemu i jej definicja może być powtórnie wykorzystywana. 1.1.29 FEDOK: Dokumenty Komponent FEDOK realizuje funkcje związane z obsługą dokumentów znajdujących się w składzie podmiotu. 46/95

Rysunek 27: Komponent FEDOK Obsługa dokumentów Komponent nie wystawia żadnych interfejsów na zewnątrz. Implementuje wewnętrzny interfejs IZarzadzaniePlikami, który definiuje zestaw operacji na plikach znajdujących się w repozytorium. Komponent wykorzystuje interfejsy dostarczane przez inne podsystemy, w tym IZarządzanieWzorami umożliwiający pobranie oraz skojarzenie dokumentu ze wzorem zapisanym w podsystemie CRW. Klasa Dokument, stanowiąca podstawową klasę implementującą komponent, opakowuje plik w dodatkowe atrybuty specyficzne dla obiektu dokumentu w podsystemie. Klasa DokumentUPO - realizująca specyficzny typ dokumentu stanowiący potwierdzenie otrzymania/nadania/doręczenia dla innego dokumentu - rozszerza klasę Dokument o dodatkowy atrybut skrót SHA-1 potwierdzanego przez siebie dokumentu. Klasa Dokument implementuje także interfejsy standardowe wzorca projektowego (ISkladowanieBaza, IZestawyDanych), które obsługują podstawowe operacje na obiektach oraz dają możliwość uzyskania dokumentu lub zestawu dokumentów spełniających określone warunki (np. zestaw potwierdzeń UPD otrzymanych dla wysłanego dokumentu). 47/95

1.1.30 FESKL: Skład Komponent odpowiedzialny jest za zarządzanie składem oraz pozycjami składu. Rysunek 28: Komponent FESKL: Skład Komponent udostępnia interfejs IZarządzanieSkladem pozwalający wykonywać podstawowe operacje na składzie, a także pobierać zestaw pozycji w składzie (poprzez implementację interfejsu IZestawyDanych). Komponent wykorzystuje interfejs dostarczany przez podsystem bezpieczeństwa służące rejestracji zdarzeń oraz uwierzytelniania użytkownika. Interfejs IZarządzanieSkladem jest odpowiedzialny również za przyjmowanie dokumentów na skład, włącznie z przyporządkowaniem odpowiedniego składu na podstawie adresu skrytki. 48/95

Dwie kluczowe klasy komponentu do Sklad oraz PozycjaSkladu implementujące logikę komponentu. Klasy wykorzystują interfejsy standardowe wzorca projektowego, takie jak FabrykaObiektow i IObiektFabrykowany (skład jest fabryką dla pozycji składu). Duże pliki W systemie istnieje możliwość wczytywania na serwer dużych załączników tj. plików powyżej kilkuset MB. Struktura folderu duże pliki nie różni się zasadniczo od struktury innych folderów np. folderu robocze. Podstawowy zestaw operacji na dyżych plikach udostępnia interfejs IZarządzanieSkladem. Główna różnica jest taka że duże pliki ze względów wydajnościowych są przechowywane na dysku a nie w bazie danych. Ponieważ epuap działa w klastrze pliki te przechowywane są w repozytorium dostępnym z obu serwerów aplikacyjnych. Najstarsze duże pliki są periodycznie usuwane z serwera dla zaoszczędzenia miejsca. Zachowaniem tego mechanizmu można manipulować przez następujące klucze konfiguracyjne, znajdujące się w elemencie konfig o nazwie FE_DUZE_PLIKI: 1) klucz deljobperiodsec określa częstotliwość odpalania zadania usuwającego (domyślnie - raz na 24 godziny); 2) klucz daystored określa maksymalny wiek dokumentu, jeśli dysk nie jest bardzo wypełniony (domyślnie - 30 dni) 3) klucz daystoredwhendiskfull określa maksymalny wiek dokumentu, jeśli dysk jest bardzo wypełniony (domyślnie - 15 dni) 4) klucz minfreespacegb określa, poniżej jakiego poziomu uznajemy dysk za bardzo wypełniony (domyślnie - 2 GB) Podczas załączania dużych plików do dokumentów nie jest załączana zawartość pliku jak to ma miejsce w przypadku np. dokumentów z folderu robocze ale link do pliku i skrót MD5. 1.1.31 FEFORM: Formularze Komponent odpowiada za obsługę formularzy. Komponent wystawia na zewnątrz interfejs IZarzadzanieFormularzami, który z kolei implementuje interfejs standardowy IZestawyDanych umożliwiając uzyskanie zbioru formularzy. 49/95

50/95

Rysunek 29: Komponent FEFORM: Formularze Komponent wystawia na zewnątrz interfejs IZarzadzanieFormularzami, który z kolei implementuje interfejs standardowy IZestawyDanych umożliwiając uzyskanie zbioru formularzy. Rysunek 30: Projekt implementacji komponentu FEFORM Z formularzem związany jest zestaw akcji, które podsystem może i potrafi wykonać na dokumentach związanych z tym formularzem. Klasa FormAkcja definiuje podstawowe atrybuty akcji oraz udostępnia podstawowe metody dostępne dla wszystkich akcji. Klasa FormAkcjaParametr reprezentuje parametry akcji, umożliwia podstawowe operacje na parametrach. Dla każdego formularza można zdefiniować triggery, reprezentowane przez klasę FormTrigger. 1.1.32 FESPR: Sprawy Komponent odpowiada za obsługę spraw, wystawia na zewnątrz interfejs IZarzadzanieSprawami umożliwiający tworzenie oraz modyfikowanie spraw. 51/95

Rysunek 31: Projekt implementacji komponentu FESPR 1.1.33 FEWZOR: Wzory Komponent odpowiada za obsługę wzorów, wystawia na zewnątrz interfejs IZarzadzanieWzorami umożliwiający dodawanie, usuwanie oraz modyfikację wzorów. 1.1.34 FEPROFILE: Profile podmiotów Komponent odpowiada za pobieranie informacji o podmiotach. Wystawia na zewnątrz interfejs IZarzadzanieProfilami, umożliwiający pobranie informacji o podmiocie. Z podmiotem związana jest osoba lub instytucja. Oba typy podmiotu zawierają odniesienia do adresu oraz danych kontaktowych 1.1.35 FEPOW: Powiadomienia Komponent odpowiada za obsługę powiadomień, wystawia na zewnątrz interfejs IPowiadomienia, umożliwiający konfigurację oraz wywoływanie powiadomień o nowych dokumentach lub nowych UPD na składzie. 52/95

SkladPowiadomienia jest obiektem, którego atrybuty są właściwościami przekazywanego powiadomienia. 1.1.36 XML: Komponent pomocniczy Komponent pomocniczy do obsługi plików XML. Pośredniczy w niektórych operacjach na dokumentach, takich jak: sprawdzenie czy dokument zawiera podpis, wycinanie podpisu, wydobywanie CID, podmiana schematów. 1.1.37 Integracja z Adobe Integracja podsystemy FE z produktem Adobe LiveCycle ES umożliwia edycję dokumentu z wykorzystaniem formularzy PDF. Integracja z systemem epuap odbywa się w dwóch wariantach: ścisłej oraz luźnej. Ścisła integracja umożliwia renderowanie formularza osadzonego w przeglądarce WWW. Pozwala na wykorzystanie wszystkich dostępnych we FrontEndzie funkcji: podpis, oznaczenie czasem, archiwizacja podpisu, edycja, zapis dokumentu. W luźnej integracji formularz znajduje się na lokalnym dysku użytkownika. Możliwe jest podpisanie oraz wysłanie dokumentu na wskazaną skrytkę. Wszystkie funkcjonalności integracji realizowane są przez aplikację webową adobeservlet_war, która współpracuje z serwerowymi komponentami Adobe LiveCycle ES. Głównymi elementami aplikacji są serwety: DocumentReceiver realizujący przyjmowanie dokumentu z formularza PDF zapisanego na lokalnym dysku użytkownika, wysłanie dokumentu na wskazaną skrytkę oraz zapis dokumentu w składzie użytkownika (wykorzystywany przy luźnej integracji) oraz Edytor pozwalający na renderowanie formularza PDF (wykorzystywany przy ścisłej integracji). 1.1.37.1.1 Dostosowanie FrontEnd do obsługi wielu edytorów Podsystem FrontEnd umożliwia dodawanie różnych typów formularzy, rozróżnianie typów formularzy oraz generowania adresu edytorów odpowiedzialnych za obsługę danego typu formularzy. Lista dostępnych edytorów przechowywana jest w pliku konfiguracyjnym epuap_konfiguracja.xml w atrybucie edytory wewnątrz węzła <konfig nazwa= FE /> w postaci typ=adres oddzielonych znakiem średnika, gdzie typ określa typ formularza, a adres określa adres URL edytora. Przykład: <konfig nazwa= FE edytory="xforms=/orbeonservlet/edytor/;xdp=/adobeservlet/" /> Elementy aplikacji FrontEnd odpowiedzielne za obsługę wielu edytorów: Klasa FrontEndPortletSessionBean atrybut edytory przechowującego mapowania dostępnych edytorów do typów formularzy, lista dostępnych edytorów pobierana jest z pliku konfiguracyjnego Klasa FrontEndPortletSessionBean, metoda getedytorurl(dokumentbean dbean) realizująca mechanizm generacji wołania odpowiedniego edytora w zależności od typu formularza. Żądanie wywołania edytora składa się z adresu URL edytora oraz parametrów: 53/95

o o o ffid identyfikatora pliku zawierającego dokument formid identyfikatora pliku zawierającego formularz context kontekst bezpieczeństwa zawierający identyfikator sesji TGSID pozwalający na uwierzytelnienie użytkownika Adres URL edytora uzyskiwany jest z listy zawierającej mapowania edytorów do typów formularzy. Przykład: /orbeonservlet/edytor/?ffid=12345&formid=12346&context=12341_32hj43j3 hd72 Warstwy prezentacji ramki, której zawartość generowana jest przez wybrany edytor (DocumentView.jsp) 1.1.37.1.2 Wykorzystywane aplikacje Adobe LiveCycle ES 8.2 Adobe LiveCycle ES jest aplikacją J2EE udostępniająca usługi związane z renderowaniem dokumentów PDF (wymaga Java 5.0). Zainstalowane zostały dwa komponenty LiveCycle Forms oraz LiveCycle ReaderExtensions pozwalające na renderowanie formularzy PDF oraz dodawanie praw do dokumentu PDF, domyślnie niedostępnych w Adobe Reader. W celu skorzystania z komponentów należy odpowiednio skonfigurować serwer aplikacyjny i przygotować bazę danych dedykowaną dla wspomnianej aplikacji. TGSID_war Aplikacja portretowa prezentująca identyfikator sesji użytkownika TGSID. adobeservlet_war Aplikacja umożliwia renderowanie formularzy PDF oraz pozwala na odbieranie dokumentów wysłanych z formularza zapisanego na lokalnym dysku użytkownika. Wykorzystuje komponenty serwerowe LiveCycle ES. Poniżej przedstawiono architekturę oraz interakcję między komponentami podczas renderowania formularza PDF (ścisła integracja) 54/95

Rysunek 32 arcitektura integracji Adobe LiveCycle 1. Żądanie wyświetlenia formularza PDF. 2. FrontEnd odszukuje formularze zgodne ze wzorem dokumentu, wypisuje na przeglądarkę WWW klienta szczegóły dokumentu oraz przygotowuje żądanie do jednej z aplikacji obsługującej formularze. W przypadku, gdy formularzem zgodnym ze wzorem jest formularz PDF, żądanie będzie zawierało adres serwletu odpowiedzialnego za przygotowanie formularza PDF (będącego częścią aplikacji adobeservlet_war) oraz niezbędne parametry (identyfikator dokumentu, identyfikator formularza itp.). 3. Przeglądarka WWW wysyła przygotowane żądanie do aplikacji obsługującej formularze PDF. 4. Serwlet Edytor wykonuje zapytanie o treść dokumentu oraz formularza do bazy danych epuap. 5. Treść dokumentu i formularz są zwracane do serwletu Edytora. 6. Aplikacja przekazuje do komponentów serwerowych Adobe LiveCycle Forms oraz Adobe LiveCycle ReaderExtensions żądanie przygotowania formularza PDF. Żądanie zawiera dokument z danymi, które mają znaleźć się na formularzu (format xml), formularz do wyrenderowania (format xdp) oraz adres serwletu (będącego częścią aplikacji obsługującej formularze PDF) odpowiedzialnego za zapis dokumentu. Komponent LiveCycle ReaderExtensions dodaje do przygotowanego formularza prawa do dodawania załączników, edycji dokumentu oraz wykonywania submisji z formularza. Do wywołania usług serweroych wykorzystywane są klasy klienckie FormsServiceClient oraz ReaderExtensionsServiceClient. 7. W celu skorzystania z komponentów serwerowych LiveCycle konieczne jest uwierzytelnienie. W tym celu aplikacja LiveCycle ES wykonuje zapytanie do bazy o dane klienta. 8. Dane klienta są zwracane do aplikacji. 9. Komponent serwerowe LiveCycle przygotowują wypełniony danymi formularz PDF i przekazuje do aplikacji adobeservlet_war. 10. Aplikacja wysyła przygotowany formularz PDF do klienta, który jest renderowany za pomocą komponentu Adobe Reader na stronie epuap. 55/95

Diagram klas prezentujący główne klasy wykorzystywane przez serwet Edytora. Poniżej przedstawiono uproszczony schemat architektury oraz interakcji między komponentami podczas odbioru dokumentu wysłanego z formularza PDF znajdującego się na dysku lokalnym użytkownika (luźna integracja). Rysunek 33 Architektura i interakcje elementów integracji luźnej 1. Żądanie wyświetlenia TGSID. 2. Aplikacja TGSID_war pobiera identyfikator sesji TGSID z Cookie i wyświetla na przeglądarce. 3. Wysłanie dokumentu na serwet DocumentReceiver odpowiedzialny za odbiór dokumentów z formularza PDF. 4. Aplikacja adobeservlet_war zapisuje odebrany dokument w składzie użytkownika. 5. Aplikacja adobeservlet_war korzystając z WebSerwisu podsystemu komunikacji PK_internal_ws wysyła dokument na wskazaną w żądaniu skrytkę. 6. Wysłany dokument zapisywany jest w bazie danych w składzie odbiorcy wśród dokumentów odebranych oraz w skladzie nadawcy wśród dokumentów wysłanych. W przypadku, gdy skrytka odbiorcy wystawia UPP, jest ono wiązane z wysłanym dokumentem. 7. Podsystem komunikacji zwraca informację o powodzeniu operacji, dodatkowo może przekazać wystawione UPP. 8. Aplikacja adobeservlet_war zwraca dokument PDF informujący o powodzeniu lub niepowodzeniu operacji. 56/95

Diagram klas prezentujący główne klasy wykorzystywane przez serwet Edytora. Rysunek 34 Diagram klas serwletu edytora 1.1.38 Obsługa TSL Platforma epuap umożliwia weryfikację dokumentów zgodnych z dyrektywą 2006/123/EC Parlamentu Europejskiego. W celu realizacji dyrektywy wprowadzono następujące elementy funkcjonalne Obsługa Trust-service Status List (TSL) Obsługa podpisu w formacie CAdES I PAdES Zmiany objęły obejmuje modyfikację trzech kluczowym komponentów: Oprogramowanie standardowe DRACO i SOPEL Podsystem komunikacyjny (PK) Podsystem FrontEnd (FE) 1.1.38.1.1 DRACO i SOPEL Poniżej na schemacie przedstawiono komponenty DRACO i SOPEL podlegające modyfikacji. 57/95

WebService Sopel XAdES WebService Sopel CAdES WebService Baza Danych Lista zaufanych CA Lista TSL Legenda Serwer wewnętrzny WEB/EJB CA Manager Zarządzanie listami TSL TSL Proxy Istniejące elementy Modyfikowane elementy Nowe elementy Rysunek 35 Modyfikacje komponentów DRACO i SOPEL Ponieważ DRACO i SOPEL są produktami standardowymi nie będą szerzej opisywane. 1.1.38.1.2 Podsystem FrontEnd W celu obsługi dodatkowych formatów podpisów zmodyfikowano klasę FeTools (Fe_core.jar): zmieniono metodę issigned( byte[] xml ) na issignedxml( byte[] xml ) dodano metodę issignedfile( String filename, byte[] file ) i w zależności od nazwypliku/zawartości przekierowuję: dla xml do starej issignedxml, dla rozszerzeń charakterystycznych dla Cades i PAdes - odpowiednio do Sopla. Dla pozostałych false. c, d) metoda removesignatures - analogicznie do a i b. Zmodyfikowano portlet FrontEnd w zakresie: klasa DocumentBean - wyświetlanie przycisku weryfikuj na szczegółach dokumentu - nie tylko dla xml - ale również dla formatów CAdES i PAdES. (metoda disable() i verifable()). wyświetlenie rodzaju podpisu na stronie szczegółu dokumentu z formatverifyresult, w elemencie SignatureType 1.1.38.1.3 Podsystem komunikacyjny 58/95

Zmodyfikowano metodę przyjmij dokument w klasie SkrytkaImpl (biblioteka pk_core.jar) w celu zapewnienia weryfikacji podpisu dla dokumentów nie będących w formacie xml, jak również umożliwienie przyjmowania dokumentów xml i ich weryfikacji z zadaną schemą dla dokumentów xml podpisanych podpisem CAdES. W celu umożliwienia sprawdzania podpisów dla dokumentów nie będących w formacie xml zmodyfikowano portlet (PKPortlet) przez przeniesienie checkboxów Przyjmowanie tylko podpisanych dokumentów oraz Wymaganie bezpiecznego podpisu (z certyfikatem kwalifikowanym) powyżej Czy skrytka akceptuje tylko dokumenty XML w konfiguracja_zaawansowana.jsp. 59/95

1.1.17 Koordynator Podsystem Koordynator jest niezależnym podsystemem, wyodrębnionym poza głównym serwerem aplikacyjnym WebSphere, który realizuje funkcje serwera procesów biznesowych BPEL. Usługa Koordynatora procesów ma za zadanie przechowywać informacje o procesach biznesowych, zarządzać ich stanem i dostarczać interoperacyjność z usługami platformy epuap. Koordynator składa się zasadniczo z następujących komponentów: Lp Nazwa Realizowane funkcje 1. Agent Instalowanie i deinstalowanie nowych procesów biznesowych wraz z mechanizmem wersjonowania na serwerze ODE Przyjmowanie nowych zadań i uruchamianie procesów Dołączanie dokumentów i korelowanie ich z instancjami procesów Gromadzenie dokumentów związanych ze sprawą Pośredniczenie w interakcjach z serwerem ODE Dostarczanie pomostu w interacji z usługami epuap i realizacja usług elementarnych Nasłuch na zdarzenia przychodzące poprzez silnik kolejek JMS 2. Silnik Apache ODE + wtyczka Startowanie i zarządzanie instancjami procesów Przechowywanie i persystencja stanu definicji procesu biznesowego Przechowywanie i persystencja stanu instancji procesu biznesowego Przechwytywanie zdarzeń w systemie ODE i przesyłanie ich do silnika kolejek 3. Silnik kolejek JMS ActiveMQ Obsługa wiadomości o instancjach pomiędzy Apache ODE a SBA Obsługa informacji o stanie procesu pomiędzy Apache ODE a Agentem Persystencja i skalowanie kolejki zadań Agenta ( zadania tworzenia nowych instancji procesów biznesowych oraz dołączania dokumentów) 4. GUI Interakcja z użytkownikiem i udostępnianie funkcjonalności dodawania, usuwania i monitorowania procesów biznesowych 60/95

Start procesu doła Start procesu doła Agent JMS Apache ODE Zdarzenia procesu Zdarzenia procesu Koordynator definiuje zestaw usług które można podzielić na serwisy zewnętrzne i wewnętrzne, przy czym podział dotyczy ściśle Koordynatora. Agent epuap Serwisy zewnętrzne Serwisy wewnętrzne Apache ODE agenta agenta Serwisy wewnętrzne inaczej zwane usługami elementarnymi są usługami WS które reprezentują różne funkcjonalności epuap, są wystawione dla procesów biznesowych wewnątrz ODE i umożliwiają korzystanie z serwisów epuap. Poniżej przedstawiono diagram klas dla serwisów/usług wewnętrznych: 61/95

Lp. Nazwa funkcjonalności Realizowane zadania 1 Usługa przesyłania dokumentów Funkcja: Przedłożenie dokumentu (tryb UPP) Funkcja: Dostarczenie dokumentu (tryb UPD) Funkcja: Odbieranie dokumentów pod określonym adresem 2 Usługa transformacji i weryfikacji dokumentów Opis: Oczekiwanie na dokument przesłany do procesu i odebranie dokumentu, automatyczne przesyłanie dokumentu XML na zadaną skrytkę z procesu koordynacyjnego Funkcja: Transformowanie dokumentu Funkcja: Weryfikacja dokumentu Opis: Transformacja wskazanego dokumentu przy pomocy określonej transformaty XSLT dostarczonej razem z definicją 62/95

procesu koordynacyjnego, do dokumentu innego formatu 3 Usługa słownikowa Funkcja: Pobranie wartości na podstawie zadanego klucza Funkcja: Pobranie listy wartości wg określonej listy atrybutów Opis: Zapytanie do określonego słownika, o występowanie i wartość zadanego klucza 4 Usługa logowania zdarzeń Funkcja: Logowanie zdarzenia do rejestru zdarzeń Funkcja: Logowanie stanu biznesowego instancji Opis: Informowanie podsystemu logującego o wszelkich zdarzeniach zaistniałych wewnątrz procesu 5 Usługa weryfikacji opłat Funkcja: Weryfikacja poprawności dokonania opłaty Opis: Przyjęcie informacji o opłacie w standardowej formie i weryfikacja w postaci funkcji logicznej true/false czy płatność jest poprawna 6 Usługa Bezpieczeństwa Funkcja: podpisywanie dokumentu certyfikatem niekwalifikowanym epuap Opis: Podpisanie dokumentu przy użyciu certyfikatu systemu epuap 7 Usługa instalacji aplikacji Funkcja: Instalacja aplikacji w Środowisku Budowy Aplikacji Opis: Instalowanie nowej lub aktualizacja istniejącej aplikacji w Środowisku Budowy Aplikacji. Serwisy zewnętrzne zapewniają sterowanie koordynatorem i dają dostęp do serwera Apache ODE 63/95

Jak widać na załączonym rysunku, usługi zewnętrzne w rozumieniu koordynatora zapewniają dostęp do zarządzania paczką procesu, są odpowiedzialne za operacje na instancjach procesów decydują o przymowaniu dokumentów startowych lub dodatkowych w procesie zgodnie ze specyfikacją odbiorcy dokumentu epuap. Lp. Nazwa funkcjonalności Realizowane zadania 1 Usługa informowania o stanie procesu (PkOdbiorcaInternalServiceSkeleton) Funkcja: Generowanie informacji o stanie procesu na żądanie użytkownika 2 Usługa komunikacji z instancją procesu (PkOdbiorcaInternalServiceSkeleton) 3 Usługa instalowania definicji procesów (KoPackageManagementService) 4 Usługa wymiany danych i instancji (KoInstanceManagementService) Funkcja: Przesłanie dokumentu do procesu (w określonych przypadkach również inicjalizowanie procesu) Funkcja: instalacja nowej definicji procesu Funkcja: deinstalacja definicji procesu Funkcja: instalacja nowej wersji istniejącej już definicji procesu Funkcja: przesłanie listy definicji procesów należących do użytkownika Funkcja: przesłanie listy instancji procesów w ramach definicji procesu Funkcja: przesłanie listy dokumentów wewnątrz zadanej instancji procesów 64/95

Funkcja: pobranie dokumentu z procesu Funkcja: dołączenie dokumentu do procesu procesu Specyfikacja serwisów zewnętrznych i wewnętrznych jest bardzo podobna, oba typy klas reprezentują serwis abstrakcyjny i zapewniają dostęp zarówno do obiektów Proxy (pośredniczących z innymi elementami epuap przy wykorzystaniu technologii Web services) jak również obiektów DAO, pozwalających na dostęp do bazy danych przy pomocy technologi Hibernate. Konfiguracja całego komponentu Agenta, serwisu ActiveMQ oraz wtyczki do Apache ODE jest zagwarantowana poprzez technologię Spring Framework. Dzięki temu podejściu struktura całej aplikacji jest spójna, poprzez wykorzystanie wspólnego i ogólno dostępnego kontenera obiektów ( 65/95

ApplicationContext ). Dodatkowo, cała konfiguracja jest dostępna poprzez instrumentalizację obiektów, co pozwala na modyfikację wszystkich parametrów wszystkich usług, oraz prostą modyfikację referencji między obiektami i kaskadowe dołączanie nowych komponentów ( np. podmiana bazodanowego connection pool a, czy też klienta JMS bez potrzeby rekompilacji aplikacji ). Konfiguracja bazy danych przy uzyciu Spring: <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd"> <beans> <bean id="dsdatasource" class="org.apache.commons.dbcp.basicdatasource" destroy-method="close"> <property name="driverclassname" value="com.ibm.db2.jcc.db2driver"/> <property name="url" value="jdbc:db2://epuapdb:50001/epuap"/> <property name="username" value=""/> <property name="password" value=""/> <property name="defaultautocommit" value="false"/> <property name="maxidle" value="60000"/> </bean> <bean id="dssessionfactory" class="org.springframework.orm.hibernate3.localsessionfactorybean"> <property name="datasource" ref="dsdatasource"/> <property name="mappingresources"> <list> Przykład konfiguracji JMS: <value>/gov/epuap/ko/beans/processdefinition.hbm.xml</value> <value>/gov/epuap/ko/beans/processinstance.hbm.xml</value> <value>/gov/epuap/ko/beans/processresource.hbm.xml</value> <value>/gov/epuap/ko/beans/processpackage.hbm.xml</value> <value>/gov/epuap/ko/beans/processdocument.hbm.xml</value> 66/95 <value>/gov/epuap/ko/beans/processboxmq.hbm.xml</value>

1.1.18 Podsystem płatności Podsystem umożliwia realizację płatności za usługi świadczone przez instytucje publiczne. Budowa podsystemu została zaprezentowana na diagramie poniżej. 67/95