Mechanizmy interoperacyjności w translatorze

Podstawowym elementem PK SIS i VIS jest tzw. translator (adapter) (patrz: Rys. 4) zapewniający zgodność komunikacji na styku systemów SIS 1+ i SIS II19. Posiada on elastyczną architekturę umożliwiającą modyfikację wraz z kolejnymi zmianami wersji SIS/VIS i wersji ICD. Dzięki temu od roku 2006 została zapewniona stabilizacja projektu SIS i VIS w Polsce, a także jego interoperacyjność wewnątrz PK SIS i VIS, jak również na styku Polski ze Strasburgiem. Skomunikowanie systemów SIS 1+ i SIS II byo możliwe przede wszystkim dzięki temu, że oba zostały zbudowane w podejściu SOA bazującym na usługach sieciowych, a komunikaty przesyłane w ramach tych systemów zostały opisane w standardzie XML.

CW PK SIS i VIS

P o d sy ste m PKI

P o d sy s te m LDAP

Em ail

S ystem W eryfikacji

W pisów

i

API SIS II

A plikacja SiSone4ALL

GUI SISone4ALL

S ieć Tl MSWiA (SDH) Użytkownicy Instytucjonalni (Ul)

Użytkownicy Indywidualni (Uln)

Rys. 4. Architektura CW PK na potrzeby SIS 1+ i SIS II Adapter (translator) odpowiedzialny jest za:

19 Koncepcja zbudowania translatora została zaproponowana przez Pełnomocnika Rządu ds. SIS i VIS jesienią 2006 r., co było niezbędne w celu przyjęcia tzw. propozycji portugalskiej. Propozycja ta oznaczała czasowe zaimplementowanie w Polsce rozwiązań bazujących na starszym SIS 1+ i równoczesną konieczność zintegrowania tego systemu ze standardami komunikacji dla nowszego SIS II, zaimplementowanych w wewnętrznych, krajowych systemach w ramach PK SIS i VIS.

• bieżące tłumaczenie zapytań przesyłanych z systemów uprawnionych użytkowników instytucjonalnych do CW PK SIS1+, z zaadaptowanego formatu SIS II na format zrozumiały przez SISone4All (portugalska implementacja systemu SIS 1+)

• adaptację asynchronicznego protokołu SIS II w obszarze CUD (ang.

Create, Update, Delete, poi. Utwórz, Modyfikuj, Usuń) na protokół zrozumiały przez SISone4All.

Problem dwukierunkowego tłumaczenia komunikatów pojawił się w Polsce z powodu trwającego już procesu przygotowań do komunikacji krajowych systemów informatycznych, wykorzystywanych kluczowych instytucjach, w szczególności w Policji, Straży Granicznej i Służbie Celnej do komunikacji z CW PK SIS. Podobnie, Urząd do spraw Cudzoziemców i Ministerstwo Spraw Zagranicznych, obsługujące polskie konsulaty na całym świecie pracował nad komunikacją z CW PK VIS. Nie było więc możliwe zastosowanie jedynie aplikacji portugalskiej umożliwiającej dostęp do specjalnej witryny WWW.

Kolejnym problemem, jak należało rozwiązać, były planowane duże obciążenia CW PK SIS i VIS. Z uwagi na to, że system miał być użytkowany w trybie ciągłym przez Policję i Straż Graniczną konieczne było takie jego zaprojektowanie, aby był on w stanie obsłużyć obciążenie ze strony Policji szacowne na około 100 tys. Zapytań na dobę i średnie obciążenie ze strony Straży Granicznej szacowane na około 5 tys. zapytań na godzinę, a w czasie szczytu obciążenia - nawet do 11 tys. zapytań na godzinę. Zapytania Policji i Straży granicznej stanowią największy procent zapytań, ale dostęp do systemu ma 21 instytucji.

Rys. 5 przedstawia diagram UML, ilustrujący logikę umieszczenia translatora w konfiguracji CW PK SIS. Komunikacja z aplikacją portugalską odbywa się dwukierunkowo. Po lewej stronie diagramu zobrazowano zautomatyzowany tryb komunikacji pomiędzy systemami użytkowników instytucjonalnych a CW PK SIS. Tryb ten stanowi główny wątek prowadzonych w tym miejscu rozważań. Drugi sposób komunikacji, to bezpośredni kontakt użytkowników indywidualnych przez specjalnie aplikację wykorzystującą przeglądarkę internetową.

cm p P o ls k i Komponent Systemu Informacyjnego Schengen 1+ (PK SIS1

♦)y

Centralny Węzeł Polskiego Komponentu Systemu Informacyjnego Schengen (CWPK SIS !♦ )

«aplikacja portugalska»

SISono4ALL

a

API SISone4AII

A

a

responslbllities Adaptacja asynchronicznego protokołu SIS II w obszarze CUO Trandacja zapytań SIS II -> SISone4AII

API zaadaptowanego SIS II

I

SOAP/HTTPS (2way sd)

I

ucjonalny (Ul)

«SC Ul*

System Centralny Użytkownika Instytucjonalnego

a

Użytkownik Końcowy (UK)

I_

Użytkownik Indywidualny (Uln)

A

P racow nik Biura SIRENE

Rys. 5. Miejsce translatora (adaptera) w architekturze logicznej CW PK SIS

Podczas implementacji translatora przyjęto również kilka kluczowych założeń, które zdeterminowały główne właściwości niefunkcjonalne systemu.

Ustalono redundantną architekturę najważniejszych komponentów sprzętowych i programowych. Założono, że środowisko produkcyjne musi zapewnić przepustowość na poziomie co najmniej 30 zapytań/sekundę, a czas reakcji do 5 sekund dla 99% zapytań standardowych przy zdefiniowanym powyżej obciążeniu.

Miara czasu reakcji nie uwzględnia tutaj dodatkowego czasu potrzebnego na komunikację w sieci rozległej, gdyż jest on mierzony w sieci lokalnej. Ponadto

przyjęto, że wszystkie komunikaty wchodzące i wychodzące z translatora będą rejestrowane we wspólnym Rejestrze Zdarzeń, o którym wspomniano w podrozdziale 4.2.

Niewątpliwym wyzwaniem dla realizatorów translatora była konieczność skomunikowania dwóch systemów, w których jeden pracuje wyłącznie w trybie synchronicznym. Mowa tutaj o SISone4All. Pojawił się zatem problem adaptacji protokołu SIS II, obsługującego zarówno tryb synchroniczny, jak i asynchroniczny do wymagań SISone4All (patrz: Rys. 6)

Protokół SIS II w zakresie zapytań (standardowych i uzupełniających) jest synchroniczny, co zostało zlustrowane na poniższym diagramie sekwencji.

i sd SIS2 -Zapytania /

Rys. 6. Synchroniczność zapytań w SIS II

Z kolei protokół SIS II w obszarze CUD (Create, Update, Delete) jest asynchroniczny - patrz: Rys. 7). Komunikacja asynchroniczna w SIS II jest realizowana w następujący sposób:

1) w pierwszym kroku CW PK SIS przyjmuje komunikat z dyspozycją zmiany i potwierdza jego przyjęcie,

2) następnie CW PK SIS przesyła komunikat z dyspozycją zmiany do CS-SIS,

3) na zakończenie, System Centralny Użytkownika Instytucjonalnego (SC Ul) otrzymuje Powiadomienie (Notification), które oznacza, że zmiana (ewentualnie utworzony wpis) została opublikowana, czyli dostępna w bazie SIS. Do wiązania powiadomienia o dokonanej zmianie z wcześniejszym komunikatem inicjującym tę zmianę służy tzw. LogicalSessionld.

Rys. 7. Asynchroniczność zapytań SIS II w zakresie CUD

Trudność w płynnym skomunikowaniu SIS II i SIS 1+ wynikała przede wszystkim z faktu, że protokół udostępniany przez SISone4All jest we wszystkich przypadkach synchroniczny (patrz: Rys. 8). W szczególności synchroniczność odpowiedzi na żądania typu CUD oznacza, że komunikat został przyjęty do SISone4All. Nie jest to jednak równoznaczne z opublikowaniem zmiany/utworzenia wpisu w bazie SIS. Wynika to bowiem z wymogów organizacyjnych, według których niektóre komunikaty typu CUD zanim zostaną opublikowane muszą być zatwierdzone przez Biuro S1RENE.

sd SISone4AII - CUD

SC Ul

3

CUD(A!ertData)

Response (AlertData)

SISone4AII

SIRENEVerifi cation

tr

Sent

F

Rys. 8. Obsługa zapytań w zakresie CUD przez SISone4All

Z analizy wykonanej podczas adaptacji zapytań typu CUD w SISone4All do protokołu SIS II za pomocą translatora wyniknęło jednoznacznie, że synchroniczny protokół udostępniany przez SISone4All jest niekompatybilny z asynchronicznym protokołem SIS II. Z tego powodu zaimplementowano właśnie translator - jako specjalny komponent pośredniczący w komunikacji między SC Ul a SISone4All. Pomysł logiki działania translatora został zilustrowany na poniższej sekwencji zdarzeń. Widać na niej wyraźnie, że ze strony SlSone4All translator dochowuje zasady synchroniczności komunikacji, a ze strony SIS II widziany jest w sposób asynchroniczny.

sd Zapytania - Adaptacja SIS 1 1 /

Rys. 9. Diagram logiczny adaptacji zapytań z SIS II do SISone4AlI

Translator pośredniczy (patrz również: Rys. 10) w przekazywaniu do SISone4All wszystkich komunikatów typu CUD. Realizowane jest to w następującej kolejności działań:

1) translator przyjmuje komunikat typu CUD od SC Ul w formacie SIS II i zapisuje go w lokalnej bazie danych,

2) translator wysyła komunikat typu CUD do SISone4All w formacie akceptowanym przez SISone4All. W przypadku operacji utworzenia wpisu, SISone4All nadaje tzw. Schengenld, które zostaje skojarzone z danymi wysłanymi przez SC Ul, 3) translator odpytuje regularnie SISone4All i w chwili wykrycia

dostępności operacji zmiany/utworzenia zapisu w wyniku zapytania jest już dostępna, odsyła powiadomienie do SC Ul zgodnie z wymaganiem protokołu SIS II. Następnie SC Ul kojarzy powiadomienie z wcześniej wysłanym żądaniem CUD za pomocą identyfikatora LogicalSessionld.

Translator korzysta wyłącznie z rozwiązań standardowych, udokumentowanych i dostępnych dla użytkowników instytucjonalnych. Translator i jego infrastruktura sprzętowa wykorzystują różne, powszechnie znane i stosowane standardy. Są to np.: XML, XSD Schema, WSDL, http, https, Two-way SSL, X.509v3, PKCS #7, PKCS #10, PKCS#12, RSA, DSA, IPSec.

\%«r iś*

X

Rys. 10. Adaptacjazapytań CUD z SISone4AlldoSIS II przypomocy translatora z uwzględnieniemCS-SIS

Kolejnym problemem, jaki został rozwiązany podczas implementacji translatora jest tłumaczenie komunikatów XML pomiędzy SIS 1+ i SIS II (patrz:

Rys. 9). Podstawą dla skutecznej implementacji mechanizmów tłumaczenia było spostrzeżenie o tym, że zbiór komunikatów z systemu SISone4All jest podzbiorem komunikatów z systemu SIS II. Równocześnie cześć wspólna zbioru komunikatów z obu systemów, pomimo różnych nazw, posiada identyczne znaczenie i jest wystarczaiaca dla zachowania pełnej funkcjonalności obu, kooperujących systemów20. W związku z tym możliwe było zdefiniowanie reguł dwukierunkowego przemapowywania komunikatów pomiędzy standardami SIS 1+

i SIS II. W poniższej tabeli został przedstawiony przykład przyporządkowania komunikatów SIS 1+ i SIS II, zaimplementowany w translatorze.

Tabela 1. Przykład mapowania komunikatów SIS 1+ i SIS II

Pole komunikatu SIS II Pole komunikatu SIS 1+ (SISone4All) SP1 = /[komunikat Sl]/create

SP2 = /[komunikat S21/Request/Alert

SP2/ExpirationDate SP1 /expirationDate SP2/ReasonForRequesl SPl/reasonForRequest SP2/ActionToBeTaken SP 1 /actionT oBeTaken SP2/SchengenID/RecordType

-SP2 = /Request/Alert/Data/Person/Core SP2/PersonRelatedRemarks

/PersonRelatedRemark

SP 1 /relatedRemarkld SP2/IdentificationMark 1 SPl/identificationMarklld SP2/IdentificationMark2 SPl/identificationMark2Id

SP2/Gender SPl/sex

SP2 = /Request/Alert/Data/Person/Core/Identities/Identity SP2/IdentityCategory SPl/identityCategory

SP2/DateOfBirth SPl/birthDate

SP2/FamilyNames SPl/lastName

SP2/FirstNames SPl/firstName

SP2/PlaceOfBirth SP1/birthPlace

SP2/Nationalities/Nationality SPl/nationalityld

Jak widać, komunikaty z SIS II otrzymały klasyfikację SP2, natomiast z SISone4All - SP1. Równocześnie, zapis reguł przemapowania jest prosty i jednoznaczny. A zatem nie powoduje to wzrostu kosztów obliczeniowych, zarówno w sensie czasowym, jak i pamięciowym na dokonywanie translacji w czasie rzeczywistym. Między innymi dzięki takiemu podejściu do implementacji

20 Regułę tą jesienią roku 2006 sformułował Pełnomocnikowi Rządu ds. SIS i VIS, co dało podstawę do postawienia tezy o możliwości zapewnienia interoperacyjności systemów SISone4All i SIS II. Teza to została potwierdzona poprzez implementację translatora w CW PK SIS i VIS.

reguł translacji w translatorze uzyskano bardzo dużą efektywność CW PK SIS i VIS, albowiem średni czas odpowiedzi systemu na zapytanie w środowisku produkcyjnym nie przekracza 600 msec.

Należy zauważyć, że przyjęte obecnie reguły implementacji translatora są elastyczne dla ewentualnych, kolejnych wersji dokumentów ICD, opisujących zbiory komunikatów dla SIS II. Warunkiem koniecznym dla tej elastyczności jest zachowanie reguły zawierania się zbioru komunikatów SIS 1+ w zbiorze komunikatów SIS II i identyczności znaczenia komunikatów ze zbioru wspólnego SIS 1+ i SIS II.

W dokumencie Społeczeństwo informacyjne : krok naprzód, dwa kroki wstecz (Stron 93-102)