Модуль для навигационной системы
Оглавление
Введение 3
. Постановка
задачи 5
. Анализ задачи 6
.1 Анализ
требований заказчика 6
.2 Анализ
архитектуры приложения 8
.3 Анализ
предметной области 12
.3.1 Сервисная
шина предприятия 12
.3.2 Основы
архитектуры SOA 13
.3.3 Составляющие
базовой архитектуры SOA 14
.3.4 Роль ESB в
архитектуре SOA 14
.3.5 Роль
веб-сервисов в SOA 15
.4 Анализ
существующих аналогов ESB технологий 16
.4.1 Mule ESB 16
.4.2 Talend-SE 17
.4.3 UltraESB 20
.4.4 WSO2 ESB 21
.4.5 Проведение
тестов 24
.5 Анализ
используемых средств 31
.5.1 WSO2
Enterprise Service Bus 31
.5.2 WSO2
Application Server 31
.5.3 WSO2
Governance Registry 34
.5.4 WSO2 Carbon 36
.5.5 Java 37
.5.6 Microsoft
SQL Server 37
.5.7 Фреймворк
Spring 38
. Реализация 39
.1 Описание
архитектуры приложения 39
.2 Структура базы
данных 41
.3 Реализация
классов 43
.4 Развертывание
приложения 52
Заключение 54
Список литературы 55
Введение
Корпоративная сервисная шина ESB (Enterprise Service Bus) -
это инфраструктурная платформа, которая объединяет стандартизованную сервис-ориентированную
архитектуру с мощными веб-сервисами. Данная технология является принципиально
новым, более мощным и эффективным подходом к интеграции приложений. В последнее
время эта технология довольно быстро развивается и является наиболее мощным, признанным
инструментом, который легко адаптируется для реализации механизмов интеграции.
ESB имеет ряд преимуществ:
Компоненты системы легко внедряются в существующие системы
компании, также, исходя из текущих и перспективных требований бизнеса,
разрабатываются дополнительные компоненты, выполняется взаимодействие, причем
привычный ход бизнеса не нарушается.
Все приложения быстро настраиваются, так как были созданы на
совершенно новой платформе, которая отличается от обычных клиент-серверных
систем.
В приложениях с унаследованными системами, ESB убирает
потребность сложного процесса их внедрения. Приложения и платформу легко
установить на “шину” и обеспечить их сосуществование независимо друг от друга.
Технология ESB, в первую очередь, предназначена для крупных
компаний и корпораций, которым необходимо достичь эффективного взаимодействия
между приложениями, максимизировать использование ресурсов, а также обеспечить
надежные средства построения соответствий между документами.
На данный момент существует множество инструментов,
позволяющих без особых усилий создавать приложения на основе ESB. Каждый из них
имеет свои преимущества и недостатки.
Исходя из вышесказанного, было решено проанализировать
существующие инструменты, помогающие при построении приложений, в основе
которых лежит ESB. На основе результатов анализа будет выбран наиболее
зарекомендовавший себя инструмент. С его использованием в качестве примера
будет разработан модуль для навигационной системы, основной целью которого
является нахождение парковочного места относительного текущего позиционирования
автомобиля. Модуль необходимо внедрить в существующую систему таким образом,
чтобы он удовлетворял поставленным требованиям к системе.
1.
Постановка задачи
Цель работы: анализ существующих инструментов, помогающих при
построении приложений, в основе которых лежит ESB. С использованием выбранного
инструмента в качестве примера будет разработан модуль для навигационной
системы. Функциональность модуля будет включать нахождение парковочного места
относительного текущего позиционирования автомобиля. Модуль необходимо внедрить
в существующую систему таким образом, чтобы он удовлетворял поставленным
требованиям к системе.
Для достижения поставленных целей необходимо решить следующие
задачи:
· Определиться с используемыми технологиями;
· Также требуется проанализировать и выбрать
инструмент для создания модуля, в основе которого будет лежать
сервис-ориентированная архитектура.
· Разработать базу данных, удовлетворяющую
поставленным целям;
· Продумать общую архитектуру модуля,
который будет удовлетворять поставленным требованиям.
Состав технических средств определен следующим образом:
· Сервер базы данных Microsoft SQL Server;
· Среда разработки - Java (версия 1.6).
2.
Анализ задачи
.1 Анализ требований заказчика
Разрабатываемое приложение будет предназначено для работы на
встроенной системе в автомобиле. Эта система будет подключена к интернет и
будет взаимодействовать с водителем автомобиля, который будет получать онлайн
услуги во время вождения.
Будет производиться большое количество запросов к различным
внешним ресурсам, и число ресурсов будет постоянно расти. Будет так же расти
число клиентов, которых надо будет обслуживать. Такие условия и приводят к
тому, что система должна быть гибкой, масштабируемой, безопасной и иметь
модульную архитектуру, позволяющую обрабатывать миллионы транзакций в день.
Общая схема приложения представлена ниже.
Рис. 1 Обзор архитектуры системы
Основным требованием заказчика является то, что система
состоит из трех основных модулей:
· Head Unit and Browser - это устройство,
которое встроено в автомобиль, внутри него функционирует собственная
операционная система, управляющая этим устройством. На базе этой операционной
системы есть браузер, позволяющий взаимодействовать с внешними ресурсами. Этот
модуль взаимодействует с модулем Vehicle Backend. Взаимодействие осуществляется через мобильное
соединение через VPN канал.
· Vehicle Backend - этот модуль
предназначен для связи различных внешних ресурсов с Head Unit and Browser модулем.
· Content and Services - это внешние сервисы и
ресурсы из которых система получает информацию.
Описав некоторую структуру приложения, было выдвинуто
требование, что приложение будет построено с использованием языка Java как веб приложение с
использованием различных технологий (JSP, Spring).
Итак, на основе рекомендаций, требования к разрабатываемому
модулю заключаются в следующем:
· Удобство и простота в эксплуатации на
каждом уровне;
· Высокая доступность и надежность всех
компонентов;
· Надежность: осуществление высокой степени
конфиденциальности передаваемой информации;
· Масштабируемость: модуль должен быть
масштабируемым для поддержки меняющихся требований;
· Гибкость: модуль должен быть разработан с
возможностью его изменения в плане расширения и улучшения;
· Комплексный мониторинг: модуль должен
предоставлять соответствующую информацию о выполнении своей работы на каждом
уровне, информация затем может быть использована в качестве основы дальнейшего
улучшения на каждом уровне (например, улучшение процессов);
· Своевременная технология обновления,
позволяющая обновить функциональные компоненты для качественного улучшения
производительности.
Основные принципы, применяемые в рамках системы для
достижения целей:
· Модульный подход к системе;
· Хорошо продуманный дизайн архитектуры для
обеспечения четкого разделения подсистем приложения;
· Строгое использование слоев в системе,
способствующее гибкости в отношении повторного использования и расширяемости;
· Ориентация на сервисы;
· Использование стандартизированных
интерфейсов на каждом уровне;
2.2
Анализ архитектуры приложения
Приложение построено на сервис-ориентированной архитектуре,
использование которой необходимо для выполнения определенных требований и
обеспечения гибкости внутри системы. Одним из основных аспектов является
концепция разделения на слои. Система представляет собой платформу,
предназначенную для управления сервисами и их выполнения. Система ориентирована
на пользователя или автомобиль для различных групп пользователей.
В операционную платформу будут интегрированы продукты для
создания ESB приложений и использованы в качестве SOA компонентов. Эти продукты
могут быть использованы как для работы, управления и осуществления контроля,
так и в качестве доставки служб внутрь автомобиля и дальнейшего подключения
различных внешних систем к платформе. На следующем рисунке более детально
показаны используемые слои приложения.
Рис. 2. Детальная архитектура приложения
Внутренний интерфейс приложения состоит из 6 различных
кластеров / слоев, назначение которых более подробно будет объяснено позже:
· Device Gateway, к которому имеет доступ
конечный пользователь;
· End User Services, предоставляющие сервисы
конечному пользователю.
· Service Integration Layer, предоставляющий сервисы
для администрирования, мониторинга и т.д.
· Central Platform Services, предоставляющие
центральные сервисы, которые необходимы всем остальным кластерам.
· B2B Interface, предоставляющий B2B сервисы интеграции.
· Security PKI, обеспечивающий
безопасные условия для ключей и сертификатов.Gateway действует как прокси между
мобильными устройствами или приборами, установленными в автомобиле, и другими
кластерами. Device Gateway представляет собой группу компонентов, отвечающих за
обработку входящих сообщений или запросов на обслуживание с мобильных устройств
или других клиентов сети. Device Gateway помогает достичь высокой пропускной
способности и малого времени задержки в обработке запросов сервисов в рамках
платформы путем отделения основных компонентов бизнес-логики от тех, которые
касаются получения сообщения. Слой состоит из нескольких WSO2 ESB, содержащих
прокси для слоя End User Services.Устройство, которое запрашивает услугу,
посылает свой запрос на Device Gateway.Входящий запрос перенаправляется в
целевую службу, которая является частью кластера "End User Service".
Для перенаправления запроса, целевая служба или слой презентации должны быть
переопределены (Conv.Resolver). После этого запрос должен быть отослан целевому
компоненту (Dispachter).
Слой End User Services содержит веб-представление и
веб-сервисы для приложений, предусмотренных устройством и предназначенных для
конечного пользователя (например, Weather, Parking и т.д.,). Как правило, приложение
состоит хотя бы из одного веб-представления и по крайней мере одного сервисного
компонента. За время существования, различные версии могут быть добавлены и
предоставлены одновременно. Система построена на гибкой и интегрированной среде
выполнения, где Tomcat и WSO2 AS используются в кластере. Сервисы могут быть
построены не только на основе фремворка Spring, но и на других парадигмах Java.
Важной особенностью так же является многоуровневая внутренняя архитектура самих
приложений.Platform Services предоставляют широкий спектр платформенных
сервисов, необходимых всем сервисам, например, доступ к данным и
т.д.Integration Layer содержит сервисы для управления, мониторинга и
администрирования платформы. Этот слой соединяет все другие, и наследует
управление интерфейсами и сервисные адаптеры.B Interface предоставляет
интерфейсы внешних сервисов, которые могут быть использованы для принятия
внешних сервисов, таких как Twitter или RSS, эти сервисы будут называться
Service Adapters.инфраструктура публичных ключей, которая обрабатывает
сертификаты транспортных средств.
Основным требованием, выдвигаемым заказчиком было то, что
клиент не может напрямую обратится к любому из компонентов и слоев архитектуры.
Все запросы, приходящие от клиента, должны идти на Device Gateway, где они контролируются
на каждом обращении к сервисам или внешним ресурсам. Это делается для того,
чтобы осуществить безопасность, нахождение проблемных мест, анализируя их и
улучшая разрабатываемое приложение. Схема маршрутов движения запросов представлена
на следующем рисунке.
Рис. 3. Схема движения запросов в приложении
навигационный модуль архитектура приложение
Инфраструктура и техническая архитектура выполнены в виде
многоуровневой архитектуры с четырьмя разделенными зонами. Разделение также
происходит на уровне 2 между web-уровнем и бизнес-логикой. Слои поддерживают
гибкость и масштабируемость всей системы.
Рис. 4. Техническая архитектура приложения
2.3
Анализ предметной области
Сервисная
шина предприятия
Сервисная шина предприятия (англ. enterprise service bus, ESB) - связующий
программный продукт, обеспечивающий централизованный и унифицированный
событийно-ориентированный обмен сообщениями между различными информационными
системами по принципу сервис-ориентированной архитектуры.
Основной принцип ESB - концентрация обмена сообщениями между
различными системами через единую точку, в которой, при необходимости,
обеспечивается транзакционный контроль, преобразование данных, сохранность
сообщений. Все настройки обработки и передачи сообщений предполагаются также
сконцентрированными в единой точке, и формируются в терминах служб, таким
образом, при замене какой-либо информационной системы, подключённой к шине, нет
необходимости в перенастройке остальных систем.
Наименование подобрано по аналогии с системной шиной
компьютера, позволяющей подключать несколько устройств и передавать данные
между ними по одному набору проводников.
Основными задачами ESB являются:
· Поддержка синхронного и асинхронного
способа вызова служб;
· Использование защищённого протокола
передачи сообщений с гарантией доставки;
· Статическая и алгоритмическая
маршрутизация сообщений;
· Доступ к данным из сторонних
информационных систем с помощью готовых или специально разработанных адаптеров;
· Обработка и преобразование сообщений;
· Разнообразные механизмы контроля и
управления (аудиты, протоколирование).
Конкретные программные продукты обычно также содержат готовые
адаптеры для соединения с определенным прикладным программным обеспечением, а
также могут включать API для создания таких адаптеров.
Основы
архитектуры SOA
Сервис-ориентированная архитектура (SOA, англ. service-oriented architecture) - модульный подход к
разработке программного обеспечения, основанный на использовании
распределённых, слабо связанных (англ. loose coupling) заменяемых компонентов,
оснащённых стандартизированными интерфейсами для взаимодействия по
стандартизированным протоколам.
Программные комплексы, разработанные в соответствии с сервис-ориентированной
архитектурой, обычно реализуются как набор веб-служб, взаимодействующих по
протоколу SOAP, но существуют и другие реализации (например, на базе jini,
CORBA, на основе REST).
Интерфейсы компонентов в сервис-ориентированной архитектуре
инкапсулируют детали реализации (операционную систему, платформу, язык
программирования) от остальных компонентов, таким образом обеспечивая
комбинирование и многократное использование компонентов для построения сложных
распределённых программных комплексов, обеспечивая независимость от
используемых платформ и инструментов разработки, способствуя масштабируемости и
управляемости создаваемых систем.
Теперь рассмотрим некоторые более сложные технические
аспекты, такие как роль ESB, бизнес-процессы, а также роль веб-сервисов.
Составляющие
базовой архитектуры SOA
Базовая архитектура SOA состоит из провайдера сервисов,
сервиса и (необязательного) каталога сервисов. Для обмена информацией
используется механизм обмена сообщениями типа "приложение к
приложению".
Сходство между этой моделью и чистыми веб-сервисами
совершенно очевидно, поскольку в обоих случаях применяется WSDL-документ,
являющийся контрактом по активизации, хранящимся в каталоге сервисов, из
которого этот сервис может быть запрошен и извлечен посредством механизма UDDI
(UDDI - это отраслевая спецификация для публикации и поиска информации о
веб-службах). Веб-сервисы в действительности являются реализацией архитектуры
SOA на самом базовом уровне.
В этой модели базовый сценарий таков. Сначала провайдер сервиса
создает сервис, принимает решение открыть этот сервис и публикует его.
Публикация выполняется путем отправки информации о сервисе в каталог сервисов.
С другой стороны, инициатор запросов сервиса, нуждаясь в определенном сервисе,
просматривает каталог сервисов в поисках того из них, который удовлетворяет
необходимому критерию. После обнаружения такого сервиса и использования
доступной в каталоге сервисов информации инициатор запросов сервиса может
напрямую обратиться к провайдеру сервисов надлежащим способом для
удовлетворения бизнес-потребности.
Роль
ESB в архитектуре SOA
ESB играет важную роль в архитектуре SOA. По сути, она
предоставляет магистральную сеть и инфраструктуру для соединения провайдеров и
потребителей сервисов.
Ниже более подробно перечислены роли ESB:
· Предоставляет
интеграционную инфраструктуру, соответствующую принципам SOA:
o Устанавливает явные
независимые от реализации интерфейсы для определения сервисов со слабым
связыванием.
o Использует
коммуникационные протоколы, обеспечивающие независимость от месторасположения и
способность к взаимодействию.
o Способствует определению
сервисов, инкапсулирующих повторно используемые бизнес-функциональности.
· Предоставляет средства
для управления инфраструктурой сервисов.
· Функционирует в распределенной
среде, поскольку она:
o Поддерживает синхронное и
асинхронное взаимодействие.
o Использует стандартные
интерфейсы и стандартные протоколы.
· Централизует управление и
распределяет обработку.
· Поддерживает механизм
посредничества для формулирования корректных запросов/ответов между различными
участниками взаимодействия без необходимости их изменения.
· Реализует защиту и
обеспечение качества сервиса в проектах SOA.
Роль
веб-сервисов в SOA
Хотя веб-сервисы появились до SOA, они представляют собой
ответ и реализацию потребности архитектуры SOA в механизме взаимодействия между
системами и платформами. Они помогают быстро внедрить и запустить SOA в работу,
поскольку уже поддерживают технологии, удовлетворяющие ее потребности. Сегодня
очевидно, что веб-сервисы представляют собой основу архитектуры SOA и являются
рекомендованной технологией для обеспечения взаимодействия.
Веб-сервисы являются основой архитектуры SOA по следующим
причинам:
· Они заставляют применять
стандарты и тем самым способствуют совместимости и переносимости;
· Они не зависят от
платформы и языка программирования;
· Они поддерживаются
повсеместно, что существенно облегчает внедрение SOA;
· Они ориентированы на
сообщения;
· Они обеспечивают более
быструю поддержку инструментальными средствами, что ускоряет реализацию SOA.
.4 Анализ существующих аналогов ESB технологий
Проанализировав требования заказчика, было определено:
· Приложение должно быть построено на основе
SOA;
· Использование ESB в приложении;
· Необходим сервер приложений.
Таким образом, требуется провести анализ существующих
технологий и выбрать именно ту, которая наиболее четко и точно удовлетворяет
поставленным требованиям.
Существует множество open-source ESB технологий. Самые
известные и используемые из них это:
· Mule ESB;
· Talend-SE;
· UltraESB;
· WSO2 ESB.
Ниже представлен обзор этих ESB технологий.
Mule
ESB
Mule ESB - корпоративная интеграционная шина с открытым
исходным кодом, с более чем 2500 промышленных внедрений, включая 5 из 10
крупнейших мировых банков и более 35% компаний и списка Global 500.ESB
предоставляет разработчикам простой и эффективный инструмент, позволяющий
интегрировать приложения и сервисы с минимальными затратами.ESB - это лёгкая и
гибкая платформа, легко адаптируемая в существующую инфраструктуру, так же
достаточно надёжная для обеспечения бесперебойной работы самых крупных и
требовательных корпоративных реализаций SOA.
Низкие системные требования упрощают внедрение и поддержку.
Работает как под управлением сервера приложений так и без.
Более 100 транспортов и модулей для интеграции с различными
системами, протоколами, SOAP и REST сервисами.
Преимуществами Mule ESB является то, что эта технология
поддерживает:
· Различные серверы приложений, в том числе:
JBoss и Apache Tomcat;
· СУБД MS SQL Server, которая используется в
разрабатываемой системе;
· Средства разработки: Eclipse, IntelliJ,
IDEA, Maven и т.д.;
· Транспорты: SOAP, Email, FTP,
Hibernate, HTTP/S, WSDL и
т.д.;
· Топологии внедрения: ESB, Client/ Server и
т.д.;
· Безопасность: Spring Security и т.д.;
· Контейнеры: EJB3, Spring и т.д.;
· Языки: Java, Javascript и т.д.;
· Форматы данных: Byte arrays, HTML/XHTML, Java Objects, JSON,
XML и т.д.;
Помимо этого, Mule имеет еще несколько продуктов, которые могут
помочь в разработке приложения:
· Anypoint
Service Registry - платформа управления SOA. Позволяет легко
организовывать и обнаруживать сервисы, управлять ими на протяжении всего их
жизненного цикла, контролировать их работу и обеспечить строгое соблюдение
стандартов, политик и контрактов;
· Tcat - Enterprise Tomcat, сервер
приложений, разработанный на базе Tomcat.
Talend-SE
Talend Open Studio ESB - инновационное средство (на базе
Eclipse) для моделирования, настройки и развертывания интеграционных решений,
использующее корпоративную сервисную шину с открытым исходным кодом Talend ESB
на базе Apache. Talend Open Studio ESB устраняет длинную кривую обучения,
типичную для большинства интеграционных инструментов. TOS ESB ускоряет
развертывание, повышая тем самым продуктивность разработчиков и позволяя им
быстро реагировать на интеграционные требования.ESB позволяет разработчикам
быстро выстраивать интеграционные процессы, путем простого перемещения
компонентов в графическую рабочую область, определения связей и отношений между
ними и настройки специфических свойств. ESB Studio предоставляет доступ к
библиотеке из 450 коннекторов, поддерживающих все типы источников и конечных
систем для интеграции, миграции и синхронизации данных.
Ключевые особенности:
· Универсальность и гибкость. Легко
разворачиваемые web-сервисы, сервисы данных, REST приложения и сложные маршруты
передачи, облегченные пакеты, настраиваемые под любую топологию приложения;
· Динамическая маршрутизация;
· Высокое представление. Шина обеспечивает
высокую пропускную способность в сочетании с прозрачными для клиента средствами
восстановления после сбоев и балансировкой нагрузки для гарантии того, что
будут соблюдены все принятые соглашения об уровне услуг;
· Простота в развертывании. Преднастроена
производителем для работы в любом Java окружении.
Функциональные возможности:
· Настройка без программирования. Хорошо
налаженный контейнер развертывания, установка и конфигурирование, не требующие
программирования, повышают продуктивность разработчиков, позволяя программистам
концентрироваться на бизнес-логике, а не на сложностях применяемых
информационных технологий;
· Модульная сборка приложения. Модули из
одного проекта в дальнейшем можно использовать и в других проектах;
· Поддержка стандартов безопасности
веб-сервисов. Talend ESB SE предлагает ряд возможностей для построения
безопасности веб-сервисов приложений, применяя при этом принятые отраслевые
стандарты для XML шифрования, аутентификации и авторизации;
· Командная строка и инструменты для
написания скриптов;
· Обмен сообщениями. Talend ESB SE снижает
затраты на аппаратное и программное обеспечение, позволяя более эффективно
использовать вычислительные ресурсы. Каждый брокер сообщения может управлять
множеством соединений, наряду с обработкой тысяч сообщений в секунду с минимальной
задержкой;
· Фреймворк для создания Службы маркеров
безопасности (STS). Talend ESB позволяет установить «доверие» между частями
приложений, применяя новейшие стандарты безопасности веб-сервисов;
· Перехват управления при отказе и
балансировка нагрузки. Talend ESB SE обеспечивает автоматический и прозрачный
перехват управления при отказе с помощью протокола обнаружения сервисов
(Service Locator), а также балансировку нагрузки с помощью динамической
регистрации конечных точек и поиск с помощью Apache Zookeeper. Service Locator
поддерживает доступность сервиса для удовлетворения требованиям и принятым
соглашениям об уровне услуг;
· Служба мониторинга активности. Служба
мониторинга активности (Service Activity Monitoring) отслеживает возникающие
события и сохраняет эту информацию для дальнейшего глубого анализа;
· Небольшое дисковое пространство. Шина
Talend ESB (под управлением Apache Karaf, занимающая небольшое дисковое
пространство, OSGi-ориентированная) предоставляет облегченный контейнер для
развертывания различных компонент и приложений. Talend ESB использует ресурсы
по минимуму в плане размера загрузки и использования процессора и памяти;
· Поддержка транспортных протоколов (HTTP,
Servlet, JMS), привязки данных и форматов(XML, JSON), Bindings (SOAP,
REST/HTTP);
· Поддержка стандартов;
· Гибкое развертывание;
· Поддержка различных языков
программирования.
UltraESB
UltraESB является бесплатным и свободно распространяемым
Enterprise Service Bus, впервые выпущенный в январе 2010 года под AdroitLogic Zero-Dollar EULA. С августа 2010 года его
исходный код был доступен по лицензии OSI, утвержденный Affero General Public
License (AGPL).
Разработка,конфигурирование и тестирование:
· С использованием любого IDE, который
предпочитает пользователь (IntelliJ IDEA, NetBeans, Eclipse и т.д.);
· Интеллектуальное автозаполнение и
встроенная в IDE пошаговая отладка;
· Отправка более 70 образцов и
соответствующих модульных тестов;
· Конфигурация ESB с испольщованием
APIDirector AdroitLogic без программирования.
Управление и мониторинг:
· Все средства управления и мониторинга
работает вне ядра ESB экземпляра;
· UConsole - веб-консоль управления;
· UTerm - интерфейс для администрирования;
· Встроенные метрики, оповещения и отладка
сбоя подключения;
· Автоматизированный шаблон на основе метрик
отчетности Zabbix.
Кластеризация и высокая доступность:
· Кластеризация на основе Apache ZooKeeper;
· Все узлы эквивалентны, отсутствуют
специальные узлы управления;
· Управление всем кластером через любой
подключенный узел;
· Репликация состояния и обмен контентом с
помощью распределенного кэширования на основе Ehcache.
Технические особенности:
· Кэширование файлов на RAM дисках;
· Возможность динамической загрузки и
перезагрузки единиц развертывания (то есть сервисы, логика посредничества и
т.д.) автоматически во времени выполнения.
WSO2 ESB
WSO2 ESB придерживается стандартов веб-сервисов, включая
SOAP, WS-*, REST.ESB может выполнять множество операций над сообщениями,
проходящими через него, таких как маршрутизация к конечным точкам (endpoints), посредничество (mediation), преобразование,
логирование информации, балансировка нагрузки и многое другое. Архитектура WSO2
ESB содержит различные функциональные компоненты, такие как транспорты,
последовательности, прокси-сервисы, медиаторы, конечные точки, компоненты QoS
(качества обслуживания) и так далее. Прием сообщений в ESB первоначально
возлагается на транспортную составляющую, которая поддерживает общие
транспортные протоколы, такие как HTTP / S, JMS, VFS, и т.д.
На транспортном уровне получение сообщений идентифицируется
тегом content-type и созданием обрабатываемого xml документа с описанием
маршрутизации и назначения медиаторов и конвертации к оригинальному формату
сообщения путем направления content-type к точке выхода.
Сообщения отсылаются через канал сообщений по транспорту к
фреймворку-медиатору(посреднику). В канале аспекты качества обслуживания
(например, безопасность и надежность сообщений) добавляются к сообщениям.
Обычно посредничество между сообщениями происходит в одном канале сообщений, но
в случае с прокси-сервисами каждый из них дожжен поддерживать свой канал
сообщений.
Фреймворк-медиатор, разработанный Synapse принимает решение о
маршрутизации и трансформации сообщения и внедряет сообщения в различные каналы
в зависимости от обозначенных точек назначения. Транспортный слой должен снова
позаботиться о преобразовании транспортного протокола, необходимого в ESB. С
помощью REST API любую реализацию SOAP сервиса можно представить как REST клиент для сервиса.
Изображение внизу показывает архитектуру WSO2 ESB.
Рис. 5 Архитектура WSO2 ESB
WSO2 ESB имеет следующие особенности: полная поддержка XML и веб-сервисов, высокое
качество использования регулирования соединения, неблокированный I/O и модель непрерывного
разбора XML. Другой важной особенностью является поддержка
событийно-ориентированной архитектуры. Процесс посредничества сообщениями
расширяется поддержкой разбиения на части, агрегации, кэширования и
регулирования сообщений. WSO2 ESB также обеспечивает всесторонний мониторинг
производительности, через консоль управления, а так же через JMX.
Особенности
· Подключения
o Транспорт: HTTP, HTTPS, JMS, TCP, UDP, FTPS, SFTP и др.;
o Форматы и протоколы: JSON, XML, SOAP 1.1, SOAP 1.2, WS-*, HTML, Text, JPEG, все бинарные форматы и
др.;
· Маршрутизация,
посредничество и преобразование
o Маршрутизация: на основе
заголовка, содержания, основанная на правилах и приоритетно- основанная
маршрутизация;
o Посредничество:
гарантированная доставка сообщений, интеграция с базами данных, публикация
событий, логирование и аудит, валидация;
o Преобразование: XSLT 1.0/2.0, XPath, XQuery, Smooks.
· Сообщения, API и безопасная
маршрутизация
o Предоставление доступа к
существующим приложениям и сервисам через различные протоколы и форматы
сообщений;
o Виртуализация услуг для
слабой связи и управления SOA;
o Балансировки нагрузки для
обеспечения масштабируемости и отказоустойчивости для обеспечения высокой
доступности конечных точек системы;
o Централизованное
обеспечение и управление безопасностью, в том числе аутентификацией,
авторизацией доступом;
o Предоставление доступа к
сервисам и приложениям через RESTful APIs с управлением ключами.
Проведение
тестов
Для того чтобы определиться, какая из представленных систем
лучше всего удовлетворяет поставленным целям, было решено проанализировать их
производительность и другие характеристики, проведя несколько соответствующих
тестов. Было решено сравнивать производительность самых последних версий
технологий, о которых было сказано выше: WSO2 ESB 4.6.0, Mule 3.3.0,
Talend-SE-5.1.1 и UltraESB 1.7.1- Enhanced. Так как по результатам тестов WSO2
ESB 4.6.0 показал одни из лучших результатов, то так же было решено
проанализировать и одну из предыдущих версий этого продукта: WSO2 ESB 4.5.1, а
так же особое внимание будет уделяться именно этому продукту, чтобы дать более
полные его характеристики и объяснить достоинства его использования в
проекте.ESB 4.6.0 является последней версией ESB на момент проведения анализа,
и данные ниже показывают прирост производительности по сравнению с WSO2 ESB
4.5.x.Критерии оценки эффективности работы выполняются в Amazon EC2, поэтому
они могут быть независимо проверены и повторены. Amazon EC2 - веб-сервис,
который предоставляет вычислительные мощности в облаке. Простой веб-интерфейс
сервиса позволяет получить доступ к вычислительным мощностям и настроить с
минимальными затратами ресурсы. Он предоставляет пользователям полный контроль
над вычислительными ресурсами, а также доступную среду для работы. Сервис
сокращает время, необходимое для получения и загрузки нового сервера.
Сценарии тестирования:
· DirectProxy;
· CBRProxy;
· CBRSOAPHeaderProxy;
· XSLTProxy;
· XSLT Enhanced Proxy (Используется FAST XSLT медиатор, управляемый
сквозным(passthrough) траспортом);
· SecureProxy.
Для каждого сценария были проведены тесты с использованием
различных значений: размеров сообщений и количества пользователей. Размеры
образца сообщения колебались от 512 до 100K байт, с одновременным количеством
20, 40, 80, 160, 320, 640, 1280 и 2560 пользователей.
Общие наблюдения
В следующей таблице и графике показаны результаты теста
производительности. Этот график показывает среднее значение среди сообщений
всех размеров.
Количество сообщений для одного клиента N = 1000 при
подключении до 320 параллельных клиентов и N = 10 для реализации более высокого
параллелизма (1280/2560 клиентов).
|
Mule 3.3.0
|
Talend-SE-5.1.1
|
UltraESB 1.7.1
-Enhanced
|
WSO2 ESB 4.5.1
|
WSO2 ESB 4.6.0
|
|
DirectProxy
|
3,375
|
3,315
|
4,839
|
2,879
|
8,278
|
|
CBRProxy
|
1,458
|
3,108
|
4,703
|
2,694
|
7,765
|
|
CBRSOAPHeaderProxy
|
2,262
|
3,185
|
5,063
|
3,118
|
7,573
|
|
CBRTransportHeaderProxy
|
2,225
|
3,751
|
5,523
|
3,502
|
11,024
|
|
XSLTProxy
|
2,225
|
2,333
|
3,387
|
1,735
|
2,504
|
|
XSLTEnhancedProxy
(Fast XSLT mediator)
|
2,225
|
2,333
|
3,387
|
N/A
|
5,473
|
|
Security
|
458
|
534
|
603
|
486
|
560
|
Тем не менее, было обнаружено, что результаты данного теста
были, возможно, ненадежными. Данный факт был исследован более подробно и было
отмечено, что в опубликованных тестах при большом количестве параллельных
клиентов для WSO2 ESB проявляются неожиданно высокие показатели. Для тестов было задано
очень низкое количество сообщений на одного клиента (N = 10) при большом
количестве параллельных клиентов. Это не позволяет дать JVM достаточного
количества времени, чтобы разогреться, а также не представляет собой длительных
испытаний, которые могут показать правдоподобные результаты.
Поэтому было решено повторно запустить тест для WSO2 ESB с использованием 200
сообщений на клиенте с большим числом параллельно работающих клиентов. После
этого аномальных данных больше не наблюдалось. Также были перезапущены тесты
для UltraESB в EC2 с 200 сообщениями на каждом клиенте для более высокого числа
параллельно работающих клиентов. Наблюдения для N = 200 и с большой степенью
параллелизма с UltraESB были намного ниже, чем ранее опубликованные. Тесты для
Mule и Talend с использованием N = 200 не перезапускались. Результаты показаны
в следующей диаграмме и таблице.
В будущих тестах будет использовано N = 200 для высокого
числа параллельно работающих клиентов для обеспечения приемлемых результатов.
Количество сообщений в клиенте N = 1000 в случае до 320
параллельных клиентов и N = 200 для большего числа параллельных клиентов
(1280/2560).
|
Mule 3.3.0
|
Talend-SE-5.1.1
|
UltraESB
1.7.1-Enhanced
|
WSO2 ESB 4.5.1
|
WSO2 ESB 4.6.0
|
|
DirectProxy
|
3,375
|
3,315
|
4,839
|
3,311
|
5,278
|
|
CBRProxy
|
1,458
|
3,108
|
4,703
|
2,920
|
4,078
|
|
CBRSOAPHeaderProxy
|
2,262
|
3,185
|
5,063
|
3,270
|
4,634
|
|
CBRTransportHeaderProxy
|
2,225
|
3,751
|
5,523
|
3,849
|
5,998
|
|
XSLTProxy
|
2,225
|
2,333
|
3,387
|
1,856
|
1,800
|
|
XSLTEnhancedProxy
(Fast XSLT mediator)
|
2,225
|
2,333
|
3,387
|
N/A
|
3,456
|
|
Security
|
458
|
534
|
603
|
529
|
566
|
На приведенном выше графике показано, что WSO2 ESB 4.6.0
работает значительно быстрее, чем ESB 4.5.1 и является конкурентоспособным с
UltraESB. Заметно, что XSLTProxy на WSO ESB проходит
значительно медленнее, чем эквивалентный тест для UltraESB. Но эта проблема
решается путем включения в WSO2 ESB 4.6.0 новой опции FastXSLT, которая
обеспечивает производительность на уровне UltraESB.
Среднее время задержки для WSO2 ESB 4.6.0 и 4.5.1
Бал проведен дополнительный тест для измерения среднего
времени задержки, добавленной в WSO2 версии ESB 4.6.0 и 4.5.1. Была рассчитана
задержка для параллелизма в 20 клиентов и размера сообщения 1000 по следующей
формуле: [Задержка = время прямого вызова - время в обе стороны через ESB]. В следующей
таблице приведены результаты теста:
|
Latency for
1K message
|
ESB 4.6.0
|
ESB 4.5.1
|
|
DirectProxy
|
0.582
|
0.828
|
|
CBRProxy
|
0.742
|
0.979
|
|
CBRSOAPHeaderProxy
|
0.691
|
|
CBRTransportHeaderProxy
|
0.827
|
0.861
|
|
XSLTProxy
|
1.987
|
1.818
|
|
XSLTEnhancedProxy
|
1.345
|
N/A
|
|
SecureProxy
|
8.867
|
9.497
|
Как указано в таблице и на графике, WSO2 ESB обеспечивает
накладную задержку всего в доли миллисекунды в большинстве случаев, что
является очень хорошим показателем.
WSO2 ESB 4.6.0 Анализ использования памяти (После
долгой работы)
Следующие графики иллюстрируют использование памяти после 40
часов непрерывной работы. Как можно увидеть, использование динамической памяти
является стабильной.
На основе представленной информации о технологиях ESB и
проведенных тестах можно сделать некоторые выводы, доказывающие
целесообразность использования определенной технологии ESB из представленных.и
WSO2 имеют множество дополнительных удобных инструментов, помогающих
программисту в разработке приложений, основанных на SOA. Это такие инструменты
как:
· Application Server;
· Governance
Registry;
· Activity
Monitor и др.
Но тесты для Mule показывают более низкие результаты, чем для
WSO2.
В отличие от Mule и WSO2, UltraESB показывает более высокие
результаты в тестах. Но эта технология не имеет такого количества
дополнительных инструментов для облегчения разработки, как представленные выше
технологии, поэтому использование UltraESB на данный момент является
нецелесообразным.SE имеет в своем арсенале службу мониторинга активности,
облегченный контейнер для развертывания различных компонент и приложений и т.д.
Но помимо не очень высоких показателей эффективности в тестах, Talend-SE не
имеет четкой, хорошей документации, что в свою очередь очень затрудняет
использование этого продукта.
На основе вышесказанного можно сделать вывод о том, что
наиболее подходит для использования на данный момент технологии WSO2. Имеется
линейка продуктов WSO2, которая удовлетворяет поставленным требованиям. Они были
выбраны именно потому, что хорошо интегрируются друг с другом, обладают хорошей
устойчивостью и решают поставленные задачи. Также наличие отличной документации
является несомненным преимуществом.
2.5
Анализ используемых средств
WSO2 Enterprise Service Bus
WSO2 ESB - легковесный, имеет высокую производительность,
поэтому именно он лучше всего подходит для использования в системе. На основе
анализа, проведенного ранее, был выбран именно этот продукт для реализации SOA
в приложении.
WSO2 Application Server
WSO2 Application Server является равноправным
WSO2 сервером, включающим хостинг, развертывание и управление различными
приложениями. Поэтому WSO2 Application Server поддерживает хостинг веб-приложений,
веб-сервисов, служб данных и многого другого.
В основе WSO2
Application Server лежат Apache Tomcat, Apache Axis2 и Apache CXF. В соответствии с
упомянутыми фреймворками, WSO2 Application Server использует многие
стандарты веб-сервисов, такие как JAX-WS 2.2, JAX-RS 2.0 спецификации, SOAP 1.1 & 1.2, WSDL 1.1 & 2.0, все WS-* стандарты и др..
Аналогичным образом он так же поддерживает широкий спектр транспортных
протоколов, в том числе HTTP/S, JMS, SMTP и TCP. Более того, WSO2 Application Server может принимать и
обрабатывать сообщения, предназначенные для Axis2 и CXf веб-сервисов (т.е.
поддерживает работу с различными веб-сервисами). Поддержка Apache Tomcat сделала возможным его
работу в качестве контейнера приложений.
Следующее изображение показывает архитектуру WSO2 Application
Server.
Рис. 6. Архитектура WSO2 Application Server
Application Server может принимать SOAP и REST сообщения из
веб-каналов, в то время как транспортный уровень сервера одновременно прослушивает
сообщения от настроенного протокола.
Поскольку в основе сервера лежит фреймворк Axis2, то запросы
направляются через канал сообщений, и набор обработчиков будет делать
дополнительную обработку сообщений, таких как операции QoS (безопасность, надежный
обмен сообщениями, информацией расшифровки и так далее). Полученные сообщения
передаются в приемник сообщений, который принимает решение о том, какой
веб-сервис должен быть вызван. Кроме того, клиенты веб-приложений могут
вызывать веб-приложения, развернутые внутри сервера приложений непосредственно
через транспорт Tomcat (HTTP / S). Application Server так же поставляется с
полным набором API для разработки приложений, обеспечивающими безопасность,
управление данными, управление метаданными и производительностью системы.
Особенности
· Хостинг и управление
веб-приложениями:
o Запуск любого
стандартного файла WAR, также получение решений для RESTful сервисов;
o Полная административная
консоль для WAR файлов;
o Комплексное управление
безопасностью приложений;
o Авторизация через интеграцию с WSO2 Enterprise Service
Bus и WSO2 Identity
Server;
o Источник данных
управления для масштабируемого управления данными;
· Хостинг и управление
веб-сервисами:
o Поддержка SOAP, RESTful и JAX-WS сервисов;
o Интеграция Apache Axis2 и Apache CXF инструментов веб-
сервисов;
o Комплексное управление
пользователями с помощью интеграции с WSO2 Identity Server;
o Встроенная поддержка для
сервисов передачи данных;
o Кластеризация и
репликация HTTP-сессии для веб-служб;
o Управление и мониторинг.
· Богатый контекст для
программирования масштабируемых приложений и сервисов:
o Всеобъемлющие простые в
использовании API-интерфейсы для разработки корпоративных приложений,
освобождающие разработчиков от сложности слежения за безопасностью,
производительностью, управлением данными, метаданными и системами управления;
o Распределенное
кэширование для больших масштабных приложений;
o Общий реестр метаданных и
хранилище для любой области применения метаданных с помощью встроенного реестра
или WSO2 Governance Registry;
o JNDI провайдер для
доступа к общему источнику данных и других ресурсов;
o Распределенный обмен
кэшем и метаданными для различных приложений и услуг;
· Масштабируемость,
легковесность, простота развертывания:
o Легкая разработка,
отладка и развертывание как приложений, так и сервисов с инструментами для
отслеживания сообщений и интерактивного тестирования;
o Очень простое управление безопасностью;
o Настройка сервера и выбор
способа развертывания;
o Интеграция с SVN, Maven,
Ant и другими стандартными инструментами для разработки и развертывания;
o Интегрировано с WSO2
Developer Studio, Eclipse IDE на основе всех продуктов WSO2.
WSO2 Governance Registry
Registry - это компонент управления ресурсами в системе
SOA. WSO2 Governance Registry является SOA интегрированным с реестром /
репозиторием, обогащен множеством различных возможностей и функций. Все
продукты WSO2 включают Registry ядро в WSO2 Carbon, который обеспечивает базовую регистрацию и
функциональность репозитория. Ядро Registry определяет пространство реестра, которое
используется для хранения данных и сохранения конфигурации. Пространство Registry, отведенное на каждый
продукт содержит три основных раздела:
· Local Data
Repository
Содержит конфигурацию системы, такую как данные времени
выполнения, являющейся локальной для одного экземпляра продукта. Например,
локальное хранилище данных используется для хранения настроенных конфигураций,
которые являются локальными для каждого экземпляра.
· Configuration
Registry
Является наиболее широко используемым разделом в пространстве
реестра, содержит конкретную конфигурацию продукта. Эти конфигурации могут быть
разделены между несколькими экземплярами одного и того же продукта (например,
кластер из узлов ESB).
· Governance
Registry
Содержит данные и конфигурацию, общую для всех платформ. WSO2
Governance Registry оставляет использование
этой части пространства реестра для хранения сервисов и связанных с ними
метаданных, таких как WSDL, схем и конечных точек.
WSO2 Governance Registry предоставляет веб и APP
интерфейсы, чтобы делать видимой извне ее функциональность. Встроенный реестр
публикует все свои методы через два основных интерфейса:
· Registry API
Обеспечивает все операции, связанные с ресурсами.
· User Manager
API
Предоставляет польз-ля/роль и особенности авторизации.
Слой доступа к данным выполняется SQL запросом для
взаимодействия с базой данных с целью выполнения различных Registry операций. Registry может быть настроен с
многими СУБД, такими как MySQL, MSSQL, Oracle, H2, Derby и т.д. На рисунке ниже
показана упрощенная схема архитектуры WSO2 Registry.
Рис. 7. Архитектура WSO2 Registry
Управление жизненным циклом является ключевым аспектом
управления в реестре, где ресурсы сохраняются в различных стадиях жизненного
цикла, где они могут изменяться в соответствии с требованиями процесса.
WSO2
Carbon
WSO2 Carbon переопределяет связующее программное обеспечение
путем предоставления интегрированной и компонентной промежуточной платформы,
которая адаптируется к специфическим потребностям любого IT-проекта на предприятии.
Открытый исходный код, основанный на стандартах, WSO2 Carbon
позволяет разработчикам быстро организовать бизнес-процессы, создавать
приложения и разрабатывать сервисы с использованием WSO2 Developer Studio и обширного спектра
бизнес- и технических легко интегрируемых сервисов.
Базовая часть фреймворка WSO2 Carbon функциониует, как
"Eclipse for servers" и включает в себя общие возможности, разделяемые всеми
продуктами WSO2, такими как встроенный реестр, управление пользователями,
протоколы, безопасность, логирование, кластеризацию, кэширование и
регулирование сервисов, координации и GUI-фреймворк.
Особенности
· Поддержка базовой
функциональности Enterprise SOA
o Механизмы предоставления
и потребления сервисов, посредничество сообщениями, управление сервисами,
бизнес-процессами и мониторингом сервисов;
o Поддержка стандартов,
таких как WS-*, REST и других бинарных и не бинарных протоколов;
o Встроенный контроль
качества (QoS) возможностей, таких как безопасность, надежность обмена
сообщениями и регулирование.
· Расширение от клиентов к
облаку
o Развертывание одного и
того же кода как на отдельном WSO2 Carbon сервере, так и на облачной платформе
WSO2 Stratos;
o Создание многопользовательских
приложений с использованием Carbon API, не беспокоясь о сложности, лежащей в
его основе.
· QoS
o Поддержка высокой доступности развертывания;
o Горизонтальное
масштабирование с помощью кластеризации с использованием серверной архитектуры
без состояния;
o Динамическое обнаружение
сервисов с использованием WS-Discovery.
· Синхронизация артефактов
через кластеры
o Дополнительная поддержка WSO2 Governance Registry в качестве репозитория;
o Большое количество
серверных артефактов может быть легко развернуто «на одном дыхании».
· Управление пользователями
через любой Carbon продукт
o Поддержка аутентификации
и авторизации на основе ролей.
· Интеграция с Governance
Registry
o Управление и контроль
крупномасштабного развертывания, в том числе кластерных серверов и облачных
реализаций.
· Легкая расширяемость и
перспективность
o Компоненты, не
используемые в настоящее время могут быть подключены тогда, когда
ИТ-инфраструктура этого потребует;
Java
Java - объектно-ориентированный язык программирования,
разработанный компанией Sun Microsystems (в последующем приобретённой компанией
Oracle). Приложения Java обычно компилируются в специальный байт-код, поэтому
они могут работать на любой виртуальной Java-машине (JVM) вне зависимости от
компьютерной архитектуры.
Microsoft
SQL Server
Microsoft SQL Server - система управления реляционными базами
данных (СУБД), разработанная корпорацией Microsoft. Основной используемый язык
запросов - Transact-SQL, создан совместно Microsoft и Sybase. Transact-SQL
является реализацией стандарта ANSI/ISO по структурированному языку запросов
(SQL) с расширениями. Используется для работы с базами данных размером от
персональных до крупных баз данных масштаба предприятия; конкурирует с другими
СУБД в этом сегменте рынка.
Фреймворк
Spring
Spring используется для больших корпоративный приложений, там
есть все для этого необходимое.
Основная функция Spring - интеграция слоев приложения в одно
целое при помощи шаблона Dependency Injection.nDependency Injection
определяет зависимости компонента от других компонентов на уровне
интерфейсов.Framework может быть рассмотрен как коллекция меньших фреймворков
или фреймворков во фреймворке. Большинство этих фреймворков может работать
независимо друг от друга, однако, они обеспечивают большую функциональность при
совместном их использовании. Эти фреймворки делятся на структурные элементы
типовых комплексных приложений:
3.
Реализация
.1 Описание архитектуры приложения
Рис. 8. Компонентная диаграмма
На рис. 8 изображена компонентная диаграмма модуля парковки
приложения. Она состоит из 6 основных компонентов:
· HeadUnit. Устройство, которое
запрашивает услугу (устройство навигации в автомобиле), посылает свой запрос на
Device Gateway.
· DeviceGateway. Все запросы,
поступающие от внешних устройств, попадают на DeviceGateway. Device Gateway
действует как прокси между мобильными устройствами или приборами,
установленными в автомобиле, и другими кластерами. Device Gateway представляет
собой группу компонентов, отвечающих за обработку входящих сообщений или
запросов на обслуживание с мобильных устройств или других клиентов сети. Этот
компонент является прокси-сервисом, который определяет источник запроса и
перенаправляет запрос к нужному сервису. В случае модуля парковки это Parking EndUserService.
Входящий запрос перенаправляется в целевую службу, которая
является частью кластера "End User Service".
· EndUserService. Компонент содержит
веб-представление, сервисы для модуля парковки и другие необходимые
составляющие для работы приложения (API, контроллер для обработки запросов клиента и
т.д.). Для получения необходимой информации о парковочных местах, приложение
отсылает запрос к внешним сервисам. Используется два внешних сервиса, выбор
сервиса происходит в зависимости от текущего положения автомобиля (от страны).
В случае, если автомобиль расположен в Европе, используется сервис EuropeService, если в Японии, то выбор
сервиса - JapanService. Использование двух сервисов обусловлено той
предоставляемой информацией, которую сервис может выдать. Так, автомобиль может
находиться за пределами европейской части (в частности, Японии), а EuropeService не может предоставить
информацию об этой стране. В соответствии со спецификой работы с внешними
сервисами, потребовалось выделить два провайдера, каждый из которых
обрабатывает требуемую информацию и преобразовывает ее к необходимому формату
для дальнейшей передачи этой информации приложению и ее обработки соответствующим
образом.
· ServiceIntegration. Данный компонент
содержит сервисы для управления, мониторинга и администрирования платформы.
Этот слой соединяет все другие, и наследует управление интерфейсами и сервисные
адаптеры. В этом компоненте содержатся два прокси-сервиса, работающих с
внешними сервисами. При обращении к внешнему сервису обращение идет не
напрямую, а через прокси. Главная задача прокси-сервиса - перенаправление
запроса. Для каждого провайдера используется свой прокси.
· EuropeService. Внешний сервис. Запросы
к нему поступают от прокси-сервиса PY_EuropeAdapter.
· JapanService. Внешний сервис. Запросы
к нему поступают от прокси-сервиса PY_JapanAdapter.
3.2 Структура базы данных
Рис. 8. Структура базы данных (PARKING_SETTINGS)
PARKING_SETTINGS. Содержит информацию о настройках приложения для
парковки:
· Отображаемое на странице максимально
возможное количество результатов поиска;
· Отображаемое на странице количество
недавно просмотренных парковочных стоянок;
· Максимально возможное количество парковок,
добавляемых в качестве избранных;
· Радиус, по которому будет производиться
поиск парковочных стоянок относительно текущего положения автомобиля;
· URL-адреса внешних сервисов,
к которым будет обращаться приложение для получения информации о парковочных
стоянках.
Рис. 9. Структура базы данных
(PARKING_FAVORITES, PARKING_RECENTLY_VIEWED)
_FAVORITES. Содержит информацию о парковках, которые пользователь
добавил в избранное:
· Название парковки;
· Тип парковки;
· Код страны;
· Индекс;
· Город;
· Улица;
· Координаты: длину и широту.
PARKING_RECENTLY_VIEWED. Содержит информацию о недавно просмотренных
парковочных стоянках. Таблица имеет такую же структуру, как и таблица PARKING_FAVORITES.
3.3 Реализация классов
Диаграмма пакетов
Рис. 10. Диаграмма пакетов
В приложении есть 5 основных пакетов, каждый из пакетов
представляет из себя набор интерфейсов и классов, реализующих функциональность
определенного слоя:
· Пакет model: содержит классы-сущности для
хранения в базе данных;
· Пакет api: содержит интерфейсы,
реализующиеся в бизнес-логике;
· Пакет bl: содержит класс с бизнес логикой:
основной класс ParkingService и вспомогательные классы для получения данных от
внешних сервисов: adac и navi;
· Пакет dao: классы для доступа к данным.
· Пакет ctrl: содержит класс-контроллер,
обрабатывающий все запросы, приходящие от клиента.
Слой DAO
Рис. 11. Слой DAO
Описание основных методов
· addFavorites(int,
Parking, int):List<Parking> - добавляет парковочную стоянку (объект Parking) в базу данных в таблицу
PARKING_FAVORITES. Возвращает список избранных паркингов.
· addRecentlyViewed(int,
Parking, int):List<Parking> - добавляет парковочную стоянку (объект Parking) в базу данных в таблицу
PARKING_RECENTLY_VIEWED. Возвращает список недавно просмотренных паркингов.
· getFavoriteParkings(int):List<Parking>
- получает список паркингов из таблицы
PARKING_FAVORITES для конкретного пользователя.
· getRecentlyViewedParkings(int):List<Parking>
- получает список паркингов из таблицы
PARKING_RECENTLY_VIEWED для конкретного пользователя.
· getServiceOptions():ServiceOptions - получает специфические
опции, присущие данному сервису для конкретного пользователя.
Контроллер
Рис. 12. Контроллер
Класс-контроллер, обрабатывающий все запросы, приходящие от
клиента.
Описание основных методов
· addToFavorites(HttpServletRequest, HttpServletResponse, String): void - вызывает метод сервиса
ParkingService, который добавляет
конкретную парковку к списку избранных для конкретного пользователя. Сохранение
в таблицу PARKING_FAVORITES.
· getGeoLocationsForAddress(HttpServletRequest, HttpServletResponse, String): void - вызывает метод сервиса
ParkingService, который получает список
местонахождений по конкретному адресу.
· getLocationHistory(HttpServletRequest, HttpServletResponse, String): void - вызывает метод сервиса
ParkingService, который получает информацию
о запросах по нахождению парковок от конкретного пользователя.
· getParkingById(HttpServletRequest, HttpServletResponse, String): void - вызывает метод сервиса
ParkingService, который получает
парковку (объект Parking) по Id.
· nearGeoLocation(HttpServletRequest, HttpServletResponse, Double, Double, Double, String, boolean, boolean, Integer): void - вызывает метод сервиса
ParkingService, который получает
информацию о местонахождениях парковок расположенных по определенным параметрам
(долгота, широта, заданный радиус и т.д.).
· removeAllFavorites(HttpServletRequest, HttpServletResponse): void - вызывает метод сервиса
ParkingService, который удаляет все
избранные парковки конкретного пользователя.
· removeAllRecentlyViewed(HttpServletRequest, HttpServletResponse): void - вызывает метод сервиса
ParkingService, который удаляет все
недавно просмотренные парковки конкретного пользователя.
· removeFromFavorites(HttpServletRequest, HttpServletResponse, int): void - вызывает метод сервиса
ParkingService, который удаляет
избранную парковку по Id.
· removeFromRecentlyViewed(HttpServletRequest, HttpServletResponse, int): void - вызывает метод сервиса
ParkingService, который удаляет недавно
просмотренную парковку по Id.
· resetLocationHistory(HttpServletRequest, HttpServletResponse): void - вызывает метод сервиса
ParkingService, который стирает историю
запросов по месту.
· setFavorites(HttpServletRequest, HttpServletResponse, String): void - вызывает метод сервиса
ParkingService, который добавляет
текущую парковку в список избранных.
Бизнес логика
Рис. 13. Диаграмма пакетов бизнес логики
Рис. 14. Диаграмма класса сервиса ParkingService бизнес
логики
Описание основных методов.
Класс ParkingService. Описанные ниже методы используется в
контроллере. Класс ParkingService инжектится в контроллер.
· addToFavorites(int, String, String): boolean - добавляет
конкретную парковку к списку избранных для конкретного пользователя. Возвращает
true при успешном выполнении, иначе false.
· getGeoLocationsForAddress(int, String): List<GeoLocation> - получает список
местонахождений (GeoLocation) по конкретному адресу.
· getLocationHistory(int): List<LocationEntry> -получает информацию
о запросах по нахождению парковок от конкретного пользователя.
· getParking
(int, String, String): void - получает парковку (объект Parking) по Id.
· nearLocation(int,
IGeoPoint, Double, String, String, boolean, boolean, int):
PagedResult<Parking> -получает информацию о местонахождениях парковок расположенных по определенным параметрам (долгота, широта, заданный радиус и т.д.). Имеется аналогичный
метод, но с другим набором параметров.
· removeAllFavorites(int): void -удаляет все избранные
парковки конкретного пользователя.
· removeFromFavorites(int, int): void - удаляет избранную
парковку по Id.
· removeFromRecentlyViewed(int, int): void - удаляет недавно
просмотренную парковку по Id.
· resetLocationHistory(int): void - стирает историю
запросов по месту.
· setFavorites(int, List<String>, String): void - добавляет текущую
парковку в список избранных.
Рис. 15. Диаграмма классов для провайдера
Здесь изображена диаграмма классов провайдера: интерфейс и
его реализация. В соответствии со спецификой работы с внешними сервисами,
потребовалось выделить два провайдера, каждый из которых обрабатывает требуемую
информацию и преобразовывает ее к необходимому формату для дальнейшей передачи
этой информации приложению и ее обработки соответствующим образом. На диаграмме
изображен один провайдер для демонстрации его функциональности -
EuropeProvider.
Основные методы.
· convertParking(ParametersGetParkingPlaceInfoByIdOutput):Parking - преобразовывает
входящую информацию по определенным входным данным к объекту Parking.
· convertParkings(ArrayOfParametersSearchForParkingPlaceByGeoInfoOutput, int, int): List<Parking> - преобразовывает
входящую информацию по определенным входным данным к объекту List<Parking>.
· convertGeoLoc(ParametersGetLocationCoordinatesOutput):GeoLocation - преобразовывает
входящую информацию по определенным входным данным к объекту GeoLocation.
· convertGeoLocs(ArrayOfParametersGetLocationCoordinatesOutput): List<GeoLocation> - преобразовывает
входящую информацию по определенным входным данным к объекту List<GeoLocation>.
· isConnected():boolean - проверка на удачное
соединение с провайдером.
API
Рис. 16. API
3.4
Развертывание приложения
Рис. 17. Диаграмма развертывания
На рис. 16 изображена диаграмма развертывания модуля парковки
приложения.
Имеется узел «Carbon Server Claster» DeviceGateway со средой исполнения WSO2 ESB. На данном WSO2 ESB разворачивается web.xml.
Данный артефакт является прокси-сервисом, который определяет источник запроса и
перенаправляет запрос к нужному сервису.
Имеется узел «Carbon
Server Claster» EndUserService с сервером приложений WSO2 AS. На сервере приложений
разворачивается артефакт web.war. Web.war содержит внутри себя следующие артефакты:
· parking-enduser-api.jar
(содержит классы api);
· parking-enduser-business.jar
(содержит классы c бизнес
логикой модуля);
· parking-enduser-presentation.jar (содержит класс
контроллера, который принимает все запросы от внешнего устройства и
обрабатывает их соответствующим образом);
Имеется узел «Carbon
Server Claster» ServiceIntegration со средой исполнения WSO2 ESB. На данном WSO2 ESB разворачиваются два
прокси-сервиса адаптера. Это артефакты PY_EuropeAdapter.xml и PY_JapanAdapter.xml. Эти два
прокси-сервиса работают с внешними сервисами. При обращении к внешнему сервису
обращение идет не напрямую, а через PY_EuropeAdapter и PY_JapanAdapter (в зависимости от страны). Главная задача прокси-сервиса
- перенаправление запроса. Для каждого внешнего сервиса используется свой
прокси.
Помимо вышеперечисленного имеется еще два артефакта: apps-web-main-carbon.car и parking-enduser.car. Apps-web-main-carbon.car разворачивается на WSO2 AS и WSO2 ESB и содержит в себе web.war и web.xml. Parking-enduser.car разворачивается на
другом WSO2 ESB и содержит в себе два артефакта: PY_EuropeAdapter.xml и PY_JapanAdapter.xml.
Также есть узел - сервер базы данных MS SQL 2008.
Заключение
В рамках данной работы был проведен анализ существующих
инструментов, помогающих при построении приложений, в основе которых лежит ESB.
С использованием продукта WSO2 был разработан модуль для навигационной системы.
В ходе реализации были решены следующие задачи:
· Были определены используемые технологии;
· Была разработана база данных,
удовлетворяющая поставленным целям;
· Была продумана общая архитектура модуля,
который будет удовлетворять поставленным требованиям.
На основе решенных задач был создан модуль для системы навигации,
который был внедрен в существующую навигационную систему. Он полностью
удовлетворяет поставленным требованиям системы. Модуль предоставляет
пользователю возможность нахождения парковочного места относительного текущего
позиционирования автомобиля. Модуль позволяет искать парковочные стоянки по
заданным критериям поиска, предоставлять информацию о них, добавлять эти
парковочные стоянки в список избранных, хранить их в системе.
Список литературы
1. Craig Walls. Spring in Action.
Third Edition.- Manning, 2011. -426 с.
2. Рик Робинсон. Статья. Сценарии и решения
использования шины Enterprise Service Bus в сервис-ориентированной архитектуре,
2011.
3. Васильев А.Н. Java.
Объектно-ориентированное программирование. - Питер, 2011. -400 с.
. Герберт Шилдт. Java. Полное руководство.
8-е издание. - Manning, 2012. - 1104 с.
. Брюс У. Перри. Java сервлеты и JSP.
Сборник рецептов. - O'Reilly, 2006. - 768 c.
. Хабиббулин И. Создание распределенных
приложений на Java 2. - Мастер, 2002. - 704 с.
. Блинов И.Н., Романчик В.С. Java.
Промышленное программирование. - Универсал Пресс, 2007. - 704 с.
. Брюс Эккель. Философия Java. - Питер,
2009. - 640 с.
. Гранд М. Шаблоны проектирования в JAVA.
Каталог популярных шаблонов проектирования, проиллюстрированных при помощи UML.
- O'Reilly, 2004. - 559 с.
. Дэвид М. Герц. Java Server Pages. Библиотека профессионала. - Sun, 2002. - 448 c.
. Флэнаган Дэвид. Java в примерах. Справочник.
- O'Reilly, 2003. -
664 с.
. Марти Холл. Программирование для Web. - Sun, 2002. - 1264 с.
13. Тимур Машнин. Web-сервисы Java. - BHV,
2012. - 560 с.
14. WSO2 Reference Documentation
-
(http://docs.wso2.org/wiki/dashboard.action/).
15. Spring Reference Documentation -
(http://www.springsource.org/documentation).
16. Mule official website -
http://www.mulesoft.com/
17. Mule official website
-http://www.talend.com/
. Maven Reference Documentation -http://maven.apache.org/
19. Антон Дмитров. Сервисно-ориентированная
архитектура в современных моделях бизнеса. - BHV, 2006. - 224 с.
20. Michael Bell. Service-Oriented
Modeling (SOA). - O'Reilly, 2008. -
384 с.
. James Bean. SOA and Web Services
Interface Design. - O'Reilly, 2010. -
с.
. Frank Cohen. Fast SOA. - Sun,
2010. - 296 с.
23. Dan Woods. Enterprise SOA. -
Manning, 2006. - 452 с.
. Eric Newcomer. Understanding SOA
with Web Services (Independent Technology Guides). - Sun, 2004. - 408 с.
. Michael Rosen. Applied SOA. -
Manning, 2008. - 696 с.