Аннотация 2
ВВЕДЕНИЕ 3
1 СЕРВЕР ПРИЛОЖЕНИЙ IAS 5
2 СПЕЦИФИКАЦИЯ JMS 7
2.1 Архитектура 7
2.2 Модели доставки сообщений 7
2.3 Сообщение в JMS 8
2.4 Отправка и получение сообщений 8
2.5 Создание поставщика JMS-клиентом 9
2.6 Создание получателя JMS-клиентом 10
2.7 Синхронное и асинхронное потребление сообщений 11
2.8 Надежный обмен сообщениями 11
3 ОПРЕДЕЛЕНИЕ ТРЕБОВАНИЙ К ПОДСИСТЕМЕ 13
3.1 Функциональные требований 13
3.2 Нефункциональные требований 13
4 ПРОЕКТИРОВАНИЕ 16
4.1 Проектирование клиента 18
4.2 Проектирование сервера 22
4.3 Проектирование общего компонента 27
4.4 Проектирование компонента общения между сервером и клиентом 32
5 РЕАЛИЗАЦИЯ 33
5.1 MS.Client 33
5.2 MS.Server 35
5.3 MS.Communication 41
6 РАБОТА ПОДСИСТЕМЫ СООБЩЕНИЙ MS 44
ЗАКЛЮЧЕНИЕ 45
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ И ЛИТЕРАТУРЫ 48
ПРИЛОЖЕНИЕ А Акт о внедрении 50
Программисты решают множество разновидных задач, все эти задачи можно поделить на какие-то типы или виды. Также можно столкнуться с задачей отправки и получения данных с одного приложение в другое.
Есть множество решений отправки таких данных. Это своеобразный мостик, через который можно отсылать данные. Видов таких мостиков много. Можно, например, отправлять данные через http [1], или использовать для этого websocket [2]. Все это можно назвать “транспортом” для данных. Мы просто передаём данные с одного места в другое.
Но что делать когда данных становится много? А что делать, когда мест куда и когда надо отправить данные тоже становится много? На помощь приходят так называемые брокеры сообщений [3]. Они как раз и помогают рассылать данные в необходимые места, и делать при этом гарантии доставки. Это уже не просто “транспорт” - это целая магистраль, в которой все знают когда, где и куда отправить или получить данные.
Это сложный механизм, который нуждается в постоянной поддержке и в чуткой настройке. Есть множество решений, которые решают эту проблему: kafka [4], RabbitMQ [5] и другие. Все брокеры [3] решают одну проблему, но по-разному. У каждого есть свои достоинства и недостатки.
При разработке сервиса приложений IAS было решено разработать своего брокера сообщений [3] для своих нужд. Это связанно с тем, чтобы было меньше зависимостей от стороннего программного обеспечения. Чтобы не приходилось поддерживать кодовую базу при обновлениях брокера сообщений [3]. Чтобы не приходилось ждать исправления ошибок в следующем обновлении. Нужен такой брокер сообщений [3], который будет покрывать все необходимые задачи, при этом интеграция не нуждался бы в поддержке, а также легко развертывался и запускался в новой системе. Все это и сыграло в пользу написания своего брокера сообщений [3].
Так как IAS - сервер приложений, в котором и будет работать написанный брокер сообщений [3], основан на идеях JBoss Application Server, то для написания брокера сообщений [3] возьмем спецификацию JMS [6].
Чтобы написать брокера сообщений [3] для сервера приложений IAS основывая на спецификацию JMS [6] необходимо решить следующие задачи:
1. Изучить функциональность сервера приложений IAS;
2. Изучить принципы работы JMS [6];
3. Определить требования к подсистеме сообщений;
4. Спроектировать подсистему сообщений;
5. Реализовать подсистему сообщений.
Целью работы является разработка подсистемы сообщений для сервера приложений IAS.
Процесс разработки делиться на этапы:
1. Выявление требований;
2. Знакомство с JMS [6];
3. Проектирование подсистемы;
4. Реализация подсистемы.
На первом этапе были выявлены основные и дополнительные требования, предъявляемые к подсистеме. А именно были выявлены функциональные и нефункциональные требования.
Функциональные требования:
1. Отправить данные;
2. Получить данные.
Нефункциональные требования:
1. Протокол передачи данных;
2. Гарантированность;
3. Надёжность;
4. Масштабируемость;
5. Используемые технологии.
Затем была выбран стандарт JMS [6]. В работе описываются принципы и идеи работы JMS [6]. Основные объекты JMS [6]:
1. Connection;
2. Session;
3. Producer;
4. Consumer;
5. MessageListner.
6. Destination:
a. Topic;
b. Queue.
На следующем этапе была спроектирована подсистема сообщений на основе выявленных требований, а именно спроектирована работа подсистемы в имеющейся архитектуре сервера приложений IAS. А, так же подсистема разбилась на пакеты:
• MS.Client:
o IConnection;
o ISession;
o IProducer;
o IConsumer;
o IMessageListner.
• MS.Server:
o Destination;
o IServerConsumer;
o IRestoreMenager;
o IDestinationMessage;
o IConnectionMessage.
• MS.Common:
o Message;
o IConnectionServerProducer;
o IConnectionServerConsumer;
o IConnectionClientProducer;
o IConnectionClientConsumer.
• Ms.Communication.
Затем на этапе реализации были реализованы объекты на основе спроектированных интерфейсов. Получившиеся пакеты:
• MS.Client:
o Connection;
o Session;
o Producer;
o Consumer.
• MS.Server:
o Topic;
o Queue;
o ServerConsumer;
o RestoreMenager;
o DestinationMessage;
o ConnectionMessage;
o ServerConnection.
• MS.Common;
• Ms.Communication:
o Local:
■ LocalConnectionFactory;
■ LocalConnectionServerProducer;
■ LocalConnectionServerConsumer;
■ LocalConnectionClientProducer;
■ LocalConnectionClientConsumer.
o ClientContext:
■ ClientContextConnectionFactory;
■ ClientContextConnectionServerProducer;
■ ClientContextConnectionServerConsumer;
■ ClientContextConnectionClientProducer;
■ ClientContextConnectionClientConsumer.
Подсистема сообщений была внедрена в сервер приложений IAS. Акт о внедрении представлен в приложении А.
Таким образом, подводя итог всех работ, которые были проведены для выполнения целей и задач, можно сделать вывод о том, что цель была достигнута, а все задачи были выполнены.
