CC BY
24
СПИСОК ЛИТЕРАТУРЫ
1. Лачинов В.М., Поляков А.О. Информодина-мика. СПб.: Изд-во СПбГТУ. 1999.
2. Кузнецов H.A., I lo ioiiiiHKOB Р.И., Юсупов P.M.
Состояние, перспективы и проблемы развития информатики // Теоретические основы и прикладные
задачи интеллектуальных информационных технологий. СПб.: Изд-во СПИИРАН. 1998.
3. 'Захаров В.Н. Интеллектуальное системы управления: основные определения и понятия // Известия АН. Теория и системы управления. 1997. № 3.
О. И. Жуковский, С. С. Ощепков, Н. Б. Рыбалов Применение стилей сервис-ориентированной архитектуры
для разработки геоинформационной системы
Последние годы характеризуются колоссальным ростом интереса к веб-картографии и ее возможностям, а также значительным ростом числа сервисов, в той или иной форме использующих картографические веб-технологии. Важными тенденциями последних двух лет можно считать появление множества публичных веб-проектов, реализующих концепцию предоставления предобработанных данных; увеличение возможностей персонификации сервисов и возможностей интеграции собственных данных с уже существующими сервисами; глобальность сервисов [1].
Данные тенденции обусловливаются появлением сразу нескольких глобальных картографических сервисов ( гак называемых "виртуальных глобусов") — Google Maps. Virtual Earth, ArcGIS Explorer, которые позволили массовому пользователю просто и эффективно создавать и распространять геопространственные данные в Интернете. Инструментальные геоиформа-ционные системы (ГИС) как коммерческие, так и с открытым исходным кодом, например, ArcGIS. Maplnio. QGIS. gvSIG. стали предоставлять пользователю эффективные средства подготовки и анализа данных перед публикацией в Сети, а картографические веб-серверы (MapServer, GeoServer, MapGuide) благодаря поддержке разнородных пространственных данных (СУПБД. файлы, веб-сервисы) и возможностям взаимодействия с корпоративными приложениями позволили повысить эффективность распространения и регламентировать доступ к картографическим данным.
Развитие веб-картографии наложило отпечаток и на корпоративные информационные системы. Последние, основанные на ГИС-технологиях. сегодня внедряются практически всеми крупными компаниями. В качестве решения проблем, связанных с территориальным распределением субъектов и объектов производственной деятельности, а также отсутствием единого хранилища пространственных данных, предлагается использовать веб-ориентированные геоинформационные технологии. Однако эффективное применение этих технологии возможно лишь при построении оптимальной архитектуры корпоративной ГИС с учетом современных тенденций развития информационных технологий и подходов к разработке приложений.
Современные приложения уже не являются неизменяемыми цельными образованиями, как это было в прошлом. Это не монолитные ядра, работающие на крупной компьютерной платформе, а скорее набор динамически изменяемых модулей. Приложения создаются несколькими командами разработчиков с помощью различных языков программирования, с применением множества данных, которые могут поступать "онлайн" из нескольких, как правило, географически распределенных источников. В итоге возникает потребность в применении иного стиля разработки приложений, основой которого являются программные службы [2]. Такой стиль позволяет реализовать следующие принципы: повторного использования программного кода — при создании
нового приложения используются уже готовые службы; слабой связанности компонентов — компонентам системы не обязательно знать, как устроены взаимодействующие с ними подсистемы, а для взаимодействия нет необходимости в определении новых форматов данных и создании специального программного обеспечения [3].
Соблюдение данных принципов позволяет строить слабосвязанные приложения (то есть такие, в которых одну часть можно менять, не затрагивая другую: за счет этого обеспечиваются гибкость и высокая производительность), а также снимать наиболее острые проблемы интеграции приложений.
В основу корпоративной ГИС рекомендуется закладывать общие принципы создания корпоративных систем: системности, развития (открытости), совместимости и стандартизации (унификации) [4].
Реализовать данные принципы позволяет концепция "сервис-ориентированной архитектуры" (SOA — service oriented architecture). Последняя предполагает разделение системы на компоненты ("сервисы"), которые, имея согласованные общие интерфейсы, используют единые правила для определения того, как вызывать сервисы и как они будут взаимодействовать друг с другом. Сервис (служба) — программный компонент, доступ к которому можно получить через компьютерную сеть, реализует некоторую функцию с четко определенным интерфейсом [5]. Наиболее часто к принципам SOA относят такие как:
не привязанность архитектуры к какой-то конкретной технологии:
независимость организации системы от используемых вычислительных платформ:
независимость организации системы от применяемых языков программирования;
использование сервисов, независимых от конкретных приложений, с единообразными интерфейсами доступа к ним;
организация сервисов как слабосвязанных компонентов для построения систем. Преимуществами SOA являются: сокращение издержек при разработке приложений за счет упорядочения процесса разработки;
расширение повторного использования кода:
независимость от используемых платформ, инструментов, языков разработки:
повышение масштабируемости создаваемых систем;
улучшение управляемости создаваемых систем.
В рамках SOA в основу корпоративной ГИС предлагается положить комплекс специализированных служб (картографических сервисов). В качестве таких служб могут выступать сервисы пространственного анализа, публикации пространственных данных (генерация растрового или векторного представления), поиска информационных (атрибутивных) описаний, генерации отчетов на основе атрибутивных данных.
На сегодняшний день принципы SOA наиболее эффективно (применительно к веб-ориентированным системам) реализуют архитектурные стили (подходы) WSA (Web services architecture) и REST (Representational state transfer). Рассмотрим каждый из них в контексте построения сервис-ориентированной архитектуры корпоративной ГИС.
Web services architecture
Веб-сервисы в данной архитектуре (рис. 1) базируются на широко распространенных и открытых протоколах: HTTP. XML. UDDI. WSDL и SOAP. Эти стандарты реализуют основные требования SOA: сервис должен поддаваться динамическому обнаружению и вызову (UDDI. WSDL и SOAP); также необходимо использовать не зависящий от платформы интерфейс (XML). Протокол HTTP обеспечивает функциональную совместимость.
WSA дает возможность реализовать SOA, в которой службы взаимодействуют, обмениваясь XML-сообщениями. Технологии создания веб-служб в настоящее время достаточно продуманы, многие компании предлагают как коммерческие, так и свободно распространяемые стеки веб-служб. Для разработки картографических веб-сервисов также существуют специальные инструментальные средства, благодаря чему разработчики могут реализовать предоставляемые ГИС-функции в виде SOAP веб-сервисов.
К достоинствам данной архитектуры можно отнести: надежность (конфигурирование надежной доставки, обеспечение последовательного порядка прохождения и недопущение дубликатов в соответствии со стандартом WS-reliability) и безопасность (конфигурирование аутентификации, целостности благодаря использованию цифровых подписей и конфиденциальности за
Регистрация сервиса
(WSOL. SOAP. XUl)
К
/HTTP
Реестр сервисов
(WSOL. SOAP. XML)
HTTP
Поставщик сервиса Потребитель сервиса
Рис. 1. Архитектура "Web services architecture"
счет шифрования в соответствии со стандартом WS-security). Однако при реализации приложения предполагается наличие инструментальных средств разработки (как правило, коммерческих). при отсутствии которых быстро создать простой и эффективный сервис — задача нетривиальная. Помимо этого при реализации достаточно простых и часто используемых картографических функций (визуализация, запрос атрибутивной информации) сервис будет обладать значительным временем отклика и некоторой избыточностью пересылаемой информации, что при больших нагрузках может привести к перегруженности вычислительных ресурсов и сетевого трафика.
Поэтому в качестве более простой реализации SOA часто рассматривают архитектурный подход Representational state transfer (REST).
Representational state transfer
Архитектура REST диктует следующие особенности:
система представляется отдельными ресурсами со своим состоянием и не хранит состояние клиентского процесса для масштабируемости: ресурсы представляются стандартными mime-типами для независимости от платформы и самоописываемости;
ресурсы имеют универсальный интерфейс, идентифицируются собственными URL и связываются только через явное указание ссылок и форм в их представлениях для обеспечения интеграции между сервисами.
Для доступа к ресурсу (рис. 2) используется небольшое количество методов HTTP (GET. PUT. DELETE. POST). Передача метаданных осуществляется посредством HTTP-заголовков
Ответ
RPC-рвзультат
С*
4
Поставщик сервиса
HTTP
"Тч
Потребитель сервиса
Запрос
Рис. 2. Архитектура Representational state transfer
(mime-типы). За кеширование. проксирование и авторизацию также отвечает протокол HTTP [6].
Кардинальное отличие REST от SOAP-сервисов заключается в том. что в первом акцент сделан на доступ к ресурсам, а не на исполнение удаленных сервисов. Если SOAP-клиенты запрашивают выполнение действия на сервере, то REST-клиенты требуют сам ресурс. Например, вместо того, чтобы запрашивать на сервере визуализацию фрагмента карты, запрашивается сам фрагмент карты как статическая картинка. По такому же принципу может быть осуществлен доступ к службам WMS(Web map service) и WFS (Web feature service) [7].
Учитывая специфику REST- и SOAP-cep-висов, авторами предлагается распределить картографические сервисы по признакам из интенсивности их использования, сложности исполняемой логики и требований к надежности процесса выполнения. SOAP-сервисы обладают более высокой надежностью за счет спецификаций безопасного доступа к службам ( WS-security), адресации служб ( WS-addressing), управления состоянием (WS-resource framework), но сильнее загружают вычислительные ресурсы, поскольку требуют разбора ХМ L-кода и упорядочения объектов, а для оптимизации управления и ускорения этих операций необходимо специальное программное и аппаратное обеспечение [ 1 ]. REST-сервисы менее надежны, но более производительны и позволяют снизить затраты на обеспечение сервис-ориентирован-ного доступа к ресурсам [3].
Таким образом, к SOAP-сервисам можно отнести службы:
управления доступом; пространственного анализа; поиска по атрибутивным данным, а к REST-сервисам — службы: визуализации:
генерации KML/GeoRSS представлений; Web map service; Web feature service.
Рассмотрев данные архитектурные подходы, можно сделать вывод о том, что при оптимальном распределении функций между REST- и SOAP-сервисами можно повысить эффективность применения SOA для реализации корпоративной ГИС. Это позволит снизить время выполнения критических для ГИС функций, уменьшить сетевой трафик, а также (в некоторых случаях) снизить время
издержки на разработку картографических сервисов.
Спроектированную с учетом приведенных принципов инфраструктуру картографических сервисов предлагается положить в основу архитектуры корпоративной Web-mashup (веб-мэшап) ГИС, которая в рамках данной архитектуры будет являться провайдером содержимого (источником данных).
Мэшап-приложсние
Указанное приложение объединяет данные из нескольких источников в один интегрированный инструмент. Например, в качестве подложки могут быть использованы картографические данные виртуальных глобусов (Google Maps. Virtual Earth), в качестве тематических слоев — поток KML-данных. предоставленный специализированным картографическим сервисом, а для добавления к ним произвольных атрибутивных данных обратиться к сервисам управления информационными описаниями. В результате создается новый уникальный веб-сервис. изначально не предлагаемый ни одним из источников.
Архитектура мэшап-приложений всегда состоит из трех частей:
провайдер содержимого — это источник данных. Они доступны через API и различные веб-протоколы, такие, как RSS. REST и веб-сервисы;
Мэшап-сайт — это веб-приложение, предлагающее новый сервис, использующий не принадлежащие ему источники данных;
браузер клиента — пользовательский интерфейс мэшап-приложения. В веб-прило-жениях содержимое может быть "смешано" клиентским (mashed up) браузером с использованием клиентского языка программирования, например JavaScript.
Основу мэшап-приложения составляет комплекс компонентов — виджетов (widgets), которые представляют собой небольшие программные модули, имеющие графический интерфейс, поддерживающий систему событий, и прикладной интерфейс программирования (API). Основная задача виджета — интегрировать веб-сервис в приложение (выполнить смешивание) [8].
Интеграция картографических сервисов посредством виджетов. по мнению авторов, — это наиболее эффективный подход к реализации веб-ориентированной корпоратив-
Рис. 3. Архитектура на основе серверного смешивания
ной ГИС в рамках SOA. поэтому архитектура мэшап-приложений требует более детального рассмотрения.
Если рассматривать архитектуру мэшап-приложения на прикладном уровне, то это шаблон проектирования "Facade", который предлагает упрошенный интерфейс для большего количества кода (в данном случае код для агрегации различных сервисов с различными API).
На уровне взаимодействия сервисов различаются два типа архитектур мэшап-при-ложений: на основе серверного (Server-Side) и клиентского (Client-Side) смешений [9]. В соответствии с этим авторами предлагается два типа архитектур веб-мэшап ГИС.
Архитектуры всб-.мэшаи ГИС
На основе серверного смешивания. События. генерируемые интерфейсом приложения в ответ на действия пользователя, обрабатываются логикой клиентского приложения (слой "контроллер" паттерна MVC), которая в свою очередь посылает HTTP-запросы веб-ГИС серверу. Веб-сервер (его начальное звено) инициирует работу интеграционной логики, которая посредством API серверных компонентов интегрирует как внутренние сервисы (ГИС). так и любые внешние веб-сервисы (рис. 3).
На основе клиентского смешивания. В отличие от архитектуры на основе серверного смешивания, в данной архитектуре интеграционная логика размещается на клиенте. Виджеты,
интегрированные в пользовательский интерфейс, генерируют события, которые могут быть обработаны как клиентской логикой, так и самими компонентами и могут взаимодействовать между собой посредством API (рис. 4). Виджеты работают напрямую с ГИС и со сторонними веб-сервисами посредством REST- и SOAP-запросов.
Представленные архитектуры позволяют перенести идеологию смешивания веб-сервисов на сектор веб-ориентированных ГИС, позволяя тем самым повысить эффективность применения SOA за счет реализации основных преимуществ мэшап-приложений [14]. а именно:
повысить г ибкость разработки, позволяя быстро собирать и конфигурировать приложения:
ускорить реализацию и снизить стоимость работ за счет легковесной интеграции, возможности многократного использования и заимствования:
связать 1Т и производство, позволяя быстро создавать работающие прототипы;
сделать 80А более бизнес-ориентированной и явной, расширяя возможности многократного использования сервисов и виджетов;
стимулировать внедрение новых технологий и идей, сохраняя при этом соответствующий уровень управляемости.
Предложенные архитектуры были положены в основу веб-ориентированных ГИС ряда крупных металлургических и химических предприятий [10].
СПИСОК ЛИТЕРАТУРЫ
1. Дубинин М., Костикова А. Веб-ГИС // Компьютерра. 2008. № 33. С. 23-27.
2. Богданов A.B., Станкова E.H., Марссв В.В.
Сервис-ориентированная архитектура: новые возможности в свете развития Grid-технологий // Все-рос. конкурсный отбор обзорно-аналитич. статей по приоритетному направлению "Информационно-телекоммуникационные системы". 2008. 32 с.
3. Байбородин Н. Веб-ссрвисы: проектирование и реализация // 1ТСПЕЦ. #10. 2008. С. 24-30.
4. Синягин М. Применение корпоративной ГИС в управлении обустройством нефтегазовых месторождений. [Электронный ресурс], http://neolant.ru/ press-center/articles/index.php?ELEMENT_lD=195.
5. Разумовский К. Введение в технологию Web-служб. [Электронный ресурс]. http://www.javable. com/col umns/webserv/reviews/01 Ich 1.
6. Маквитги Л. REST как альтернатива SOAP. // Сети и системы связи. 2007. № 1.
7. Christopher J. Andrews. Emerging Technology: Geospatial Web Services and REST. [Электронный ресурс], http://www.directionsmag.com/article. php?article_id=2515.
8. Sherif Mansour. Why Mashups = (REST + 'Traditional SOA') * Web 2.0. [Электронный ресурс]. http://blog.sherifmansour.com/'?p=187.
9. Ort Ed.; Brydon Sean, Basler M. Mashup Styles. Part 1: Server-Side Mashups. [Электронный ресурс]. hitp://java.sun.com/developer/technicalArticles/J2EE/ mashup_l.
10. Жуковский О.И., Рыбалов Н.Б. Архитектура корпоративной Web-ориентированной ГИС // Доклады ТУ СУ Р. 2008. № 2 (18). Ч. 2. С. 46-57.
А. Б. Нелюбин Моделирование систем передачи данных
с позиции общей теории защиты информации
Согласно Доктрине информационной безопасности РФ от 9 сентября 2000 года "Информационная сфера на современном этапе представляет собой совокупность информации, информационной инфраструктуры, субъектов.
осуществляющих сбор, формирование, распространение и использование информации, а также системы регулирования возникающих при этом общественных отношений. Информационная сфера, являясь системообразующим фактором
