PLATFORMA DLA USŁUG MOBILNEGO SAMORZĄDU

Transkrypt

1 PLATFORMA DLA USŁUG MOBILNEGO SAMORZĄDU Witold Abramowicz, Andrzej Bassara, Szymon Łazaruk, Marek Wiśniewski, Paweł śebrowski Wprowadzenie Jednostki samorządu terytorialnego stoją przed powaŝnym wyzwaniem. Z jednej strony mają moŝliwość inwestycji w nowe technologie informacyjne, które prowadzą do zwiększenia efektywności świadczenia usług publicznych. Z drugiej strony, wraz z rozwojem społeczeństwa informacyjnego, jego członkowie stają się coraz bardziej wymagający oczekując od samorządów, aby usługi przez nie oferowane były łatwo dostępne, a takŝe, aby były realizowane szybko oraz w sposób dogodny dla obywatela. Działania legislacyjne prowadzą do nakazów udostępnienia informacji publicznych na witrynach internetowych. JednakŜe, co raz więcej jednostek, w tym samorządowych, oferuje oprócz samych informacji (np. oferowanych poprzez Biuletyn Informacji Publicznej) takŝe proste usługi umoŝliwiające załatwienie nieskomplikowanych spraw drogą elektroniczną, tj. za pośrednictwem sieci Internet. W wielu przypadkach oferowanie usług za pośrednictwem tego medium nie jest jednak optymalne. Alternatywą moŝe być wykorzystanie infrastruktury operatorów telefonii komórkowej oraz urządzeń mobilnych tzw. kanał mobilny [USEME07]. Pomijając większą dostępność urzą-

2 dzeń mobilnych w porównaniu do komputerów z dostępem do Internetu, wykorzystanie kanału mobilnego pozwala na dostęp do usług z dowolnego miejsca (wyznaczonego poprzez zasięg telefonii komórkowej), o dowolnej porze. Wykorzystanie tego kanału stwarza takŝe nowe, niewykorzystywane w przypadku Internetu stacjonarnego, moŝliwości takie jak: informacja dotycząca lokalizacji uŝytkownika, aktywne powiadamianie uŝytkownika (np. SMS) czy wykorzystanie komunikacji wielomodalnej (np. połączenie interakcji głosowej z wyborem komend przy pomocy klawiatury). Niestety zastosowanie kanału mobilnego zwiększa takŝe złoŝoność a tym samym koszt wdroŝenia rozwiązania. W celu zniwelowania tego problemu proponujemy wykorzystanie platformy interoperacyjnej, która moŝe być współdzielona przez róŝne jednostki samorządowe i ich wydziały. Podstawowym zadaniem takiej platformy jest umoŝliwienie świadczenia usług kanałem mobilnym poprzez wykorzystanie współdzielonej infrastruktury, a tym samym umoŝliwienie zmniejszenia kosztów budowania i dostarczania usług. Współdzielenie zasobów Jednym z kluczowych czynników stojących u podstaw opracowania platformy interoperacyjnej jest zmniejszenie kosztów tworzenia, wdraŝania i utrzymania systemów przeznaczonych do świadczenia usług drogą elektroniczną, w szczególności drogą mobilną. Środkiem do osiągnięcia tego celu jest umoŝliwienie współdzielenia zasobów oraz oparcie rozwiązania na: nieskomplikowanych, otwartych i powszechnie wykorzystywanych technologiach.

3 Konieczne jest w tym ujęciu wyjaśnienie koncepcji współdzielenia zasobów oraz zdefiniowanie jego zakresu przedmiotowego. Poprzez współdzielenie zasobów rozumiemy moŝliwość wykorzystania pojedynczego zasobu przez wiele podmiotów w wielu kontekstach - np. wykorzystanie komponentu integrującego z infrastrukturą operatora telefonii komórkowej przez wiele jednostek administracji samorządowej. Współdzielenie zasobów związane jest takŝe z outsourcingiem. tj. podmioty współdzielące zasób mogą cedować obowiązek utrzymania i zarządzania zasobem na podmiot trzeci, np. operatora platformy. Współdzielenie zasobów przebiegać moŝe na róŝnych stopniach zaawansowania. Najprostszym, a zarazem najbardziej powszechnym jest współdzielenie infrastruktury fizycznej, w szczególności sieciowosprzętowej. Na tym poziomie powszechne są usługi wynajmu miejsca w serwerowni, sprzedaŝy powierzchni dyskowej czy mocy obliczeniowej. Te ostatnie przeŝywają swoje nowe wcielenie pod postacią cloud computing [Weis07] (przykładowo usługi oferowane przez Google czy Amazon). Kolejny poziom stanowi współdzielenie danych. Podobnie jak infrastruktura fizyczna, dane mogą być wykorzystywane w szeregu kontekstów. Konieczne jest zatem wdroŝenie mechanizmów umoŝliwiających zmniejszenie redundancji i uspójnienie posiadanych danych. Dziedzina Master Data Management [BeDu07] wypracowała w tym ujęciu szereg wzorców projektowych, które mogą być wykorzystywane. Powszechne zaczyna być takŝe wykorzystanie technologii sieci semantycznej do opisu semantyki udostępnianych danych, co w zamierzeniu ma prowadzić do zwiększenia poziomu interoperacyjności.

4 NajwyŜszy poziom, który jest w centrum naszych zainteresowań, to współdzielenie funkcjonalności. Współdzielenie funkcjonalności moŝe być realizowane poprzez wydzielenie funkcjonalności usług mobilnych, które są powtarzalne i występują w szeregu kontekstów zastosowania. Funkcjonalności te mogą być następnie oferowane takŝe w postaci usług (usługi infrastrukturalne). Usługi skierowane do uŝytkownika końcowego (usługi końcowe) mogą być następnie tworzone w oparciu o udostępnione usługi infrastrukturalne. Ilustracja 1: Architektura rozwiązania Na ilustracji 1 przedstawiono schematyczną architekturę platformy realizującej wszystkie poziomy współdzielenia. Platforma stanowi centralny punkt zarządzania danymi, które mogą być wykorzystywane w szeregu usług. Do takich danych naleŝą w szczególności profile uŝytkowników. Platforma zwalnia usługi z obowiązku rejestrowania uŝytkowników, czy teŝ zarządzania ich preferencjami. UŜytkownik rejestruje się na platformie, jego dane udostępniane są następnie poszczególnym usługom. JednakŜe, na wyraźne zezwolenie i w zakresie umoŝliwionym przez uŝytkownika. W zaleŝności od kontekstu

5 wdroŝenia Platformy, zestaw współdzielonych danych moŝe być rozszerzony o specyficzne dane, właściwe dla domeny wdroŝenia Platforma zawiera takŝe zbiór usług infrastrukturalnych, które w znacznym stopniu upraszczają oraz skracają czas wdraŝania nowych usług. Do podstawowych usług infrastrukturalnych naleŝy zaliczyć: integracja z operatorem telefonii komórkowej dostarczenie uproszczonych, zestandaryzowanych interfejsów umoŝliwiających nadawanie i odbieranie wiadomości (SMS, MMS) od poszczególnych uŝytkowników oraz za rozliczanie kosztów wykorzystania infrastruktury operatora telefonii komórkowej, transformacja treści usługa końcowa dostarcza do platformy treść niesformatowaną (bez informacji dotyczących szczegółów prezentacji), natomiast Platforma odpowiedzialna jest za ustalenie parametrów urządzenia uŝytkownika oraz za formatowanie treści zgodnie z tymi parametrami, zarządzanie profilami uŝytkowników platforma odpowiedzialna jest za: rejestrację uŝytkowników, zarządzanie preferencjami oraz zarządzanie subskrypcjami w ramach poszczególnych usług, udostępnianie współdzielonych danych udostępnianie treści zarządzanych przez Platformę przy pomocy standardowych interfejsów z wykorzystaniem technologii sieci semantycznej, zarządzanie kontekstem uŝytkownika odkrywanie sytuacji, w której znajduje się uŝytkownik (np. określenie jego lokalizacji). Architektura została zrealizowana z wykorzystaniem powszechnie stosowanych technologii. Na szczególną uwagę zasługują poniŝsze aspekty:

6 komunikacja między platformą a usługami została zrealizowana wyłącznie w oparciu o protokół HTTP, dane natomiast są strukturyzowane w postaci dokumentów XML, całość podejścia jest zgodna z REST [Fiel00], współdzielone dane udostępniane są jako dokumenty RDF przy czym językiem zapytań do repozytorium danych jest SPARQL, brak standardowych mechanizmów szyfrowania komunikacji na poziomie wiadomości przy zastosowaniu podejścia REST sprawił, iŝ konieczne było opracowanie dedykowanego mechanizmu. Mechanizm bezpieczeństwa szyfruje i podpisuje poszczególne komunikaty (dokumenty lub wywołania HTTP) korzystając z infrastruktury klucza publicznego (platforma pełni w tym ujęciu takŝe role centrum certyfikacyjnego). MoŜliwa jest zatem komunikacja między platformą a usługami końcowymi przez kanał publiczny. Tworzenie usług Tworzenie usług powinno być moŝliwe przy zastosowaniu wyłącznie uznanych, powszechnie wykorzystywanych oraz ujednoliconych standardów i technologii. Najgorszym z moŝliwych podejść jest wymuszenie na dostawcach usług końcowych wykorzystywania nowych, specyficznych dla danej infrastruktury (dla danej platformy) protokołów czy formatów wymiany danych. Niestety, większość znanych nam podejść, tworzy własne rozwiązania dotyczące: warstwy definiowania struktury przesyłanych komunikatów, prezentacji treści, utrzymywania stanu aplikacji, czy sesji uŝytkownika.

7 Opierają one przy tym swoje rozwiązania na standardach związanych z usługami sieciowymi (Web Services). Na szczęście, dla dostawców usług tworzenie usług sieciowych dawno juŝ przestało być trudne. Współczesne środowiska programistyczne znakomicie ułatwiają proces ich tworzenia. Usługi sieciowe są jednak nadal bardzo kosztowne w utrzymaniu i zarządzaniu. Logika wywołania funkcjonalności usługi oraz jej wynik reprezentowane są w ciele wiadomości HTTP w postaci wiadomości SOAP. Zarówno usługodawca, jak i klient, czy strona trzecia (np. bramka) zobowiązani są do przetwarzania wiadomości SOAP w celu podjęcia odpowiednich działań. WiąŜe się to z obowiązkiem utrzymywania pewnej części logiki aplikacji. W usługach sieciowych (rozumianych jako Web Services) brakuje ponadto bezstanowości oraz adresowalności. Konieczność utrzymywania stanu aplikacji jest kosztowna, poniewaŝ wymusza dodatkowe funkcjonalności związane z przetrzymywaniem logiki aplikacji, co niepotrzebnie komplikuje sposób tworzenia klientów usług. Brak adresowalności powoduje natomiast, Ŝe określenie funkcjonalności jakiej Ŝąda klient wymaga kosztownego procesu przetwarzania koperty SOAP. Biorąc pod uwagę wymienione wady obecnie tworzonych rozwiązań proponujemy tworzenie usług w paradygmacie REST [Fiel00] opierającym się na zasadach: adresowalności, bezstanowości, powiązań między zasobami oraz ujednoliconych interfejsów dostępu. Podstawowym obiektem w projektowaniu architektury tworzonej w paradygmacie REST są zasoby, które definiują obiekty biznesowe aplikacji (np. w przypadku usługi pozwalającej na sprawdzanie ocen w szkole będą to: uczeń czy przedmiot). Wykorzystane zasoby muszą być adreso-

8 walne, tzn. posiadać unikatowe URI. Nawigacja pomiędzy zasobami powinna być bezstanowa, co oznacza, Ŝe kaŝde wywołanie zasobu jest samowystarczalne. Do kaŝdego zasobu moŝna zatem odwołać się z dowolnego miejsca. Model nawigacji usługi zawiera się w powiązaniach pomiędzy zasobami. Wynikiem wywołania zasobu winna być lista innych, powiązanych zgodnie z modelem nawigacji zasobów. Ujednolicenie interfejsu dostępu przebiega na poziomie standardowych metod HTTP, tj. GET (pozyskanie zasobu), PUT (stworzenie nowego zasobu o nieistniejącym URI), POST (stworzenie nowego zasobu o istniejącym URI) oraz DELETE (usunięcie zasobu). Przykładowe wywołanie funkcjonalności w paradygmacie REST wygląda w sposób następujący: GET które moŝe oznaczać pobranie listy uczniów. Wywołanie w paradygmacie REST nie zawiera zatem Ŝadnych kopert w formatach takich jak SOAP. Cała logika wywołania znajduje się w nagłówku wywołania HTTP. Tworzenie usług w paradygmacie REST jest zatem ujednolicone poprzez wykorzystanie powszechnie stosowanego protokołu HTTP. Natomiast funkcjonalności, takie jak: bezpieczeństwo, w tym uwierzytelnianie, autoryzacja oraz szyfrowanie wiadomości, prezentacja treści w róŝnych formatach (np. XHTML na urządzenia mobilne), komunikacja za pomocą protokołów specyficznych dla sieci telefonii komórkowych mogą tym samym zostać wydzielone na platformę.

9 Podsumowanie Administracja samorządowa w coraz większym stopniu wykorzystuje technologie informatyczne do zwiększenia uŝyteczności i efektywności świadczonych usług lokalnej społeczności. JednakŜe budowanie i świadczenie usług w oparciu o nowe technologie jest kosztowne i nie wszystkie jednostki samorządowe mogą sobie na to pozwolić. Jednym ze sposobów rozwiązania tego problemu jest zbudowanie narzędzia umoŝliwiającego w jak największym stopniu współdzielenie zasobów. Proponujemy zatem wykorzystanie platformy integracyjnej, która umoŝliwia oddzielenie tego, co jest specyficzne dla usługi (logika biznesowa) od funkcjonalności, które mogą być współdzielone. Jednostki samorządu terytorialnego mogą wtedy duŝo niŝszym kosztem realizować usługi publiczne drogą elektroniczną. Literatura [LeSv02] Leenes, R.E., Svensson, J.S.: Size Matters - Electronic service delivery by municipalities? Conference Paper in Proceedings: Electronic Government - First International Conference, EGOV 2002, Aix-en-Provence, France. [USEME07] Moore, P.O., Peinel, G., Tilsner, D., Abramowicz, W., Bassara, A., Filipowska, A., Wisniewski, M., śebrowski, P.,: Usability Driven Open Platform for Mobile Government (USE-ME.GOV). W: Mobile Government: An Emerging Direction in E-Government, Redaktor: Kushchu, I., IGI Global, Hersey, USA 2007.

10 [BeDu07] Berson, A. and Dubov, L Master Data Management and Customer Data Integration for a Global Enterprise. McGraw-Hill Osborne Media. [Fiel00] Fielding, R. T Architectural Styles and the Design of Network-Based Software Architectures. Doctoral Thesis. UMI Order Number: AAI , University of California, Irvine. [Weis07] Weiss, A Computing in the clouds. networker 11, 4 (Dec. 2007), 16-25