• jimbot.core - содержит активатор бандла и коннекторы сервисов. Название пакета отличается от общепринятого из-за того, что этот пакет не нужно экспортировать для других бандлов.
  
• ru.jimbot - несколько общих классов, которые я не смог отнести к другим пакетам. Самые важные из них: MainConfig и Manager.
  
• ru.jimbot.core - тут собраны общие классы, которые должны быть использованы при работе других бандлов. Часть из классов абстрактные и должны быть расширены.
  
• ru.jimbot.core.api - тут собраны все интерфейсы, которые должны реализовываться бандлами.
  
• ru.jimbot.core.events - в данном пакете содержатся классы событий. Я планирую переделать систему коммуникации между частями бота, т.к. в OSGi есть собственные средства обмена сообщениями и событиями между бандлами, но с этим еще предстоит разбираться.
  
• ru.jimbot.db - содержит общие абстрактные классы для работы с БД. Возможно, они тоже будут переписаны.
  
• ru.jimbot.utils - некоторые сервисные классы, реализующие функции общего назначения.
  

Посмотрим что происходит в активаторе бандла.

Создаются два объекта: ServicesConnector и ProtocolConnector, в которые передается контекст бандла. Назначение коннекторов - следить за подключением бандлов, реализующих новые сервисы бота и протоколы.

А вот дальше происходит попытка запуска ботов посредством Manager. Это место предстоит переделать - потому как не факт, что в этот момент все бандлы сервисов и протоколов будут установлены и запущены.

Пару слов о терминологии. В боте и в OSGi имеется понятие сервиса. Чтобы не путаться, когда это не очевидно из контекста, я буду конкретизировать "сервис бота", или "сервис OSGi".

Сервисы бота и новые протоколы IM регистрируются в Manager следующим образом. Бандлы, их реализующие, регистрируют при запуске новые сервисы OSGi. Эти сервисы реализуют соответствующие интерфейсы IServiceBuilder и IProtocolManager. С помощью этих билдеров в нужный момент создается конкретная реализация сервиса бота (по его имени) или конкретная реализация протокола (с указанием уина и пароля).

Класс MainConfig реализует паттерн singleton и претставляет собой ява-бин. Реализация настроек в виде бина, на мой взгляд, позволит мне жестче контролировать изменение настроек бота - в случае ошибок я сразу увижу проблему на этапе компиляции. Сохранение настроек на диске происходит путем сериализации бина в XML. Класс MainConfigBeanInfo содержит информацию для редактора конфига в админке. Редактирование бинов в админке происходит при помощи библиотеки Commons BeanUtils.

Класс Manager также является singleton, и служит, как и раньше, главным средством управления ботом.

Класс ChronoMaster используется для запуска в боте периодически повторяемых задач. Например, можно чистить раз в сутки базу данных. Запускаемые задачи должны реализовывать интерфейс Task.

Класс Message представляет собой отправляемое или принимаемое по каналам IM сообщение.

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

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

Класс UserContext реализует понятие сессии пользователя бота. Служит для дальнейшего развития идеи интерактивных команд - когда общение бота и пользователя идет в едином информационном пространстве независимо от остальных пользователей. Класс ContextManager управляет текущими сессиями бота.

Перейдем к рассмотрению интерфейсов.

Интерфейс Command описывает отдельную команду бота. Существуют методы инициализации и уничтожения команды для создания и удаления необходимых ресурсов. Команда сама должна проверять необходимые полномочия, выдавать паттерн команды, выдавать справку. Все команды в боте хранятся в виде пар <паттерн, объект команды>. Скрипты при запуске должны теперь создавать новые объекты команд - поэтому скорость выполнения скомпилированных модулей и скриптов отличаться не будет.

Остается открытым вопрос использования псевдонимов команд (так называемых "русификаций") - сложность возникает при инициализации и уничтожении в момент обновления скриптов, а так же хранении объектов. Так что интерфейс и логика работы с командами в боте может еще значительно поменяться.

Абстрактный класс DefaultCommand реализует некоторые методы интерфейса Command. Если вы будете расширять его, вам не придется выполнять некоторые рутинные операции для простых команд.

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

Интерфейс Protocol описывает как должна выглядеть реализация протокола IM.

Интерфейс Service описывает сервис бота. А интерфейс ServiceConfig - обязательные параметры бина конфигурации любого сервиса. В остальном в конфиге сервиса можно добавлять любые данные.

Абстрактный класс DefaultService реализует некоторые методы интерфейса Service, в частности - регистрацию слушателей.

Сами интерфейсы слушателей, думаю, описывать не стоит, с ними и так все понятно.

Бандл, в котором создаются новые команды бота, должен реализовать интерфейс ICommandBuilder. Это происходит в сервисе OSGi, регистрируемом таким бандлом.

Интерфейс IProtocolBuilder описывает создание нового экземпляра протокола. Позволяет при создании указывать только часть параметров, оставляя для остальных значения по умолчанию.

Остальное, думаю, и так понятно из комментариев.

На сегодня все. Продолжение следует...

Автор статьи: Spec (jimbot.ru & Forum.JimBot)

С уважением, DeadInside
Dark ICQ-Chat : 555585550