Моделі надання державних послуг

Важлива частина моделей надання державних послуг - традиційні канали, доповнені сучасними веб-технологіями. Якщо персональне спілкування є ключовим компонентом державних послуг, то застосування веб-технологій значно поліпшує їх якість. Так, через Інтернет громадяни можуть дізнатися про готовність тієї чи іншої довідки, але для її отримання необхідно відвідати державну установу; записатися на прийом до лікаря, і водночас лікар може скористатися електронною системою для доступу до всієї інформації про пацієнта.

Приватні компанії вибирають модель, відповідно до якої використовуються центри телефонного обслуговування, але при цьому вони існують як вторинний канал. З погляду на підвищення зручності та зменшення витрат на обслуговування запитів громадян і бізнесу державі було б вигідно, щоб її клієнти максимально користувалися каналами взаємодії першого рівня (тобто доступ до порталу через персональні комп’ютери, інформаційні кіоски тощо) і тільки потім використовували інші канали взаємодії, такі як центри телефонного обслуговування або візити до державних установ.

Рисунок 2.7. Моделі надання державних послуг [6].

Рисунок 2.8. Моделі взаємодії громадян з державою [6].

Розглянемо основні компоненти архітектури міжвідомчої взаємодії, в основі якої лежить програмне забезпечення корпорації Microsoft. Архітектура міжвідомчої взаємодії [6] містить такі основні складові:

• XML як універсальний формат інформації/документів або обміну ними;

• середовище гарантованої доставки і маршрутизації інформації на базі XML-документів стандартних Інтернет-протоколів. До них належить програмний продукт Microsoft BizTalk Server, призначений для інтеграції додатків;

• реалізація державних інформаційних систем у вигляді веб-служб, які є програмними компонентами додатків, доступні на основі відкритих стандартних Інтернет-протоколів і виконують певні бізнес-функції.

Технології інтеграції можна класифікувати за категоріями:

• системи інтеграції корпоративних додатків (Enterprise Applications Integration, EAI) - технології, орієнтовані на розв’язання проблем інтеграції різних систем, додатків та даних всередині окремої організації;

• системи інтеграції між організаціями (міжвідомча організація) Business-to-Business (Business-to-Business Integration, B2Bi) - технології, орієнтовані на гарантування безпечного, надійного інформаційного обміну між різними організаціями та їх інформаційними системами. Вони забезпечують пересилання інформації за межі мережевих екранів і дають можливість автоматизувати бізнес-процеси в рамках “розширених організацій”, до яких входять постачальники, партнери, споживачі товарів і послуг;

• технології управління бізнес-процесами (Business Process Management, BPM) інтегрують дані, додатки й системи через єдині бізнес-процеси.

Технології інтеграції корпоративних додатків і міжвідомчої інтеграції базуються на використанні брокера повідомлень (вузла пересилки, шлюза), технологічним фундаментом якого є програмне забезпечення проміжного прошарку пересилання повідомлень (Messaging-Oriented Middleware, MOM).

Одним з головних компонентів інтеграційної взаємодії є урядовий шлюз, архітектура якого показана на Рис. 2.6. До архітектури урядового шлюзу належать:

• веб-вузли і портали окремих відомств;

• аутентифікація і реєстрація користувачів;

• контроль трансакцій і маршрутизація документів;

• інтеграція та застосування правил на основі протоколу SOAP і стандарту UDDI;

• сервери інтеграції відомства.

Основні функції урядового шлюзу [6]:

• швидке розгортання електронних послуг. Наприклад, модифікація вже існуючих систем міністерств і відомств, спрямована на розширення їх можливостей для масового надання послуг;

• гнучкий зв’язок між клієнтською і серверною частинами, який дозволяє їх незалежний розвиток;

• усунення дублювання технічних засобів і послуг, необхідних для забезпечення взаємодії окремих державних установ з громадянами через Інтернет;

• створення бази для надання інтегрованих послуг через централізацію послуг аутентифікації та організацію взаємодії з широким колом державних структур;

• стимулювання розробки власних додатків приватних компаній і державних установ, які взаємодіють з інформаційними системами центральних органів влади на стандартній основі.

Модель урядового шлюзу містить такі компоненти:

• об’єднані послуги аутентифікації й авторизації для державних органів (дають можливість працювати з інформаційними системами відповідних організацій через Інтернет у захищеному режимі на основі використання єдиного набору сертифікатів з будь-якого пристрою будь-коли і будь-де);

• простий засіб створення веб-форм для подання документів (шлюз надає розробникам програмного забезпечення єдині механізми для передачі даних до урядового порталу);

• умови для міжвідомчої взаємодії і комунікацій (фактично він працює як брокер повідомлень, який маршрутизує документи їх отримувачам, водночас перетворюючи їх у формат систем-приймачів);

• єдиний механізм правил, реалізований як веб-служби, що надає доступні всім інформаційним системам правила обробки документів; перевіряє правильність полів, відповідність документів схемам і бізнес-правилам;

• основа для надання послуг, тобто шлюз надає всім сторонам, які подають інформацію та надають послуги, відповідний інтерфейс, що дає змогу будь-яким суб’ єктам один раз ввести інформацію, щоб вона була доступна певним користувачам (наприклад, при створенні нового підприємства лише раз заповнюється форма подання, а інформація з неї буде доступна органам державної реєстрації, податковим службам, фондам);

• гнучка архітектура з можливістю подальшого розвитку, вдосконалення та модернізації клієнтських і серверних систем, підключення нових державних структур;

• реалізація єдиної структури для створення послуг, керування ними та їх інформаційно-програмного супроводу; спільна інформаційна база для всіх користувачів.

Можна визначити такі основні принципи проектування урядового шлюзу: максимальне використання стандартних комерційних програмних продуктів; покомпонентна розробка, що включає локалізацію функціональних можливостей у незалежних послугах із стандартними інтерфейсами між ними; опора на промислові стандарти; мережеві протоколи ТСР/ІР, НТТР; інтерфейси (Com+, XML, SOAP); СУБД (SQL Server, ADO, OLEDB i ODBC для доступу до даних); засоби розробки (C#, Visual Basic, Visual C++, ATL, Transact SQL); висока продуктивність; масштабованість; надійність; гнучкість і розвиток; підтримка багатьох мов (зберігання стандартних елементів інтерфейсу у спеціальних базах даних).

До технічних елементів архітектури урядового шлюзу належать веб-вузли й портали, аутентифікація та реєстрація, трансакції, сервери інтеграції відомства. На Рис. 2.9 показано логічну структуру урядового порталу [6].

Веб-вузли і портали слугують систематизованими сховищами веб-форм, які використовуються громадянами і компаніями для надання інформації державним органам. Портали надають структуру для всіх форм документів, містять служби реєстрації й аутентифікації. Підсистема роботи з формами використовує локальне програмне забезпечення проміжного прошарку. Також використовуються веб-служби, які містять загальнодоступні правила реалізації бізнес-логіки для окремих форм. Дані, що вводить користувач, зберігаються в базі даних порталу, і після заповнення форми використовуються для побудови XML-документа, який пересилається у шлюз. Всі етапи виконання трансакцій, пов’язані з відправленням (збереженням) документа, відслідковуються в базі даних порталу.

Служба форм працює з електронними версіями існуючих паперових бланків, які відповідають “життєвим епізодам”, коли кілька державних відомств повинні отримати інформацію про дії громадянина. Технічно ці форми можуть бути представлені як ASP-сторінки або ASP.NET-сторінки, які реалізують логіку за допомогою компонентів проміжного прошарку на основі COM+ або NET-служб. При використанні веб-служб для окремих форм проміжний прошарок перенаправляє туди запити, що формує певний рівень абстракції і гнучкість. Після заповнення форми користувач надсилає дані у шлюз.

Рисунок 2.9. Логічна структура урядового порталу.

Дії, які виконує система, залежать від способу реєстрації користувача: використовує він ім’я і пароль чи сертифікат. Якщо користувач при реєстрації використовує ім’я і пароль, то після передачі ним даних компонент бізнес-служби (логіки) на сервері конструює XML-документ, що відповідає опублікованій схемі. Так, заголовок документа включає заповнені поля імені і пароля користувача. Після цього XML-документ через HTTPS-з’єднання передається на приймаючу ASP-сторінку шлюзу, де компонент авторизації і реєстрації перевіряє права та відповідним чином маршрутизує документ. Якщо користувач при реєстрації використовує сертифікат, після передачі ним даних компонент бізнес-служби (логіки) на сервері теж конструює XML-документ, який відповідає опублікованій схемі. Однак у даному разі документ пересилається назад веб-оглядачу, де клієнт підключає сертифікат (ключ) до специфічних секцій документа і відсилає його знову на сервер. Після цього сервер через HTTPS-з’єднання пересилає документ на шлюз, який за допомогою відкритого (відправленого разом з документом) ключа, отриманого від авторизованого сертифікаційного центру, перевірить сертифікат і відповідним чином маршрутизує документ [4, 6].

Механізм правил інтеграції надає порталу і серверам відомства загальний механізм для перевірки документа в цілому або окремих його полів. Поширення протоколу SOAP і можливість реалізації SOAP в Microsoft Visual Studio надає можливості перевірки форм по Інтернету, через що державні клієнтські і серверні системи можуть використовувати загальний набір служб, забезпечуючи таким чином високий рівень відповідності і гарантію того, що документ, відісланий через веб-вузол, буде прийнятий відомством, для якого він призначений. Це також означає, що після зміни будь-якого бізнес-правила, реалізованого як веб-служба, воно одразу стає доступним для всіх систем і використовується ними однаково. Інтерфейс веб-служб реалізується на основі протоколу SOAP.

Брокер повідомлень і аутентифікації містить дві підсистеми: реєстрація і авторизація; механізм трансакцій.

Підсистема реєстрації і авторизації обслуговує користувачів, які передплатили послугу, та виконує функцію аутентифікації. Механізм трансакцій використовує цю підсистему для аутентифікації ухвалених документів, а також управляє надійною маршрутизацією документів до відповідних серверних систем. Підсистема реєстрації й авторизації керує процесом реєстрації документів у шлюзі, перевіркою введеної інформації на основі даних, представлених серверними системами, передплатою послуг і поточним управлінням даними про реєстрацію та передплату послуг.

Механізм трансакцій є головною точкою входу для трансакцій, які виконують різні державні структури. Ці трансакції можуть бути підготовані клієнтами при взаємодії веб-оглядача з відомчими чи іншими веб-вузлами або за допомогою програмних додатків на клієнтських машинах. У будь-якому разі підготована трансакція може бути доповнена цифровим підписом і відправлена на урядовий шлюз по Інтернету у вигляді відформатованого XML-документа, що пересилається HTTP.

Після цього механізм трансакцій перевіряє цілісність отриманого запиту, викликає службу реєстрації і авторизації для перевірки використаних сертифікатів і підтвердження того, що клієнт має право на запитувану трансакцію. Потім трансакція надсилається на обробку відповідній серверній системі. Повідомлення відправляється на сервер інтеграції відомства в Інтернет-мережі, яка не підтримує автоматично механізм гарантованої доставки. Відповідно механізм трансакцій може використовувати систему гарантованої доставки повідомлень, яку надає сервер BizTalk Server.

Сервер-відправник BizTalk Server пересилає документ на сервер інтеграції установи і зберігає його копію на випадок повторної пересилки. BizTalk Server на стороні сервера інтеграції відомства, що приймає, при отриманні повідомлення через посилання URL всередині документа надсилає підтвердження на BizTalk Server, який відіслав повідомлення. При цьому сервер, який відправив повідомлення, усуває його з черги можливого повторного відправлення. У разі, якщо відправник BizTalk Server не отримав підтвердження, він повторно відправляє повідомлення доти, доки його не буде прийнято або доки не вичерпається ліміт кількості спроб. У такому випадку повідомлення буде розміщено в черзі проблемних повідомлень для відповідної обробки механізмом трансакцій.

Сервери інтеграції відомства забезпечують з’єднання і двосторонні комунікації між урядовим шлюзом і системами окремих відомств [4, 6]. При цьому зменшується кількість серверних систем, з якими брокер повідомлень урядового шлюзу повинен зв’язуватися напряму. Він взаємодіє з окремими відомствами на рівні серверів інтеграції, які забезпечують інтеграцію з різними прикладними серверними системами конкретного відомства. Сервер інтеграції відомства отримує документ на свою ASP-сторінку від механізму трансакцій через систему гарантованої доставки повідомлень BizTalk Server. Далі він пересилає документ без змін відповідній прикладній системі, використовуючи стандартний компонент інтеграції додатків BizTalk Server.

Основна складність реалізації проектів у сфері електронного уряду та міжвідомчих проектів полягає в організації процесу прийняття відповідних стандартів і узгодження архітектур інформаційних технологій різних організацій і відомств. Проекти електронного уряду передбачають такі типи стандартів: даних, міжвідомчого обміну інформацією, метаданих і пошуку інформації, безпеки. Зазначені стандарти постійно оновлюються і вдосконалюються країнами, які в архітектурі електронного уряду мають аналог урядового шлюзу.