Model węzła Infrastruktury Informacji Przestrzennej na poziomie regionalnym Katowice, marzec 2010 r.

Województwo Śląskie Model węzła Infrastruktury Informacji Przestrzennej Katowice, marzec 2010 r.

Województwo Śląskie. Wszelkie prawa zastrzeŝone. Kopiowanie, modyfikacja, wprowadzanie do obrotu, publikacja, dystrybucja w celach komercyjnych całości lub części dokumentu bez uprzedniej zgody właściciela - są zabronione. Dokument niniejszy moŝna kopiować i przechowywać oraz drukować wyłącznie na własne potrzeby (w celach niekomercyjnych). Zabronione jest jakiekolwiek upowszechnianie skopiowanego dokumentu, w szczególności jego zamieszczanie w witrynach internetowych innych niŝ naleŝących do właściciela.

SPIS TREŚCI: 1 WSTĘP... 7 2 CEL OPRACOWANIA I JEGO BENEFICJENCI... 8 3 ZAŁOśENIA WSTĘPNE I ŹRÓDŁA REKOMENDACJI... 9 4 INFRASTRUKTURA TECHNICZNA, INFORMACYJNA I FUNKCJONALNA MW-IIP... 10 4.1 Wymagania dotyczące infrastruktury technicznej 10 4.1.1 Architektura logiczna... 10 4.1.2 Architektura fizyczna... 16 4.1.3 Infrastruktura sprzętowa... 22 4.1.4 Infrastruktura teleinformatyczna... 25 4.2 Wymagania dotyczące infrastruktury informacyjnej 26 4.2.1 Ogólna charakterystyka danych... 26 4.2.2 Zasady gromadzenia danych... 29 4.2.3 Lokalne i zdalne zasoby informacyjne... 30 4.2.4 Procedury aktualizacji danych... 31 4.3 Wymagania dotyczące infrastruktury funkcjonalnej 32 4.3.1 Funkcjonalność serwera danych przestrzennych... 32 4.3.2 Funkcjonalność dedykowanych aplikacji... 33 4.3.3 Funkcjonalność portali i geoportali... 38 4.3.4 Funkcjonalność związana z kategoryzacją uŝytkowników... 40 5 ZAŁOśENIA ORGANIZACYJNE FUNKCJONOWANIA MW-IIP... 45 5.1 Poziomy administrowania infrastrukturą węzła 45 5.2 Dysponenci zasobów i zakres ich odpowiedzialności 46 5.3 Współdzielenie zasobów informacyjnych 46 6 WYMAGANIA NORMATYWNE, STANDARYZACYJNE I PRAWNE... 47 6.1 Zgodność z ustawodawstwem krajowym 47 6.1.1 Przepisy ustrojowe i uwarunkowania prawne dotyczące usług publicznych... 47 6.1.2 Przepisy prawa dotyczące systemów informatycznych... 50 6.1.3 Uwarunkowania prawne dotyczące publikacji danych... 51 6.1.4 Minimalne wymagania dotyczące systemów teleinformatycznych.. 52 6.2 Zgodność z Dyrektywą INSPIRE 53 6.3 Zgodność z załoŝeniami krajowej IIP 55 6.4 Obowiązujące normy i standardy w zakresie danych przestrzennych i ich metadanych 56 7 WSPÓŁPRACA Z INNYMI WĘZŁAMI IIP NA POZIOMIE LOKALNYM, REGIONALNYM, KRAJOWYM I EUROPEJSKIM... 60 7.1 Zasada interoperacyjności 60 7.2 Współdzielenie usług 60 7.3 Wymiana danych między węzłami IIP 61 3

Załącznik 1. Przykładowa konfiguracja infrastruktury sprzętowej MW-IIP. Załącznik 2. Przykładowa konfiguracja infrastruktury sprzętowej zespołu zintegrowanych węzłów IIP poziomu regionalnego. Załącznik 3. Przykładowa konfiguracja infrastruktury sprzętowej węzła IIP poziomu lokalnego. Załącznik 4. Potencjalne zasoby danych przestrzennych i opisowych gromadzone przez jednostki samorządu terytorialnego. Załącznik 5. Wykaz najwaŝniejszych funkcjonalności portali i geoportali. 4

Wykaz zastosowanych skrótów i określeń API ang. Application Programming Interface; interfejs programowania aplikacji CAD ang. Computer Aided Design; komputerowe wspomaganie projektowania CMS ang. Content Management System; system zarządzania treścią serwisów WWW EFRR Europejski Fundusz Rozwoju Regionalnego EGiB rejestr ewidencji gruntów, budynków (i lokali) GESUT Geodezyjna Ewidencja Uzbrojenia Technicznego GIS ang. Geographical Information Systems (Systemy Informacji Geograficznej) GML ang. Geography Markup Language GUGiK Główny Urząd Geodezji i Kartografii GUI ang. Graphical User Interface (graficzny interfejs uŝytkownika) HTML ang. HyperText Markup Language, pol. hipertekstowy język znaczników; dominujący język wykorzystywany do tworzenia stron internetowych HTTP ang. Hypertext Transfer Protocol HTTPS ang. Hypertext Transfer Protocol over Secure Sockets Layer IIP Infrastruktura Informacji Przestrzennej INSPIRE ang. INfrastructure for SPatial InfoRmation in Europe (Europejska Infrastruktura Informacji Przestrzennej) ISO ang. International Organization for Standardization, fra. Organisation internationale de normalisation; Międzynarodowa Organizacja Normalizacyjna ICT ang. Information and Communication Technologies; technologie komputerowe i komunikacyjne JOA Jednostka organizacyjna administracji - w niniejszym dokumencie rozumiane jako: urzędy administracji samorządowej róŝnych szczebli, ich jednostki organizacyjne, straŝe, słuŝby, i inne jednostki administracji niezespolonej JRE ang. Java Runtime Environment; środowisko uruchomieniowe dla programów napisanych w języku Java JST jednostka samorządu terytorialnego (np.: powiat, gmina) LAN ang. Local Area Network; siec lokalna, wewnętrzna MPZP miejscowy(e) plan(y) zagospodarowania przestrzennego MW-IIP modelowy węzeł Infrastruktury Informacji Przestrzennej poziomu regionalnego OGC ang.: Open Geospatial Consortium off-line przeciwieństwo on-line; najczęściej jako określenie sposobu oglądania danych/materiałów pobranych z Internetu bądź innej sieci komputerowej on-line "na Ŝywo"; status osoby (uŝytkownika) lub serwera określający stały i nieskrępowany dostęp do Internetu OPI-TPP Ogólnodostępna Platforma Informacji - Tereny Poprzemysłowe i Zdegradowane ORSIP Otwarty Regionalny System Informacji Przestrzennej PHP obiektowy, skryptowy język programowania zaprojektowany do 5

generowania stron internetowych w czasie rzeczywistym PZGiK Państwowy Zasób Geodezyjny i Kartograficzny RADIUS ang. Remote Authentication Dial In User Service, usługa zdalnego uwierzytelniania uŝytkowników RPC ang. Remote Procedure Call, protokół zdalnego wywoływania procedur RPO WSL Regionalny Program Operacyjny dla Województwa Śląskiego 2007-2013 RSIP Regionalny System Informacji Przestrzennej SEKAP System Elektronicznej Komunikacji Administracji Publicznej SI Społeczeństwo Informacyjne SIP System Informacji Przestrzennej SIT System Informacji o Terenie SIWZ Specyfikacja Istotnych Warunków Zamówienia SOA ang. Service Oriented Architecture; architektura zorientowana na usługi SOAP ang. Simple Object Access Protocol; protokół wywoływania zdalnego dostępu do obiektów SSL ang. Secure Sockets Layer SWDE geodezyjny Standard Wymiany Danych Ewidencyjnych TCP/IP ang. Transmission Control Protocol / Internet Protocol; teoretyczny model warstwowej struktury protokołów komunikacyjnych WAN ang. Wide Area Network; siec rozległa, zewnętrzna WebDAV ang. Web-based Distributed Authoring and Versioning WMS/WFS ang. Web Map Service / Web Feature Service - międzynarodowe standardy internetowego serwisu do tworzenia i udostępniania map WODGiK Wojewódzki Ośrodek Dokumentacji Geodezyjnej i Kartograficznej w Cieszynie WWW ang. World Wide Web XML ang. Extensible Markup Language 6

1 Wstęp Niniejsze opracowanie stanowi wyciąg z dokumentacji zrealizowanej przez firmę GEOINFO Kozłowski Jacek z siedzibą we Wrocławiu (filia Cieszyn) w ramach zamówionych przez Śląskie Centrum Społeczeństwa Informacyjnego (ŚCSI) "Konsultacji technicznych w zakresie opracowania modelowego węzła Infrastruktury Informacji Przestrzennej (MW-IIP) wraz z weryfikacją załoŝeń infrastruktury technicznej, informacyjnej i funkcjonalnej ORSIP", prowadzonych na podstawie umowy nr ŚCSI/022/PPZP/10a/2009 z dnia 04 grudnia 2009 roku. W stosunku do dokumentacji oryginalnej zaniechano publikacji jedynie rozdziału 8, prezentującego ocenę autora dwóch projektowanych systemów informatycznych, które docelowo mają stać się węzłami śląskiej regionalnej Infrastruktury Informacji Przestrzennej: Otwartego Regionalnego Systemu Informacji Przestrzennej (ORSIP) oraz Ogólnodostępnej Platformy Informacji Tereny Poprzemysłowe (OPI-TPP). Decyzja taka wynika z faktu, Ŝe oba wskazane projekt znajdują się obecnie w fazie przed-implementacyjnej, a ich ocena została dokonana na podstawie dokumentacji aplikacyjnej (Wniosku o dofinansowanie oraz Studium Wykonalności), które ze swej natury cechuje znaczny poziom ogólności w zakresie aspektów technicznych i technologicznych. PoniŜsze opracowanie w uporządkowany sposób porusza zagadnienia związane z infrastrukturą techniczną, informacyjną i funkcjonalną modelowego rozwiązania węzła IIP na poziomie regionalnym (rozdz. 4), jego załoŝenia organizacyjne (rozdz. 5), wykaz wymagań normatywnych, standaryzacyjnych i prawnych (rozdz. 6), a takŝe zasady współpracy z innymi węzłami krajowej IIP (rozdz. 7). 7

2 Cel opracowania i jego beneficjenci Zasadniczym celem niniejszego opracowania jest określenie podstawowych wytycznych i zaleceń technicznych, technologicznych, funkcjonalnych i organizacyjnych dla projektów dotyczących utworzenia rozwiązań informatycznych z zakresu SI o charakterze tematycznego węzła IIP. Podstawowymi Beneficjentami opracowania są zatem JOA takie jak: Urząd Marszałkowski Województwa Śląskiego (jego wydziały lub jednostki organizacyjne), czy teŝ Urząd Wojewódzki (jego wydziały lub podległe jednostki administracji zespolonej) realizujące lub zamierzające realizować (samodzielnie albo poprzez wykonawców zewnętrznych) przedsięwzięcia zmierzające do zbudowania kompleksowego systemu klasy GIS/SIP, którego zakres merytoryczny oraz planowana funkcjonalność umoŝliwiają włączenie go do regionalnej IIP. Poziom szczegółowości przedstawianych wytycznych i zaleceń został tak dobrany, Ŝeby umoŝliwić wykorzystanie ich w sposób bezpośredni przez Beneficjentów do: o opracowania warunków technicznych SIWZ w obszarze dotyczącym IIP dla projektów, które juŝ znajdują się fazie realizacji (np. OPI-TPP) lub o weryfikacji i uszczegółowienia podstawowej dokumentacji technicznej (np.: projektów generalnych, projektów funkcjonalno-uŝytkowych) projektów, dla których jeszcze nie złoŝono wniosków aplikacyjnych lub teŝ oczekujących na weryfikację formalną i merytoryczną (np.: ORSIP). Niektóre podane przykłady rozwiązań (np. w zakresie infrastruktury sprzętowej) odwołują się do komponentów konkretnych producentów jedynie w celu czytelnego zobrazowania proponowanych załoŝeń technologicznych lub wydajnościowych. Nie ogranicza to jednak moŝliwości zastosowania odpowiadających im, równowaŝnych rozwiązań innych podmiotów. Dodatkowo w dokumencie wskazano zakres skalowalności opracowanego modelu oraz konkretne rozwiązania w tym zakresie, tak aby moŝna było zastosować go do projektów budowy systemów GIS/SIP stanowiących węzły IIP w JOA niŝszych szczebli - w szczególności w powiatach i gminach. JOA szczebla powiatowego i gminnego stanowią więc grupę pośrednich Beneficjentów niniejszej dokumentacji. Ze względu na duŝą róŝnorodność konkretnych rozwiązań oferowanych przez poszczególnych dostawców systemów GIS/SIP działających na rynku krajowym i europejskim, wskazane w opracowaniu zapisy mają charakter rekomendacji. W niektórych specyficznych przypadkach ich zastosowanie moŝe być częściowo ograniczone lub nawet niemoŝliwe do zrealizowania, szczególnie w projektach polegających na rozwoju juŝ istniejącej IIP, opartej na technologiach konkretnych producentów i ich rozwiązaniach aplikacyjnych. Dodatkowym celem niniejszego opracowania jest dokonanie weryfikacji zgodności załoŝeń w zakresie IIP poczynionych w dokumentacji aplikacyjnej systemów ORSIP oraz OPI-TPP z zawartymi w niniejszym dokumencie wytycznymi i zaleceniami. 8

3 ZałoŜenia wstępne i źródła rekomendacji Przedstawiony w niniejszym dokumencie model regionalnego węzła IIP został oparty o pięć zasadniczych źródeł rekomendacji: o obszar regulacji wynikających z Dyrektywy INSPIRE (rozporządzenia Unii Europejskiej, akty powstałe w wyniku transpozycji do prawa krajowego), o obszar ustawodawstwa krajowego, m.in. w zakresie ustrojowym, przepisów branŝowych oraz dotyczących informatyzacji, o obszar regulacji Międzynarodowej Organizacji Normalizacyjnej (ISO), w szczególności dokumentów opracowanych przez Komitet ISO TC 211 Geografic Information/Geomatics, o obszar regulacji Open Geospatial Consortium (OGC) w zakresie standardów z zakresu geoinformacji, o obszar dobrych praktyk w zakresie budowy systemów informatycznych, ze szczególnym uwzględnieniem systemów klasy GIS/SIP. Uwzględniono takŝe generalne pryncypia dotyczące zapewnienia interoperacyjności w rozwiązaniach ICT dla europejskiej administracji publicznej (ISA - "interoperability solutions for European public administrations" 1 ), a dotyczące: o technologicznej neutralności oraz adaptowalności (przenaszalności) (technological neutrality and adaptability), o otwartości (openness), o wielokrotnego wykorzystania (reusability), o prywatności oraz ochronie danych osobowych (privacy and protection of personal data), o bezpieczeństwa (security). Dzięki temu przestawione w opracowaniu wytyczne i zalecenia w pełni spełniają takŝe podstawowe kryteria dla opracowań dofinansowywanych z EFRR, a mianowicie: o neutralności technologicznej nie wskazują i nie faworyzują Ŝadnej konkretnej technologii - oprogramowania GIS/SIP, jak równieŝ nie ograniczają beneficjentowi moŝliwości technologicznego wyboru ostatecznego rozwiązania, o swobodnego (otwartego) dostępu zapewniają moŝliwość współpracy i korzystania ze zbudowanej infrastruktury wszystkim zainteresowanym stronom, zarówno operatorom jak i uŝytkownikom. Dokumentacja nie wskazuje rozwiązań aplikacyjnych konkretnych producentów/dostawców, ale ogranicza się jedynie do uwzględnienia ustanowionych w zakresie IIP standardów i norm europejskich i krajowych, dobrych praktyk w zakresie budowy systemów GIS/SIP oraz powszechnie stosowanych technologii o charakterze standardów (np. dotyczących protokołów komunikacyjnych, formatów wymiany danych, itd.). Dzięki temu moŝe być wykorzystana zarówno na potrzeby inwestycji realizowanych z środków własnych beneficjentów, jak i dofinansowywanych z funduszy wspólnotowych. 1 Decision No 922/2009/EC of the European Parliament and of the Council of 16 September 2009 on interoperability solutions for European public administrations (ISA). Official Journal of the European Union, L 260/20, 3.10.2009 9

4 Infrastruktura techniczna, informacyjna i funkcjonalna MW-IIP Zasadniczym elementem systemu informatycznego klasy GIS/SIP, jakim jest takŝe opisywany w niniejszym opracowaniu MW-IIP, jest jego infrastruktura rozpatrywana w trzech głównych obszarach: o technicznym, o informacyjnym, o funkcjonalnym. MoŜliwie precyzyjne sformułowanie załoŝeń i uwarunkowań, jakie system powinien spełniać w powyŝszych obszarach pozwala osiągnąć jego zakładaną, docelową uŝyteczność oraz wpływa znacząco na wybór optymalnej technologii przeprowadzenia wdroŝenia systemu, czasu realizacji wdroŝenia, a ostatecznie takŝe wysokość kosztów budowy i późniejszej eksploatacji (utrzymania) systemu. 4.1 Wymagania dotyczące infrastruktury technicznej 4.1.1 Architektura logiczna Przedstawiona w tym rozdziale koncepcja logicznej architektury MW-IIP bazuje na wymaganiu zgodności z Dyrektywą INSPIRE, zaleceniami technicznymi INSPIRE i OGC oraz dobrymi praktykami tworzenia oprogramowania, w tym w szczególności projektem architektury referencyjnej SOA. W kolejnych podrozdziałach przedstawiono krótko koncepcję architektury INSPIRE, architektury referencyjnej SOA oraz zalecenia do architektury MW-IIP. 4.1.1.1 Koncepcja architektury INSPIRE Koncepcja architektury systemów informatycznych proponowana przez INSPIRE oparta jest na usługach. W Dyrektywie INSPIRE i w dokumentach jej towarzyszących wymienia się następujące usługi (cytaty za Dyrektywą INSPIRE): o usługi rejestrów (ang. Registry Services), które choć pozostają poza bezpośrednimi regulacjami dostarczają istotne informacje pozostałym usługom, wykorzystując rejestry takie jak: rejestr przestrzeni nazw zewnętrznych identyfikatorów obiektów (ang. External Object Identifier Namespaces Register), rejestr list kontrolowanych (ang. Code List Register), rejestr układów odniesienia (ang. Coordinate Reference System Register), rejestr jednostek miar (ang. Units of Measurements Register), rejestr pojęć słuŝących do opisu informacji geograficznej (ang. Feature Concept Dictionary Register), rejestr definicji i opisów typów obiektów przestrzennych (ang. Feature Catalogue Register), słownik (ang. Glossary), o usługi wyszukiwania (ang. Discovery Services) umoŝliwiające wyszukiwanie zbiorów oraz usług danych przestrzennych na podstawie zawartości odpowiadających im metadanych oraz umoŝliwiające wyświetlanie zawartości metadanych. Ich implementacje opierają się na specyfikacji CSW. o usługi przeglądania (ang. View Services) umoŝliwiające co najmniej: wyświetlanie, nawigowanie, powiększanie i pomniejszanie, przesuwanie lub nakładanie na siebie 10

zbiorów danych przestrzennych oraz wyświetlanie informacji z legendy i wszelkiej istotnej zawartości metadanych. Ich implementacje opierają się na specyfikacji WMS. o usługi pobierania (ang. Download Services) umoŝliwiające pobieranie kopii całych zbiorów danych przestrzennych lub części takich zbiorów oraz, gdy jest to wykonalne, dostęp bezpośredni. Ich implementacje opierają się na specyfikacji WFS. o usługi przekształcania (ang. Transformation Services) umoŝliwiające przekształcenie zbiorów danych przestrzennych w celu osiągnięcia interoperacyjności, o usługi umoŝliwiające uruchamianie usług danych przestrzennych (ang. Invoke Spatial Data Services; na rys. 1 oznaczone jako "Usługa uruch. UDP"). Ich implementacje opierają się na specyfikacji WPS. Koncepcja architektury INSPIRE 2 (rys. 1) ma na celu wymianę, wspólne korzystanie, dostęp i uŝytkowanie interoperacyjnych danych przestrzennych i usług dotyczących danych przestrzennych na róŝnych szczeblach organów publicznych i w róŝnych sektorach. Szyna usług INSPIRE jest pojęciem logicznym, implementowanym w oparciu o technologie Web Services. Architektura INSPIRE abstrahuje od lokalizacji usług. Istniejące systemy nie dostosowane do wymagań INSPIRE, w celu ich dołączenia do szyny usług muszą zostać wyposaŝone w fasadę implementującą te wymagania. Aplikacje i geoportale Szyna usług INSPIRE Usługa rejestrów Usługa wyszukiwania Usługa przeglądania Usługa pobierania Usługa przekszt. Usługa uruch. UDP Rejestry Metadane Zbiory danych przestrzennych Rys. 1. Logiczna architektura INSPIRE. 4.1.1.2 Architektura referencyjna SOA Obecnie standardem w zakresie budowy systemów informatycznych jest wykorzystywanie architektury warstwowej. W rozwiązaniach komercyjnych i literaturze podaje się wiele róŝnych modeli warstw. W celu przezwycięŝenia trudności powodowanych przez wydzielanie róŝnych warstw i przypisywanie im róŝnych zakresów odpowiedzialności konsorcjum The Open Group, będące neutralne względem technologii i dostawców, zaproponowało projekt architektury referencyjnej SOA (ang. SOA Reference Architecture) 3. 2 INSPIRE Network Services Architecture, INSPIRE 19-07-2008 3 Draft Technical Standard SOA Reference Architecture April 2009, The Open Group 11

Model ten stanowi kompromis pomiędzy modelami wiodących producentów oprogramowania, proponując zbiór warstw oraz zakresy ich odpowiedzialności. W architekturze referencyjnej SOA wyróŝniono następujące warstwy (rys. 2): o Warstwa konsumentów (ang. Consumer Layer), o Warstwa procesów biznesowych (ang. Business Processes Layer), o Warstwa usług (ang. Services Layer), o Warstwa komponentów usług (ang. Service Component Layer), o Warstwa oprogramowania systemowego (ang. Operational Systems) obejmuje infrastrukturę organizacji, w szczególności: zastane aplikacje (ang. legacy applications), inne serwisy, bazy danych, systemy przetwarzania transakcji, o Warstwa integracji (ang. Integration Layer) dostarcza mechanizmy pozwalające na transport Ŝądania i odpowiedzi pomiędzy Ŝądającym i dostawcą usługi, o Warstwa jakości serwisów (ang. Quality of Service Layer), o Warstwa architektury informacji (ang. Information Architecture Layer), o Warstwa zasad zarządzania (ang. Governance Layer). Konsumenci Procesy biznesowe Usługi Integracja Jakość serwisów Architektura informacji Zasady zarządzania Komponenty usług Oprogramowanie systemowe Rys. 2. Referencyjna architektura SOA. 4.1.1.3 Zalecenia dla architektury MW-IIP Architektura MW-IIP musi umoŝliwiać łatwe włączenie go do krajowej i europejskiej IIP. Docelowo musi równieŝ umoŝliwiać włączenie takiego węzła do infrastruktury tworzonej w ramach projektów związanych z e-administracją (e-government). Zapewnia to implementacja zaleceń Dyrektywy INSPIRE oraz towarzyszących jej dokumentów wykonawczych i zaleceń technicznych. Na rys. 3 przedstawiono umiejscowienie węzła IIP utworzonego na postawie MW-IIP, oznaczając znajdujące się w takim węźle komponenty sufiksem MW-IIP. Węzeł taki musi udostępniać usługi definiowane w ramach INSPIRE w zakresie określonym jego specyfiką (komponent Usługi INSPIRE MW-IIP). Potencjalnie moŝe równieŝ udostępniać usługi, które nie wchodzą w zakres Dyrektywy INSPIRE, na przykład związane z e-administracją (komponent Usługi spoza INSPIRE MW-IIP). Ze względu na udostępnianie takich usług szyna usług na rys. 3 została nazwana Szyną usług INSPIRE+. Usługi oferowane przez inne 12

węzły dostępne w ramach krajowej i europejskiej IIP są reprezentowane przez komponent Usługi INSPIRE. Geoportal i aplikacje zainstalowane w węźle utworzonym na postawie MW- IIP (symbolicznie oznaczone odpowiednio przez komponenty Geoportal MW-IIP i Aplikacja MW-IIP) logicznie komunikują się z usługami dostępnymi w tym węźle za pośrednictwem szyny usług (co nie wyklucza uŝycia bardziej efektywnego sposobu komunikacji, który pozwalałby uzyskiwać szybciej takie same dane, np.: bezpośrednie połączenie za pomocą wydzielonej lokalnej sieci fizycznej). Rys. 3. Umiejscowienie węzłów IIP utworzonych na podstawie MW-IIP. Podłączenie do szyny komponentów SEKAP i e-puap obrazuje moŝliwość korzystania przez te systemy z danych przestrzennych w oparciu o standardy zdefiniowane w ramach INSPIRE. Na rys. 3 przedstawiono przyłączenie tylko jednego węzła utworzonego na postawie MW- IIP oraz pojedyncze usługi, co było podyktowane czytelnością tego rysunku. Proponowana architektura pozwala na podłączenie do szyny dowolnej liczby węzłów utworzonych na podstawie MW-IIP, które będą mogły nawzajem korzystać ze swoich usług oraz z usług całej infrastruktury INSPIRE. KaŜdy z takich węzłów będzie świadczył wybrane usługi INSPIRE w zaleŝności od jego specyfiki. Spośród usług INSPIRE z punktu widzenia MW-IIP najwaŝniejsze wydają się: o usługa wyszukiwania, o usługa przeglądania, o usługa pobierania. Udostępnienie usługi wyszukiwania w danym węźle pozwala na jego samo opisywanie się, tzn. opis wszystkich oferowanych przez niego usług jest dostępny w postaci metadanych w tym węźle. UmoŜliwia to równieŝ przechowywanie metadanych o lokalnie utrzymywanych zasobach, które są wymagane podczas ich przetwarzania. Usługa rejestrów jest utrzymywana i zarządzana w ramach infrastruktury INSPIRE. Tworzone węzły powinny korzystać z dostępnych rejestrów. 13

Implementacja pozostałych dwóch usług, tj. przekształcania i uruchamiania, jest uzaleŝniona od charakteru węzła. Ich implementacja lub brak ich implementacji nie wpływa na architekturę danego węzła. Dołączenie węzła do IIP zgodnej z INSPIRE w przypadku usługi wyszukiwania polega na rejestracji tej usługi wyszukiwania w katalogu nadrzędnym tak, aby umoŝliwić wyszukiwanie rozproszone (względnie danobranie; ang. harvesting). W przypadku pozostałych usług rejestracja polega na opublikowaniu dla nich metadanych. Nadmienić naleŝy, Ŝe brak rejestracji danego węzła w usłudze wyszukiwania wyŝszego poziomu oraz nie opublikowanie metadanych o usługach umoŝliwia uzyskanie w prosty sposób węzła autonomicznego. Dyrektywa INSPRE i towarzyszące jej przepisy wykonawcze oraz zalecania techniczne nie określają architektury systemów implementujących wymagane usługi. Zalecenia te ograniczają się do implementacji usług w postaci Web Services. W niniejszym opracowaniu proponuje się oparcie logicznej architektury MW-IIP o architekturę referencyjną SOA. PoniŜej przedstawiono interpretację warstw tej architektury w kontekście MW-IIP: o W warstwie konsumentów znajdzie się geoportal oraz specjalizowane aplikacje dostępne w danym węźle. o W miarę potrzeb w warstwie procesów biznesowych zostanie umieszczone oprogramowanie wspomagające przepływy pracy oparte na usługach oferowanych przez warstwę usług. Przykładem jest obsługa spraw obywateli załatwianych przez wydziały urzędów. o W warstwie usług zostaną umieszczone usługi INSPIRE, które mają być świadczone przez dany węzeł oraz inne usługi dostępne przez szynę usług. o Warstwa komponentów usług dostarcza funkcjonalność wykorzystywaną do budowy usług. Szczególnie istotne jest tu wyróŝnienie funkcji wykorzystywanych w wielu usługach, czego przykładem jest moŝliwość wykorzystania metadanych w usługach przeglądania, pobierania czy transformowania. o W warstwie oprogramowania systemowego znajdą się np. bazy danych, inne składnice danych, istniejące juŝ systemy źródłowe (np. RSIP) oraz usługi dostępne przez szynę usług INSPIRE+. Pozostałe warstwy, tj. integracji, jakości serwisów, architektury informacji i zasad zarządzania, zaleŝą silnie od implementacji i nie będą tu dalej dyskutowane. WaŜne jest, aby wykorzystane rozwiązania pozwalały na realizację wszystkich wymagań niefunkcjonalnych i funkcjonalnych stawianych MW-IIP. Poza aplikacjami oferującymi usługi, które moŝna podpiąć do szyny usług INSPIRE+, w MW-IIP mogą istnieć inne aplikacje, np. zasilające bazę danymi. Aplikacje takie powinny zostać wpasowane w referencyjną architekturę SOA, na poziomie warstw komponentów usług i/lub oprogramowania systemowego. Jednym z zasadniczych komponentów warstwy najniŝszej (na rys. 2) jest w przypadku MW-IIP repozytorium danych, które umoŝliwiać ma przechowywanie dowolnych obiektów i zbiorów danych (m.in.: przestrzennych, opisowych, metadanych) oraz sprawny dostęp do nich. W strukturach bazy danych (na przykład obiektowej i/lub obiektowo-relacyjnej) zapisywane są informacje o obiektach, w tym w szczególności dla obiektów przestrzennych: o cechy geometryczne, np.: współrzędne połoŝenia naroŝy, długość, obwód, powierzchnia, o topologia, np.: połoŝenie, sąsiedztwo innych obiektów, charakter elementów wspólnych, 14

o atrybuty, zarówno opisowych (np.: tekstowych, liczbowych, linków WWW), o metadane geoinformacyjne. PowyŜej znajdują się warstwy pośredniczące pomiędzy zasobami systemu, a jego uŝytkownikami. Dotyczy to w szczególności usług oraz ich komponentów. Dostęp do usług uŝytkownicy mają poprzez konkretne rozwiązania aplikacyjne oraz zlokalizowane w najbardziej zewnętrznym obszarze architektury róŝnorodne interfejsy obsługi uŝytkowników. Ze względu na róŝnorodność pełnionych funkcji oraz sposób implementacji w ramach konkretnego rozwiązania, wymagana jest modularna budowa środowiska aplikacji (por. rozdz. 4.1.1.4 oraz 4.1.2.3). Bezpośredni dostęp uŝytkowników do systemu (zgromadzonych w nim danych, obsługujących je aplikacji oraz oferowanych usług) odbywa się za pośrednictwem najbardziej zewnętrznej warstwy, gdzie interfejs dostępu moŝe mieć róŝny charakter. W systemach GIS/SIP, w zaleŝności od potrzeb, realizuje się go najczęściej za pomocą: o prostych funkcjonalnie interfejsów korzystających z przeglądarki WWW: stosowane na przykład do przeglądania (wyszukiwania, sortowania, raportowania) lub wprowadzania danych posiadających charakter rejestrów lub innych zbiorów o prostej strukturze (np. interaktywnych formularzy), o zaawansowanych funkcjonalnie interfejsów korzystających z przeglądarki WWW: stosowane na przykład do przeglądania danych opisowych o skomplikowanej strukturze (wykorzystując metody docierania do informacji typu drill-down i drill-up), przeglądanie danych graficznych (przestrzennych) oraz wykonywanie na nich operacji, a takŝe inne narzędzia zarządzania danymi (np. ich edycję), o dedykowanych interfejsów dostępu GUI, oferujących róŝnorodną funkcjonalność (np.: przeglądarki danych przestrzennych, edytora metadanych, itd.), o portali/geoportali zrealizowanych jako witryny WWW: funkcjonujące najczęściej jako interaktywne mapy z róŝnorodnym zestawem narzędzi umoŝliwiających manipulację wyświetlaną mapą, zakresem prezentowanych danych, czy wyszukiwanie obiektów oraz sporządzaniem wydruków i raportów. 4.1.1.4 Modularna budowa środowiska aplikacyjnego Ogólnie przyjętym sposobem implementacji wielowarstwowych aplikacji jest oparcie warstwy pośredniczącej o tzw. serwer aplikacji, rozumiany jako aplikacja przeznaczana do uruchamiania innych aplikacji spełniających określone wymogi (odnośnie technologii, języka). Serwer tak rozumiany jest bazującym na wielu komponentach produktem niezaleŝnym od aplikacji, jakie są na nim uruchamiane, a którego rolą jest dostarczenie API tym aplikacjom, które zapewni podstawowe i wspólne dla wielu rozwiązań mechanizmy. Usługi świadczone przez serwer aplikacji zainstalowanym w nim aplikacjom składają się np. na: o usługi bezpieczeństwa zarówno autentykacja jak i autoryzacja, o usługi dostępu do baz danych utrzymywanie i zarządzanie połączeniami z bazami danych, o serwer WWW, o zapewnienie zdalnego dostępu do aplikacji, zarówno w postaci zdalnego API (np. WebServices, RPC), jak i dostęp do komponentów interfejsu uŝytkownika (WWW), o utrwalanie stanu aplikacji (sesji uŝytkownika, stanu konwersacji poprzez róŝnego rodzaju API, o róŝnorodne często wielopoziomowe cache, 15

o mechanizmy przesyłania wiadomości, zdarzeń, o wiele innych usług zaleŝnych od rodzaju i typu serwera aplikacji. Rys. 4. Schemat umiejscowienia aplikacji w środowisku serwera aplikacji. 4.1.2 Architektura fizyczna Analizując zagadnienie architektury fizycznej MW-IIP naleŝy mieć na uwadze, Ŝe rozpatrywany w niniejszym opracowaniu model odnosi się do abstrakcyjnego, jednostkowego elementu większej całości, jaką jest IIP (lub na przykład infrastruktura SI Urzędu Marszałkowskiego Województwa Śląskiego), która z natury rzeczy ma charakter architektury rozproszonej. Jednocześnie nie moŝna wykluczyć, Ŝe na pewnym etapie funkcjonowania, poszczególne komponenty tej infrastruktury (np. pojedyncze węzły tematyczne IIP) będą funkcjonowały jako częściowo lub w pełni niezaleŝne systemy, mające charakter rozwiązań o architekturze scentralizowanej. Dlatego teŝ w niniejszej dokumentacji nie przesądza się charakteru architektury MW-IIP w tym zakresie, a jedynie wskazuje na najistotniejsze wymagania odnoszące się do jej poszczególnych składników. Zastosowanie architektury zcentralizowanej ma natomiast swoje uzasadnienie w przypadku węzłów IIP na poziomie lokalnym (powiatowym, czy gminnym), gdyŝ moŝe ułatwić proces udostępniania zasobów na zewnątrz urzędu (jedno wspólne repozytorium danych o charakterze hurtowni) przez dedykowane rozwiązania informatyczne w postaci interaktywnej mapy/geoportalu powiatu/gminy, centrum dostępu do metadanych, itd. W takim przypadku konkretny węzeł stanowił będzie centrum informacji przestrzennej o danym obszarze (powiecie, gminie) i potencjalne źródło danych dla innych węzłów IIP, szczególnie tych poziomu regionalnego, gdzie następuje agregacja danych z większego obszaru. 16

Dodatkowymi cechami architektury zcentralizowanej, które pretendują ją do zastosowania w węzłach IIP szczebla lokalnego są: o znaczna prostota budowy, o łatwość zarządzania systemem, o łatwe zapewnienie fizycznego bezpieczeństwa, o ułatwienie utrzymania spójności danych w skali całego systemu, o wprowadzanie zmian w funkcjonowaniu oprogramowania tylko w jednym miejscu - na jednostce centralnej, o łatwość i szybkość implementacji takiego systemu. 4.1.2.1 Serwer bazy danych W najprostszym przypadku (model architektury scentralizowanej) jądro MW-IIP stanowić będzie baza danych znajdująca się na dedykowanej jednostce komputerowej (serwerze), obsługującej w zasadzie wszystkie zadania wymagane do utrzymania węzła. Wówczas tutaj zainstalowane będą: serwer bazy danych warstwy wewnętrznej, serwer danych przestrzennych oraz dedykowane aplikacje warstwy pośredniej. Ze względów ekonomicznych (eliminacja kosztów związanych z zakupem oddzielnych fizycznie serwerów) sytuacja taka zaistnieć moŝe takŝe w węzłach IIP budowanych w JST niŝszego szczebla (powiatach, gminach). W przypadku bardziej rozbudowanych rozwiązań zaleca się fizyczne rozdzielnie powyŝszej infrastruktury na dwa, a nawet trzy oddzielne serwery sprzętowe lub ich wirtualizację (np. w rozwiązaniach klastrowych) (por takŝe rozdz. 4.1.3.2). Analizując uwarunkowania związane z systemem zarządzania bazą danych, to wziąć naleŝy pod uwagę co najmniej następujące wymania szczegółowe: o obiektowy lub obiektowo-relacyjny charakter (w zaleŝności od zastosowań), o dostępność interfejsów, o skalowalność, o obsługa rozproszonych baz danych oraz zasobów plikowych, o ukierunkowanie na transakcyjne przetwarzanie danych (a w konsekwencji umoŝliwienie pracy wielu uŝytkownikom jednocześnie), o zapewnienie wysokiego poziomu bezpieczeństwa danych oraz procesów ich przetwarzania, o moŝliwość pracy w środowisku dowolnych systemów operacyjnych, o moŝliwość pracy w środowisku maszyn wirtualnych, o w przypadku rozwiązań komercyjnych elastyczny model licencjonowania (na uŝytkownika - per user, na procesor/serwer/instytucję - per procesor/per serwer/per unit), o ewentualne istnienie opcji zakupu wsparcia serwisowego (np. hot-line) i prawa do upgrade-u. Ze względów praktycznych oraz w celu zachowania swobody dostępu do danych w celach administracyjnych zaleca się dodatkowo, aby zastosowany w MW-IIP system zarządzania bazą danych umoŝliwiał takŝe współpracę z aplikacjami CAD/GIS w technologii klientserwer. 17

4.1.2.2 Serwer danych przestrzennych Specyfika samych danych przestrzennych oraz potrzeba sprawnego i elastycznego zarządzania ich dystrybucją wymagają zaopatrzenia warstwy wewnętrznej w dodatkowy komponent - serwer danych przestrzennych (stosuje się teŝ nazwę serwer mapowy). Podstawowe zadanie serwera danych przestrzennych polega na udostępnianiu danych przestrzennych innym aplikacjom (w formie usług) jak i uŝytkownikom końcowym (w formie gotowych map, które mogą być prezentowane w przeglądarce WWW). Serwer danych przestrzennych separuje pozostałe komponenty od bazy danych przestrzennych umoŝliwiając jednolity dostęp zarówno do lokalnych jak i zdalnych (poprzez usługi OGC) zasobów. Serwer danych powinien współpracować z szyną usług w celu umoŝliwienia dostępu do jego zasobów. Minimalna oferowana funkcjonalność musi zapewnić obsługę podstawowych standardów OGC: Web Map Service (WMS), Web Feature Service (WFS) i Web Coverage Service (WCS). Wskazanym jest, aby usługi serwera danych przestrzennych umoŝliwiały innym komponentom systemu dokonywanie analiz przestrzennych na oferowanych przez serwer danych moŝna w tym celu wykorzystać standard Web Processing Service (WPS). Wszystkie moduły systemu korzystające z danych przestrzennych będą bazować na serwerze danych przestrzennych i oferowanych przez niego usługach (np.: portal/geoportal mapowy będzie korzystał z usługi WMS w celu prezentacji mapy). W celu zachowania spójności z pozostałymi modułami aplikacyjnymi jak i w celu maksymalizacji wykorzystania zasobów sprzętowych, serwer danych przestrzennych powinien działać w środowisku serwera aplikacji, będąc kolejnym modułem MW-IIP oferującym swoje usługi. Pozostałe moduły MW-IIP mogą komunikować się z serwerem danych przestrzennych z wykorzystaniem szyny komunikacyjnej i Web Services. Dodatkowo moduły aplikacyjne działające w ramach serwera aplikacji mogą korzystać z jego wewnętrznego API, które jest w stanie zapewnić efektywniejszy dostęp do duŝych zbiorów danych (rys. 5). Dyrektywa INSPIRE nakłada obowiązek udostępniania razem z danymi takŝe ich metadanych. Nie jest koniecznym, aby to serwer danych przestrzennych udostępniał metadane, jednak powinien on móc współpracować z osobną usługą (aplikacją) katalogu metadanych (por. rozdz. 4.3.2.1). PoniewaŜ serwer danych przestrzennych wykonuje operacje wymagające przetwarzania duŝych zbiorów danych jak i duŝych mocy obliczeniowych, powinien być rozwiązaniem skalowanym, zapewniającym wzrost mocy przetwarzania poprzez dołączanie kolejnych instancji działających na osobnych serwerach (klastrowanie). Aby było moŝliwe wykorzystanie juŝ istniejącej infrastruktury sprzętowej oraz łatwa rozbudowa jej w przyszłości wskazane jest, aby oprogramowanie serwera danych przestrzennych mogło działać na róŝnych platformach sprzętowych i programowych. Obszar przetwarzania danych przestrzennych jest dziedziną dynamicznie się rozwijającą, oferującą coraz to nowe moŝliwości, jak i powodującą pojawianie się nowych standardów serwisów jak i usług. Dlatego teŝ wybrane oprogramowanie serwera danych przestrzennych powinno być aktywnie rozwijane tak, aby moŝliwe było sprostanie przyszłym potrzebom w zakresie udostępniania i przetwarzania danych. 18

Rys. 5. Schemat lokalizacji serwera danych przestrzennych w ramach architektury MW-IIP. 4.1.2.3 Środowisko aplikacyjne Kolejnym istotnym elementem infrastruktury fizycznej MW-IIP jest środowisko dedykowanych aplikacji warstwy pośredniczącej. Powinno ono mieć charakter elastycznego i skalowalnego rozwiązania o budowie modularnej, opartego o platformę programistyczną, umoŝliwiającą tworzenie nowych aplikacji (rozszerzeń), wykorzystujących dane przestrzenne, bazy danych i technologie internetowe. Dzięki temu w dowolnym momencie powinna istnieć moŝliwość dodania nowego modułu (aplikacji) do istniejącej konfiguracji wzbogacającego system o nowe funkcjonalności, bez konieczności wymiany całego systemu. Cel ten moŝna osiągnąć poprzez zastosowanie serwera aplikacji. Serwery aplikacji mogą być tworzone przez inny podmiot niŝ podmiot tworzący aplikację funkcjonalną posadowioną na tym serwerze. Niektóre klasy serwerów aplikacji spełniają określone specyfikacje, co pozwala na tworzenie oprogramowania mogącego być uruchomionym na serwerze aplikacji pochodzącym od dowolnego dostawcy (przykładem jest specyfikacja Java EE, w zgodzie z którą pozostają serwery Glassfish firmy Sun Microsystems, WebSphere firmy IBM, Jboss firmy RedHat, czy WebLogic firmy Oracle). Stąd w projektowaniu węzła IIP istotne jest wybranie takiej technologii, która zagwarantuje niezaleŝność zarówno od producenta serwera aplikacji, jak i od systemu operacyjnego na jakim serwer aplikacji moŝe być uruchomiony wymagania te spełniają serwery zgodne z JEE, w mniejszym stopniu serwer IIS wraz z platformą.net. Serwer aplikacji stanowi pewną platformę, która moŝe być współdzielona przez wiele aplikacji, bądź modułów, dzięki czemu szereg funkcji administracyjnych zostaje 19

scentralizowanych w serwerze aplikacji. Z jednej strony ułatwia to zarządzanie aplikacjami ich instalację, aktualizację, blokowanie dostępu z drugiej pozwala na scentralizowane zarządzanie podstawowymi parametrami konfiguracyjnymi, na przykład parametry dostępu do baz danych. Większość serwerów aplikacji zawiera w sobie mechanizmy umoŝliwiające monitoring, co ułatwia diagnostykę i optymalizację konfiguracji. Zarówno monitorowanie aplikacji jak i zarządzanie konfiguracją serwera aplikacji najczęściej moŝliwe jest zdalnie, w tym równieŝ poprzez specjalne, często oparte o standardy interfejsy API, za pomocą których moŝna stworzyć mechanizmy dopuszczające automatyczne lub pół-automatyczne zarządzanie serwerem (co w duŝych wdroŝeniach będzie wartością nie do przecenienia), bądź teŝ rejestrację róŝnych rozszerzeń (funkcjonalności aplikacji, które mogą być instalowane oddzielnie). Wszystkie te narzędzia do działania nie wymagają wprowadzania zmian w aplikacjach, jakie zainstalowane są na serwerze. JeŜeli serwer aplikacji oparty będzie o otwarte standardy, daje to moŝliwość łatwego rozszerzania systemu o kolejne aplikacje spełniające ten standard w tym na przykład aplikacje open source istniejące na rynku, ale równieŝ rozwiązania komercyjne. Dzięki zastosowaniu przyjętego i sprawdzonego rozwiązania opartego o uznany serwer aplikacji, moŝna mieć uzasadnione nadzieje, Ŝe dołoŝenie kolejnej aplikacji w przypadku wolnych zasobów sprzętowych nie wywoła konieczności tworzenia nowego środowiska dla kolejnych aplikacji. Serwery aplikacji zapewniają takŝe wiele mechanizmów, które zwiększają skalowalność zainstalowanych na nich aplikacji. Z jednej strony umoŝliwiają proste rozdzielenie posadowionych na nim aplikacji na kilka niezaleŝnych serwerów aplikacji, z drugiej mogą zapewnić moŝliwość klastrowania (rys. 6). Klaster serwerów aplikacji zwiększa ich dostępność (poprzez mechanizm fail-over), jak i wydajność (load-balance). Aplikacje umieszczone w serwerze aplikacji najczęściej muszą spełnić dodatkowe wymogi niefunkcjonalne, aby podlegały bezproblemowemu rozproszeniu, jednak jest to relatywnie niski koszt w porównaniu z zyskami wynikającymi z moŝliwości prostej rozbudowy całego systemu poprzez dostawienie kolejnej maszyny (serwera). Ze względu na zaleŝne od zewnętrznych czynników i trudne do przewidzenia w przypadku opisywanego modelu obciąŝenie systemu, moŝliwość łatwego skalowania warstwy pośredniczącej, w tym serwera aplikacji, moŝe okazać się kluczowa. 20