Описание на софтуерната архитектурата на електронното управление с цел свързване на регистри.

1. Архитектура на
електронното управление
Божидар Божанов

2. Vanity slide
• Все още програмист
• http://blog.bozho.net
• http://techblog.bozho.net
• http://twitter.com/bozhobg
• съветник за електронно управление на
вицепремиера Р.Бъчварова

3. Електронно управление
Имаме електронно управление, когато
държавата не занимава гражданите с
глупости

4. Сложна задача?
• 20% техническа
• 20% правна
• 60% организационна

5. Първични регистри
• Регистър = база данни
• Първичен - източник на истина за
дадени обстоятелства
• ЕСГРАОН, БДС, Търговски регистър,
Булстат, регистър КАТ, Имотен
регистър, Кадастър.

6. Свързване на регистри
• задачаТА
• Правно - вече е регламентирано
• Технически - има 2 незаработили
реализации
• Организационно - причината за
неработещите реализации

7. Еднократно събиране
• 2 закона (ЗЕУ, АПК) забраняват на
администрацията да събира данни,
които вече има
• Автоматизирано събиране от
първичните регистри

9. Как?
• Децентрализирана архитектура
• или разпределена?
• Адресиране на правните пречки
• “Това не се отнася за нас”
• “Ние си имаме специален закон”
• Споразумения!
• Организациони пречки: морков и тояга

10. Изисквания
• Много участващи организации
• вкл. от частния сектор
• Защита на личните данни
• 100% отчетност на достъпа
• Сигурна идентификация на системите
• PKI, HSM
• Синхронни, асинхронни и subscribe заявки
• Управление на промените

11. Microservices?
• Сходно
• … но не са micro
• .... и не са в рамките на една
организация

12. История
• “Ведомствените ИС ще си “говорят”,
най-после” (TechNews, юни 2006-та)
• 1-ви опит: ЕСОЕД
• неуспешен
• 2-ри опит: RegiX
• засега не се ползва
• Рамка за оперативна съвместимост
• a.k.a WSDL

13. Meanwhile in Estonia...
• X-Road функционира от 2001-ва
• Свързани регистри: 200+
• Институции: 900+
• Транзакции: 600 милиона / година
• Спестени човекочасове годишно: 47
милиона

14. Технологичните минуси не са причината за
неуспеха

15. Фундаментален въпрос
Документи, данни или услуги?

16. • “Електронен документ”
• Wrapper на данни?
• Вътрешна услуга за предоставяне на
документи/данни
• Основно разграничение:
• Документооборот с/у обмен на данни

17. Архитектурен въпрос
ESB или P2P?

18. Източник: МТИТС

19. ЕСОЕД
• ESB/Message Queue
• Работи изцяло с електронни документи
• Проверява и рутира заявки
• Сложна интеграция
• липса на достъпни библиотеки
• Съвет по вписванията
• VPN?

20. Източник: МТИТС

21. ЕСОЕД - как?
• Вписване на всички схеми в регистър
(ръчно)
• SOAP заявка с destinationURI
• Асинхронен отговор
• Криптиране, подписване

22. RegiX
• ESB (sort of)
• Адаптира legacy регистри като им
expose-ва уеб-услуги
• Централен компонент рутира заявките
• Нужно е надграждане на централния
компонент за всеки нов регистър
• Не поддържа Subscribe

23. RegiX + ESB
• ESB в допълнение на RegiX
• Автентикация на информационни
системи
• В допълнение с вграденото в RegiX
• Проверка на достъпа в регистър на
достъпа
• В допълнение на вградената в RegiX
• ...

24. Източник:
презентац
ия на BulSI
за МТИТС

25. RegiX - как?
• SOAP заявка към централния сървър
• с идентификатор на услуга
• с данни за заявителя
• Централният сървър препраща на адаптера.
• Проверява достъпа
• Записва събитието (но без данните)
• Адаптерът “бърка” в базата и връща отговор

26. NoESB
• ESB-тата са single point of failure
• Колкото и да ги “резервираме”
• Магическите им способности са само на
книга
• Добрите интерфейси и управление на
версиите отменят нуждата от ESB*

27. X-Road
• p2p
• Security server (proxy) + adapter server -
интеграционни компоненти
• Security server вместо централизирано
ESB

28. X-Road

29. X-Road - как?
• Комуникация: само със security server
• Security server-ът се грижи за logging и
автентикация
• Security server-ът е proxy
• Локален кеш
• Load balancing

30. X-Road protocol
• Стандартен протокол за adapter server
• SOAP
• Списък с налични услуги и техните дефиниции
• Версии
• Всеки adapter server се вписва в регистър,
който автоматично извлича метаданни
• Адаптерите са силно интегрирани с ИС
• поддържат subscribe

31. UK: Registers
• Един софтуер за всички регистри
• Multi-tenant deployment
• RESTful интеграция

32. Security server?
• Допълнителните сървъри усложняват
инфраструктурата
• Вместо отделни сървъри - стандартни
компоненти
• Цена
• Вместо сертифициран security server -
координатор на транзакции

34. Данни, освен услуги
• Гранулярност: данни
• Стандартен протокол за автоматично
поддържане на описания на данните
• Заявка: тип/версия/идентификатор

36. Разпределена архитектура?
• Съхраняване на данните в blockchain
• Криптирани
• ...с личния частен ключ на гражданите
• ...и с ключа на институцията (ако човек загуби
своя)
• Естония: здравни записи

37. Privacy
• Контрол на достъпа
• Лог (журнал на събитията)
• Достъп за граждани
• + известия за четене на данни
• Правни последици за нерегламентиран
достъп

38. So...
• Стандартен протокол
• Стандартни SDK-и и компоненти
• Имплементиращи протокола
• Централни регистри с метаинформация
• Контрол на достъпа, типове данни, регистри
• Лог/журнал на достъпа
• Достъпна документация и sandbox

39. KISS
• С минимален брой компоненти
• С минимална човешка намеса
• Сложността убива

40. Сложна задача?
• Не
• Архитектурата (може да) е проста
• Организационният и човешкият фактор
са сложни

41. Благодаря!