Анализ существующих инструментов, помогающих при построении приложений, в основе которых лежит ESB. Разработка модуля для навигационной системы, основные требования к нему, структура, обоснование инструментов. Сервис-ориентированная архитектура.
Краткое сожержание материала:

Размещено на

Размещено на

Оглавление

• Введение 3
• 1. Постановка задачи 5
• 2. Анализ задачи 6
• 2.1 Анализ требований заказчика 6
• 2.2 Анализ архитектуры приложения 8
• 2.3 Анализ предметной области 12
• 2.3.1 Сервисная шина предприятия 12
• 2.3.2 Основы архитектуры SOA 13
• 2.3.3 Составляющие базовой архитектуры SOA 14
• 2.3.4 Роль ESB в архитектуре SOA 14
• 2.3.5 Роль веб-сервисов в SOA 15
• 2.4 Анализ существующих аналогов ESB технологий 16
• 2.4.1 Mule ESB 16
• 2.4.2 Talend-SE 17
• 2.4.3 UltraESB 20
• 2.4.4 WSO2 ESB 21
• 2.4.5 Проведение тестов 24
• 2.5 Анализ используемых средств 31
• 2.5.1 WSO2 Enterprise Service Bus 31
• 2.5.2 WSO2 Application Server 31
• 2.5.3 WSO2 Governance Registry 34
• 2.5.4 WSO2 Carbon 36
• 2.5.5 Java 37
• 2.5.6 Microsoft SQL Server 37
• 2.5.7 Фреймворк Spring 38
• 3. Реализация 39
• 3.1 Описание архитектуры приложения 39
• 3.2 Структура базы данных 41
• 3.3 Реализация классов 43
• 3.4 Развертывание приложения 52
• Заключение 54
• Список литературы 55

Введение

Корпоративная сервисная шина ESB (Enterprise Service Bus) - это инфраструктурная платформа, которая объединяет стандартизованную сервис-ориентированную архитектуру с мощными веб-сервисами. Данная технология является принципиально новым, более мощным и эффективным подходом к интеграции приложений. В последнее время эта технология довольно быстро развивается и является наиболее мощным, признанным инструментом, который легко адаптируется для реализации механизмов интеграции.

ESB имеет ряд преимуществ:

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

- Все приложения быстро настраиваются, так как были созданы на совершенно новой платформе, которая отличается от обычных клиент-серверных систем.

- В приложениях с унаследованными системами, ESB убирает потребность сложного процесса их внедрения. Приложения и платформу легко установить на “шину” и обеспечить их сосуществование независимо друг от друга.

Технология ESB, в первую очередь, предназначена для крупных компаний и корпораций, которым необходимо достичь эффективного взаимодействия между приложениями, максимизировать использование ресурсов, а также обеспечить надежные средства построения соответствий между документами.

На данный момент существует множество инструментов, позволяющих без особых усилий создавать приложения на основе ESB. Каждый из них имеет свои преимущества и недостатки.

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

1. Постановка задачи

Цель работы: анализ существующих инструментов, помогающих при построении приложений, в основе которых лежит ESB. С использованием выбранного инструмента в качестве примера будет разработан модуль для навигационной системы. Функциональность модуля будет включать нахождение парковочного места относительного текущего позиционирования автомобиля. Модуль необходимо внедрить в существующую систему таким образом, чтобы он удовлетворял поставленным требованиям к системе.

Для достижения поставленных целей необходимо решить следующие задачи:

· Определиться с используемыми технологиями;

· Также требуется проанализировать и выбрать инструмент для создания модуля, в основе которого будет лежать сервис-ориентированная архитектура.

· Разработать базу данных, удовлетворяющую поставленным целям;

· Продумать общую архитектуру модуля, который будет удовлетворять поставленным требованиям.

Состав технических средств определен следующим образом:

· Сервер базы данных Microsoft SQL Server;

· Среда разработки - Java (версия 1.6).

2. Анализ задачи

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 Platfor...