Назад в библиотеку  

ПРОЕКТИРОВАНИЕ АРХИТЕКТУРЫ КОМПЬЮТЕРИЗИРОВАННОЙ
ПОДСИСТЕМЫ УПРАВЛЕНИЯ РАБОТОЙ СЛУЖБЫ ТАКСИ

Авторы: В. О. Коношенко, М. В. Привалов

Описание: Спроектирована архитектура компьютеризированной подсистемы управления работой службы такси, основанная на принципах сервисориентирования. Предложено решение на основе WebSocket, позволяющее предоставить постоянное асинхронное соединение между компонентами подсистемы.

Источник: ИУСМКМ – 2017 http://iuskm.donntu.ru/electronic/iusmkm2017.pdf

Аннотация Коношенко В.О., Привалов М.В. Проектирование архитектуры компьютеризированной подсистемы управления работой службы такси. Выполнено проектирование архитектуры компьютеризированной подсистемы управления работой службы такси. Рассмотрены технологии, позволяющие предоставить постоянное асинхронное соединение

Ключевые слова: данные, сервер, архитектура, REST, СОA, WebSocket.

Постановка проблемы. В современном мире сложно найти человека, который не пользуется сервисами, доступными посредством Интернет. Их ценность в том, что они постоянно предоставляют доступ к актуальной информации. Отличным примером являются различного рода социальные сети, мессенджеры и так далее. Такие приложения имеют сложную архитектуру, но во всех случаях это – распределённая Интернет-архитектура или сервис-ориентированная архитектура, при общем взгляде на которые выделяются несколько основных компонентов. Это клиентское приложение, серверная часть (это может быть так называемый backend либо слой сервисов), коммуникации между ними и система управления базами данных. Качество работы такой системы в значительной мере зависит от архитектуры каждого компонента, но при этом ещё и от методов соединения клиентов с серверной частью. Коммуникации стараются сделать постоянными для поддержания актуальной информации, асинхронными и двухсторонними для организации взаимодействия по инициативе любого из участников. Асинхронность особенно важна для мобильных приложений, так как позволяет экономить трафик. Компьютеризированная подсистема управления работой службы такси предполагает доступ различных пользователей с различных устройств. При этом уведомления о событиях должны направляться как от клиентов к серверу, так и по инициативе сервера. Исходя из этого, задача проектирования архитектуры данной системы с учётом обеспечения постоянного, асинхронного соединения клиента с сервером является актуальной.

Цель работы – проектирование архитектуры компьютеризированной системы управлений работой службы такси с предоставлением постоянных асинхронных коммуникаций клиента с сервером.

Сравнительный анализ различных типов архитектур. Для решения поставленной цели необходимо рассмотреть основные типы архитектур, распределенную Интернет-архитектуру и сервис-ориентированную архитектуру (СОА).

В распределённой архитектуре обработка информации распределена не на одной машине, а выполняется на нескольких независимых. Связанные между собой они представляют единую инфраструктуру. Основные критерии распределённой архитектуры является следующее. Каждый уровень распределённого приложения должен взаимодействовать со смежными уровнями. Вся сложная бизнес-логика должна быть реализованная в отдельном слое. Преимущества распределённой архитектуры:

Открытость – гибкое использование ПО различных производителей.

Параллелизм, масштабируемость, отказоустойчивость.

Недостатки: более восприимчива к внешним атакам, ниже управляемость, работа зависит от организации системы и сетевых нагрузок.

СОА предполагает модульный подход к разработке программного обеспечения, основанный на использовании распределенных, слабо связанных между собой, заменяемых компонентах, оснащенных стандартизированными интерфейсами для взаимодействия по стандартизированным протоколам. Главное отличие СОА – это использование независимых сервисов, которые имеют четко определённые интерфейсы. Особенностью такой системы является предоставление следующих возможностей: собрать новые процессы из существующих служб, функциональная совместимость. [1] Рассмотрев данный тип архитектуры, можно выделить следующие ее преимущества.

• Каждый компонент независим от других компонентов.
• Слабое связывание сервисной ориентации обеспечивает большую гибкость.
• Клиент или любая услуга могут получить доступ к другим услугам независимо от их реализации, платформы, технологии, поставщика или языка.

Сравнительный анализ использования REST и SOAP. REST является архитектурным стилем или набором принципов, который мы используем для получения данных.[2,3] В свою очередь, SOAP – это семейство протоколов. SOAP требует очень много сервисных данных для отправки и получения своих сообщений, так как использует XML и не зависит от языка программирования на котором написан наш конечный продукт.

Проблемы использования SOAP:

• Очень большой размер данных из-за использования XML и лишние данные, связанные с WSDL файлами
• В случае изменения кода без обновления WSDL, клиенты не смогут работать, так как изменения не описаны в метаданных.
• Для передачи данных можно использовать только XML формат в текстовой или двоичной форме.

Положительные стороны:

• Безопасность: невозможно использовать функции, не описанные в WSDL документе.
• Предоставляет сразу описание всего функционала веб-сервиса.

REST, в отличие от SOAP, проще в использовании на практике. Он позволяет без риска изменять наборы методов на сервисах: достаточного того чтобы клиент знал, как пользоваться методом сервиса, при этом не будет никаких конфигурационных файлов и XML. Таким образом, на данный момент использование СОА совместно с REST является наилучшим решением, так как это гарантирует масштабируемость системы, независимость каждого узла, легкость в разработке.

Проектирование архитектуры подсистемы. Проектируемая система включает в себя веб-клиент, мобильное приложение, сервер и сервер базы данных, а также предполагает взаимодействие со сторонними сервисами, например, Google Maps. Для реализации такой системы необходимо предусмотреть сервисы для авторизации, передачи данных, кэширования данных, обработки локальной логики работы приложений. Также они имеют различную реализацию слоя представления. Сервер также должен иметь методы для передачи данных и для работы с непосредственно с БД. Предлагаемая реализация данной системы представлена на рис.1.

На практике, для обеспечения качественного соединения узлов немало важную роль играют методы соединения между ними.

Анализ технологий передачи данных между компонентами подсистемы. WebSocket – протокол полнодуплексной связи (может передавать и принимать одновременно) поверх TCP-соединения, предназначенный для обмена сообщениями между браузером и веб-сервером в режиме реального времени. [4] Крайне полезная технология для разработчиков, которые создают приложения, связанные с интенсивным обменом данных, требовательные к скорости обмена и стабильности канала связи. Позволяет передавать данные по TCP-соединению одновременно в оба направления. Такой функционал позволяет снижает задержки и нагрузки на сеть. Он основывается на протоколе HTTP и занимает его место после процедуры установление соединения. Схема работы представлена на рис.2. Такой метод передачи данных необходим для более оперативного взаимодействия в реальном времени и потоковой передачи.

Сегодня REST является самым стандартизированным способом структурирования API для запросов. Для большинства приложений информацию требуется только передать, когда пользователь предпринимает действие. Например, при просмотре новостного сайта, когда браузер запросил статью, пользователь занят ее чтением и не предпринимает никаких действий.

Решение описанных проблем. Для решения поставленной проблемы, необходимо спроектировать СОА на основе REST, а также предоставить технологии, которые позволяют создавать постоянные асинхронные соединения между клиентом системы и серверной частью. При проектировании сервис-ориентированной архитектуры предполагается предоставить сервисы для работы сразу двух технологий передачи (REST API и WebSocket). Распределив технологии по их назначению, мы получаем гибкую систему. Для отслеживания автомобиля по маршруту и предоставлению всегда актуальной информации, как водителя, так и клиента, будет использоваться технология WebSocket. А при необходимости отредактировать какие-либо данные, потребуется просто отправить запрос, реализованный при помощи REST API (рис.3).

Выводы. Для выполнения поставленной цели были проанализированы различные типы архитектур. Выяснено, что сервис-ориентированная архитектура на основе REST является наилучшим решением. Спроектирована архитектура подсистемы управления работой службы такси, в которой обеспечена возможность постоянных асинхронных коммуникаций наряду с типовыми HTTP/REST. Для предоставления асинхронного постоянного соединения клиента с сервером был выбран протокол полнодуплексной связи, основанный на технологии WebSocket, что предоставляет возможность обмениваться данными как по запросу клиента, так и по инициативе сервера, тем самым избегая периодичного обновления. Такой подход позволит сэкономить трафик, что весьма критично для доступа к системе с мобильных устройств, а также повысить отзывчивость приложения в целом.

Список литературы

1. Сервис-ориентированная архитектура [электронный ресурс] // Википедия – свободная энциклопедия: [сайт].
2. REST [электронный ресурс] // Википедия – свободная энциклопедия: [сайт]. [2016]. URL: https://ru.wikipedia.org/wiki/REST.
3. Roy Fielding. Architectural Styles and the Design of Network-based Software Architectures (англ.) (2000).
4. WebSocket [электронный ресурс] // Википедия – свободная энциклопедия. URL: http://ru.wikipedia.org/wiki/WebSocket.