Создание системы обмена мгновенными сообщениями

Сервер постоянно прослушивает канал, и когда он обнаруживает подключение  клиента, то он создает новый экземпляр  класса, который расширяет Java-класс Thread и переопределяет метод run(), который создает отдельный поток для каждого клиента. Таким образом, количество клиентов подключаемых к нашему серверу будет ограничено только пропускной способностью сети и производительностью сервера.

Когда администратор запускает  сервер, после запуска он увидит перед собой обычное окно (рис. 3.1).

 

Рис. 3.1. Запуск серверного приложения.

А пользователь, в свою очередь, увидит перед собой следующее окно (рис. 3.2).

Рис. 3.2. Главное окно клиентского  приложения.

В самом верху находится поле для ввода логина пользователя. Если пользователь первый раз вошел в  этот чат, то по нажатии кнопки “Log In” сервер сам зарегистрирует нового пользователя.

 

Рис. 3.3. Главное окно чата после авторизации.

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

Рис. 3.4. Отправленное сообщение другому  пользователю.

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

Рис. 3.5. Переписка с пользователями.

Что касается подключения к серверу, все настройки хранятся в  XML файле server.xml, представляющий следующий структуру данных:

<?xml version="1.0" encoding="utf-8"?>

<server>

<host>77.120.203.3</host>

<port>8085</port>

</server>

Подобным образом хранятся и настройки подключения к базе данных:

<?xml version="1.0" encoding="utf-8"?>

<datasource>

<source-name>Oracle</source-name>

<connection-url>jdbc:oracle:thin:@localhost:1521:xe</connection-url>

<driver-class>oracle.jdbc.driver.OracleDriver</driver-class>

<user-name>SYSTEM</user-name>

<password>1</password>

</datasource>

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

<xml version=\"1.0\" encoding=\"utf-8\"?>

<message>

<from>Отправитель</from>

<to>Получатель</to>

<text>Текст сообщения</text>

</message>

История переписки в таблице Logs выглядит как на рис. 3.6. А список пользователей в таблице Users на рис. 3.7 соответственно.

 

Рис. 3.6. История переписки в базе данных.

 

Рис. 3.7. Список пользователей в  базе данных.

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

3.1. Построение диаграммы вариантов использования.

На первом этапе предпроэктного исследования выяснено, что основная задача разрабатываемой системы  – сопровождение процесса.

 

Рис. 3.1.1. Диаграмма вариантов использования.

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

Следующим шагом пользователя, после  процесса авторизации (регистрации) будет  отправка и получение сообщений. Сообщения будут предварительно приниматься сервером от отправителя, в виде XML пакетов, парситься протоколом, логироваться в сервер базы данных, и перенаправляться на получателя в виде XML пакета, после чего клиентская программа распарсит сообщение и выведет отправителя и текст сообщения на экран, в читабельном для пользователя виде.

3.2. Диаграмма последовательности  действий

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

Рис. 3.2.1. Диаграмма последовательности действий.

Каждые пять секунд серверное приложение отправляет запрос вместе со списком  пользователей клиентскому сообщению (request), на который клиент должен будет ответить (response), иначе сервер посчитает, что пользователь отключился от сервера или у него проблемы с сетевым подключением. В этом случае сервер отключит клиента и закроет Socket, через который он с ним «общался».  А спустя 5 секунд, с новым запросом, пользователям будет отправлен уже новый список.

 3.3. Построение диаграммы классов

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

Так как в системе обмена мгновенными  сообщениями используется хранилище  данных (SQL server Oracle), то диаграмма классов была спроектирована отдельно для базы данных, клиентского приложения и серверного приложения.

Рис. 3.3.1. Диаграмма классов базы данных.

Из диаграммы классов видно, что существует всего 2 класса, пользователи (Users) и логи (Logs). Отношение между классами «Многие-ко-многим».

 

Рис. 3.3.2 Диаграмма классов клиентского  приложения.

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

Рис. 3.3.3. Диаграмма классов серверного приложения

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

3.4. Проектирование базы данных

Отношения Пользователи и Логи, выявленные на этапе построения концептуальной модели, характеризуются следующими атрибутами (табл. 3.4.1).

Таблица 3.4.1 Атрибуты отношения «Пользователи»

Атрибут	Описание
Логин	Первичный ключ
Адрес	IP-адрес пользователя

 

Отношению «Пользователи» соответствует полная ФЗ: Логин → Адрес. Все поля кроме «Логин» не могут быть первичным ключом.

Таблица 3.4.2 Атрибуты отношения «Логи»

Атрибут	Описание
Отправитель	Внешний ключ отношения «Пользователи»
Получатель   Текст_сообщения	Логин получателя   Текст передаваемого сообщения
Дата_отправки	Дата отправки сообщения

 

Отношение «Логи» играет роль связи «Многие ко Многим», а атрибут  «Отправитель» показывает эту связь.

Анализ функциональных зависимостей, которые имеют место для отношений «Пользователи» и «Логи» показывает, что они полные. Следовательно, универсальное отношение Пользователи – Логи нормализовано.

3.5 Логическая реализация базы  данных

Реализуем таблицу Users. Для идентификации записей введем первичный ключ LOGIN.

Таблица 3.5.1 Обоснование типов полей таблицы Users:

Атрибут	Столбец	Тип данных	Мотивация	Примечание
Логин	LOGIN	VARCHAR(200)	Имя пользователя в чате	Primary Key
Адрес	ADDRESS	VARCHAR2(100)	IP Адрес из 4 октет

 

Реализуем таблицу Users. Здесь у нас присутствует внешний ключ LOGIN, который здесь представлен как FROM.

Таблица 3.5.1 Обоснование типов полей таблицы Users:

Атрибут	Столбец	Тип данных	Мотивация	Примечание
Отправитель	FROM	VARCHAR(200)	Логин отправителя	Foreign Key
Получатель	TO	VARCHAR2(200)	Логин получателя
Текст сообщения	TEXT	VARCHAR2(5000)	Текст передаваемого сообщения
Дата отправки	MESSAGE_DATE	DATE	Дата отправки сообщения

 

Схема базы данных представлена на рис. 3.3.1.

 

Выводы

Сегодня трудно найти компанию, в  которой нет хотя бы несколько  компьютеров, объединённых в общую  локальную сеть. Сеть нужна для  обмена данными, для общего доступа к принтерам, файловому хранилищу, корпоративной СУБД и для многих других вещей. Возникает необходимость создания единой системы обмена сообщениями между сотрудниками компании. 

Необходимо пояснить, почему стоит  использовать систему обмена мгновенными сообщениями, а не ограничиться телефонами, факсами и электронной почтой. Даже если сотрудники находятся в одном офисе. У системы обмена мгновенными сообщениями есть ряд очень серьёзных преимуществ.

Например: 

• Обмен сообщениями сильно экономит рабочее время сотрудников. Одно сообщение с подробным описанием и картинками того, что и как нужно сделать, стоит целого телефонного звонка. И весьма длительного. Это сообщение не потребует дальнейших звонков с уточнениями, как нужно было сделать, ведь оно хранится на компьютере в истории принятых сообщений.
• Отправленные сообщения будут храниться на сервере. И будут доставлены получателю, даже если его нет на рабочем месте. Человеку достаточно только включить свой компьютер и получить их.
• Полученные сообщения никуда не потеряются, а информация в них никогда не будет забыта. Сообщения будут надёжно храниться на сервере. И даже если сотруднику нужно будет прочитать свою историю сообщений в дороге или в другом городе, без доступа к рабочему месту, он сможет это сделать через Интернет, в следующих версиях. Безопасно и быстро.
• Обмен сообщениями позволяет значительно снизить затраты на междугороднюю и сотовую связь. Ведь для этого будет использоваться уже оплаченный Интернет-канал.
• При наличии нескольких филиалов общение между сотрудниками компании значительно упрощается. Нет разницы, сидит собеседник за стенкой, в другой комнате офиса, или в другом городе. Все сообщения передаются и принимаются в реальном времени, мгновенно.

Система обмена сообщениями является одним из самых доступных и востребованных средств общения в Интернете, в корпоративных и локальных сетях. Службы обмена сообщений разделяются на службы обмена сообщениями в режиме оффлайн (почтовые системы E-mail) и службы мгновенных сообщений (Internet Relay Chat и Instant Messaging Service) в режиме онлайн. В службе мгновенных сообщений кроме текстовых сообщений можно передавать, звуковые сигналы, картинки, видео, файлы.

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

Как правило, сети обмена имеют отдельный  сервер (некоторые сети являются децентрализованными), к которому подключаются мессенджеры, и свои протоколы взаимодействия, что и было реализовано в этой работе.

Разработанная система обмена мгновенными сообщениями может использоваться как в домашних сетях, небольших локальных сетях (или больших), так и в сетях малого офиса. Данная система создавалась не в коммерческих целях и может быть использована кем угодно, передачи мгновенных текстовых сообщений. Протокол TCP/IP гарантирует доставку сообщений между клиентами, а всю информацию о переписке сервер хранит в базе данных, что в дальнейшем поможет расширить программа, создать, например, фильтрацию нецензурной лексики и др.

 

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

1. Система обмена мгновенными сообщениями. Энциклопедия. http://ru.wikipedia.org/
2. Официальны сайт ICQ. http://www.icq.com
3. Даты выпуска Windows Messenger из официального блога. http://messengerarchiveblog.wordpress.com/
4. Jabber Inc. http://www.jabber.com
5. Open Real Time messaging system. http://tech.slashdot.org/article.pl?sid=99/01/04/1621211
6. Запись в блоге Питера Сен-Андре. http://stpeter.im/journal/
7. RFC 3920 Протокол. http://tools.ietf.org/html/rfc3920
8. Jabber Software Foundation Renamed to XMPP Standards Foundation. http://xmpp.org/xsf/press/2007-01-16.shtml
9. Skype. Официальная страница. http://www.skype.com/intl/ru/home
10. Статистика использования IM в России и СНГ. http://onlinemonitor.ru
11. Java. http://ru.wikipedia.org/wiki/Java
12. About Java technologies.

 http://www.oracle.com/technetwork/java/index.html

13. Поставщики встроенных СУБД, статья http://oracle.axoft.ru/fordev/advantagesOracle.php
14. XML Технологии в действии. http://ru.wikipedia.org/wiki/XML
15. Понятие реляционной СУБД, энциклопедия. http://ru.wikipedia.org/wiki/%D0%A0%D0%B5%D0%BB%D1%8F%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%B0%D1%8F_%D0%A1%D0%A3%D0%91%D0%94
16. Что такое сокет? Энциклопедия. http://ru.wikipedia.org/Socket
17. Чат для офиса или корпоративная IMS. http://www.nsoft-s.com/mychatarticles/799-chat-dlia-ofisa-ili-korporativnaia-sistema-im.html