Założenia funkcjonalne i techniczne Syriusz Broker

Transkrypt

1 Umowa na opracowanie opisu wymagań funkcjonalnych i technicznych dla SYRIUSZ_BROKER Produkt: Założenia funkcjonalne i techniczne Syriusz Broker 27 kwietnia 2010 wersja 1.1 Umowa zawarta w ramach projektu współfinansowanego ze środków EFS prowadzonego w ramach Programu Operacyjnego Kapitał Ludzki Implementacja i rozwój systemu informacyjnego publicznych służb zatrudnienia

2 2 Spis treści SPIS TREŚCI... 2 SŁOWNIK... 4 I WSTĘP... 7 II STRUKTURA SYSTEMU SYRIUSZ BROKER... 8 III WĘZŁY SYSTEMU SYRIUSZ BROKER Węzeł SB Podstawowe procesy biznesowe w systemie SB Węzeł SBPx SBPx API Komunikacja w SSB Bezpieczeństwo Fragmentacja Nagłówek Identyfikator węzła Potwierdzenia IV KOMPONENTY SSB FUNKCJONALNOŚCI KOMPONENTU CBUIW Baza węzłów Baza użytkowników Kalendarz transmisji Realizowane usługi Interfejs użytkownika Funkcjonalności Bazy Węzłów Funkcjonalności Bazy Użytkowników Funkcjonalności kalendarza transmisji: Podsumowanie MENADŻER SŁOWNIKÓW (MS) MODUŁ ADMINISTRACYJNO DIAGNOSTYCZNY Procjon APLIKACJA CENTRALNA KOMPONENTY SSB PODSUMOWANIE V OPERACJE UTRZYMANIOWE PODŁĄCZENIE NOWEGO WĘZŁA MODYFIKACJA PROCESÓW BIZNESOWYCH ZMIANY W SŁOWNIKACH Umowa zawarta w ramach projektu współfinansowanego ze środków EFS prowadzonego w ramach Programu Operacyjnego Kapitał Ludzki Implementacja i rozwój systemu informacyjnego publicznych służb zatrudnienia

3 3 VI ZALECANA TECHNOLOGIA VII ZALECANIA DO WDROŻENIA ETAPY WDROŻENIA Etap I wdrożenie pilotażowe PWD Bridge Etap II wdrożenie we wszystkich PUP REDUNDANCJA KOMPONENTÓW ŚRODOWISKO TESTOWE VIII PODSUMOWANIE... 35

4 4 Słownik Aplikacje docelowe (klienckie) - aplikacje wchodzące w skład SI PSZ, będące jednocześnie aplikacjami wysyłającymi i odbierającymi komunikaty PWD. Aplikacje te będą wymieniały informacje za pomocą Systemu Syriusz Broker (SSB), podłączone za pośrednictwem węzła SBPx; Aplikacje dziedzinowe - aplikacje wchodzące w skład SI PSZ, użytkowane bezpośrednio w instytucjach obszaru PSZ w celu realizacji funkcji statutowych w/w instytucji, przykładem tych aplikacji jest Oprogramowanie aplikacyjne Syriusz Std ( Syriusz Std ) oraz aplikacja WUP-Viator; ARP (ang. Address Resolution Protocol) - protokół sieciowy służący do pozyskiwania informacji mówiącej o tym, którego interfejsu sieciowego należy użyć w celu skontaktowania się z maszyną o konkretnym identyfikatorze; pozyskane informacje są przechowywane w tablicy ARP, tak aby przy kolejnej próbie kontaktu nie było wymagane ponowne uruchamianie procedury pozyskiwania informacji; EDA (ang. Event Driven Architecture) - koncepcja tworzenia systemów informatycznych oparta o zdarzenia; zdarzeniem może być podjęcie akcji przez użytkownika, zmiana stanu lub dowolna inna przyczyna; zdarzenie jest raportowane w systemie, a jego wystąpienie może powodować wywołanie odpowiednich akcji architektura EDA może uzupełniać architekturę SOA ponieważ wystąpienie zdarzenia może powodować wywołanie usługi; ESB (ang. Enterprise Service Bus) - technologia ESB bazuje na szynie zapewniającej warstwę odpowiedzialną za obsługę zdarzeń; podejście to bazuje na podpinaniu do szyny elementów reagujących na zdarzenia (ang. Event Consumers) i wpuszczaniu na tą szynę zdarzeń; w momencie pojawienia się zdarzenia odpowiednie elementy wyczulone na tego rodzaju zdarzenia podejmują działanie. Szyna ESB jest realizacją architektury EDA; Komunikacja asynchroniczna oznacza komunikację, dla której nadawca po nadaniu komunikatu kontynuuje proces bez jego przerywania i oczekiwania na odpowiedź; Komunikacja synchroniczna oznacza komunikację, dla której nadawca komunikatu wstrzymuje swój proces do momentu otrzymania odpowiedzi na nadany komunikat; inaczej zwana komunikacją on-line; Komunikat ACK potwierdzenie odebrania komunikatu; Load balancing - mechanizm mający na celu równoważenie obciążenia pomiędzy dwoma lub więcej aplikacjami tego samego typu; Ministerstwo Pracy i Polityki Społecznej (dalej: MPiPS) - urząd obsługujący m.in. ministra właściwego do spraw pracy.

5 5 Obszar Publicznych Służb Zatrudnienia (dalej: obszar PSZ) - obszar tworzą organy zatrudnienia, m.in.: powiatowe i wojewódzkie urzędy pracy, urząd obsługujący ministra właściwego do spraw pracy oraz urzędy wojewódzkie, realizujące zadania określone ustawą z dnia 20 kwietnia 2004 r. o promocji zatrudnienia i instytucjach rynku pracy (art. 6, ust. 2); funkcjonowanie obszaru PSZ wspiera SI PSZ; Obszar zabezpieczenia społecznego (dalej: obszar ZS) obszar tworzą instytucje, których zadania skupiają się na pomocy osobom w trudnej sytuacji materialnej i społecznej; zakres funkcjonowania tego obszaru określają następujące ustawy: o ustawa z 12 marca 2004 r. o pomocy społecznej (Dz. U z 2 lipca 2008 r. Nr 115 poz. 728 z późniejszymi zmianami), o ustawa z dnia 28 listopada 2003 r. o świadczeniach rodzinnych (Dz. U. Nr 228, poz z późniejszymi zmianami), o ustawa z dnia 7 września 2007 r. o pomocy osobom uprawnionym do alimentów (Dz. U. Nr 192, poz z późniejszymi zmianami); OPS - Ośrodek Pomocy Społecznej; pl.id projekt realizowany przez Ministerstwo Spraw Wewnętrznych i Administracji, którego celem jest wdrożenie elektronicznego dowodu tożsamości; PSZ publiczne służby zatrudnienia; RMI - (ang. Remote Method Invocation - zdalne wywołanie metod) jest mechanizmem umożliwiający zdalne wywołanie metod w środowisku wirtualnej maszyny Java; SOA (ang. Service-Oriented Architecture) - koncepcja tworzenia systemów informatycznych, w której główny nacisk stawia się na definiowanie usług, które spełnią wymagania użytkownika; mianem usługi określa się tu każdy element oprogramowania, mogący działać niezależnie od innych oraz posiadający zdefiniowany interfejs, za pomocą którego udostępnia realizowane funkcje; SSO (ang. Single sign-on) - mechanizm uwierzytelniający użytkownika w wielu systemach jednocześnie; użytkownik uwierzytelnia się w jednym systemie połączonym z SSO, następnie przełączając się do innego systemu (który również musi być podłączony do SSO) nie jest już pytany o hasło; drugi system automatycznie uwierzytelnia użytkownika bazując na danych uwierzytelniających wprowadzonych do systemu pierwszego; System Syriusz Broker (dalej: SSB) - jest to system definiujący warstwę integracyjną w obszarze PSZ. Integracja zachodzi na dwóch płaszczyznach, tj. komunikacyjnej (wyznaczonej przez sieć węzłów SB i SBPx), i biznesowej, definiującej środowisko do tworzenie i wykonywania procesów biznesowych; Systemy Centralne aplikacje obszaru PSZ, dla których infrastruktura aplikacyjno-sprzętowa nie jest instalowana ani w powiatowym ani wojewódzkim urzędem pracy. Są to wszystkie te aplikacje, które istnieją tylko jako jedna

6 6 instancja w całym obszarze praca. Przykładami takich aplikacji są: Aplikacja Centralna (dalej: AC), Krajowy System Monitoringu Rynku Pracy (dalej: KSMRP), Centralna Baza Ofert Pracy (dalej: CBOP), Rejestr Instytucji Szkoleniowych (dalej: RIS), Administracja SI SYRIUSZ, Krajowy Rejestr Agencji Zatrudnienia (dalej: KRAZ); System informacyjny publicznych służb zatrudnienia (dalej: SI PSZ) tworzą systemy informatyczne, oprogramowanie aplikacyjne oraz rejestry wspomagające funkcjonowanie obszaru PSZ; SI PSZ składa się z aplikacji dziedzinowych i systemów centralnych; inne kryterium kwalifikacji aplikacji SI PSZ bazuje na wymianie i przetwarzaniu informacji na tej podstawie wyróżnia się aplikacje zasilające i zasilane; Web Service usługa sieciowa realizująca ściśle określone funkcje; definicja takiego serwisu jest dokonywana przez specjalny język opisu usług (WSDL Web Service Definition Language); Web Service umożliwia zdalne wywoływanie realizowanych przez siebie funkcjonalności; XML z angielskiego Extensible Markup Language, jest to rozszerzalny, niezależny od platformy język przeznaczony do reprezentowania danych.

7 7 I Wstęp Dokument ten powstał w rezultacie przeprowadzonych analiz obecnie wykorzystywanych narzędzi, obszaru, wymagań użytkowników istniejących systemów, analizy technicznej oraz ekonomicznej. Stanowi on zestaw wymagań funkcjonalnych i technicznych, niezbędnych do realizacji preferowanego rozwiązania systemu Syriusz Broker w modelu architektury ze scentralizowanymi procesami biznesowymi.

8 8 II Struktura Systemu Syriusz Broker Syriusz Broker będzie platformą integrującą aplikacje w obszarze PSZ. W przeciwieństwie do swego poprzednika PWD, oprócz mechanizmów komunikacyjnych Syriusz Broker dostarczy mechanizmy umożliwiające także integrację na poziomie biznesowym. W swym docelowym modelu będzie, dzięki usługom dostarczanym przez aplikacje klienckie, definiował, wykonywał i zarządzał procesami biznesowymi obszaru PSZ. Przyjęty model zakłada centralną obsługę procesów biznesowych, tzn. ich środowisko wykonawcze będzie stanowiło jedną z podstawowych funkcjonalności Syriusz Brokera. Zakłada się, że System Syriusz Broker zastąpi PWD i będzie funkcjonalnie co najmniej równoważny tej platformie. Podstawowymi elementami składającymi się na system Syriusz Broker są: Syriusz Broker (SB) węzeł mający za zadanie przesyłanie komunikatów pochodzących od węzłów SBPx do innych węzłów SBPx oraz SB. SB z punktu widzenia komunikacyjnego stanowić będzie router nawigujący komunikaty między podłączonymi systemami. W systemie może występować jeden lub więcej połączonych ze sobą węzłów SB. W tej sytuacji poszczególne SB będą również odpowiedzialne za znajdowanie drogi dla komunikatów z systemów podłączonych do różnych węzłów SB. Ponadto węzły SB zawierać będą definicje procesów biznesowych występujących w systemie oraz środowisko umożliwiające ich wykonywanie. Syriusz Broker Proxy (SBPx) węzeł pośredniczący w komunikacji pomiędzy aplikacją docelową, a węzłem SB. Głównym zadaniem Syriusz Broker Proxy będzie zapewnienie komunikacji z jednym z węzłów SB, poprzez przekazywanie komunikatów z i do tego węzła. SBPx Adapter adapter stanowi część SBPx, budowaną na bazie dobrze udokumentowanego API. Jest on tworzony, jako łącznik z aplikacją kliencką. W zależności od potrzeb istnieje możliwość stworzenia różnych adapterów do różnych systemów docelowych. Dodatkowo funkcjonowanie tych części wspomagać powinny następujące komponenty: Centralna Baza Użytkowników i Węzłów (CBUiW) podstawowym zadaniem aplikacji jest przechowywanie informacji uwierzytelniających oraz uprawnień zarówno użytkowników jak i węzłów (jako węzeł rozumie się wszystkie te elementy, które nawiązują połączenie z Syriuszem Brokerem). Menadżer Słowników (MS) w obszarze PSZ występować będzie grupa słowników, w dużej mierze definiowanych w sposób ustawowy, które są wspólne dla wszystkich aplikacji. Zadaniem MS jest umożliwienie definiowania nowych, modyfikacji istniejących słowników, a także propagowania zmian i nadzór wersji w obszarze działania Syriusz Brokera

9 9 oraz przechowywanie historii zmian. W ten sposób aplikacja ta ułatwi zarządzanie oraz synchronizację słowników. Moduł Administracyjno Diagnostyczny (MAD) narzędzie umożliwiające administratorom systemu nadzorowanie ruchu i diagnostykę problemów, jakie mogą wystąpić w komunikacji między aplikacjami klienckimi. Opisaną powyżej strukturę systemu prezentuje poniższy rysunek. Rysunek 1 Struktura systemu Syriusz Broker W kolejnych rozdziałach przedstawione zostaną funkcjonalności zaprezentowanych składowych i komponentów Systemu Syriusz Broker.

10 10 III Węzły Systemu Syriusz Broker Jak zostało przedstawione na rysunku nr. 1, szkielet komunikacji w systemie Syriusz Broker stanowić będą węzły SB i SBPx. SB pełnić mają funkcję routerów ruchu, odbywającego się w systemie, a SBPx pośredników między aplikacjami klienckimi a Brokerem, stanowiąc interfejs umożliwiający podłączenie do systemu. Ponadto, zgodnie z przyjętym modelem centralnych procesów biznesowych, węzły SB powinny zawierać definicje procesów biznesowych w systemie oraz środowisko umożliwiające ich wywołanie i działanie. Z kolei aplikacje dołączane za pośrednictwem SBPx definiować będą usługi na potrzeby tych procesów. Komunikacja między składowymi systemu odbywać się powinna za pośrednictwem komunikatów. Ich struktura została przedstawiona w rozdziale II Struktura Systemu Syriusz Broker. W związku z powyższym, węzły SB i SBPx muszą: 1. Zapewnić komunikację synchroniczną i asynchroniczną pomiędzy dwoma dowolnymi aplikacjami docelowymi. Rodzaj komunikacji byłby wybierany przy przekazywaniu danych do wysłania w API zdefiniowanym w SBPx. 2. Zapewnić zachowanie komunikatu nawet w przypadku awarii węzła. Każdy węzeł odpowiadać będzie za dostarczenie komunikatu do momentu przekazania go do innego węzła (zagadnienie szerzej opisane w rozdziale III1.3.5 Potwierdzenia). Komunikaty czekające na przekazanie muszą być przetrzymywane w taki sposób, aby awaria węzła nie powodowała ich utraty. 3. Umożliwić transmisję dużego komunikatu. W trakcie przesyłu nie może wystąpić zjawisko blokady połączenia, konsekwencją którego będzie uniemożliwienie przesłania komunikatów o wyższym priorytecie. Zalecenie techniczne: Zaleca się, aby węzły posiadały funkcjonalność fragmentowania dużych komunikatów (zagadnienie szerzej opisane w rozdziale III1.3.2 Fragmentacja). 4. Umożliwić kompresowanie bloku danych w zależności od ustawień konfiguracyjnych. Zalecenie techniczne: Należy stworzyć filtr (patrz: pkt. 9), który będzie dokonywał kompresji na wyjściu węzła. Kompresja bloku danych powinna skutkować umieszczeniem odpowiedniej informacji w nagłówku komunikatu. 5. Zabezpieczyć transmisję pomiędzy węzłami w taki sposób, aby uniemożliwić osobom trzecim przechwycenie transmitowanych danych. Przy czym, włączanie i wyłączanie zabezpieczenia powinno być parametrem konfiguracyjnym SBPx. Zalecenie techniczne: Zaleca się stworzenie filtru (patrz: pkt. 9) dokonującego szyfrowania bloku danych.

11 11 6. Zapewnić możliwość informowania administratora za pośrednictwem ostrzeżeń o wszelkich sytuacjach awaryjnych. Komunikat ostrzeżenia powinien zostać dostarczony do aplikacji MAD (szczegółowo omówionej w rozdziale IV3 Moduł Administracyjno Diagnostyczny). Administrator powinien być informowany o: awarii węzła; przełączeniu się węzła SBPx między węzłami SB; braku możliwości dostarczenia komunikatu do adresata (sytuacja może wystąpić, gdy SB nie będzie w stanie zlokalizować węzła z adresatem). 7. Komunikat z ostrzeżeniem musi zawierać następujące informacje: data wygenerowania ostrzeżenia; rodzaj węzła (SB czy SBPx); identyfikator węzła; typ aplikacji stojąca za węzłem, jeśli jest ta informacja dostępna w CBUiW; opis problemu, np.: o o brak węzła - opis będzie generowany przez SB, w sytuacji gdy niemożliwe będzie zlokalizowanie adresata komunikatu. W komunikacie zapisywana powinna być informacja o ilości podjętych prób wysłania lub czasie, jaki upłynął od pierwszej próby lokalizacji węzła; zerwanie połączenia z SB - opis będzie generowany przez SBPx w chwili nastąpienia przełączenia między węzłami SB. W komunikacie podana powinna być informacja o identyfikatorach węzłów SB: tym, z którym wystąpił błąd w łączności i nowym, do którego nastąpiło przełączenie. 8. Zapewniać priorytetową obsługę komunikatów, ma to szczególne znaczenie dla komunikacji synchronicznej. 9. Umożliwić dokonywanie różnych operacji na komunikatach wejściowych i wyjściowych. Zalecenia techniczne: Filtry to zestaw niewielkich kawałków kodu podejmujących drobne działania na pakietach wchodzących i wychodzących. W skład tych działań może wchodzić: kompresja bloku danych komunikatu, szyfrowanie bloku danych komunikatu, odrzucanie komunikatów od nieautoryzowanych węzłów, tworzenie statystyk ruchu. Każdy z filtrów powinien realizować tylko jedną funkcję co umożliwi ich niezależne włączanie i wyłączanie. Zaleca się umieszczenie mechanizmu filtrującego na wejściu i wyjściu komponentów SB i SBPx.

12 Udostępniać aplikacjom klienckim (procesom biznesowym w przypadku węzłów SB) API do pobierania słowników centralnych z Menadżera Słowników (o komponencie tym więcej w rozdziale IV2 Menadżer słowników (MS)). W związku z tym powinien zostać stworzony mechanizm cache-owania danych słownikowych w węzłach, aby przyśpieszyć te operacje. 11. Obsługiwać systemowe komunikaty o zmianach w słownikach i odpowiednio aktualizować swój cache. 12. Udostępniać usługi na potrzeby Modułu Administracyjno Diagnostycznego (więcej o komponencie w rozdziale IV3 Moduł Administracyjno Diagnostyczny), które pozwolą administratorowi na: pobranie informacji o cache-owanych słownikach; dodanie i usunięcie słownika z listy subskrybowanych; wymuszenie pobrania i wykorzystywania konkretnej wersji słownika; przegląd i modyfikację kolejek wejściowych i wyjściowych (w tym nakaz retransmisji komunikatu); zmianę parametrów konfiguracyjnych (w taki sposób, aby po ponownym uruchomieniu zmiany nie były utracone).

13 Węzeł SB Węzeł SB, poza wymienionymi w rozdziale powyżej, powinien dodatkowo spełnić następujące wymagania: 1. Zapewnienie alternatywnej metody uwierzytelniania komponentu CBUiW. Jest to spowodowane tym, że dane uwierzytelniające znajdują się w CBUiW i węzeł SB potrzebuje alternatywnego sposobu uwierzytelnienia tego komponentu, gdy jest on dołączany do systemu. Zalecenie techniczne: Wskazanym jest, aby oprócz danych uwierzytelniających ten komponent, użyć dodatkowo metody ograniczenia puli adresu IP, z których może podłączyć się CBUiW. 2. Zapewnienie alternatywnej metody uwierzytelniania dla aplikacji MAD, aktywnej tylko wtedy, gdy komponent CBUiW jest niedostępny w systemie. Metoda alternatywnego uwierzytelniania musi zapewniać taki stopień zabezpieczeń, aby uniemożliwić podszycie się pod węzeł SBPx obsługujący aplikacje MAD. Zalecenie techniczne: Zaleca się ograniczenie puli adresów IP, z których można uzyskać połączenie uwierzytelnione metodą alternatywną do CBUiW. 3. Zapewnienie kontroli nad ważnością komunikatów. Węzeł powinien odrzucać komunikaty, których data ważności minęła. Zalecenie techniczne: Aby zapewnić powyższe wymaganie węzły systemu Syriusz Broker muszą dzielić ten sam znacznik czasowy, aby walidacja ważności komunikatów odbywała się poprawnie. Stąd należy zapewnić synchronizację zegarów dla węzłów dołączających do systemu. 4. Udostępnienie mechanizmu dostarczenia komunikatów najkrótszą drogą. Węzeł Syriusz Broker odpowiedzialny jest za przekazanie komunikatu od węzła SBPx "A" do węzła SBPx "B". W tym celu węzeł SB musi posiadać informacje na temat ścieżki dotarcia do docelowego węzła, czyli SBPx-a "B". Przy czym jako ścieżkę dotarcia rozumie się wyznaczoną najkrótszą (pod względem ilości pokonywanych przez komunikat węzłów SB) najszybszą drogę od SB do SBPx-a "B". Zalecenie techniczne: Jedną z propozycji rozwiązania tego problemu jest wprowadzenie mechanizmu odnajdowania celu, opartego o zasadę podobną do stosowanej w ARP (Address Resolution Protocol). Mechanizm ten będzie wykorzystany w ramach węzłów SB. Sposób jego funkcjonowania omawianego mechanizmu ilustruje poniższy przykład: W sytuacji, gdy węzeł SB otrzyma polecenie dostarczenia komunikatu do węzła SBPx "B", musi uzyskać informację, do którego z węzłów jest podpięty poszukiwany SBPx "B". Jeśli węzeł ten jest bezpośrednio powiązany z danym węzłem SB, to sytuacja jest prosta i nie wymaga wyjaśniania. Jednak w momencie, gdy SBPx nie jest podpięty do danego węzła SB, konieczne jest uzyskanie informacji, do którego z węzłów jest podpięty dany

14 14 SBPx. W tym celu węzeł SB musi dowiedzieć się, czy jakiś inny węzeł SB nie posiada aktywnego połączenia z SBPx "B". Aby to zadanie zrealizować, SB rozsyła do innych węzłów SB komunikat "ARP" z zapytaniem, kto zna SBPx "B". W następnej kolejności każdy z węzłów SB powinien udzielić odpowiedź, niezależnie od tego czy jest ona pozytywna, czy negatywna. Jeśli wszystkie węzły SB odpowiedzą, że nie mają połączenia z SBPx "B", oznacza to, że system SPBx "B" jest aktualnie niedostępny. W przypadku, gdy nadejdzie odpowiedź od węzła, który posiada połączenie z SBPx-em B to, węzeł SB poszukujący połączenia, zapisuje tą informacje i od tej pory będzie kierował komunikaty przeznaczone dla SBPx-a B do tego SB, które udzieliło odpowiedzi. Informacja ta powinna następnie być zapisana na węźle SB (tablica ARP), tak aby nie zaszła po raz kolejny potrzeba odpytywania ARP przy następnej wysyłce danych do SBPx "B". Przy ponownym przesyle pakietu do SBPx, węzeł SB będzie mógł skorzystać z lokalnie zgromadzonej informacji i od razu skierować komunikat do odpowiedniego węzła SB. W przypadku, gdy ten sam komunikat trafia do drugiego węzła SB, a ten nie jest już w stanie zapewnić komunikacji z poszukiwanym SBPx, węzeł SB powinien odpowiedzieć odpowiednim komunikatem. Takie działanie natomiast po stronie pierwszego SB powinno skutkować usunięciem tej pozycji z tablicy ARP. 5. Zapewnienie mechanizmu wczytywania i wykonywania procesów biznesowych. Mechanizm ten musi zapewniać: a. Obsługę komunikatów zdefiniowanych na potrzeby komunikacji w systemie Syriusz Broker; b. Możliwość wstawienia kodu w meta języku w celu umożliwienia zdefiniowania przekształceń dla danych otrzymywanych w komunikatach; c. Możliwość wczytywania procesów zdefiniowanych w edytorze procesów (patrz punkt następny); d. Możliwie jak najmniej skomplikowany sposób zmiany definicji procesów biznesowych; e. Zalecane jest, aby istniała możliwość podmiany definicji procesów biznesowych na dowolnym węźle SB za pośrednictwem aplikacji MAD (więcej o aplikacji w rozdziale III1.1.1 Podstawowe procesy biznesowe w systemie SB). 6. Udostępnienie zewnętrznego edytora do modelowania i definiowania procesów biznesowych. Edytor powinien pozwolić na: a. graficzną reprezentację procesów biznesowych; b. modyfikację procesów biznesowych; c. eksportowanie zdefiniowanych procesów do formatu, który będzie mógł być wczytany przez silnik zdefiniowany w węzłach SB.

15 15 7. Udostępnienie mechanizmu, dzięki któremu węzeł SB będzie odrzucać komunikaty nadchodzące od nieuwierzytelnionych węzłów. Jednocześnie SB musi zapewniać możliwość uwierzytelniania dowolnego węzła SB czy SBPx, jako zbiór danych uwierzytelniających przyjmując CBUiW. Wymaganym jest, aby węzły SB zapamiętywały uprawnienia (dotyczące dozwolonych transmisji) podłączonych do nich klientów SBPx, tak aby każda transmisja z węzła SBPx nie powodowała wysyłania zapytania o uprawnienia do CBUiW. W przypadku zmiany uprawnień węzła, CBUiW odpowiedzialne będzie za wysłani odpowiedniego komunikatu, pozwalającego na aktualizację zapamiętanych uprawnień. 8. Udostępnienie mechanizmu zmiana adresu IP. Uwierzytelniane węzły (szczególnie te, które działają w małych PUP lub OPS) wykorzystują usługi dostawców Internetu, którzy nie zapewniają stałego adresu IP. Stąd mechanizm uwierzytelniania musi uwzględniać możliwości zmiany adresów IP węzłów. 9. Udostępnienie mechanizmu cache-owania danych z CBUiW. Węzeł SB wykorzystuje te dane do uwierzytelniania węzłów w SSB oraz do kontrolowania zgodności przesyłu danych z kalendarzem zasileń. Aby operacje te były wykonywane jak najszybciej zalecane jest wprowadzenie cacheowania tych danych Podstawowe procesy biznesowe w systemie SB W celu zapewnienia podstawowej funkcjonalności Systemu Syriusz Broker należy zdefiniować minimalny zestaw procesów biznesowych, które zostaną w nim zaimplementowane. W skład tej grupy powinny wejść: 1. Proces biznesowy odpowiedzialny za przesyłanie zmian wykonanych za pośrednictwem aplikacji ASI Syriusz do Menadżera Słowników. 2. Proces biznesowy rozsyłający notyfikację o nowym lub zaktualizowanym słowniku. 3. Proces biznesowy zapewniający dostarczenie do aplikacji MAD komunikatów z ostrzeżeniami systemowymi. 4. W fazie przejściowej (czyli w momencie istnienia zarówno SSB jak i PWD) należy zdefiniować proces biznesowy, który dla wszystkich nieznanych odbiorców prześle komunikat do "PWD Bridge" (więcej w rozdziale VII1.1.1 PWD Bridge). 5. Proces biznesowy informujący wszystkie węzły o pojawieniu się w systemie aplikacji MAD. Pozwoli to tym węzłom na przesłanie zaległych ostrzeżeń administracyjnych. 6. Domyślny proces odpowiedzialny za dostarczenie komunikatów z ustalonym adresatem, tzn. takich, które zostały zaadresowane do konkretnego systemu docelowego.

16 Węzeł SBPx Do listy wspólnych wymagań dla węzłów SB i SBPx przedstawionych na początku tego rozdziału należy dodać jeszcze następujące specyficzne wymagania dla węzła SBPx: 1. Niezależność od systemu operacyjnego. 2. Bardzo dokładna specyfikacja umożliwiająca implementację węzła SBPx w dowolnym języku programowania. Zapewni to możliwość dołączania SBPx, jako modułu do aplikacji klienckich napisanych w różnych językach. 3. Odrzucanie komunikatów będących duplikatami. Zalecenie techniczne: Duplikat powinien być rozpoznawany po unikalnym identyfikatorze komunikatu. 4. W przypadku awarii połączenia z węzłem SB, węzeł SBPx musi podejmować próby połączenia się z innymi węzłami SB obecnymi w SSB. Przy czym, administrator musi posiadać możliwość zawężenia puli węzłów SB, do których może się podłączyć konkretny węzeł SBPx. Jeśli próba przełączenia na inny węzeł SB zakończy się sukcesem, węzeł SBPx musi wysłać alert do aplikacji MAD informujący o tym zdarzeniu. 5. Węzeł SBPx powinien przechowywać komunikaty wygenerowane przez podłączoną do niego aplikację docelową do momentu otrzymania informacji o poprawnym przetworzeniu komunikatu. Ma to na celu umożliwienie retransmisji komunikatu. 6. Zalecane jest, aby po potwierdzeniu poprawnego przetworzenia, komunikat (o którym mowa w punkcie powyżej) nie był usuwany, a przenoszony na zdefiniowany (najlepiej w konfiguracji) okres czasu do archiwum. Pozwoli to administratorowi na uzyskanie cennych informacji przydatnych w procesie diagnozowania niepoprawnie działającego systemu SBPx API Węzeł SBPx udostępnia API (ang. Application Programming Interface) na potrzeby wykonania połączenia z aplikacją kliencką. Można tego dokonać na dwa sposoby: wcielając SBPx, jako moduł do danej aplikacji i bezpośrednio w niej wykorzystywać API (model zalecany), lub na bazie API tworzyć adaptery, czyli mosty łączące SBPx z daną aplikacją. Razem stanowi to bardzo elastyczny mechanizm, pozwalający na jak najlepsze skonstruowanie połączenia z daną aplikacją. Dzięki API twórca aplikacji może stworzyć połączenie zgodnie z zapotrzebowaniem danego systemu. Minimalne wymagania wobec API SBPx obejmują następujące możliwości: 1. Wywołanie dowolnej usługi/procesu biznesowego oraz wygenerowanie i przesłanie do SB dowolnego komunikatu w sposób synchroniczny lub asynchroniczny. 2. Uzyskanie słownika lub wartości słownikowej z wybranego słownika (w ramach uprawnień) w dowolnej wersji.

17 17 3. Sprawdzenie listy subskrybowanych słowników i ich modyfikacja. 4. Sprawdzenie statusów komunikatów wygenerowanych w tym SBPx. 5. Sprawdzenie stanu połączenia SBPx z SB. 6. Wymuszenie połączenia z konkretnym SB. 7. Odebranie komunikatu. 8. Mechanizm generowania zdarzeń dla aplikacji klienckiej (np. informacja o pojawieniu się nowego słownika). 1.3 Komunikacja w SSB Niniejszy rozdział przedstawia zagadnienia związane z mechanizmem komunikacji między węzłami systemu Syriusz Broker. Zaczynając od wymagań bezpieczeństwa, dalej opisany zostanie system obsługi dużych komunikatów. Następnie przedstawione zostaną wymagane dane w nagłówku do opisu komunikatu, sposób identyfikacji węzłów w systemie. Na zakończenie rozdziału zaprezentowany zostanie mechanizm potwierdzeń obsługi komunikatów przesyłanych między węzłami Bezpieczeństwo W celu zapewnienia odpowiedniego poziomu bezpieczeństwa przesyłanych danych wymagane jest, aby każde połączenie węzłów było uwierzytelniane w sposób uniemożliwiający podanie się za węzeł o innym identyfikatorze niż przydzielony przez administratora. Stąd wymagane jest, aby każde dołączenie węzła (obojętne czy SB czy SBPx) do systemu Syriusz Broker było uwierzytelniane. Dane uwierzytelniające przechowywane będą w komponencie CBUiW (więcej o nim w rozdziale 0 Komponenty SSB to aplikacje Systemu Syriusz Broker, bez których węzły SB lub węzły SBPx nie mogłyby funkcjonować lub ich funkcjonalność byłaby ograniczona. Wśród aplikacji pomocniczych wyróżniamy: Centralną Bazę Użytkowników i Węzłów (CBUiW); Menadżer słowników; Moduł Administracyjno Diagnostyczny. Poniżej przedstawione zostały szczegółowe założenia funkcjonalne i techniczne wymienionych komponentów. Funkcjonalności komponentu CBUiW) i na ich podstawie powinien przebiegać ten proces. Za zarządzanie tymi danymi odpowiadać powinien administrator centralny, wykorzystując do tego komponent CBUiW. Należy zapewnić, aby elementy konfiguracyjne (zwłaszcza elementy uwierzytelniające) nie były dostępne dla osób postronnych. Dodatkowe informacje na temat uwierzytelniania zawarte zostały w rozdziale III1.1 Węzeł SB.

18 Fragmentacja SBPx musi zapewniać możliwość transportowania dużych bloków danych w taki sposób, aby nie miało to wpływu na przepływ innych komunikatów (przede wszystkim tych z wyższym priorytetem). W tym celu należy wprowadzić po stronie SBPx mechanizm fragmentacji komunikatu na mniejsze, a następnie po stronie węzła SB lub docelowego węzła SBPx odpowiednie funkcje, które pozwolą scalać otrzymywane fragmenty Nagłówek Komunikacja pomiędzy węzłami SB a SBPx oparta powinna być o protokół SSB (zwany dalej protokołem), który musi być dokładnie opisany i przygotowany na dalszy rozwój, z zachowaniem kompatybilności wstecz. Ponadto jest wymagane, aby miał on konstrukcję, umożliwiającą przerwanie transmisji komunikatu po odebraniu bloku nagłówka a przed odebraniem bloku danych. Sam nagłówek powinien być łatwo rozszerzalny w przyszłości o dowolny zestaw danych. Dzięki temu możliwe będzie wzbogacanie protokołu o nowe informacje wraz z zapotrzebowaniem, jakie może wystąpić w przyszłym rozwojem SSB. W celu wdrożenia funkcjonalności przedstawionych w tym dokumencie, konieczne jest, aby nagłówek komunikatu zawierał następujące informacje: unikalny identyfikator komunikatu; typ komunikatu; priorytet komunikatu; unikalny identyfikator nadawcy; unikalny identyfikator odbiorcy; informacje o tym, czy blok danych jest zaszyfrowany lub skompresowany; informację o ilości fragmentów oraz numer porządkowy danego fragmentu (patrz: funkcjonalność SBPx fragmentowanie, opisana w rozdziale III1.3.2 Fragmentacja); sumę kontrolną bloku danych; informację o identyfikatorze procesu biznesowego (w przypadku, gdy komunikat został wygenerowany na skutek uruchomienia określonego procesu w węźle SB) nazwy i wersje słowników, które zostały użyte do wygenerowania komunikatu; znacznik czasowy ważności komunikatu Identyfikator węzła Każdy z węzłów w SSB powinien posiadać jednoznaczny identyfikator, który pozwoli na adresowanie komunikatów w systemie. Wymagane jest, aby identyfikator węzła

19 19 SBPx przyjął taką formę, aby możliwe było zarówno zaadresowanie komunikatu do konkretnej instancji danej aplikacji, jak również do aplikacji wybranego typu bez wskazania jej konkretnej instancji. Dla przykładu proces biznesowy może generować komunikat do AC, natomiast w systemie może istnieć kilka instancji AC. W takiej sytuacji warstwa komunikacyjna węzła Syriusz Broker może przesłać komunikat do dowolnej z instancji tej aplikacji. Przy czym należy tak skonstruować mechanizm dystrybucji komunikatów, aby pozwolić na kierowanie ruchu do wszystkich instancji aplikacji danego typu tak i równomiernie obciążać wszystkie instancje Potwierdzenia Każde przesłanie komunikatu (lub fragmentu komunikatu) wymusza na węźle odbierającym odpowiedź potwierdzającą odebranie przekazu. W przypadku poprawnego odbioru, wysłanie potwierdzenia pozytywnego może nastąpić dopiero po dokonaniu zapisu odebranego komunikatu przez odbierający go węzeł, kiedy jest pewne, że ewentualna awaria węzła odbierającego nie spowoduje utraty tego komunikatu. W przypadku komunikatu odbioru odrzucającego transmisję komunikat musi posiadać dodatkowo informacje o powodzie odrzucenia. Poniżej wylistowane zostały przykłady treści komunikatów, zawierające informacje o możliwych przyczynach odrzuceń: Odrzucam, ponów wysłanie za X sekund (w przypadku, gdy węzeł nie ma uprawnień do wysyłania komunikatu w danym momencie (patrz: kalendarz transmisji w rozdziale IV1.3 Kalendarz transmisji). Wartość X oznacza taki okres czasu, po którym uprawnienie to będzie aktywne. Ponów, suma kontrolna bloku nie zgadza się. Odrzucam, z powodu braku uprawnień do generowania tego typu komunikatów. Odrzucam, nieznany typ komunikatu. Odrzucam ponieważ komunikat wygasł.

20 20 IV Komponenty SSB Komponenty SSB to aplikacje Systemu Syriusz Broker, bez których węzły SB lub węzły SBPx nie mogłyby funkcjonować lub ich funkcjonalność byłaby ograniczona. Wśród aplikacji pomocniczych wyróżniamy: Centralną Bazę Użytkowników i Węzłów (CBUiW); Menadżer słowników; Moduł Administracyjno Diagnostyczny. Poniżej przedstawione zostały szczegółowe założenia funkcjonalne i techniczne wymienionych komponentów. 1. Funkcjonalności komponentu CBUiW CBUiW jest komponentem wspomagającym prace systemu Syriusz Broker. Jego podstawowym zadaniem jest przechowywanie informacji odnośnie węzłów i użytkowników Systemu Syriusz Broker, umożliwiających ich uwierzytelnienie i autoryzację. Dodatkowo aplikacja zawiera także informacje pozwalające realizować nadzór czasowy nad przesyłanymi danymi w SSB. CBUiW składa się z trzech części: Bazy węzłów; Bazy użytkowników; Kalendarza transmisji. Poniżej przedstawiona została lista funkcjonalności, które powinny zostać zrealizowane w ramach implementacji wymienionych powyżej elementów CBUiW. 1.1 Baza węzłów Podstawowym zadaniem Bazy Węzłów będzie przechowywanie danych o węzłach Systemu Syriusz Broker, w tym informacji uwierzytelniających. Dane gromadzone w tym elemencie będą wykorzystywane przez System Syriusz Broker do zapewnienia bezpieczeństwa w przypadku dołączania nowych węzłów, jak również uwierzytelniania tych już podłączonych. Informacje te, służące do wewnętrznej kontroli SSB, powinny objąć: identyfikator węzła; element uwierzytelniający; pule adresów IP, z których może nastąpić połączenie z SSB; zbiór typów komunikatów, jakie dany węzeł może wysyłać; typ aplikacji łączącej się z danego węzła;

21 21 lokalizację aplikacji (adres jednostki). W związku z faktem, że węzły SB cache-ują dane z CBUiW, w przypadku modyfikacji w CBUiW powyższych danych, aplikacja ta musi rozpropagować dokonane zmiany wśród węzłów SB, tak aby wszystkie mogły dysponować aktualnymi danymi. Służyć ma temu wysyłany przez CBUiW komunikat, zawierający informacje o dokonanych zmianach i uruchamiający odpowiedni proces (patrz: III1.1.1 Podstawowe procesy biznesowe w systemie SB) odpowiedzialny za propagację tych zmian. 1.2 Baza użytkowników Baza użytkowników jest centralnym elementem, stworzonym dla komponentów SSB oraz aplikacji obszaru PSZ w celu ułatwienia zarządzania użytkownikami i ich uprawnieniami. W przypadku aplikacji z obszaru zaleca się wykorzystanie funkcjonalności bazy użytkowników, jednak nie jest to obligatoryjne. Dzięki jej wykorzystaniu możliwe będzie również wprowadzenie mechanizmu Single Sign On. Baza użytkowników powinna: przechowywać dane uwierzytelniające użytkowników SSB, tzn.: imię i nazwisko; login; element uwierzytelniający; miejsce pracy; stanowisko; zawierać definicje uprawnień dostępnych w aplikacjach podłączonych do SSB; umożliwiać definiowanie grup uprawnień; umożliwiać przyporządkowanie użytkownika do uprawnień (lub grupy uprawnień) i aplikacji (konkretnego węzła). 1.3 Kalendarz transmisji Kalendarz transmisji przechowywać będzie informacje o dozwolonych dla poszczególnych aplikacji terminach transmisji określonych typów danych. Podobnie jak i Baza węzłów, jest on mechanizmem służącym do wewnętrznej kontroli SSB. Kalendarz transmisji zawierać powinien przyporządkowanie węzła do typu pakietu i do przedziału czasowego, w jakim dany komunikat może wystąpić. Typy komunikatów w powyższym przyporządkowaniu muszą zostać ograniczone do tych, które mogą z danego węzła być wysyłane. Informacja ta następnie powinna zostać zapisana w Bazie węzłów. W przypadku, gdy dla określonego typu komunikatu nie zostanie stworzony wpis w kalendarzu, będzie możliwe przesyłanie go w dowolnym momencie. 1.4 Realizowane usługi

22 22 W związku z faktem, że zadaniem CBUiW jest gromadzenie danych zarówno na potrzeby SSB, jak również aplikacji dziedzinowych, wymagane jest, aby aplikacja ta udostępniała przechowywane dane w całym Systemie Syriusz Broker. W tym celu konieczne jest, aby CBUiW udostępniała wymienione poniżej usługi: 1. Usługa sprawdzająca poprawność danych uwierzytelniających danego węzła. 2. Usługa sprawdzająca poprawność IP danego węzła. 3. Usługa sprawdzająca, czy dopuszczalne jest wysłanie danego typu komunikatu przez dany węzeł. 4. Usługa sprawdzająca, czy dopuszczalne jest wysłanie danego typu komunikatu przez dany węzeł w podanym czasie. 5. Usługa sprawdzająca, czy dopuszczalne jest odebranie danego typu komunikatu przez dany węzeł. 6. Usługa pobrania dla zadanego węzła informacji odnośnie typów komunikatów, jakie węzeł może wysyłać. 7. Usługa pobrania dla zadanego węzła informacji odnośnie typów komunikatów, jakie węzeł może odbierać. 8. Usługa pobrania dla zadanego węzła informacji odnośnie kalendarza transmisji. 9. Usługa sprawdzająca poprawność danych uwierzytelniających dla danego użytkownika. 10. Usługa pobrania uprawnień dla danego użytkownika. 11. Usługa sprawdzająca czy dany użytkownik posiada zadane uprawnienia. 1.5 Interfejs użytkownika Przedstawione powyżej części składowe CBUiW wraz z informacją o danych, jakie będą gromadzone i listą usług, dostarczane do systemu Syriusz Broker stanowią silnik CBUiW. Na bazie tego silnika powinien powstać graficzny interfejs użytkownika (GUI) Aplikacji. Interfejs użytkownika powinien zostać zrealizowany, jako aplikacja webowa dostępna przez protokół https. Połączenie CBUiW z Systemem Syriusz Broker będzie zrealizowane przez SBPx. Użytkownicy korzystający z interfejsu CBUiW muszą zostać zdefiniowani wraz ze swymi uprawnieniami w tej aplikacji. Uprawnienia będą przede wszystkim dotyczyć tego, kto i w jaki sposób jak może dodawać użytkowników, węzły i definiować uprawnienia z nimi związane. Zaleca się delegowanie zarządzania użytkownikami do administratorów aplikacji, z których użytkownicy pochodzą.

23 23 Interfejs użytkownika powinien oferować przedstawione poniżej funkcjonalności Funkcjonalności Bazy Węzłów lista węzłów SSB; wyszukiwarka węzłów po kryteriach obejmujących dane wylistowane w rozdziale IV1.1 Baza węzłów; funkcjonalność, prezentująca szczegółowe informacji o wybranym węźle; funkcjonalność, pozwalająca na dokonywanie modyfikacji danych o węźle; funkcjonalność umożliwiająca dodawanie i usuwanie węzłów Funkcjonalności Bazy Użytkowników lista użytkowników zdefiniowanych w bazie; wyszukiwarka użytkowników po kryteriach, obejmujących imię i nazwisko, login, miejsce pracy, stanowisko; funkcjonalność prezentująca szczegółowe informacje o użytkowniku; funkcjonalność, pozwalająca na dokonywanie modyfikacji danych użytkownika; funkcjonalność umożliwiająca dodawanie i usuwanie użytkowników; lista uprawnień zdefiniowanych w bazie; wyszukiwarka uprawnień; funkcjonalność pozwalająca na dodanie nowego uprawnienia; funkcjonalność pozwalająca na usunięcie uprawnienia; lista grup uprawnień zdefiniowanych w bazie; wyszukiwarka grupy; funkcjonalność prezentująca zawartości grupy uprawnień; funkcjonalność, pozwalająca na dokonywanie modyfikacji grupy; funkcjonalność umożliwiająca dodawanie i usuwanie grup; funkcjonalność, pozwalająca na przyporządkowanie uprawnień do użytkownika i aplikacji (węzła); funkcjonalność, pozwalająca na usunięcia uprawnień użytkownikowi Funkcjonalności kalendarza transmisji: funkcjonalność, pozwalająca na przyporządkowanie węzła do typu komunikatu i przedziału czasowego;

24 24 funkcjonalność, pozwalająca na dokonywanie modyfikacji przyporządkowania węzła do typu komunikatu i przedziału czasowego; funkcjonalność, dająca możliwość usunięcia przyporządkowania do typu komunikatu i przedziału czasowego; lista przyporządkowań zdefiniowanych w punkcie 1; wyszukiwarka przyporządkowań (po typie komunikatu, aplikacji i zdanym przedziale czasowym). 1.6 Podsumowanie Warto zauważyć, iż w codziennej pracy systemu dane zgromadzone w CBUiW będą bardzo często używane. W szczególności dotyczy to danych o uprawnieniach węzłów, gdyż będą dotyczyć wszystkich komunikatów przepływających przez węzły SB. Z tego tez powodu należy tak zaprojektować i wykonać system uprawnień, aby czas odpowiedzi usług zarządzających procesem uwierzytelniania i pobierania uprawnień był jak najkrótszy. W celu przyspieszenia wykonania tych zapytań wskazane jest, aby informacje otrzymywane z CBUiW były cache-owane zarówno w węzłach, jak i aplikacjach dziedzinowych. CBUiW jest komponentem, który będzie wykorzystywany w procesie uwierzytelniania nowych węzłów w SSB. Jednak sam (dołączany do systemu przez SBPx) również podlegał będzie uwierzytelnianiu. Dlatego konieczne jest zapewnienie mechanizmu alternatywnego uwierzytelniania tej aplikacji w węzłach SB. W kierunkach rozwoju dla systemu Syriusz Broker, opisanych w dokumencie Analiza obszaru Syriusz Broker, przedstawiono możliwości rozbudowy CBUiW o dodatkowe informacje o pracownikach obszaru PSZ. Wskazane jest, aby wykonawca CBUiW projektując aplikację uwzględnił późniejszą jej rozbudowę i wykonał ją w ten sposób, aby dodanie nowych danych o użytkownikach nie wymagało dużych nakładów pracy i ingerencji w strukturę samej aplikacji. Standardem do tworzenia systemów zarządzających uprawnieniami jest baza LDAP. Może ona stanowić podstawę do wykonania aplikacji CBUiW. Nie jest to jednak wymagane. Wykonawca może zaproponować inne rozwiązanie, o ile umożliwi ono realizację wszystkich powyższych założeń.

25 25 2. Menadżer słowników (MS) Menadżer Słowników (MS) jest komponentem wspierającym działanie Systemu Syriusz Broker. Odpowiada on za przechowywanie i synchronizację danych słownikowych, występujących w SSB. MS realizuje następujące funkcje: 1. Przechowywanie słowników, w ramach których gromadzone są dane: nazwa unikalna nazwa słownika; wersja jest nadawana każdemu nowemu i zmodyfikowanemu słownikowi. dane słownikowe ten zbiór danych będzie generowany za pomocą aplikacji ASI Syriusz. 2. Przechowywanie historycznych wersji słowników, tak aby była możliwość uzyskania dowolnego słownika w dowolnej wersji. 3. Inicjacja procesu dystrybucji nowych wersji słowników w SSB. Słowniki stanowią element wspólny dla aplikacji w SI PSZ i warunkują spójne funkcjonowanie wszystkich jednostek tego obszaru. Z tego też powodu ważne jest, aby wszystkie aplikacje miały do nich dostęp. Poniżej przedstawiony został spis podstawowych usług, które powinny zostać zdefiniowane przez MS i udostępnione za pośrednictwem Syriusz Brokera. Dodaj (zdefiniuj) nowy słownik usługa pozwoli na wprowadzenie nowego słownika. Aktualizuj słownik usługa pozwalająca na wprowadzenie aktualizacji słownika. Oznacz słownik (lub wersję słownika) jako nieaktywną usługa wyłącza słownik z procesu dystrybucji. Słownik przestaje być dostępny dla aplikacji dziedzinowych. Pobierz słownik usługa umożliwi pobranie słownika o danej nazwie i (opcjonalnie) wersji. Menadżer Słowników będzie realizował przedstawione powyżej funkcjonalności. Natomiast aplikacją służącą do modyfikacji i tworzenia słowników pozostanie aplikacja ASI Syriusz. Menadżer Słowników odpowiada wyłącznie za ich dystrybucję. W warstwie biznesowej będzie zdefiniowany specjalny proces odpowiedzialny za dystrybucje słowników w systemie (opisany w rozdziale III1.1.1 Podstawowe procesy biznesowe w systemie SB). Wszystkie te składowe razem stanowią mechanizm, który ułatwi zarówno zarządzanie jak i synchronizację słowników w SSB. 3. Moduł Administracyjno Diagnostyczny System Syriusz Broker w obszarze swego działania obejmuje szeroki wachlarz aplikacji. Aby ułatwić administratorom nadzorowanie tego złożonego systemu

26 26 zostanie stworzony Moduł Administracyjno Diagnostyczny. Będzie on realizował następujące funkcje: 1. agregowanie i zapis ostrzeżeń otrzymywanych od węzłów systemu Syriusz Broker (struktura alertów została opisana w rozdziale III Węzły Systemu Syriusz Broker); 2. przy nawiązywaniu połączenia z SB inicjuje proces o swym podłączeniu do systemu. Ma to służyć poinformowaniu wszystkich węzłów o obecności aplikacji w systemie i przekazaniu przez nie do MAD skolejkowanych informacji. Sposób wykorzystania powyższych funkcjonalności przebiegać powinien następująco: w czasie działania SSB mają miejsce w systemie różne sytuacje awaryjne. Informacje o tych stanach są zbierane przez węzły SB lub SBPx. Następnie w postaci ostrzeżeń przesyłanych do aplikacji MAD. Jeśli nie jest ona podłączona do SSB, to wszystkie alerty są kolejkowane przez węzły SB. W momencie podłączenia do SSB, MAD wysyła komunikat do węzła SB, który inicjuje proces informowania wszystkich węzłów SB o obecnym położeniu tej aplikacji. W ten sposób mogą one przesłać wszystkie zaległe alerty. Następnie są one przechowywane i prezentowane administratorowi za pośrednictwem interfejsu użytkownika (GUI). Jednak GUI aplikacji MAD jest dużo bogatsze w funkcjonalności niż tylko obsługa otrzymywanych alertów. Wynika to z faktu, że korzysta również ze zdalnych usług dostarczanych przez węzły SB i SBPx. Interfejs użytkownika aplikacji Moduł Administracyjno Diagnostyczny powinien oferować takie funkcjonalności, jak: 1. lista alertów otrzymanych z SSB; 2. wyszukiwarka alertów po kryteriach: id węzła, typie aplikacji, dacie wystąpienia; 3. funkcjonalność, umożliwiająca kasowanie alertów (zarówno pojedynczo, jak i grupowo); 4. dynamiczna lista węzłów (początkowo lista powinna zawierać tylko węzeł SB, do którego jest podłączony MAD); 5. funkcjonalność, pozwalająca dla każdego węzła SB na liście (patrz punkt 4) pobranie listy węzłów, z którymi jest on połączony; 6. funkcjonalność prezentująca szczegółowe informacje odnośnie wybranego węzła (przy wykorzystaniu odpowiedniej usługi z CBUiW); 7. dla każdego węzła z dynamicznej listy, administrator ma do dyspozycji następujące funkcjonalności: a. funkcjonalność pozwalająca na pobranie listy komunikatów z kolejek wejściowej jak i wyjściowej wraz z informacją o statusie danego komunikatu; b. funkcjonalność pozwalająca na pobranie listy cache-owanych słowników w danym węźle wraz z ich wersjami;

27 27 c. funkcjonalność umożliwiająca zatwierdzenie wgranie nowej wersji słownika do danego węzła (opcja dostępna tylko wtedy, gdy słowniki w węźle będą konfigurowane ręcznie a nie automatycznie); d. funkcjonalność umożliwiająca subskrypcję nowego słownika; e. funkcjonalność umożliwiająca usunięcie słownika (jest to jednoznaczne z usunięciem słownika z cache-a oraz z listy subskrybowanych przez dany węzeł); f. funkcjonalność umożliwiająca pobranie z węzła logów z zadanego okresu czasu; g. funkcjonalność pozwalająca na dokonanie sprawdzenia dostępności (opcja ping) węzła. Komunikat taki przesyłany do węzła docelowego powinien zostać przez wszystkich pośredników uzupełniany o ich id. W ten sposób po odebraniu jego administrator nie tylko będzie znał status interesującego go węzła, ale również drogę jaką przebył; 8. funkcjonalność dająca administratorowi możliwość (dla węzłów SBPx z dynamicznej listy) wydania polecenia, aby dane SBPx przełączyło się na wskazane SB centralne; Opcje przedstawione w punktach mogą zostać wywołane dla konkretnego ID węzła. Tzn. administrator ma też możliwość podania identyfikatora węzła, bez korzystania z listy dynamicznej z punktu 4., i wywołania dla tego identyfikatora dowolnej opcji spośród tych przedstawionych w punktach Opcje z punktów 1 3 wykorzystują informacje gromadzone przez MAD, natomiast pozostałe bazują na funkcjonalnościach, jakie są zdefiniowane w węzłach SB i SBPx. Ich opis znajduje się w rozdziale III Węzły Systemu Syriusz Broker. W odróżnieniu od dwóch poprzednich komponentów, gdzie istniał podział na silnik i GUI, w przypadku Modułu Administracyjno Diagnostycznego powyższe funkcjonalności będą tworzyć jedną aplikacje. Interfejs użytkownika, podobnie jak w poprzednich komponentach, powinien być zrealizowany jako aplikacja webowa dostępna przez protokół https. Połączenie MAD z systemem Syriusz Broker ma być wykonane przez SBPx. Dostęp do funkcjonalności GUI powinien być ograniczony odpowiednimi uprawieniami. Ważne jest, aby administratorom centralnym dać możliwość wykorzystywania MAD dla dowolnego węzła lub ich grupy w SSB. Należy również pozwolić delegować część z powyższych zadań do administratorów lokalnych, ograniczając je tylko do możliwości wykorzystania na konkretnym węźle. Do organizacji struktury uprawnień w Module Administracyjno Diagnostycznym należy wykorzystać CBUiW. Podobnie jak CBUiW Moduł Administracyjno Diagnostyczny jest aplikacją szczególną, która pozwala nadzorować węzły w SSB. Stąd mogą zdarzyć się sytuacje, że aplikacja ta będzie łączyła się z węzłami SB, które nie będą miały dostępu do CBUiW, aby przeprowadzić proces dołączania węzła (patrz rozdział V1 Podłączenie

28 28 nowego węzła). Dlatego należy zapewnić mechanizm alternatywnego uwierzytelniania tej aplikacji w węzłach SB. Ponadto brak dostępu do CBUiW będzie oznaczał fakt, że nikt nie będzie mógł zalogować się do MAD. Stąd wymagane jest stworzenie w aplikacji specjalnego użytkownika, który będzie miał dostęp do wszystkich funkcjonalności w sytuacji braku połączenia z CBUiW. 3.1 Procjon Poza Modułem Administracyjno Diagnostycznym przewidziano dla administratora jeszcze jedno narzędzie do wykorzystania w sytuacjach awaryjnych. Mianowicie, w sytuacji awarii serwera, na którym działa węzeł SB lub SBPx, nie może nastąpić utrata komunikatów, które były przetwarzane w węźle. Stąd konieczne jest wprowadzenie narzędzia o nazwie Procjon 1, które zapewni następujące funkcjonalności: możliwość eksportowania komunikatów z kolejek: wejściowej i wyjściowej węzłów SB lub SBPx. Eksport odbywa się z systemu plików serwera, który uległ awarii. Tym samym narzędzie pozwala odzyskać komunikaty z danych zapisanych na dysku twardym, na którym działał SB lub SBPx. możliwość importowania komunikatów otrzymanych z eksportu do kolejek: wejściowej i wyjściowej węzłów SB lub SBPx. 1 Procjon jest najbliższą Syriuszowi gwiazdą

29 29 4. Aplikacja Centralna Aplikacja Centralna (AC) stanowi centralny zbiór informacji o beneficjentach Rynku Pracy. Zapewnia wykrywanie i raportowanie nieprawidłowości w obszarze rejestrowania bezrobotnych i przyznawanych im środków. Dodatkowo, pozwala ona na zachowanie spójności i poprawności wprowadzonych danych (beneficjent przy jej pomocy weryfikowany jest w systemie PESEL). Obecnie działająca Aplikacja Centralna zasilana jest paczkami danych przez PWD. Dostęp do raportów odbywa się przez aplikację webową. Aby dać możliwość wykorzystywania funkcjonalności AC w ramach aplikacji dziedzinowych, należy wykonać w niej następujące zmiany: 1. Udostępnienie w postaci usług synchronicznych dla SSB dotychczasowych raportów o nieprawidłowościach, tzn: o Osoby nieżyjące i pozbawione obywatelstwa; o Osoby aktywne w innych jednostkach; o Kontrahenci o podobnych danych identyfikacyjnych. 2. Dodanie usługi rejestracji danych bezrobotnego w AC usługa ta powinna działać w trybie online i umożliwiać rejestrację danych pojedynczej osoby. Stanowiłaby ona alternatywę dla dotychczasowego mechanizmu zasilania paczkami w trybie asynchronicznym. W ramach tej usługi powinien być generowany i zwracany identyfikator scalający. 3. Dodanie usługi weryfikacji danych osobowych w rejestrze PESEL dla podanych danych osobowych usługa sprawdza czy znajdują się takie w rejestrze. 4. Zdefiniowanie nowego raportu w aplikacji i udostępnienie go zarówno w takiej formie, jaka jest stosowana obecne, jak również przez usługę. Raport ten powinien prezentować informacje na temat osób, które straciły status bezrobotnego na skutek osiągnięcia wieku emerytalnego. Aplikacja Centralna będzie komunikować się z SSB za pośrednictwem SBPx. Stąd należy dokonać integracji SBPx z AC. Możliwe jest wykonanie tego na dwa sposoby: bezpośrednio w AC korzystając z SBPx API, lub tworząc odpowiedni adapter. W ten sposób aplikacja będzie miała dostęp do pełnej funkcjonalności Syriusz Brokera (m.in. zarządzanie słownikami, komunikacja synchroniczna, zewnętrzny system uprawnień). Jest wymagane ze względu na fakt, że usługi przedstawione będą powyżej działać w trybie online. Obecnie AC jest wdrożone w 4 województwach w Polsce. Jak wynika z analizy ilościowej zawartej w dokumencie Analiza obszaru Syriusz Broker, komunikaty dla AC stanowią ilościowo 24% ruchu w PWD, a pod względem objętościowym stanowią większość. Dlatego wraz z wdrożeniem powyższych zmian będzie musiała być przeprowadzana analiza, która określi wymagania wydajnościowe dla wdrożenia w całej Polsce i w razie potrzeby spowoduje wykonanie zmian optymalizacyjnych w aplikacji.

30 30 Zaleca się, aby rejestr PESEL nie był zintegrowany z AC, a dostępny w SSB za pośrednictwem usług, z których m.in. korzystałaby ów aplikacja. Ponadto daje to możliwość wykorzystania tych usług przez inne aplikacje klienckie w miarę występowania potrzeb. Zagadnienie to zostało szerzej przedstawione w dokumencie Analiza obszaru Syriusz Broker. Rozwiązanie to jednak jest możliwe w momencie wprowadzenia rejestru PESEL2. 5. Komponenty SSB podsumowanie W powyższych rozdziałach przedstawione zostały wymagania funkcjonalne i techniczne dla komponentów wspomagających pracę systemu Syriusz Broker. Każdy z nich wzbogaca system o funkcjonalności dostarczające aplikacjom klienckim dodatkowych możliwości i wspomagające ich działanie. Dla komponentu CBUiW wprowadzono pojęcie silnika i GUI. W przypadku MAD nie występuje taki podział (wynika to ze względów bezpieczeństwa oraz faktu, że aplikacja musi mieć możliwość funkcjonowania bez CBUiW). Zalecane jest, aby wykonać komponenty w sposób jaki został przedstawiony na poniższym rysunku. Rysunek 2 Propozycja struktury komponentów SSB Jak zostało pokazane powyżej, każdy z komponentów powinien zostać połączony z SSB przez SBPx. W przypadku CBUiW i MS samodzielnie podłączone będą silniki. Natomiast GUI aplikacji MAD będzie zintegrowane z GUI pozostałych komponentów (w przypadku MS aplikacją stanowiąca GUI będzie ASI Syriusz). Rozdzielenie GUI i silnika daje dużą elastyczność. Umożliwia to podmianę interfejsu użytkownika wedle zapotrzebowania, czy też pozwala na wykorzystanie części z funkcjonalności komponentów przez aplikacje dziedzinowe (wystarczy tylko nadać odpowiednie uprawnienia do korzystania z usług). Jeśli w czasie wykonywania interfejsu użytkownika dla komponentów stwierdzone zostanie, że lista usług jest niepełna i funkcjonalności z GUI wymagają stworzenie kolejnych, to należy silniki komponentów rozbudować o zdiagnozowane braki. W związku z wykonaniem usług dedykowanych pod GUI należy zdefiniować odpowiednie uprawnienia dla nich, tak aby inni klienci podłączeni do SSB nie mogli z nich korzystać.