Общее назначение системы.

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

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

Система имеет следующие составные части:

• Основная база данных
• Интерфейс администратора
• Интерфейс клиента
• Утилита циклического обслуживания базы
• Плагины сбора статистики и передачи команд управления
• Удаленные агенты

Система построена по принципу циклической обработки. При такой схеме в Вашем сервере нет ни одной постоянно запущенной программы. Обработка статистики, управление, выдача информации администратору или клиенту происходит при вызове соответствующих утилит. Интерфейсы администратора и клиента созданы в виде web-приложений. Остальные компоненты являются обыкновенными программами. Цикличность обработки результатов обеспечивается периодическим вызовом необходимых утилит из системного планировщика задач (crond).

Основные функциональные модули системы имеют следующие возможности:

1. База клиентов, разделенных на группы
   
• Персональная учетная запись клиента, содержащая набор необходимой информации о клиенте - имя, адрес, телефон и т.д.
• Перечень зарегистрированных за клиентом ресурсов. Каждый ресурс включает идентификатор этого ресурса (например, login), название сервиса, возможный параметр ресурса (IP адрес, e-mail, domain, virtual host и т.д.), тариф, по которому ведется начисление оплаты.
• Статистика использования ресурса в случае, если такая статистика является частью предоставляемого сервиса.
• Кредитная история клиента, содержащая все операции для данного клиента, такие, как начисления, внесение оплаты, комментарии и т.д.
2. База сервисов
• Общее описание сервиса
• Техническое описание сервиса и параметры плагина для сбора статистической информации
• Список всех ресурсов сервиса, включая неактивные и удаленные
• Список всех тарифов, определенных для данного сервиса
• Общая статистика для данного сервиса с детализацией по ресурсам, либо по дням
3. Дополнительные данные
• База администраторов с разделением полномочий
• Конфигурация системы с описанием валютной базы системы
• Блок накопления суммарной информации по всем платежам системы
• Блок шаблонов для страниц интерфейса клиента
• Блок страниц контекстной помощи администратору
• Регистрационная база активности администратора и клиента (log file)
• Модуль пополнения счета при помощи предоплаченных карт

Отличительные особенности системы.

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

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

В результате формализации возникла вторая концепция системы. Любые учетные и управляющие процедуры представлены в системе исключительно в финансовом эквиваленте. Таким образом, любая форма обслуживания выражается исключительно категориями финансов. Например, входящая в пакет бесплатная квота (например мегабайт при кабельном подключении к интернету) должна быть определена в ее финансовом эквиваленте. С точки зрения логики совершенно неверно смешивать в такого рода системах разно-размерные величины, такие, как деньги, минуты, литры, мегабайты и т.п. Разумеется, что в интерфейсах система показывает соответствующие величины в привычном виде, переводя их из финансового представление в количественное.

Еще одной базовой концепцией системы является понимание того, что любой клиент - это никак не логин, и не IP адрес (чем грешат 99% подобного рода продуктов). Клиент - это человек с кошельком, которого Вы обслуживаете, и которому продаете набор услуг. Именно поэтому в системе создана независимая структура учета клиентов, и регистрируемых за клиентом определенных ресурсов. Как результат, в системе могут быть зарегистрированы клиенты, не имеющие ни одного ресурса, так же, как могут существовать ресурсы, незакрепленные ни за каким клиентом. Это позволило сделать очень гибкую структуру, снимающую любое ограничение на перечень услуг оказываемых клиенту, на изменение этого перечня, и даже передачи каких-либо услуг от одного клиента другому. При таких изменениях никакая другая информация в системе не нарушается.

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

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

Тарифная подсистема имеет ряд интересных особенностей. Для каждого сервиса определяется свой набор тарифов, имеющих разные категории (публичный, специальный). Каждый тариф может описать различную стоимость любого кванта услуги для каждого из 24-х часа суток. При этом для специально обозначенных дней можно определять собственную линейку цен (например выходные дни, или какие-либо отдельные праздники). Помимо этого тариф позволяет определить фиксированную абонентскую плату, распределяемую равномерно в течении месяца, и неоплачиваемую квоту, выраженную в денежном эквиваленте.

Примечательной особенностью системы является отсутствие каких-либо ограничений на количество зарегистрированных пользователей, групп, сервисов, ресурсов и т.п. (в полной коммерческой версии). Единственное программное ограничение имеет количество тарифов для каждого сервиса - не более 100 млн. Разумеется, что физические характеристики сервера накладывают свои ограничения.

Структура системы и взаимодействие ее составных частей.

На рисунке ниже представлена упрощенная структурная схема системы.

Как видно из рисунка, базовая система установлена на одном сервере. Основной системы является "Основная база" (на рисунке обозначена зеленым квадратом). Эта база является основным хранилищем всех данных, используемых в системе.

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

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

Развитие системы.

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

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

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