 |
|
 |
|  |
В настоящее время основной проблемой информатизации государственных органов как в Казахстане и странах СНГ, так и в высокоразвитых странах мира является слабое взаимодействие различных ведомственных систем и баз данных. При такой "лоскутной" информатизации каждое ведомство ограждается барьерами от внешнего мира, не позволяя использовать накопленные данные и наработки, необходимые другим ведомствам, в результате чего создаются многочисленные системы, дублирующие функции других систем, порой содержащие данные об одних и тех же объектах и субъектах но в различных форматах, что приводит к еще большему хаосу. Новейшие достижения в ИТ-технологиях сегодня позволяют интегрировать разнородные информационные системы без необходимости вносить существенные изменения в работающие модули. Данная концепция основана на том, что любая ведомственная система является пунктом приема, хранения и обработки информации об объектах и субъектах внешнего мира, решающая в оперативном режиме свои ведомственные задачи. При решении этих задач создаются новые знания, новая (вторичная) информация. Часть этих знаний – вторичной и первичной информации - может быть использована другими системами, принадлежащих другим ведомствам, для решения других задач. В свою очередь, новая информация в этих системах может быть необходима для первой системы, и т.д. Таким образом, "интегрированное правительство" позволяет рассматривать совокупность различных информационных систем государственных органов как единую систему – "виртуальный компьютер", где каждая система может иметь авторизованный доступ к "разрешенным" данным другой системы и в свою очередь быть доступна для других систем. Ярким примером интеграционного взаимодействия ведомственных систем является разработанная в НК МФ РК система РНиОН (государственный реестр налогоплательщиков и объектов налогообложения) (разработчик – фирма Бимаш). Аналогов такой системы в странах СНГ нет. РНиОН может являться основой и примером для дальнейшей интеграции информационных систем правительства Казахстана. Этот документ описывает среду взаимодействия (СВ) государственных органов для предоставления услуг гражданам и представителям бизнеса. Так же предлагается механизм интеграции ранее разработанных приложений. Механизм основан на модели Enterprise Service Bus (ESB) и технологии Вэб-сервисов (WS). 1. Введение Многие государства мира разрабатывают концепции Электронного Правительства. Основной целью является предоставление более качественного сервиса гражданам. Основной задачей улучшения качества сервиса с использованием новых технологий является совместное использование информации и функций различных информационных систем в регионах и в центре. В связи со сложностью информационных систем министерств и ведомств предполагается их дальнейшее использование, нежели переработка, что является затратным. Для достижения этих целей правительства разрабатывают проекты по взаимодействию систем. Основой для совместного использования ресурсов является единая доступная среда передачи данных. Работы по ее созданию планируется завершить только к 2007 году. 2. Background Основная задача СВ является интеграция уже имеющихся приложений. Интеграция существующих приложений всегда была длительным и затратным процессом, поэтому все больше внимания уделялось концепциям Сервис Ориентированной Архитектуры и Event Driven Architecture. Эти две модели позволяют проводить интеграцию на уровне процессов путем автоматического взаимодействия различных компонентов разнородных систем, вместо простого обмена данными. В настоящее время правительства рассматривают решения основанные на SOA для решения проблем интеграции согласно концепции электронного правительства, новым технологиям и рынку. Правительственные организации, которые стремятся к работе в реальном времени без задержек должны использовать event-driven architecture, message-oriented middleware и publish-subscribe communication. Использование event-driven architecture позволяет синхронизировать данные без пакетной обработки и утомительного ручного ввода. EDA and SOA архитектуры совместимые, но разные концепции, каждая со своими плюсами и минусами. Один из основных вопросов – это поиск более эффективных способов проектирования, разработки и внедрения систем основанных на вэб-сервисах; более того, переход от взаимодействия один-к-одному к более широкому применению этих технологий. Важно расширить видение вэб-сервисов и сервис ориентированной архитектуры моделью Enterprise Service Bus, которая обеспечивает интеграцию основанную на стандартах с использованием событийно ориентированной архитектуры. Service Oriented Architecture - SOA - Сервис ориентированная архитектура Сервис ориентированная архитектура основана на нотации сервисов – независимых, но взаимодействующих строительных блоках для построения распределенных приложений. Модель SOA скрывает особенности реализации приложения, таким образом ограничивая количество изменений. Управление изменениями – это одно из важнейших преимуществ компонентных архитектур и моделей. На сегодняшний день существует много техник взаимодействия, но все они обособлены, без ярко выраженной архитектуры. Движение в сторону сервис ориентированного подхода не только стандартизирует взаимодействия, но так же придает больше гибкости процессу. Вся цепь событий в отдельно взятой организации разбита на отдельные небольшие функциональные модули, или сервисы. Сервис ориентированная архитектура определяет описание и организацию сервисов для поддержания их нахождения и использования. На сегодняшний день для реализации решений основанных на SOA наиболее подходит технология вэб-сервисов (Web Service). Event Driven Architecrute - EDA - Архитектура основанная на событиях EDA – это подход к проектированию и разработке приложений в котором каждое приложение отвечает на входящие асинхронные сообщения, которые представляют бизнес-данные и бизнес-события. Источник события посылает сообщение посреднику, посредник определяет кому, какой программе, следует направить данное сообщение. EDA приложения больше подходят для случаев, при которых одно сообщение должно быть доставлено нескольким пользователям. Все о чем необходимо договориться – это формат сообщения. Сообщения обычно посылаются по принципу опубликация-и-подписка, т.к. он позволяет доставлять сообщения до нескольких адресатов. Enterprise Service Bus - ESB - Корпоративная сервисная шина Созданная для того, чтобы снизить стоимость и сложность развертывания распределенных приложений уровня предприятия, ESB - новый тип программного обеспечения среднего уровня, которое обеспечивает стандартные интерфейсы для взаимодействия, трансформации, переносимости и безопасности. Она создает шину сообщений, которая включает в себя инфраструктуру передачи сообщений с трансформацией сообщений и маршрутизацию основанную на содержании сообщения на уровне интеграционной логики между потребителями и провайдерами сервиса. Основная цель ESB - это виртуализация бизнес ресурсов, которая позволит разрабатывать и управлять бизнес-логикой независимо от инфраструктуры, сети и планирование этих бизнес сервисов. ESB основана на открытых стандартах, что снижает стоимость приобретения и реализации. Организациям больше не надо поддерживать большое количество разрозненных продуктов. ЕТС - Единая Транспортная Среда ЗАО НИТ, 2007 год. 3. Среда взаимодействия правительственных учреждений В этом документе рассказывается о среде взаимодействия основанной на сети кооперативных информационных систем называемых eG-Domain. eG-Domain представляет все вычислительные ресурсы, сети, приложения и данные, которые принадлежат отдельно взятому государственному органу. Управление взаимодействием в этой сети осуществляет eG-Bus. Каждый eG-Domain подключен к eG-Bus через шлюз eG-Gate, как показано на рис. 1.  eG-Bus eG-Domain Для eG-Domain основными взаимодействиями являются запрос/предоставление сервиса и опубликование/обработка события чтобы обеспечить сервисы жизненного цикла как процесс исполнения одного и более Domain services.  Intra Domain сервисы представляют все ресурсы присутствующие в госучреждении: базы данных, приложения, порталы и воркфлоу. Extra Domain сервисы предоставляются удаленными госучреждениями через eG-Bus или самой eG-Bus. eG-Bus предоставляет базовые сервисы взаимодействия, такие как FTP и электронная почта, а так же DNS, адресация и сервис синхронизации времени. Для реализации интеграции ресурсов различных госорганов архитектура eG-Bus основана на модели ESB. Основные компоненты этой модели: eG-DomainBus eG-DomainBus – это высокоскоростная среда передачи, которая предоставляет базовые сервисы, такие как интеллектуальная маршрутизация, управление процессом, трансформация, слежение, аудит и журналирование. Она использует архитектуру и технологии такие же как в eG-Bus, но отличается в одном – реализует интеграцию внутренних сервисов. eG-Gate eG-Gate представляет собой единую точку доступа с внешними системами. Он может предоставлять и запрашивать сервисы и отправлять и принимать сообщения. eG-ServiceDB Этот сервис позволяет получать доступ к базам данных через WSDL интерфейс (Web Service). eG-ServiceApplication Этот тип eG-Service (сервиса) позволяет предоставлять функциональность информационных систем госоргана обычно состоящих из разнородных приложений, таких как: Реестры, регистрация налогоплательщиков и т.п. eG-ServicePortal Задача eG-ServicePortal предоставлять услуги гражданам и юр.лицам. eG-ServiceWorkflow eG-ServiceWorkflow позволяет автоматизировать бизнес-процессы в госучреждении. 4. Применение модели с учетом имеющегося опыта На сегодняшний день создано много обособленных информационных систем в различных министерствах и ведомствах. На данном этапе встает вопрос интеграции систем для совместного использования информации и более оперативной работы. В связи с тем, что отсутствуют государственные стандарты на принципы интеграции выбор того или иного метода интеграции остается за разработчиком системы. Это приводит к тому, что у различных систем разрабатываются разные интерфейсы взаимодействия. А это, в свою очередь, сказывается негативно на организации взаимодействия т.к. для интеграции с определенной системой необходимо реализовать интерфейс взаимодействия именно с этой конкретной системой. Это приводит к хаосу и только тормозит процесс интеграции. Рис 3. К примеру, для передачи извещений о регистрации юридических лиц по принципу "в одно окно" используются XML-документы. Передача документов из МЮ в АС происходит через SMTP-интерфейс, в то время как передача из АС в НК производится с использованием СГДС. Таким образом в ИС АС для взаимодействия с двумя ИС необходимо использовать два различных интерфейса взаимодействия. С увеличением числа систем с которыми необходимо провести интеграцию количество интерфейсов только возрастает, что еще больше затрудняет интеграцию.  Для решения этой проблемы лучше всего подходит предложенная модель интеграции, при которой используется единый стандартный интерфейс и единая точка соединения систем через сервисную шину Рис.4.  Такой подход позволяет не только гибко управлять существующими соединениями между системами, но и быстро и эффективно организовывать новые связи. 5. Заключение Основа того, что среда взаимодействия способна предоставлять для граждан сервисы построенные вокруг событий их жизни – это процесс исполнения операций в eG-Domain-ах. Для достижения этой цели среда основана на 2х ESB. П ервая для взаимодействия между госучреждениями, вторая – интеграция сервисов внутри самого госучреждения. Кроме того, основываясь на открытых и распространенных стандартах, предполагаемая Среда позволяет интегрировать правительство с другими индустриями и служит основой для снижения стоимости и рисков связанных с большинством ИТ проектов. Приложение I. Общие сведения о WEB-Сервисах Для осуществления взаимодействия систем наиболее подходящей технологией, как показывает мировой опыт, является Web Services. Основой данной технологии являются стандарты всемирной сети Интернет, а именно системы World Wide Web. Система WWW на практике доказала свою платформонезависимую сущность, распространившись на все существующие платформы, предоставляя различную информацию пользователям практически любых устройств. Залогом успеха данной технологии является то, что основой представления информации является язык текстовой разметки HTML и средством передачи информации является протокол HTTP, работающий на основе транспортного протокола TCP/IP. Технология WWW была спроектирована с расчетом на то, что основным потребителем информации будет человек, интерактивно взаимодействующий с Web сервером при помощи Web браузера (в независимости от используемой платформы). Во время бурного развития и использования WWW появилась идея о том, что потребителем инфомации может быть не только человек, что благодаря принципам открытости и платформонезависимости на данной технологии возможно организовать эффективное взаимодействие гетерогенных информационных систем. Но для организации автоматического взаимодействия разнородных систем возможностей WWW недостаточно, необходимо доработать технологию WWW в соответствии с требованиями по взаимодействию сложных систем по надежности и безопасности. Так родилась технология Web Services (далее WS). В основу WS легли такие технологии как XML – расширяемый язык разметки, пришедший на смену HTML; SOAP – высокоуровневый протокол доступа к объектам, использующий язык XML, что делает его независимым от используемого языка программирования; зарекомендовавший себя протокол HTTP для передачи текстовых данных и транспортный протокол TCP/IP; а так же WSDL и UDDI, о которых чуть позже. Основным понятием является сервис. Любая программная система (А) может предоставить сервис посредством протокола SOAP использующим XML для представления информации и HTTP и TCP/IP для передачи информации. Любая другая программная система (Б) может воспользоваться данным сервисом. Но для того, чтобы система Б могла воспользоваться сервисом предоставляемым системой А, системе Б необходимо знать детальное описание сервиса предоставляемого системой А, как им воспользоваться. На помощь приходит WSDL (Web Services Description Language) – язык описания вэб сервиса. Данный язык, в основе которого лежит XML предоставляет подробное описание сервиса для того, чтобы разработчики системы Б могли без труда воспользоваться сервисом А при разработке системы Б. При такой простом подходе к организации взаимодействия, когда каждая система может предоставлять неограниченное количество сервисов (доступ к различного рода информации) количество предоставляемых сервисов стремительно растет и чтобы не потеряться во всем многообразии разнообразных сервисов предоставляемыми различными системами был разработан UDDI (Universal Discovery and Description Interface)– универсальный интерфейс поиска и описания. UDDI – это реестр вэб сервисов. После того, как в системе А реализован вэб сервис, для того, чтобы разработчики системы Б, а так же сотен и тысяч других систем могли найти именно тот сервис, именно ту информацию которая им необходимо - сервис системы А необходимо зарегистрировать в реестре вэб сервисов. После того, как разработчики системы Б сделав поиск по реестру сервисов UDDI нашли сервис предоставляемый системой А, получили подробное описание сервиса WSDL они могут реализовать потребление данного сервиса без участия разработчиков системы А, т.к. они имеют всю необходимую информацию о сервисе, что несомненно положительно сказывается на процессе разработки. Но для реального использования сервисом системы А разработчики системы Б должны получить доступ к сервису А. Для решения вопросов безопасности создана комиссия WS-S. Так же существуют комиссии WS-I (interoperability) для решения проблем взаимодействия. Ориентированность на сервисы является основой для SOA – сервис-ориентированной архитектуры. научный консультант проекта Е.Р. Сулейменов, к.ф.-м.н. |
|
||||||||||||
|
|||||||||||||
