«Сервис-ориентированная архитектура (SOA, англ. service-oriented architecture) — модульный подход к разработке программного обеспечения, основанный на использовании распределённых, слабо связанных заменяемых компонентов, оснащённых стандартизированными интерфейсами для взаимодействия по стандартизированным протоколам» [1].
Говоря о SOA, часто подразумевают веб-сервисы или веб-службы — технологию распределенного взаимодействия, воплощающую идеи SOA в среде Интернет (а также Интранет). Взаимодействие осуществляется посредством HTTP протокола (Hyper Text Transfer Protocol). Веб-сервисы позволяют сделать функции программы доступными через Интернет, т. е. разработав некий универсальный функционал, мы можем предоставить его программам, работающим на других компьютерах (и иных вычислительных устройствах типа планшетов, смартфонов и т. д.). Главное, чтобы при этом было подключение к сети Интернет. Как следствие, веб-сервисная технология дает возможность разрабатывать кросплатформенные решения, а также использовать для написания сервиса и его потребителя (клиента) разные языки программирования.
Логика работы с веб-сервисом выглядит следующим образом [2]:
1) Владелец веб-сервиса размещает его на сервере, а также определяет формат запросов к сервису и его ответов.
2) Программа-потребитель веб-сервиса делает запрос на выполнение функции, предоставляемой веб-сервисом.
3) Веб-сервис отрабатывает запрос и возвращает ответ в заявленной ранее форме.
По сути, определяется формализованный интерфейс взаимодействия с веб-сервисом, в рамках которого происходит обмен данными между программой-владельцем сервиса и программой-потребителем.
Учитывая существующую организацию программных систем ИСЭРТ РАН в общем виде схему планируемого взаимодействия можно представить следующим образом (рис. 1).
Рис. 1. Схема взаимодействия поставщика и потребителей услуг веб-сервиса
1-й уровень — это веб-сервис. Напомним, что веб-сервис — это программа, которая выполняется на компьютере, а если говорить точнее, то на веб-сервере. На этом рисунке представлен один веб-сервер, но их может быть несколько.
На 2-м уровне находятся потребители услуг веб-сервиса, в случае ИСЭРТ РАН это тоже веб-серверы, на которых развернуты веб-сайты (портал института) и веб-приложения (например, внутренняя система контроля исполнения поручений).
На 3-м уровне находятся конечные потребители. Набирая адрес сайта в Интернет-браузере, мы инициируем взаимодействие между уровнями 2 и 3. Результатом этого взаимодействия является навигация по сайту, а также работа с веб-приложениями.
Веб-сервис позволяет вынести аналогичный программный функционал, используемый на серверах 2-го уровня. Выгода здесь, прежде всего, в отсутствии дублирования программного кода и пользовательской информации (например, регистрационных данных).
Как уже было сказано выше, представленная на рис. 1 схема взаимодействия учитывает существующую веб-ориентированную парадигму разработки программного обеспечения (ПО) в ИСЭРТ РАН. ПО в данном случае — это преимущественно веб-приложения, т. е. большая часть операций реализуется сервером и меньшая клиентом. Клиент — это Интернет-браузер, основная работа которого заключается в отображении результатов работы веб-сервера. Такой подход имеет неоспоримое достоинство в простоте и скорости развертывания ПО на компьютере пользователя. Все, что необходимо для работы веб-приложения — это установленный браузер и подключение к Интернету. Доступ к ПО может быть осуществлён практически с любого устройства, позволяющего выполнять Интернет-навигацию.
К недостатку данного подхода можно отнести ограничения на вычислительную нагрузку, создаваемую клиентом. Чем больше клиентов и чем больше их вычислительные запросы, тем сложнее веб-серверу их отработать. Для малотребовательных по части вычислительных ресурсов приложений этот недостаток не является проблемой, к таковым относятся подавляющее большинство существующих в настоящее время в ИСЭРТ РАН приложений. Вместе с тем, в связи с проводимой в институте научной работой вполне может возникнуть потребность в разработке ресурсоемких приложений, требовательных к вычислительным ресурсам. Обычно они реализуют в виде десктоп-приложений (приложений, устанавливаемых на компьютер). Большая часть их работы — сложные и длительные вычисления, анализ данных — выполняется на персональном компьютере, а меньшая на сервере, к которому приложение может обращаться, например, за исходными данными. Для таких приложений веб-сервисы также будут полезны. Схема организации взаимодействия с ними показана на рис. 2. Она похожа на ранее представленную схему, главное отличие заключается в том, что приложение, работающее на компьютере, может напрямую обращаться к веб-сервису, т. е. без посредников.
Рис. 2. Схема взаимодействия поставщика и потребителей услуг веб-сервиса для десктоп-приложений
Существуют несколько протоколов взаимодействия с веб-сервисом, перечислим наиболее популярные. «SOAP (Simple Object Access Protocol) — протокол обмена структурированными сообщениями в распределённой вычислительной среде. Первоначально SOAP предназначался в основном для реализации удалённого вызова процедур. Сейчас протокол используется для обмена произвольными сообщениями в формате XML, а не только для вызова процедур» [3]. «REST (Representational State Transfer) — стиль построения архитектуры распределенного приложения» [4].
Созданные к настоящему моменту в ИСЭРТ РАН программные системы обеспечивают решение самых разных научных и административно-организационных вопросов, но при этом остаются обособленными по части хранения и обмена данных между приложениями. Многие функциональные особенности систем приходится дублировать, например регистрацию пользователей. Учетная запись, созданная в одной системе, никак не используется в другой, что порождает путаницу и неудобство. На уровне программного кода разработчики вынуждены дублировать некоторые блоки кода, что приводит к лишней работе, а также повышает времязатраты на сопровождение существующих систем.
В свете имеющихся планов по созданию новых программных систем, например, системы учета результатов научно-исследовательской деятельности, проблема обособленных данных будет только усугубляться. В связи с вышесказанным считаем необходимым внедрение SOA в существующие, а также планируемые программные разработки ИСЭРТ РАН. Для этого предполагается выполнение следующих этапов.
1-й этап
1) Установка и настройка сервера, необходимого для работы веб-сервисов. Сервер должен поддерживать IIS (Internet Information Services), в нашем случае это реализуется установкой Windows Server.
2) Разработка и запуск программной части веб-сервиса в тестовом режиме. На данном этапе предполагается реализовать программный функционал, ограниченный вводом и выводом информации, относящейся к регистрационным данным пользователя: логин, пароль, ФИО и др. данные пользователя. Схема базы данных, необходимая для реализации такого веб-сервиса представлена на рис. 3.
Рис. 3. Схема базы данных для веб-сервиса
Информация о пользователе (ФИО) вынесена в отдельную таблицу исходя из тех соображений, что фамилия может быть изменена, например, в случае замужества сотрудницы. При этом необходимо сохранить и старую и новую фамилии в базе данных, а также дату изменения фамилии. Помимо персональных (ФИО) и регистрационных данных (логин, пароль) также необходимо определить группу пользователя, которая будет задавать права доступа.
Программная часть разработки веб-сервиса планируется на языке C# с использованием технологии WCF (Windows Communication Foundation). Клиентская часть веб-сервиса (потребитель его услуг) будет на языке PHP, именно на нем написаны все существующие на данный момент веб-приложения ИСЭРТ РАН.
3) Интеграция и тестирование веб-сервиса с разрабатываемой в настоящее время информационной системы учета результативности научно-исследовательской деятельности (ИСУ РНИД). При разработке данной системы изначально закладывается возможность относительно простого перевода части функционала на веб-сервисы к тому моменту, когда они будут запущены и отлажены. На рисунке 4 представлена схема взаимодействия ИСУ РНИД и веб-сервиса.
Рис. 4. Взаимодействие ИСУ РНИД с веб-сервисом
БД — база данных, необходимая для функционирования системы ИСУ РНИД. Программная часть (PHP-код, выполняющийся на сервере) обрабатывает входящие запросы пользователей, адресует запросы к БД, веб-сервису, обрабатывает результаты этих запросов и предоставляет результаты работы системы в удобном для пользователя виде. ИСУ РНИД — это совокупность программной части и базы данных.
Здесь показано объединение данных, получаемых из БД и веб-сервиса. Та часть данных, которая является общей для всех (или большинства) программных систем ИСЭРТ РАН предоставляется веб-сервисами, а специализированные данные, необходимые для работы конкретной программной системы (в данном случае ИСУ РНИД) оформлены в виде отдельной базы данных. Часть запросов к этой базе данных необходимо формировать на основе данных, получаемых от веб-сервиса, т. е. они будут зависимыми от веб-сервиса. Проиллюстрируем эту зависимость на рис. 5.
Рис. 5. Формирование зависимых от веб-сервиса запросов к БД
Действие № 1 — программная часть (ПЧ) получает запрос, допустим, что это запрос на выдачу списка всех публикаций некоторого пользователя. Действие № 2 — ПЧ обращается к веб-сервису, чтобы получить ID пользователя (ID — это техническое имя, однозначно идентифицируемое пользователя в системе). Действие № 3 — веб-сервис предоставляет идентификатор. Действие № 4 — идентификатор используется в запросе на получение публикаций пользователя (указанного через ID) из базы данных. Действие № 5 — БД возвращает список публикаций в ПЧ. Действие № 6 — ПЧ предоставляет ответ инициатору запроса, в виде списка публикаций.
2-й этап
На основе полученных результатов предыдущего этапа, позволяющих корректно оценить сложность и трудоёмкость работ, можно будет планировать дальнейшие шаги по разработки и внедрения SOA в другие программные системы ИСЭРТ РАН.
Очевидно, что разработка веб-сервисов предполагает реализацию ряда дополнительных методов и вспомогательных структур данных, необходимых для обеспечения режима доступа в соответствии с принадлежностью пользователя к той или иной группе (администратор, начальник отдела, сотрудник и др.). В рамках информационной архитектуры веб-приложений ИСЭРТ РАН расширенная схема базы данных предположительно будет выглядеть следующим образом (рис. 6).
Рис. 6. Расширенная схема базы данных для веб-сервиса
На этой схеме указы такие таблицы как «хост», «контроллер», «группа_действие» и др. Они описывают режим доступа пользователя к определенному сайту (именуемому как «хост») в соответствии с его правами. Под сайтами здесь понимается сайты ИСЭРТ РАН. Права пользователя могут значительно варьироваться в зависимости от того, с каким сайтом он работает. Именно поэтому нам необходимо вводить дополнительные поля, уточняющие возможные для пользователя (а точнее группы, к которой он принадлежит) действия на том или ином сайте.
Также необходимо организовывать в виде веб-сервисов методы доступа к данным организационно-административной структуры института, т. е. реализовать методы, позволяющие получить структуру института (перечень отделов, лабораторий, секторов), выяснить, в каком подразделении работает сотрудник, а также изменить данную информацию в случае необходимости.
Литература:
1. Сервис-ориентированная архитектура [Электронный ресурс]. — Режим доступа: http://ru.wikipedia.org/wiki/Сервис-ориентированная_архитектура
2. Веб-сервисы [Электронный ресурс]. — Режим доступа: http://www.webmascon.com/topics/technologies/8a.asp
3. SOAP [Электронный ресурс]. — Режим доступа: http://ru.wikipedia.org/wiki/SOAP
4. REST [Электронный ресурс]. — Режим доступа: http://ru.wikipedia.org/wiki/REST
