CC BY
63
УДК 004.428.4
Ю.Б. Гриценко, О.И. Жуковский, И.В. Лазарев, М.М. Милихин, П.В. Сенченко
Интерфейс взаимодействия геоинформационной технологии ведения электронного генерального плана со сторонними программными системами
Рассмотрены возможности интеграции программного обеспечения информационной технологии ведения электронного генерального плана инженерной инфраструктуры со смежными информационными системами. Описаны методы кроссдоменного взаимодействия. Рассмотрен вариант использования интерфейса API для интеграции приложений.
Ключевые слова: геоинформационные системы, электронный генеральный план, интеграция информационных систем, API, документооборот.
Геоинформационная система ведения электронного генерального плана промышленного предприятия (ГИС ЭГП) представляет собой единую корпоративную информационную систему обработки геоданных пространственных и атрибутивных описаний объектов предприятия. Являясь распределенным Web-ориентированным программным продуктом, данная система нуждается в прикладном интерфейсе (API), служащем для ее интеграции с другими программными системами, использующимися на предприятии. Примером приложения, которому необходим такой интерфейс, может служить система электронного документооборота (СЭД) предприятия, для которой в результате интеграции с ГИС становятся возможными формирование и учет специфичных документов, необходимых для работы с генеральным планом.
Другим способом взаимодействия между системами является обмен данными посредством файлов установленного формата. Потребность в таком способе возникает в том случае, когда стороннему программному продукту требуются только данные, которыми оперирует ГИС (без необходимости интеграции пользовательского интерфейса приложений), например, предоставление атрибутивных описаний объектов генерального плана, необходимых для выполнения функций анализа и восстановления данных. В настоящей статье рассмотрены основные этапы реализации интерфейса взаимодействия ГИС ЭГП со сторонними программными продуктами.
Программный интерфейс взаимодействия web-ориентированной геоинформационной системы со сторонними программными продуктами. Одним из требований к ГИС ЭГП является масштабируемость системы, в соответствии с которым ГИС состоит из отдельных независимых друг от друга программных модулей, отвечающих за выполнение определенных функциональных возможностей системы. Первоочередной задачей, возникающей при разработке внешнего API системы, является разработка модели взаимодействия, которая обеспечила бы возможность вызова упрощенной версии ГИС ЭГП в качестве виджета (элемента графического пользовательского интерфейса) стороннего приложения.
Трудность интеграции Web-ориентированных систем, клиентской частью которых выступает Web-браузер, определяется необходимостью организации кроссдоменного взаимодействия между такими системами.
Разрабатываемая ГИС ЭГП предполагает возможность установки и эксплуатации в сетях, управление которыми осуществляется на основе службы каталогов Active Directory корпорации Microsoft. Active Directory имеет иерархическую структуру, состоящую из объектов (ресурсов, служб и учетных записей пользователей и групп пользователей). Совокупность таких объектов формирует лес - верхний уровень организации инфраструктуры сети промышленного предприятия. Лес содержит одно или несколько деревьев, связанных отношениями доверия. Деревья, в свою очередь, включают в себя один или несколько доменов, которые идентифицируются своими пространствами имен DNS (Domain Name Service).
В соответствии с данной структурой сети предприятия различные Web-приложения могут функционировать в различных доменах. При этом возможности взаимодействия меду такими системами определяются правилами ограничения домена (Same Origin Policy). Такие правила реализо-
ваны во всех современных Web-браузерах и не имеют определенного стандарта [1]. Основной целью их использования является ограничение доступа к функциям управления содержимым web-страниц и Web-приложений внутри домена со стороны недоверенных сайтов.
Таким образом, выбор модели взаимодействия определяется поддержкой правил ограничения домена всех современных Web-браузеров и обеспечением достаточного уровня безопасности такого взаимодействия.
Методы кроссдоменного взаимодействия. Существует несколько основных способов реализации кроссдоменного взаимодействия:
1. Использование технологии JSONP (Java Script Object Notation with Padding). В отличие от формата JSON, служащего для передачи данных в виде пар «ключ: значение» (объекта вида {ключ: значение, ключ2: значение2, ...}), данная технология предполагает возможность выполнения GET-запросов на основе использования HTML-тега (элемента разметки страницы HyperText Markup Language) <script>, выполняющего загрузку приложения на языке JavaScript и позволяющего передать в качестве параметра запроса имя функции, которую необходимо выполнить для обработки данных [2]. Одним из основных недостатков данной технологии является подверженность сайтов, использующих JSONP, подделке межсайтовых запросов со стороны вредоносных web-страниц, вследствие чего внедрение JSONP зачастую рассматривается как небезопасный способ кроссдомен-ного взаимодействия [3]. Кроме того, JSONP не позволяет передавать данные с использованием POST-запросов.
2. Использование технологии предоставления доступа к ресурсам CORS (Cross-origin resource sharing) [4]. Согласно данной технологии серверу интегрируемого Web-приложения необходимо указать список доверенных клиентских приложений с помощью параметра Access-Control-Allow-Origin (например, Access-Control-Allow-Origin: http://example.com http://another.example.com:8080). Использование данного метода более безопасно по сравнению с технологией JSONP и позволяет использовать обычные запросы XMLHttpRequest. Основным недостатком данного метода является отсутствие поддержки со стороны Web-браузеров Microsoft Internet Explorer 6 и 7 и лишь частичная поддержка в Internet Explorer 8.
3. Собственные методы управления кроссдоменными запросами для каждого Web-браузера. Основными недостатками способа является отсутствие поддержки со стороны браузеров Microsoft Internet Explorer, а также необходимость отдельной реализации API для каждого браузера, что значительно затрудняет процесс разработки и поддержания функционирования программного обеспечения.
4. Использование фреймов (HTML-тег <iframe>). Данный подход предполагает создание на странице родительского приложения окна iframe, которое может обслуживать GET-запросы посредством смены его URL-адреса или POST-запросы посредством установки свойства form.target формы с данными в соответствии с идентификатором окна iframe.
5. Использование функции PostMessage. Данный механизм доступен как часть стандарта HTML5 [3] и поддерживается всеми совместимыми с данным стандартом браузерами. Основным недостатком способа является отсутствие поддержки со стороны браузеров Microsoft Internet Explorer.
Создание интерфейса API. На основании представленного выше обзора возможных решений в качестве основного метода взаимодействия был выбран метод использования функции PostMessage стандарта HTML5. Такой подход не требует отдельной реализации для различных браузеров и является стандартом, рекомендованным консорциумом W3C (World Wide Web Consortium) [3]. В качестве альтернативы для клиентских приложений, не поддерживающих стандарт HTML5, возможно использование одного из трех методов:
- обмен данными с использованием технологий Adobe Flash;
- обмен данными с использованием специальных HTML-файлов на клиентской и серверной сторонах;
- обмен данными с использованием hash-части строки URL элемента iframe.
Такой подход позволяет достичь поддержки программного интерфейса всеми современными Web-браузерами, выбирая оптимальный вариант взаимодействия для каждого конкретного случая.
Основой взаимодействия служат объекты классов сокета (специальные объекты, инициализируемые на стороне клиентского и серверного приложений), предоставляемые библиотекой JavaScript инструментов EasyXDM [5]. Рассмотрим механизм взаимодействия более подробно (рис. 1).
Клиентское приложение
^Инициализация сокета^*
Web-ГИС-сервер ЭГП
[Авторизация не выполнена/Недостаточно прав]
^Загрузка виджета WGS3J
Ж.
Выполнение
пре-авторизации
[Авторизация выполнена]
^Инициализация сокета!
ІМГ
Гсоздание запросаЛ-
Выполнение запрошенной операции
[Иначе]
^Передача ответа^
V
______V
^Обработка ответа/)
[Сеанс завершен]
л
Ж
^Фильтрация запроса^
—V_____________
^Регистрация активности)
Рис. 1. Обобщенный алгоритм функционирования внешнего API ГИС ЭГП
Согласно представленному алгоритму соединение инициализируется внешней программной системой (клиентским приложением), которая создает сокет для установления соединения с ГИС ЭГП. Основным параметром сокета является адрес URL (Universal Resource Locator) программного обеспечения Web-ГИС-клиента ЭГП, которое будет использовано в качестве виджета. В качестве параметров GET-запроса данного адреса указываются имя и хэш-функция пароля учетной записи пользователя, которые необходимы для выполнения авторизации в системе, например:
http://gis/mapwidget?user={USER_NAME}&auth={SECRET_KEY}, где SECRET_KEY = md5({IP-адрес}.{USER_PASSWORD}).
Таким образом, обеспечивается безопасность передачи учетных данных пользователя по недоверенной сети.
После выполнения инициализации сокета на стороне внешней системы создается экземпляр облегченной версии клиентского Web-приложения ГИС ЭГП, реализующей обработку запросов через сокет. Выполняется подтверждение установки соединения, после чего возможно взаимодействие систем посредством передачи сообщений.
Обмен сообщениями. Разработанный программный интерфейс предполагает обработку двух основных видов запросов:
- запросы на выделение области территории генерального плана;
- запросы на выделение отдельных объектов генерального плана.
Каждый из данных типов запросов, в свою очередь, содержит запросы на получение и установку текущих параметров отображения картографического описания генплана.
Запрос представляется в виде сообщения фиксированной структуры. Такое сообщение является строкой в формате нотации JSON (строковым представлением объекта JavaScript).
Сообщение имеет следующий формат: {type: message_type, content: message_content}, где mes-sage_type - числовая константа, определяющая тип запроса, message_content - параметры запроса. Параметры запроса включают в себя контекст карты (список активных слоев, масштаб и центральную точку), а также данные, позволяющие идентифицировать выделенную область генплана или его отдельный объект. Система поддерживает четыре значения message_type:
1) получение выделенной области генерального плана и его текущего контекста;
2) установка выделенной области генерального плана и его текущего контекста;
3) получение идентификатора выделенного объекта и текущего контекста карты;
4) установка идентификатора выделенного объекта и текущего контекста карты.
Передача контекста карты. Контекст карты служит для однозначного определения видимой области территории генерального плана и списка активных слоев карты. Область территории однозначно определяется посредством указания координат центральной точки карты и ее масштаба. Для указания списка слоев используется циклический избыточный код 32-битных полиномов (crc32). Каждый слой идентифицируется контрольной суммой crc32 его основных характеристик (наименования, группы слоев, расположения в репозитории геоданных). Такой подход позволяет избежать зависимости функционирования API от текущих характеристик базы данных пространственных описаний и значений идентификаторов пространственных слоев, которые могут изменяться с течением времени.
Таким образом, контекст картографического объекта представляет собой строку следующего вида: <координата Х центра карты>,< координата Y центра карты > | <масштаб карты> | контрольная сумма активного слоя 1>,<контрольная сумма активного слоя 2>,...,<контрольная сумма активного слоя n>.
Дополнительно к перечисленным характеристикам контекст может также включать в себя описание выделенной области: «|<тип выделенной области>| <характеристика области 1>, Характеристика области 2>, ..., <характеристика области т>», где <тип выделенной области> может принимать два значения: «radius» - выделение окружностью и «polygon» - выделение полигональным объектом. Характеристиками выделенной области являются координаты по оси абсцисс, и ординат точки центра окружности и радиус для выделения окружностью и координаты вершин многоугольника для полигонального выделения.
Использование API ГИС ЭГП при интеграции со сторонними приложениями. В качестве примера использования API геоинформационной системы используем задачу разработки программного обеспечения организации документооборота электронного генерального плана промышленного предприятия.
В общем виде процесс организации документооборота включает в себя все действия по обработке входящей, исходящей и внутренней корреспонденции: прием и первичная обработка входящих документов, составление, согласование и утверждение проектов документов, формируемых внутри организации, формирование поручений и контроль их исполнения, отправка исходящих документов. Особенности процессов документооборота зависят от характеристик автоматизируемых бизнес-процессов. Так, при автоматизации процессов по управлению инженерной инфраструктурой предприятия СЭД должна решать следующие характерные для данной предметной области задачи:
- обеспечение регистрации всех типов документов, находящихся в общем потоке документооборота ЭГП;
- ведение электронного архива документов ЭГП;
- организация взаимодействия с другими профильными подсистемами программного комплекса ведения ЭГП;
- организация автоматизированного контроля исполнения документов;
- ведение технологии электронного взаимодействия между подразделениями организации (пользователями ЭГП);
- мониторинг документа - определение стадии, на которой находится рассмотрение того или иного документа;
- связь между документами различного уровня исполнения;
- хранение информации обо всех документах, обеспечив возможность доступа к любой стадии работы с документами;
- ведение системы отчетности по исполнению документов и исполнительской дисциплине сотрудников организации.
Решение обозначенных задач требует наличия информационной связи между объектами инженерной инфраструктуры предприятия и документами, циркулирующими в общем потоке документооборота. При этом можно выделить два вида связей: 1) связь документа с конкретным объектом генерального плана, при этом объект характеризуется уникальным идентификатором в системе ЭГП; 2) связь документа с некоторой пространственной областью генерального плана, которая характеризуется набором точек (полигоном). Для отражения данных связей в СЭД может быть использована дополнительная таблица базы данных со структурой:
Структура таблицы связи документов СЭД и пространственных данных ЭГП
PK* Название поля Тип данных Комментарий
+ ID NUMBER(10) Уникальный идентификатор связи
LinkType NUMBER(2) Код типа связи
DocumentID NUMBER(10) Уникальный идентификатор документа
GIS ObjectID NUMBER(10) Уникальный идентификатор объекта ЭГП
GIS Area BLOB Описание области генерального плана
GIS Context BLOB Контекст ЭГП
AddedAt DATE Время создания связи
Примечание. PK* - Primary Key (первичный ключ таблицы).
Необходимо отметить наличие информации о контексте электронной карты в приведенной структуре. Информация о контексте не является характеристикой связи между документом и объектом ЭГП, однако наличие данной информации обеспечивает однозначность определения видимой области генерального плана при отображении электронной карты. С точки зрения интерфейса пользователя системы электронного документооборота связь между документом и объектом генерального плана создается с использованием виджета ГИС ЭГП, демонстрация которого представлена на рис. 2.
Рис. 2. Привязка пространственных данных к документу в системе электронного документооборота
Для интеграции данного пользовательского элемента в интерфейс СЭД создан специальный класс ОБ08е1ее1;огСоПго1, который инкапсулирует в себе логику взаимодействия с АР1 ГИС ЭГП и отображение электронной карты в системе электронного документооборота.
В качестве примера связи пространственных данных и данных документационного обеспечения можно привести процесс получения выкопировки генерального плана. При регистрации заявки на выкопировку в СЭД пользователю необходимо указать информацию об участке территории для формирования выкопировки. Другим примером является добавление нового пространственного объекта на электронный генеральный план и регистрации в СЭД соответствующего документа-основания.
Заключение. Результатами проделанной работы являются разработанные в рамках проекта W4GIS модель взаимодействия и программный модуль для интеграции ГИС ведения электронного генерального плана в пользовательский интерфейс сторонних Web-приложений. Реализованная технология взаимодействия опирается на стандарты консорциума W3C и поддерживается всеми современными Web-браузерами.
Выполнение данной работы проводилось при финансовой поддержке Министерства образования и науки Российской Федерации в рамках мероприятия 2.4 федеральной целевой программы «Исследования и разработки по приоритетным направлениям развития научно-технологического комплекса России на 2007-2013 годы», проект «Разработка Web-ориентированных геоинформаци-онных технологий формирования и мониторинга электронного генерального плана инженерной инфраструктуры», государственный контракт № 07.524.11.4013 от 03 ноября 2011 г.
Литература
1. Same Origin Policy [Электронный ресурс]. - Режим доступа: http://www.w3.org/Security/ wiki/Same_Origin_Policy, свободный (дата обращения: 21.11.2012).
2. RIAspot JSON P for Cross Site XHR [Электронный ресурс]. - Режим доступа: http://www.ria-spot.com/blogs/entry/JSONP-for-Cross-Site-XHR, закрытый (дата обращения: 21.09.2012).
3. Json-p.org. The problem [Электронный ресурс]. - Режим доступа: http://json-p.org, свободный (дата обращения: 19.01.2013).
4. Cross-Origin Resource Sharing [Электронный ресурс]. - Режим доступа: http://www.w3.org/ TR/cors/, свободный (дата обращения: 18.01.2013).
5. EasyXDM. Home [Электронный ресурс]. - Режим доступа: http://easyxdm.net, свободный (дата обращения: 19.01.2013).
Гриценко Юрий Борисович
Канд. техн. наук, доцент каф. автоматизации обработки информации (АОИ) ТУСУРа
Тел.: 8(382-2) 90-01-80
Эл. почта: [email protected]
Жуковский Олег Игоревич
Канд. техн. наук, доцент каф. АОИ ТУСУРа
Тел.: 8(382-2) 90-01-80
Эл. почта: [email protected]
Лазарев Иван Васильевич
Мл. науч. сотрудник каф. АОИ ТУСУРа Тел.: +7-913-812-46-79 Эл. почта: [email protected]
Милихин Михаил Михайлович
Студент факультета систем управления ТУСУРа
Тел.: +7-952-807-90-51
Эл. почта: [email protected]
Сенченко Павел Васильевич
Канд. техн. наук, доцент каф. АОИ, декан факультета систем управления ТУСУРа Тел.: 8 (383-2) 70-15-46 Эл. почта: [email protected]
Gritsehko Yu.B., Zhukovskiy О.1., Lazarev I.V., Milikhin M.M., Senchenko P.V.
Interface between GIS technology of electronic master plan with other software systems
We investigate the possibilities of software integration of electronic information technology of a master plan for physical infrastructure with related information systems. The methods of cross domain interaction are described. We considered a variant using an API for application integration.
Keywords: geographic information systems, electronic master plan, integration of information systems, API, workflow.
