Среднее время задержки для 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	0.857
CBRTransportHeaderProxy	0.827	0.861
XSLTProxy	1.987	1.818
XSLTEnhancedProxy	1.345	N/A
SecureProxy	8.867	9.497

Рис. 9. Задержка для WSO2 ESB 4.6.0 и 4.5.1 .

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

WSO2 ESB 4.6.0 Анализ использования памяти (После долгой работы)

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

Рис. 10. Анализ использования памяти.

Рис. 11. Анализ использования памяти.

Заключение

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

Mule и WSO2 имеют множество дополнительных удобных инструментов, помогающих программисту в разработке приложений, основанных на SOA. Это такие инструменты как:

· Application Server;

· Governance Registry;

· Activity Monitor и др.

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

В отличие от Mule и WSO2, UltraESB показывает более высокие результаты в тестах. Но эта технология не имеет такого количества дополнительных инструментов для облегчения разработки, как представленные выше технологии, поэтому использование UltraESB на данный момент является нецелесообразным.

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

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

Анализ используемых средств

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.

Рис. 12. Архитектура WSO2 Application Server

WSO2 Application Server может принимать SOAP и REST сообщения из веб-каналов, в то время как транспортный уровень сервера одновременно прослушивает сообщения от настроенного протокола.

Поскольку в основе сервера лежит фреймворк Axis2, то запросы направляются через канал сообщений, и набор обработчиков будет делать дополнительную обработку сообщений, таких как операции QoS (безопасность, надежный обмен сообщениями, информацией расшифровки и так далее). Полученные сообщения передаются в приемник сообщений, который принимает решение о том, какой веб-сервис должен быть вызван. Кроме того, клиенты веб-приложений могут вызывать веб-приложения, развернутые внутри сервера приложений непосредственно через транспорт Tomcat (HTTP / S).

WSO2 Application Server так же поставляется с полным набором API для разработки приложений, обеспечивающими безопасность, управление данными, управление метаданными и производительностью системы.

Особенности

· Хостинг и управление веб-приложениями:

• Запуск любого стандартного файла WAR, также получение решений для RESTful сервисов;
• Полная административная консоль для WAR файлов;
• Комплексное управление безопасностью приложений;
• Авторизация через интеграцию с WSO2 Enterprise Service Bus и WSO2 Identity Server;
• Источник данных управления для масштабируемого управления данными;
• Хостинг и управление веб-сервисами:
• Поддержка SOAP, RESTful и JAX-WS сервисов;
• Интеграция Apache Axis2 и Apache CXF инструментов веб- сервисов;
• Комплексное управление пользователями с помощью интеграции с WSO2 Identity Server;
• Встроенная поддержка для сервисов передачи данных;
• Кластеризация и репликация HTTP-сессии для веб-служб;
• Управление и мониторинг.
• Богатый контекст для программирования масштабируемых приложений и сервисов:
• Всеобъемлющие простые в использовании API-интерфейсы для разработки корпоративных приложений, освобождающие разработчиков от сложности слежения за безопасностью, производительностью, управлением данными, метаданными и системами управления;
• Распределенное кэширование для больших масштабных приложений;
• Общий реестр метаданных и хранилище для любой области применения метаданных с помощью встроенного реестра или WSO2 Governance Registry;
• JNDI провайдер для доступа к общему источнику данных и других ресурсов;
• Распределенный обмен кэшем и метаданными для различных приложений и услуг;
• Масштабируемость, легковесность, простота развертывания:
• Легкая разработка, отладка и развертывание как приложений, так и сервисов с инструментами для отслеживания сообщений и интерактивного тестирования;
• Очень простое управление безопасностью;
• Настройка сервера и выбор способа развертывания;
• Интеграция с SVN, Maven, Ant и другими стандартными инструментами для разработки и развертывания;
• Интегрировано с 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.

Рис. 13. Архитектура WSO2 Registry

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

WSO2 Carbon

WSO2 Carbon переопределяет связующее программное обеспечение путем предоставления интегрированной и компонентной промежуточной платформы, которая адаптируется к специфическим потребностям любого IT-проекта на предприятии.

Открытый исходный код, основанный на стандартах, WSO2 Carbon позволяет разработчикам быстро организовать бизнес-процессы, создавать приложения и разрабатывать сервисы с использованием WSO2 Developer Studio и обширного спектра бизнес- и технических легко интегрируемых сервисов.

Базовая часть фреймворка WSO2 Carbon функциониует, как "Eclipse for servers" и включает в себя общие возможности, разделяемые всеми продуктами WSO2, такими как встроенный реестр, управление пользователями, протоколы, безопасность, логирование, кластеризацию, кэширование и регулирование сервисов, координации и GUI-фреймворк.

Особенности

• Поддержка базовой функциональности Enterprise SOA

• Механизмы предоставления и потребления сервисов, посредничество сообщениями, управление сервисами, бизнес-процессами и мониторингом сервисов;
• Поддержка стандартов, таких как WS-*, REST и других бинарных и не бинарных протоколов;
• Встроенный контроль качества (QoS) возможностей, таких как безопасность, надежность обмена сообщениями и регулирование.
• Расширение от клиентов к облаку
• Развертывание одного и того же кода как на отдельном WSO2 Carbon сервере, так и на облачной платформе WSO2 Stratos;
• Создание многопользовательских приложений с использованием Carbon API, не беспокоясь о сложности, лежащей в его основе.
• QoS
• Поддержка высокой доступности развертывания;
• Горизонтальное масштабирование с помощью кластеризации с использованием серверной архитектуры без состояния;
• Динамическое обнаружение сервисов с использованием WS-Discovery.
• Синхронизация артефактов через кластеры
• Дополнительная поддержка WSO2 Governance Registry в качестве репозитория;
• Большое количество серверных артефактов может быть легко развернуто «на одном дыхании».
• Управление пользователями через любой Carbon продукт
• Поддержка аутентификации и авторизации на основе ролей.
• Интеграция с Governance Registry
• Управление и контроль крупномасштабного развертывания, в том числе кластерных серверов и облачных реализаций.
• Легкая расширяемость и перспективность
• Компоненты, не используемые в настоящее время могут быть подключены тогда, когда ИТ-инфраструктура этого потребует;

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 определяет зависимости компонента от других компонентов на уровне интерфейсов.

Spring Framework может быть рассмотрен как коллекция меньших фреймворков или фреймворков во фреймворке. Большинство этих фреймворков может работать независимо друг от друга, однако, они обеспечивают большую функциональность при совместном их использовании. Эти фреймворки делятся на структурные элементы типовых комплексных приложений:

Реализация

3.1 Описание архитектуры приложения

Рис. 14 Компонентная диаграмма

На рис. 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 Структура базы данных

Рис. 15. Структура базы данных (PARKING_SETTINGS)

PARKING_SETTINGS. Содержит информацию о настройках приложения для парковки:

· Отображаемое на странице максимально возможное количество результатов поиска;

· Отображаемое на странице количество недавно просмотренных парковочных стоянок;

· Максимально возможное количество парковок, добавляемых в качестве избранных;

· Радиус, по которому будет производиться поиск парковочных стоянок относительно текущего положения автомобиля;

· URL-адреса внешних сервисов, к которым будет обращаться приложение для получения информации о парковочных стоянках.

Рис. 16. Структура базы данных (PARKING_FAVORITES, PARKING_RECENTLY_VIEWED)

PARKING_FAVORITES. Содержит информацию о парковках, которые пользователь добавил в избранное:

· Название парковки;

· Тип парковки;

· Код страны;

· Индекс;

· Город;

· Улица;

· Координаты: длину и широту.

PARKING_RECENTLY_VIEWED. Содержит информацию о недавно просмотренных парковочных стоянках. Таблица имеет такую же структуру, как и таблица PARKING_FAVORITES.

3.3 Реализация классов

Диаграмма пакетов

Рис. 17. Диаграмма пакетов

В приложении есть 5 основных пакетов, каждый из пакетов представляет из себя набор интерфейсов и классов, реализующих функциональность определенного слоя:

· Пакет model: содержит классы-сущности для хранения в базе данных;

· Пакет api: содержит интерфейсы, реализующиеся в бизнес-логике;

· Пакет bl: содержит класс с бизнес логикой: основной класс ParkingService и вспомогательные классы для получения данных от внешних сервисов: adac и navi;

· Пакет dao: классы для доступа к данным.

· Пакет ctrl: содержит класс-контроллер, обрабатывающий все запросы, приходящие от клиента.

3.3.2 Слой DAO

Рис. 18. Слой 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 - получает специфические опции, присущие данному сервису для конкретного пользователя.

Контроллер

Рис. 19. Контроллер

Класс-контроллер, обрабатывающий все запросы, приходящие от клиента.

Описание основных методов

· 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, который добавляет текущую парковку в список избранных.

Бизнес логика

Рис. 20. Диаграмма пакетов бизнес логики

Диаграмма классов бизнес логики:

Рис. 21. Диаграмма класса сервиса 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 - добавляет текущую парковку в список избранных.

Рис. 22. Диаграмма классов для провайдера.

Здесь изображена диаграмма классов провайдера: интерфейс и его реализация. В соответствии со спецификой работы с внешними сервисами, потребовалось выделить два провайдера, каждый из которых обрабатывает требуемую информацию и преобразовывает ее к необходимому формату для дальнейшей передачи этой информации приложению и ее обработки соответствующим образом. На диаграмме изображен один провайдер для демонстрации его функциональности – 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

Рис. 23. API

Model

Рис. 24. Модель

Здесь изображена диаграмма классов модели. Класс, описывающий модель парковки – Parking. Основные атрибуты модели:

· Name: название парковки;

· Hours: часы работы парковки;

· Distance: расстояние до парковки;

· Type: тип парковки;

· Rate: тариф оплаты;

· FormOfPayment: форма оплаты за парковку;

· isWomanParking: является ли парковка специализированной (только для женщин).

Развертывание приложения

Рис. 25. Диаграмма развертывания

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

Имеется узел «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.

Заключение

В рамках данной работы был разработан модуль для навигационной системы в автомобиле с использованием SOA-платформы WSO2.

В ходе реализации были решены следующие задачи:

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

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

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

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

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

1. Craig Walls. Spring in Action. Third Edition.- Manning, 2011. -426 с.

2. Рик Робинсон. Статья. Сценарии и решения использования шины Enterprise Service Bus в сервис-ориентированной архитектуре, 2011.

3. Васильев А.Н. Java. Объектно-ориентированное программирование. – Питер, 2011. -400 с.

4. Герберт Шилдт. Java. Полное руководство. 8-е издание. - Manning, 2012. – 1104 с.

5. Брюс У. Перри. Java сервлеты и JSP. Сборник рецептов. – O'Reilly, 2006. – 768 c.

6. Хабиббулин И. Создание распределенных приложений на Java 2. – Мастер, 2002. – 704 с.

7. Блинов И. Н., Романчик В. С. Java. Промышленное программирование. – Универсал Пресс, 2007. – 704 с.

8. Брюс Эккель. Философия Java. – Питер, 2009. – 640 с.

9. Гранд М. Шаблоны проектирования в JAVA. Каталог популярных шаблонов проектирования, проиллюстрированных при помощи UML. - O'Reilly, 2004. - 559 с.

10. Дэвид М. Герц. Java Server Pages. Библиотека профессионала. – Sun, 2002. – 448 c.

11. Флэнаган Дэвид. Java в примерах. Справочник. – O'Reilly, 2003. –

664 с.

12. Марти Холл. Программирование для 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/

18. Maven Reference Documentation –

http://maven.apache.org/

19. Антон Дмитров. Сервисно-ориентированная архитектура в современных моделях бизнеса. – BHV, 2006. – 224 с.

20. Michael Bell. Service–Oriented Modeling (SOA) . – O'Reilly, 2008. –

384 с.

21. James Bean. SOA and Web Services Interface Design. – O'Reilly, 2010. –

384 с.

22. Frank Cohen. Fast SOA. – Sun, 2010. – 296 с.

23. Dan Woods. Enterprise SOA. – Manning, 2006. – 452 с.

24. Eric Newcomer. Understanding SOA with Web Services (Independent Technology Guides). – Sun, 2004. – 408 с.

25. Michael Rosen. Applied SOA. – Manning, 2008. – 696 с.